Когда семеро одного не ждут. Как снизить фактор автобуса в команде

В вашей компании наверняка есть такой сотрудник — опытный, знающий систему от а до я, способный в одиночку справиться со всем и вся.

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

Что произойдет с бизнесом на следующий день? Если от этой мысли становится тревожно, значит, пора поговорить о факторе автобуса.

Фактор автобуса (от англ. bus factor, в российской практике также называют фактором кирпича) — это метрика, которая показывает хрупкость системы в случае потери ключевых сотрудников. В буквальном значении — количество людей, после внезапного ухода которых (условно говоря, из‑за попадания под автобус) всё развалится.

Итак, по нашему опыту, фактор автобуса обычно формируется незаметно и неумышленно — если один разработчик пишет код, то ему самому проще и быстрее поддерживать его.

В течение долгого времени у нас было именно так — если один разработчик писал код, то исключительно он его и поддерживал.

Это действительно было эффективно, однако вместе с тем росла и зависимость: знания годами концентрировались у отдельных людей, решения не проговаривались, а сложные участки кода воспринимались как чья‑то зона ответственности, куда лучше не погружаться, ведь, как говорится, “если работает — не трогай”.

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

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

Формирование культуры передачи знаний

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

Что нам в этом помогло:

• документирование процессов — база знаний (мы ведем ее в Confluence) должна быть доступной (не спрятанной за паролями), регулярно обновляемой (удобно, когда за актуализацию отвечает отдельный человек) и понятной (один раздел = один пласт информации), а README‑файл (от англ. — прочти меня) помогает понимать, что за проект, как его запустить и как с ним работать;
• наставничество — включает разбор кейсов и решений, проверку кода с объяснением логики и контекста, а также поэтапное делегирование ответственности с контролем понимания;
• обмен опытом — на личных и общих синхронизационных встречах, ретроспективах, докладах внутри команды и т. д.

Важность формирования культуры передачи знаний подтверждена и статистикой — вот лишь несколько показательных цифр от исследовательских компаний WifiTalents и Gitnux:

• управление знаниями может сократить время вывода новых продуктов на рынок на 20% и повысить скорость принятия решений в компаниях на 32%;
• 20% банкротств предприятий происходит из‑за недостаточного управления информацией и обмена знаниями;
• управление знаниями повышает эффективность совместной работы на 37%, а сотрудники в 4,5 раза чаще остаются в компаниях, которые уделяют приоритетное внимание обмену знаниями;
• организации, использующие управление знаниями, сообщают об увеличении производительности на 25%, повышении уровня удержания сотрудников на 22% и уровня удовлетворенности клиентов на 35%.

При формировании культуры передачи знаний важна подготовка среды, где поощряются вопросы и контекст проговаривается проактивно, а не только по запросу — ведь знание, которое нельзя безопасно запросить, по сути, не существует.

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

Чередование зон ответственности

Момент, который часто остается за кадром, — эксперты со временем привыкают к своей зоне комфорта, где всё понятно и мотивации что‑либо пересматривать нет.

В этом случае могут быть полезны:

• проверка кода всеми членами команды — минимум 2 человека должны понимать каждый модуль;
• автоматизация процессов — разделите сложные процессы на простые этапы и задокументируйте действия (с помощью шаблонов и чек‑листов), которые выполняются многократно, чтобы любому сотруднику, включая новых, было понятно, что делать в тех или иных случаях;
• создание скамьи запасных — чтобы отдельные сотрудники, которые в основное время не участвуют в разработке конкретных модулей, могли прийти на замену и взять обязанности отсутствующих коллег на себя.

В то же время если есть какой‑то процесс, который не фигурирует во время адаптации регулярно приходящих новых сотрудников и не нуждается в постоянной письменной актуализации, то будет достаточно всего 1–2 человек, хорошо разбирающихся в этой конкретной предметной области.

Также, по нашему опыту, очень полезно периодически давать экспертам задачи, в которых они ничего не понимают, — это приземляет, возвращает эмпатию к новичкам и устраняет ощущение, что всё очевидно. В таких ситуациях хорошо видно, где система опирается на реальные знания, а где — на привычку.

Заключение

Закон Мерфи гласит: если плохое может случиться — оно случится. Бутерброд всегда падает маслом вниз. А фактор автобуса, в свою очередь, указывает, что устойчивость команды — это вопрос подготовки.

О том, какие действия могут помочь в такой подготовке, мы и рассказали сегодня.

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