Уход ключевого разработчика часто выявляет проблему, которая годами оставалась незаметной: формально модули закреплены за командой, но фактически никто, кроме одного человека, не знает, как они устроены. Truck factor (или bus factor) — это минимальное число участников, потеря которых приведёт к остановке проекта. Чем ниже показатель, тем выше риск. Историю git можно использовать, чтобы оценить концентрацию авторства и заранее увидеть файлы, которые останутся без активного автора.

Что такое truck factor и зачем его считать

Truck factor измеряется в людях. Если для остановки проекта достаточно ухода одного разработчика, фактор равен 1. Если проект продолжит жить после потери двух ключевых участников, но остановится после третьего — фактор равен 3. Показатель не абсолютен: он зависит от критериев «остановки» и от того, какие файлы считать критичными. Но даже приблизительная оценка помогает выявить зоны риска и спланировать передачу знаний.

Считать truck factor стоит перед реорганизацией, при найме и увольнении, а также в регулярном режиме — например, раз в квартал. Это не разовая метрика, а индикатор устойчивости команды.

Методика расчёта по истории git

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

  • Соберите историю изменений. Используйте git log --name-only или аналогичные команды, чтобы получить список файлов и авторов коммитов. Учтите, что один коммит может затрагивать несколько файлов.
  • Отфильтруйте шум. Исключите сгенерированные файлы, зависимости, локализации и документы, которые не влияют на работоспособность продукта. Иначе метрика будет искажена.
  • Определите «владельцев» файла. Для каждого файла посчитайте, кто вносил изменения. Можно использовать порог: например, автор считается значимым, если сделал не менее 5% правок или последний коммит был его. Порог зависит от размера проекта.
  • Смоделируйте уход разработчиков. Начните с самого «нагруженного» автора: если после его удаления из списка у файла не остаётся ни одного значимого владельца, файл считается «осиротевшим». Повторяйте, пока проект не потеряет критическую массу файлов.
  • Зафиксируйте результат. Truck factor — это число разработчиков, после ухода которых доля осиротевших файлов превышает заданный порог (например, 50% или 80%). Порог выбирается исходя из критичности проекта.

Расчёт можно автоматизировать скриптом на Python или с помощью готовых утилит, но важно понимать логику: метрика зависит от выбранных порогов и фильтров. Поэтому результаты разных проектов напрямую сравнивать некорректно.

Типичные ошибки при интерпретации

Даже корректный расчёт легко истолковать неверно. Вот несколько распространённых ошибок:

  • Игнорирование «невидимых» знаний. Разработчик может редко коммитить, но быть единственным, кто понимает архитектуру. Git этого не покажет.
  • Учёт только последних коммитов. Если смотреть лишь на недавнюю историю, можно пропустить авторов, которые заложили основу модуля, но давно не касались кода.
  • Смешивание кода и документации. Файлы README и конфиги могут исказить картину, если их учитывать наравне с бизнес-логикой.
  • Оценка по количеству коммитов, а не по значимости. Частые мелкие правки не равны глубокому владению модулем.
  • Игнорирование парного программирования и ревью. Знания могут распределяться через обсуждения, которые не отражаются в авторстве коммитов.
  • Восприятие метрики как приговора. Низкий truck factor — сигнал к действию, а не доказательство некомпетентности команды.

Например, в проекте с одним ключевым разработчиком расчёт может показать, что после его ухода 97% файлов останутся без владельца. Это не значит, что проект обречён, но указывает на необходимость срочных мер: документации, парного программирования, ротации задач.

Как снизить риски концентрации знаний

Работа с truck factor — это не только измерение, но и управление. Конкретные шаги:

  • Введите обязательные ревью. Каждый значимый коммит должен проходить через второго разработчика. Это распределяет знания и фиксирует решения в обсуждениях.
  • Практикуйте ротацию. Периодически передавайте задачи между участниками, чтобы никто не оставался единственным экспертом по модулю.
  • Документируйте архитектурные решения. Не только «что сделано», но и «почему». Это снижает зависимость от памяти конкретного человека.
  • Проводите сессии передачи знаний. Записывайте короткие видео или встречи, где ключевой разработчик объясняет устройство сложных участков.
  • Автоматизируйте онбординг. Чек-листы и тестовые задачи помогают новым участникам быстрее войти в контекст.

Отдельно стоит учитывать AI-агентов. Если часть кода генерируется автоматически, авторство коммитов может быть размыто, а знания о том, как работает сгенерированный код, — сосредоточены у одного человека. Это усложняет оценку truck factor и требует дополнительных мер: маркировки сгенерированных участков и их обязательного ревью.

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