Bus Factor: когда уход одного человека останавливает продукт

Разработчик, который знал всю архитектуру платёжного модуля, уходит в отпуск на две недели. В первый же день на проде падает интеграция с эквайрингом. Команда часа три читает код, потом пишет ему в мессенджер. Он отвечает с пляжа, но без ноутбука помочь не может. Релиз переносится.

Это не катастрофа. Это просто стоимость Bus Factor = 1 на критическом модуле. Вы только что заплатили за него временем, деньгами и нервами.

Bus Factor (коэффициент автобуса) — минимальное количество людей в команде, которых нужно «убрать» (уволились, заболели, попали под автобус), чтобы проект встал. Если этот коэффициент равен единице, у вас нет команды — у вас есть незаменимый человек с командой вокруг него. Это разные вещи.

Почему умные команды создают Bus Factor = 1

Проблема не в лени и не в плохом менеджменте. Незаменимость возникает как побочный продукт правильных решений — и именно поэтому её так сложно замечать. Когда команда в режиме 0→1 и каждый спринт — это борьба за скорость, специализация выглядит как эффективность. Один человек знает всё про инфраструктуру, другой — про биллинг, третий — про интеграции с внешними API. Задачи летят быстрее, решения принимаются без совещаний. Это работает — до момента, когда кто-то из троих исчезает.

«Мы думали, что у нас сильная команда. Оказалось — у нас сильные одиночки» — паттерн, который воспроизводится на каждом стартапе после первой плановой текучки.

Проблема усугубляется на растущих командах: чем быстрее рост, тем меньше времени на передачу знаний, тем глубже специализация, тем выше концентрация критических знаний у конкретных людей.

Ловушки

01 Незаменимость как признание — ловушка статусного знания

Самый опытный разработчик или PM знает больше всех. Это естественно. Опасно то, что это знание не передаётся — и часто намеренно. Быть единственным, кто понимает, как работает критический модуль, — это форма власти. Не обязательно циничной: просто у человека нет стимула документировать то, что создаёт его ценность. Он не против передачи знаний, он просто всегда занят чем-то более срочным.

Руководители видят загруженность и думают: «человек работает». Никто не смотрит на то, передаётся ли знание вниз или в сторону.

Ключевая метрика: количество задач, которые не могут начаться без конкретного человека (blocker dependency rate). Если в спринте больше 20% задач заблокированы на одном имени — вы уже здесь.

Что произошло. В одном из финтех-стартапов CTO был единственным, кто знал, как работает система лимитов транзакций. Когда он ушёл на другую позицию, команда потратила три месяца на reverse engineering собственного кода. За это время конкурент выпустил аналогичную функцию.

02 Документация для галочки — ловушка мёртвого знания

Интуитивное решение выглядит разумно: попросить всех писать документацию. Создать Confluence, Notion, внутреннюю вики. Поставить это в OKR. Через квартал в базе 200 страниц, которые никто не читает. Половина из них устарела через месяц после написания. Новый разработчик приходит и всё равно идёт спрашивать того же человека, потому что «в доках написано непонятно».

Почему это ломает систему. Документация, написанная тем, кто и так всё знает, пишется с позиции уже имеющегося знания. Она пропускает именно то, что неочевидно снаружи. Читатель без контекста не может по ней восстановить понимание — и идёт к автору.

Настоящая передача знания происходит в действии, а не в тексте. Документ фиксирует что, но не фиксирует почему и как думать в нестандартной ситуации.

Ключевая метрика: time-to-productivity нового человека на задачах критического модуля. Если новый разработчик после онбординга тратит первые три недели в основном на вопросы к одному человеку — документация не работает.

Большинство команд обнаруживают, что их внутренняя база знаний отвечает на вопрос «что было сделано», но не отвечает на вопрос «что делать, когда сломается».

03 Кросс-функциональность на словах — ловушка формальной взаимозаменяемости

