Fiat Roma, et ubi illa nunc est?
Я ранее писал статью о матрице компетенций, это её логическое продолжение. Очень часто менеджеры на эту матрицу забивают и допускают ситуацию, когда только один сотрудник понимает систему до конца, в его руках сосредоточен деплой, только он понимает все зависимости и хитросплетения продукта. Да, пока он работает, всё хорошо. Но стоит ему заболеть или уйти в отпуск, работа если не встаёт, то очень сильно тормозится.
Давайте глубже погрузимся в тему bus-фактора и разберём, как его снизить:
Определение
Что, вообще, такое, bus-фактор, простыми словами? Это количество людей, которые вы можете потерять, прежде чем работа над проектом встанет и он загнётся. Чем меньше это значение, тем хуже. Наихудший вариант, когда он равен единице.
Признаки высокого bus-фактора
Идентифицировать, что у вас проблема, несложно:
- Как только уходит Серёга, починить проблемы с CI не может никто, даже штатный девопс компании.
- Никто, кроме Васи не понимает, как работает важный кусок системы, поэтому все доработки этого куска идут только ему.
- Техническая документация не ведётся, потому что у нас «самодокументированный код» с комментариями, всё и так понятно.
- Онбординг новичков затруднён, они долгое время после входа в команду, толком не могут ничего реализовать, для каждого чиха приходится звонить старшим товарищам.
Если у вас что-то из этого, время бить тревогу и начинать снижать bus-фактор.
Причины проблемы
- Желание контроля и власти. Ключевые сотрудники не любят делиться властью. «Я сделаю лучше» → «только я это и делаю» → «без меня тут никто не разберётся». Это приятно щекочет эго.
- Нехватка времени. Сроки вечно подгорают, «старичку» проще самому запилить важную фичу или поправить критичный дефект, чем кому-то что-то растолковывать.
- Отсутствие процессов. Работа в команде выставлена по наитию, менеджер и тимлид не озаботились выстраиванием процессов и процедур.
- Отсутствие культуры передачи ответственности. У сотрудника семья и ипотека, он боится, что его уволят, поэтому всеми силами старается держать ответственность на себе.
- Или даже банальная хитрость. Завязать критичные вещи на себя — древний и испытанный способ шантажировать работодателя, требуя повышения зарплаты.
Как снизить bus-фактор
Напарничество
В экстремальном программировании есть такая практика, как парное кодирование, когда два разраба сидят перед одним экраном, один проектирует и командует, а второй кодит. Это, пожалуй, ту матч, но сделать напарничество — не самая плохая идея. Проблема только в том, что не каждом проекте бюджеты могут такое позволять, эта практика больше для продуктовиков.
Ревизия серых зон
Попробуйте попросить разработчика реализовать фичу не в своей части продукта, а в соседней. И если у него это не получится за приемлемые сроки, у вас проблема. Надо обкладывать этот кусок юнит-тестами, комментировать и чистить код, писать документацию, корректировать и выстраивать процессы. И так, пока в продукте не останется «серых зон».
Упрощение входа в проект через реальные задачи новичкам
Буду честен, у меня был проект, на котором бэкенд делал один-единственный джун и это было стрёмно. Но ставить новичков в компании сразу на новые фичи — интересная практика. Если новичок не может, даже с документацией развернуть проект, настроить окружение и разобраться, какой класс и какой модуль за что отвечает, значит, у нас высокий bus-фактор.
Вообще, считается нормой, когда новичок настраивает окружение и разворачивает у себя проект за один рабочий день, а лучше быстрее.
Оставление следов
Хорошая практика — чтобы разрабы обязательно писали пояснительные записки с технической документацией о каждом своём значимом действии. Совершенно необязательно это должно быть в формате университетской курсовой, нет. Пара абзацев в конфлю сильно поможет делу, когда в реализованном модуле понадобится разобраться, спустя полгода.
Реализовал код — оставь след.
1-2-1 как профилактика точки отказа
Это больше тимлидская, нежели пиэмская задача, но 1-2-1 надо регулярно проводить, так как через них можно увидеть, в том числе, риски bus-фактора. На такой встрече может выясниться, что человек перегружен и работает в своей части продукта в одиночку, считает, что тянет всё на себе.
Через диалоги на 1-2-1 вы можете мягко указать сотруднику на необходимость передачи знаний и разделения ответственности, пояснив, зачем всё это нужно, обойдясь без приказов и стучания кулаком по столу.
Заключение
Чаще всего на практике вы приходите в уже сложившуюся команду и игнирование bus-фактора вам может очень скоро выйти боком. Выстраивайте систему, в которой нет незаменимых людей. Не для того, чтобы от них избавляться, а чтобы они могли спокойно ходить в отпуска и болеть, не боясь, что их кусок продукта останется без компетентного присмотра. Чтобы проект не останавливался, даже если кто-то выпал.
Системность ест героизм на завтрак.
