Представь, Бро. У тебя в команде есть один человек, который держит в голове все тонкости проекта. Архитектура — его. Сборки — его. Логика в бекенде, деплой, связи между модулями — тоже он. Всё работает идеально, пока он рядом. Но стоит ему уйти в отпуск, заболеть или, как говорится, попасть под автобус — и всё, команда в ауте, сроки летят, клиенты в шоке.
Это и есть тот самый bus‑фактор. В этой статье разберём, почему это не круто, как он возникает, почему так распространён, и главное — как его снизить. Поделюсь личными кейсами, проверенными практиками и нетривиальными приёмами, которые реально работают. Без воды, честно и с примерами из боевого менеджмента.
Что такое bus-фактор: объяснение на пальцах
Bus‑фактор — это метрика, которая показывает, сколько людей можно потерять, прежде чем проект загнётся. Чем он ниже, тем выше риски. Если у тебя bus‑фактор = 1 — ты зависишь от одного человека. А если он выпадает, проект можно заворачивать.
Но давай без академичности. Вот аналогия:
Ты участвуешь в командной игре — например, на выживании в лесу. И у вас один игрок знает, как разводить огонь, строить укрытие и находить еду. Все остальные просто ходят за ним. В какой‑то момент его сбивает медведь. Всё. Группа погибает не от холода, а от того, что знание не было распределено.
То же и с командами. Уязвимость не в человеке — а в системе, где без него никто не может продолжить движение.
Признаки высокого bus-фактора
Всё кажется нормальным. Но вот ты читаешь это и ловишь флешбеки:
Уходит один сотрудник — и больше никто не может починить CI.
Никто, кроме Лёхи, не знает, как работает биллинг.
Документации нет, потому что «всё и так понятно».
Новичок не может развернуть проект без звонка «главному».
Это и есть симптомы bus‑фактора. Особенно коварно то, что часто такие люди — самые надёжные. Они сами на себя всё тянут, им проще сделать, чем объяснять. И именно поэтому вокруг них вырастают зоны полной зависимости.
Почему это случается
Желание контролировать. Кто‑то просто не любит делиться властью. «Я сделаю лучше» → «только я это и делаю» → «без меня тут никто не разберётся».
Нехватка времени. Объяснять дольше, чем сделать. Особенно в горящих спринтах.
Отсутствие процессов. Документация, ревью, передача знаний — не приоритет.
Отсутствие культуры передачи ответственности. Люди боятся делиться зоной, потому что боятся, что станут ненужными.
Или даже банальная хитрость. Кто то цели направленно завязывает всё строго на себя.
Как понижать bus-фактор без боли и революций
1. Параллельная интеграция (двойной пилот)
Не надо сажать людей друг другу на шею. Надо делать напарничество. Один ведёт задачу — второй подключается, чтобы разобраться. Это не shadowing, а нормальный спарринг: обсуждают архитектуру, вместе деплоят, вместе фиксируют баги.
Моя практика: в одном проекте по VR мы ввели правило — архитектурно важная задача не считается закрытой, если только один человек в ней разобрался. В итоге часть людей подтянулась по скилам, а ключевые зоны перестали быть точкой риска.
2. Ревизия чужих зон (правило «открой шкаф»)
Есть простой способ проверить, насколько зона закрыта: дай её другому человеку. Пусть попробует сделать там задачу. Если не может — значит, зона обросла «мхом». Надо писать инструкции, чистить код, описывать процессы.
Это как ревизия в армии: если никто не знает, где хранятся патроны, и на складе бардак — в бою вы попали.
(В целом это схоже с первым пунктом, но скажем так мы порой работаем на разных стадиях разработки, поэтому стоит отметить и такую интеграцию)
3. Упрощение входа в проект через ротацию джунов
Есть подход, который редко обсуждают, но он даёт отличный эффект: регулярно ставить джунов или стажёров на разные части проекта. Не чтобы они моментально приносили пользу, а чтобы проверяли, насколько понятна инфраструктура и логика.
Джун — это как лакмусовая бумажка. Если он не может развернуть проект, настроить окружение, понять, что делает модуль — значит, система требует доработки. Потому что если её не может понять обучаемый новичок, то тем более в неё никто не вольётся в экстренной ситуации.
У нас был случай: пришёл новый человек, и на старте потратил три дня, чтобы просто собрать проект. Это был сигнал, что пора перестраивать README, добавить auto‑setup скрипты, обновить инструкции. После этих изменений onboard новых участников сократился с 3 дней до 4 часов.
Такая ротация даёт команде постоянную обратную связь и держит систему в тонусе. А новичкам — реальное понимание архитектуры, не в теории, а в действии.
4. Публичное наследование (оставляй след)
Если делаешь что‑то важное — оставь послание потомкам. Не просто коммит, а короткую запись: «что сделал», «где лежит», «в чём суть». Можно в Notion, Confluence, даже в Telegram‑группу(тут лучше с тегами, а то Бро, ну рили ты запаришься искать). Главное — чтобы это было доступно другим.
Это не про формальность, это про культуру. Ты не обязан писать трактат. Но пара абзацев может спасти проект.
5. Один на один: ван ту ваны как профилактика точки отказа
Если ты лидер или тимлид — не недооцени силу регулярных ван ту ванов. Это не просто формат, где вы обсуждаете задачи и мотивацию. Это ещё и окно, через которое можно увидеть потенциальную зону риска.
На таких встречах часто всплывает, кто перегружен, кто варится в одиночку, кто чувствует себя единственным в команде, кто «тянет всё» и даже не жалуется. А значит — потенциальный bus‑фактор.
Плюс, через такие диалоги ты можешь подкинуть идею делегировать, взять в напарники кого‑то, передать часть знаний. Это мягкая точка входа, без приказов. И, главное, она работает. Потому что люди раскрываются не на ретро, а в личном разговоре.
Кейсы из практики
Один случай, который я не забуду никогда — классика bus‑фактора в бою. Подготовка к релизу, крупный заказчик, всё под таймер. Основной разработчик, который держал на себе весь блок логики и интеграции, попадает в аварию. Реально, не фигура речи. Госпитализация, отключение от процессов, а весь проект — у него в голове и на машине.
Что пришлось делать: срочно подключать другого спеца, менее опытного, чтобы он въехал в архитектуру на лету. Времени на это не было, но выбора тоже. Слепили релиз, но с задержкой. Команда выдохлась, клиент напрягся, и вся история могла закончиться хуже.
Вывод? Простой и жёсткий. Если бы заранее в процесс был вовлечён второй разработчик, хотя бы на уровне ревью и совместных задач, если бы код был нормально задокументирован, — мы бы пережили аварию как штатную ситуацию. А так — это был адреналиновый квест, из которого мы сделали вывод: ключевые зоны не должны быть замкнуты на одном человеке. Теперь по каждому направлению есть минимум два человека, плюс короткие инструкции, плюс вводные сессии для новых ребят. Работает.
Итог:
Bus‑фактор — это не шутка. Если вы всерьёз развиваете продукт, строите команду, планируете масштабироваться — начните с выстраивания системы, где никто не незаменим. Не потому что вы плохие, а потому что это — реальность.
Ваша цель — не убрать ключевых людей, а сделать так, чтобы они могли спокойно уйти в отпуск. Чтобы они были уверены, что за их зоной кто‑то присмотрит. И чтобы проект не останавливался, даже если кто‑то выпадет.
Короче, Бро: делись знаниями, строй культуру прозрачности и не строй бизнес вокруг одного героя. Геройство — это круто, но системность — выигрывает в долгую.
(Ребят, если кто то дочитал до сюда, буду признателен если в комментах поделитесь своими кейсами, это рили полезно)
