Специалист по интеграции ушёл в отпуск в пятницу. В понедельник обмен с внешней системой отработал частично: часть документов получила ответ, остальные остались в очереди.
В рабочем чате появился вопрос: "Может, просто запустить ещё раз?" Разработчик, назначенный на время отпуска, не стал перезапускать обмен. Внешняя система могла уже принять часть данных, и новая отправка создала бы риск дублей. По журналу понять состояние каждой операции не получалось.
Инструкция в базе знаний была. В ней перечислялись адреса сервисов, методы и порядок штатного запуска. Необходимые права у разработчика тоже были. Но текущая ошибка в штатный сценарий не укладывалась.
Где искать подробный протокол? Какие запросы разрешено повторить? Как восстановить очередь после частичного выполнения? Как оперативно сверить данные на двух сторонах?
Раньше такими сбоями занимался сам эксперт, остальные в детали не погружались. Руководитель видел работающий процесс, инструкцию и сотрудника, назначенного на замену.
Технические причины сбоя здесь вторичны. Важнее, что без эксперта у команды не осталось безопасного следующего шага.
Пока эксперт рядом
Образ «слепой несёт безногого» хорошо показывает взаимодополнение: один участник умеет то, чего не умеет другой. Для проектной группы часто это норма. Один разработчик знает обмены, другой - сложный расчёт. Аналитик помнит исключения бизнес-процесса. Администратор отвечает за серверы и регламентные задания.
Сила такой группы находится не только в отдельных специалистах, но и в связях между ними. Каждый понимает, к кому идти с конкретным вопросом, и не тратит годы на глубокое освоение всех соседних областей.
Пытаться одинаково обучить всех четырём направлениям дорого. Пока сотрудник разбирается в чужой работе, он меньше занимается своей. Редкий навык без практики постепенно теряется. Можно потратить много времени на обучение и всё равно не получить полноценную замену.
Теория транзактивной памяти помогает описать такое распределение экспертизы. Участники специализируются на разных областях, но понимают, кто каким знанием располагает и к кому обращаться в нужной ситуации. Юцин Рен и Линда Арготе обобщили 76 работ. По итогам обзора развитая система распределённого знания была связана с лучшей координацией, обучением и выполнением групповых задач. Команде не требуется хранить одинаковые знания в каждой голове. Польза появляется, когда участники дополняют друг друга и могут быстро получить нужную экспертизу.
Такая система работает, пока нужная экспертиза действительно доступна. Знание «этот обмен ведёт Сергей» помогает, пока Сергея можно позвать.
Само наличие уникальных знаний я бы ещё не называл критической зависимостью. Гораздо важнее, что остаётся у команды на время отсутствия человека. Может ли кто-то продолжить работу?
Резерв есть только на бумаге
Разработчик из начальной сцены несколько раз присутствовал при восстановлении обмена. Он открывал те же формы, смотрел журналы и выполнял команды под руководством эксперта.
На деле сложную часть продолжал выполнять специалист по интеграции. Он замечал необычный ответ сервиса, просил открыть дополнительный лог, сопоставлял идентификаторы и решал, допустимо ли повторять запрос.
Коллега нажимал кнопки и выполнял отдельные действия. Выбор действий оставался у эксперта.
При реальном сбое прежнюю последовательность повторить не удалось. Один документ имел успешный статус, но отсутствовал в целевой системе. Другой вернулся с временной ошибкой. У третьего не было ответа вообще.
Разработчику, назначенному на время отпуска, не требовалось проектировать интеграцию или самостоятельно устранять любой редкий сбой. Его задача была другая: заметить выход за пределы обычного сценария, остановить опасные повторы, собрать данные и выбрать дальнейший маршрут. Но для этого одного присутствия на разборах оказалось мало.
Что не попало в инструкцию
В инструкции можно зафиксировать штатный запуск, адреса сервисов, порядок получения доступа и уже известные ошибки. Но в начальной сцене проблема возникла за пределами штатного маршрута. Нужно было понять, какие операции завершились, что разрешено повторить и как проверить результат.
Бет Бечки изучала совместную работу инженеров, техников и сборщиков на производстве. Каждая группа видела свою часть продукта и последствия ошибок на своём участке. Когда возникала проблема, участники объясняли друг другу, что именно они наблюдают, к чему это приводит в их работе и как предлагаемое решение повлияет на остальные этапы. Такой совместный разбор помогал сформировать общее понимание ситуации и найти решение.
При подготовке замещающего сотрудника происходит нечто похожее. Недостаточно показать, какую форму открыть и какую команду выполнить. Нужно разобрать, на какие признаки смотрит эксперт, почему один вариант считает безопасным, а другой отвергает.
Затем сотрудник проходит похожий сценарий самостоятельно. Если он остановился, фиксируется конкретная причина: нет доступа, не найден подробный журнал, непонятен критерий результата или неизвестно, кому передавать проблему. Такой пробел уже можно исправлять.
Где риск действительно критичен
Представим другой пример. Только один разработчик умеет работать с редким отчетом. Его используют раз в квартал. Доработка может подождать неделю, текущая работа пользователей продолжится, данные не пострадают.
Подготовка полноценной замены в таком случае может оказаться дороже самой задержки. Руководитель вправе оставить эту область одному специалисту и принять последствия его временного отсутствия.
С остановившимся обменом ситуация иная. Очередь растёт, пользователи не получают результат, повторная отправка может создать проблемы. При этом никто не понимает, сколько процесс способен ждать и куда передавать сложный случай.
Джессика Сигел Кристиан и её коллеги изучили 78 команд по четыре человека. Развитая система распределённого знания помогала командам адаптироваться после неожиданной потери участника, но её польза заметно снижалась, когда отсутствовал критичный участник: группе становилось труднее перестроить план действий.
Иными словами, знать, у кого находилась экспертиза, недостаточно. После его ухода команда ещё должна суметь перераспределить хотя бы минимально необходимую часть работы.
В разработке похожую зависимость называют фактором автобуса - числом ключевых участников, после потери которых проект уже не сможет нормально развиваться. Гильерме Авелино и его коллеги оценили этот показатель для 133 открытых проектов. По их расчётам, примерно в двух третях проектов критичными могли оказаться один или два разработчика.
Такая оценка помогает заметить участки, где код долго сосредоточен у небольшого числа авторов. Но сама по себе она ещё не доказывает критическую зависимость.
Поэтому фактор автобуса можно использовать как повод для проверки. Для управленческого решения лучше взять конкретную работу и разобраться, что произойдёт после её остановки.
Карта критической зависимости одного участка
Проводить аудит всей команды необязательно. Для начала достаточно выбрать работу, про которую чаще всего говорят: "Это знает только он".
Формулировка должна быть узкой. Например, "восстановление обмена после частично выполненной отправки", а не поддержка интеграции целиком.
Карта помогает увидеть, какая конкретная работа остановится без специалиста и чего не хватает для её временного восстановления.
- Какая работа зависит от специалиста?
В нашем случае нужно определить состояние отправленных документов и безопасно возобновить обмен. - Что произойдёт во время его отсутствия?
Очередь продолжит расти, пользователи не получат документы, а повторный запуск создаст риск дублей. - Сколько времени есть у команды?
Нужно определить момент, когда задержка начнёт мешать работе, затронет обязательства или приведёт к ущербу. - Что замещающий сотрудник уже способен сделать?
Допустим, он может приостановить регламентное задание, сохранить очередь, определить период сбоя и собрать данные журнала. - Где он застрянет?
Например, не поймёт, какие документы внешняя сторона уже приняла и что разрешено отправить повторно. - Какого минимального резерва достаточно?
Возможно, самостоятельное исправление не требуется. На время отпуска достаточно остановить развитие ошибки, сохранить данные, собрать подробную диагностику и передать её по известному маршруту. - Как проверить готовность?
Сотрудник самостоятельно проходит безопасный сценарий. Эксперт вмешивается только при риске повредить данные.
При заполнении карты может обнаружиться, что сотрудник не знает границу своих полномочий и не умеет проверить результат.
Один тест не подготовит его ко всем возможным сбоям. Зато руководитель увидит, существует ли резерв хотя бы для ожидаемой ситуации.
Что показала проверка
Предположим, замещающий разработчик дошёл до четвёртого пункта карты. Он может приостановить регламентное задание и сохранить очередь. Материалы найдены, но журнал всё равно не позволяет понять состояние документов. Тогда слабое место находится в самой системе. Разработчиков можно сколько угодно учить читать косвенные признаки, хотя разумнее добавить диагностические сообщения и сделать состояние обмена понятнее.
Сложнее, когда сотрудник собрал данные, но не может выбрать между повторной отправкой и ручным восстановлением. Основной специалист разбирает один случай вместе с коллегой, а похожий сценарий тот проходит уже самостоятельно.
Иногда выясняется, что внутренний резерв вообще не нужен. Редкая проблема может подождать возвращения эксперта или быть передана внешней поддержке. Важно заранее знать, сколько допустимо ждать, кому обращаться и какие данные потребуются для начала диагностики.
После заполнения карты должно стать видно, где именно обрывается путь восстановления. Одному участку не хватает доступа, другому - понятного журнала, третьему - сотрудника, который хотя бы раз самостоятельно прошёл нештатный сценарий.
Ответы, которых не хватило в понедельник
Вернёмся к остановившемуся обмену. Команде не требовалось заранее научить второго разработчика устранять любой возможный сбой.
Подробное описание действий должно было находиться в известном месте и быть доступным замещающему сотруднику. Правила повторной отправки - зафиксированы и проверены на безопасном сценарии. Для повреждённой очереди требовался понятный порядок остановки и восстановления. Результат следовало сверять по идентификаторам и статусам обеих систем, а не только по отсутствию новых ошибок в журнале.
Специалист по интеграции мог спокойно оставаться единственным человеком, который глубоко понимает архитектуру обмена и редкие исключения. От команды требовалось оперативно потушить возникший пожар и не допустить возникновение критичных последствий.