Почему один незаменимый сотрудник может обрушить проект

В разработке и управлении проектами есть метрика с мрачноватым названием «Фактор автобуса» (Bus Factor). Она измеряет не количество жертв, а количество незаменимых людей, пишет Financial Times.

Фактор автобуса - это минимальное число ключевых участников, которые должны внезапно выпасть из проекта, чтобы он остановился из-за нехватки знаний или компетенции.

Название пошло от гипотетического вопроса: «А если ключевого разработчика собьет автобус?» Под «автобусом» понимается любое событие, из-за которого человек исчезает из проекта: болезнь, увольнение, рождение ребенка, выгорание .

Чем ниже число - тем выше риск. Фактор автобуса равный 1 означает, что есть один человек, который знает что-то критически важное. Если он исчезнет, то все встанет.

Насколько это распространено

Исследование 2015 года проанализировало 133 популярных проекта на GitHub. Результаты показали масштаб проблемы:

 

34% проектов имели фактор автобуса, равный 1

 

31% проектов - фактор, равный 2

 

В совокупности 65% проектов имели фактор 2 или ниже 

То есть почти две трети популярных open-source проектов могли остановиться, если бы всего два человека перестали вносить вклад.

Для сравнения: у ядра Linux фактор автобуса составил 57. Это означает, что для остановки проекта должны выпасть 57 ключевых разработчиков одновременно - практически невозможно.

Низкий фактор автобуса создает структурную хрупкость. Компания или проект зависят от одного человека не потому, что он лучший, а потому что знание не распределено.

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

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

Как это исправляют

Чтобы повысить фактор автобуса, компании и команды используют несколько практических подходов. Первый — документирование процессов. Знание не должно жить только в голове одного человека. В исследовании 2015 года разработчики сами назвали документацию главным способом смягчить потерю ключевых авторов. Если процесс описан, новый человек может его подхватить, а не восстанавливать с нуля.

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

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

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

Фото из открытых источников