Команды знают про Bus Factor. Они говорят: «у нас нет незаменимых людей». На практике кросс-функциональность означает, что формально каждый может сделать всё — но реально вся сложная экспертиза по-прежнему у одного. Это особенно опасно для PM-функции. Продакт-менеджер аккумулирует контекст: историю решений, логику продуктовой стратегии, неформальные договорённости с ключевыми клиентами, понимание того, почему три года назад решили не делать определённую фичу. Когда он уходит, эта история исчезает вместе с ним.

Ключевая метрика: скорость принятия решений после ухода ключевого PM (decision velocity). Если через две недели после его ухода команда начинает переизобретать уже принятые решения или делать ошибки, которых год назад не делала, — контекст не был передан.

Что произошло. Команда B2B SaaS потеряла lead PM, который в одиночку вёл отношения с тремя enterprise-клиентами. Новый PM получил доступ к CRM и переписке. Потребовалось четыре месяца, чтобы восстановить отношения до прежнего уровня. Один клиент за это время перешёл к конкуренту.

04 Уход как вынужденная форс-мажорная ситуация — ловушка реактивного управления

Команды обсуждают Bus Factor только тогда, когда кто-то уже уходит. Человек говорит «я ухожу через месяц» — начинается срочная передача дел, документирование, онбординг. За месяц передаётся 20–30% реального контекста. Остальное потеряно. Проблема не в том, что месяц — это мало. Проблема в том, что знание, накопленное за два года, не передаётся за месяц в принципе. Оно передаётся через совместную работу, постепенно, в реальных рабочих ситуациях.

Реактивное управление Bus Factor создаёт иллюзию контроля — и гарантирует потери при каждой смене состава.

Инвесторы на due diligence часто задают вопрос: «что произойдёт, если ваш CTO завтра скажет, что уходит?». Большинство фаундеров отвечают: «это будет сложно». Правильный ответ: «у нас есть план».

Конкуренция и рыночный контекст

Крупные технологические компании решили эту проблему системно: ротация команд, обязательные ревью кода с передачей контекста, внутренние конференции, где люди рассказывают о своих доменах коллегам. У Spotify, Amazon, Google есть инфраструктура для управления знаниями, которая строилась годами.

Стартап проигрывает крупному игроку в институциональной памяти - но выигрывает в скорости. Проблема в том, что высокий Bus Factor уничтожает именно это преимущество: когда ключевой человек недоступен, стартап останавливается быстрее, чем корпорация.

Где стартап выигрывает - в возможности выстроить культуру передачи знаний с нуля. Корпорация меняет культуру годами. Команда из 8 человек может изменить паттерн работы за квартал, если есть намерение и простые ритуалы.

Цена ошибок

Уход одного PM с Bus Factor = 1 на продукте в стадии активного роста стоит в среднем 3–6 месяцев продуктивности команды. Это не оценка — это накладные расходы: онбординг нового человека (6–10 недель до первого самостоятельного решения), восстановление контекста (ещё 4–8 недель), потеря темпа в переговорах с клиентами и партнёрами.

Уход ключевого разработчика с монопольным знанием критического модуля — это технический долг, который вы только что обнаружили в самый неподходящий момент. Стоимость: от нескольких недель до нескольких месяцев работы команды, в зависимости от сложности домена.

Для стартапа с runway 12 месяцев потеря 3 месяцев продуктивности — это 25% запаса. Не абстрактный риск, а конкретное влияние на следующий раунд или путь к прибыльности.

Что происходит на рынке

Гибридный и удалённый режим работы сделал проблему Bus Factor острее: знание, которое раньше передавалось в коридорных разговорах и совместной работе в одном пространстве, теперь не передаётся вообще. Люди работают асинхронно, контекст накапливается в чатах и доках, которые никто не читает системно.

Рынок труда для сильных продактов и инженеров остаётся конкурентным. Текучка на ключевых позициях — не исключение, а норма. Команды, которые строят устойчивость к уходам людей как системное свойство продукта, проходят смены состава без потери скорости. Те, кто надеется на лояльность — платят каждый раз заново.

Как делать правильно

