Ключевой разработчик написал заявление. Тот самый. Который знает всю архитектуру. На котором держатся три критических сервиса. Который единственный понимает, как работает система платежей, написанная четыре года назад.
Директор по разработке позвонил мне в панике: “Что делать? Он незаменим.”
Я ответил: “Нет незаменимых. Есть те, чьим уходом вы не управляли.”
Он не поверил. Через три месяца — поверил.
Первый месяц: ад
Не буду приукрашивать — первый месяц был адом. Разработчик ушёл, и в первую же неделю посыпались баги в платёжном сервисе. Никто не знал, как он устроен. Документации не было — вернее, была, но написанная два года назад и не обновлявшаяся.
Продакшн падал дважды. Один раз — на четыре часа. Клиенты звонили, менеджеры паниковали, CEO вызвал на ковёр. Классический сценарий, который снится руководителям в кошмарах.
Команда работала по ночам. Разбирались в коде, который писал один человек на протяжении четырёх лет. Код был хороший — но он был написан одним человеком, под его логику мышления, с его соглашениями по именованию, с его подходом к обработке ошибок. Для остальных это был иностранный язык.
На третьей неделе один из разработчиков признался: “Я чувствую себя идиотом. Смотрю на этот код и не понимаю, что происходит.” Он не идиот. Просто четыре года знание копилось в одной голове и не распределялось.
Второй месяц: стабилизация
Ко второму месяцу команда начала разбираться. Не полностью, но достаточно, чтобы тушить пожары без ночных смен. Появилось базовое понимание архитектуры. Начали писать документацию — не ту формальную, которую никто не читает, а рабочую: что где лежит, как что связано, какие есть подводные камни.
Произошла интересная вещь. Разработчики, которые раньше не лезли в платёжный сервис (“это территория Андрея”), начали в нём разбираться. И обнаружили вещи, которые их удивили.
Костыли, которые ставились как временные решения три года назад и остались навсегда. Участки кода, которые можно упростить в десять раз. Архитектурные решения, которые имели смысл тогда, но не имеют смысла сейчас.
Один человек не видит собственных слепых зон. Когда вы годами работаете с одной системой — вы перестаёте видеть её недостатки. Они становятся нормой. “Так исторически сложилось.”
Третий месяц: рост
К третьему месяцу произошло то, чего никто не ожидал. Команда не просто разобралась в системе — она начала её улучшать.
Переписали модуль обработки ошибок — стало в три раза меньше ложных срабатываний мониторинга. Рефакторнули API платёжного шлюза — упростили интеграцию, которая раньше занимала неделю, до двух дней. Начали закрывать технический долг, который копился годами.
И что важнее — знание распределилось. Теперь три человека понимали систему платежей, а не один. Появились ревью кода, парное программирование, регулярные архитектурные разборы. Не потому что кто-то заставил — а потому что все пережили боль и не хотели повторения.
Через три месяца система работала стабильнее, чем при “незаменимом” сотруднике. Не потому что он был плохим разработчиком — он был отличным. А потому что система, которую понимают трое, надёжнее системы, которую понимает один.
Чему эта история учит
Урок первый: “незаменимый сотрудник” — это симптом управленческой проблемы. Если один человек является единственным носителем критических знаний — это не его заслуга. Это ваш провал как руководителя. Вы допустили ситуацию, в которой компания зависит от одного человека.
Урок второй: кризис — это возможность. Да, это затёртая фраза. Но в данном случае она буквально верна. Уход ключевого человека заставил команду сделать то, что нужно было сделать давно: разобраться в критической системе, распределить знания, навести порядок в коде.
Урок третий: люди растут, когда им дают пространство. Пока “незаменимый” был на месте, остальные не развивались в этом направлении. Зачем, если Андрей всё сделает? Когда Андрея не стало — люди выросли. Не все и не сразу, но выросли.
Что делать, чтобы не попасть в эту ситуацию
Проведите аудит. Прямо сейчас спросите себя: если завтра уйдёт ваш ключевой разработчик, что произойдёт? Если ответ “ничего страшного” — поздравляю, у вас хорошо распределены знания. Если ответ “всё сломается” — у вас проблема, и она не в человеке, а в системе.
Распределяйте знания принудительно. Парное программирование, ротация между проектами, обязательные ревью, внутренние tech talks. Это стоит времени и денег. Но дешевле, чем месяц в аду после ухода ключевого человека.
Документируйте не “для галочки”, а для следующего разработчика. Представьте, что завтра в команду придёт новый человек, который ничего не знает о вашей системе. Сможет ли он разобраться по вашей документации? Если нет — документация бесполезна.
И перестаньте называть людей “незаменимыми”. Это не комплимент — это диагноз. Диагноз вашей системы управления знаниями.
Потерять ключевого человека больно. Но это боль роста, а не боль разрушения.