Bus Factor: что произойдёт, если самый важный разработчик завтра исчезнет

В команде есть разработчик, который знает всё про платежи.

Любой сложный баг идёт к нему. Любое изменение API ревьюит он. На любой вопрос ответ: «Спроси Васю».

Кажется, у команды есть сильный эксперт.

На самом деле у неё ещё есть single point of failure.

Bus Factor показывает, сколько людей должно внезапно выпасть из работы, чтобы команда потеряла критичные знания и не смогла нормально продолжать проект.

Если без Васи нельзя безопасно изменить платежи, разобраться с инцидентом или выпустить релиз, Bus Factor этой области равен единице.

Сам по себе сильный эксперт — не проблема. Наоборот, глубокая экспертиза нужна команде.

Проблема начинается, когда знания эксперта не превращаются в знания системы.

Признаки обычно хорошо заметны:

— только один человек понимает, почему архитектура устроена именно так; — его approval фактически обязателен для каждого изменения; — во время его отпуска задачи встают или откладываются; — документация заканчивается на «там всё понятно из кода»; — остальные разработчики избегают области, потому что дешевле дождаться эксперта; — после инцидента объяснение остаётся в созвоне и нигде не фиксируется.

Так появляется knowledge silo — область знаний, доступная одному человеку или узкой группе.

При этом формально ownership есть. Фактически это не владение системой, а монополия на её обслуживание.

Что можно сделать?

Разделять code ownership. У критичной области должен быть основной владелец, но не единственный человек, способный внести изменение. Полезная проверка: кто примет решение, если владелец недоступен две недели?

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

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

Использовать shadowing. Разработчик сначала наблюдает за работой эксперта, потом выполняет похожую задачу вместе с ним, а затем делает её самостоятельно под наблюдением. Просто посидеть на одном созвоне рядом недостаточно.

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

При этом «пусть Вася обучит всех» — тоже не стратегия.

Во-первых, Вася становится ещё большим bottleneck: теперь он одновременно разрабатывает, ревьюит, отвечает на вопросы и ведёт внутренний университет.

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

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

И важное ограничение: снижать Bus Factor — не значит делать всех взаимозаменяемыми.

Не нужно, чтобы каждый разработчик знал всё про каждый сервис. Это дорого и почти невозможно.

Цель проще: критичная область не должна зависеть от доступности одного человека.

Сильный эксперт усиливает команду, когда рядом с ним растут другие владельцы. Если же без него останавливается работа, это уже не только экспертиза.

Это организационный риск.

В какой области вашей системы ответ на большинство вопросов до сих пор звучит как «спроси Васю»?