Измерьте текущий Bus Factor. Пройдите по всем критическим модулям, процессам и отношениям с клиентами. Задайте вопрос: если этот человек завтра недоступен на две недели, что встанет? Запишите ответы. Это ваша карта рисков - честная, без украшений. Критерий успеха: у вас есть список из 5–10 конкретных зон с именами людей и оценкой критичности. Не «всё нормально», а «вот три точки с Bus Factor = 1».
Назначьте вторых владельцев на критические домены. Для каждой зоны с Bus Factor = 1 назначьте «тень» — человека, который начинает погружаться в этот домен прямо сейчас. Не «изучит документацию», а работает рядом с основным владельцем на реальных задачах. Критерий успеха: через шесть недель второй человек может самостоятельно принять решение в нестандартной ситуации в этом домене — и объяснить логику.
Встройте передачу знаний в процессы, а не в ритуалы. Code review как инструмент передачи знания, а не контроля качества. Парная работа на сложных задачах. Внутренние демо, где человек объясняет домен коллегам — не формально, а с ответами на «почему так, а не иначе». Критерий успеха: новый человек в команде за первые четыре недели задаёт вопросы не одному человеку, а нескольким — потому что контекст распределён.
Документируйте решения, а не состояния. Полезная документация — это не «как устроена система», а «почему мы решили сделать так, а не иначе» и «что делать, когда X сломается». Decision log, архитектурные решения с контекстом, runbook для критических сценариев. Критерий успеха: новый разработчик может самостоятельно разобраться в нестандартной ситуации, используя только внутренние документы, без звонка предыдущему владельцу.
Проводите «Fire drills» — плановые симуляции отсутствия. Раз в квартал: ключевой человек на критическом модуле берёт два дня офлайн. Команда работает без него. Это не наказание — это тест системы. По результатам — ретроспектива: где встали, где справились. Критерий успеха: после двух-трёх таких итераций команда перестаёт звонить отсутствующему. Это значит, что знание действительно распределено.
Включите Bus Factor в offboarding. Когда человек говорит, что уходит, у вас есть стандартный план: четыре недели парной работы по его критическим доменам, документирование ключевых решений с объяснением логики, передача отношений с клиентами через совместные звонки, а не через CRM-записи. Критерий успеха: через месяц после ухода команда работает без видимых замедлений. Это проверяемо - сравните velocity до и после.
Измеряйте регулярно. Bus Factor - не проблема, которую можно решить один раз. Команды меняются, домены усложняются, новые зоны концентрации знания возникают постоянно. Ежеквартальный аудит занимает час — и экономит месяцы. Критерий успеха: у вас есть список «наших Bus Factor = 1» и он обновляется каждый квартал. Он никогда не будет пустым — но он должен быть управляемым.

Литература и источники

«The Mythical Man-Month» — Frederick Brooks (1975) Классика, из которой вырос Закон Брукса: добавление людей в опаздывающий проект делает его ещё более опаздывающим. Читать за: понять механику координационных издержек и почему замена человека — не замена знания. Конкретно взять: главу про концептуальную целостность — почему знание одного человека о системе принципиально ценнее коллективного.
An Elegant Puzzle» — Will Larson (2019) Книга инженерного менеджмента от CTO Stripe, Calm и Carta. Читать за: практические паттерны управления знаниями в растущих командах. Конкретно взять: главу про succession planning и раздел про документирование решений как управленческую практику.
«Team Topologies» — Matthew Skelton, Manuel Pais (2019) Фреймворк для проектирования команд вокруг когнитивной нагрузки и потоков знания. Читать за: понять, как структура команды влияет на распределение знания. Конкретно взять: концепцию «cognitive load» как причину концентрации знания у одного человека.
«The DevOps Handbook» — Gene Kim и другие (2016) Откуда пришли Fire drills и Game days — плановые симуляции отказов. Читать за: операционная культура, которая строит устойчивость системно, а не реагирует на инциденты. Конкретно взять: главы про «blameless postmortems» и «chaos engineering» как инструменты управления знанием через практику.
«Accelerate» — Nicole Forsgren, Jez Humble, Gene Kim (2018) Исследование DORA: что реально отличает высокопроизводительные команды от средних. Читать за: данные, а не интуицию. Конкретно взять: связь между распределением знания (pair programming, code review) и deployment frequency — одним из ключевых показателей продуктивности команды.