Всем привет. Я Беклемишев Константин, менеджер разработки в Контуре. Недавно мы с Викторией Алешиной, менеджером продукта, проводили мастер-класс по Bus Factor для коллег. Хочу поделиться собранным материалом и личным опытом здесь. Материал практико-ориентированный и будет полезен любой роли, которая отвечает за команду или влияет на устойчивость бизнеса.

Что такое Bus Factor?

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

Bus Factor (бас-фактор, BF, БФ) — это метрика, которая показывает хрупкость проекта в случае внезапной потери ключевых сотрудников. Представьте себе: автобус сбивает ключевого разработчика, и проект останавливается.

Bus Factor измеряет минимальное количество членов команды, внезапное исчезновение которых (по любой причине) приведет к остановке проекта из-за отсутствия необходимых знаний и навыков.

История

Одно из первых задокументированных упоминаний Bus Factor связано с историей языка Python. В 1994 году на встрече обсуждалось использование Python в продукте.

Я только что вернулся со встречи, где главным аргументом против использования языка Python была его зависимость от Гвидо. Они хотели знать, выживет ли Python, если Гвидо исчезнет. Это серьезный момент для бизнеса и он может быть ключевым при принятии решения о его использовании в продукте.

// Michael Mc Lay

Эта история ярко демонстрирует, насколько важна диверсификация знаний и навыков в команде. Bus Factor помогает оценить риски и принять меры для повышения устойчивости проекта.

Для чего рассчитывают?

• Оценка рисков остановки проекта: Bus Factor показывает, потеря скольких человек из команды может привести к остановке проекта. Чем ниже Bus Factor, тем выше риск.

• Оценка способности команды оперативно реагировать: Низкий Bus Factor указывает на то, что знания и навыки сосредоточены в руках немногих, что может привести к задержкам в случае непредвиденных обстоятельств.

Целевые показатели

Стандартные целевые показатели BF для продуктов на разных этапах жизненного цикла:

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

Когда стоит посчитать?

• Принимаете дела в новой команде: Bus Factor поможет вам быстро оценить риски и понять, на кого опирается команда.

• Актуализируете текущее состояние команды: Регулярный расчет позволит отслеживать изменения в структуре команды и выявлять потенциальные "узкие места".

• Готовитесь к пересмотрам или обсуждению целей, вариантов развития с сотрудником или всей командой: Bus Factor может стать полезным инструментом для обоснования необходимости найма, перераспределения обязанностей или обучения сотрудников.

• Команде грозит сокращение или рост: Поможет смоделировать последствия таких изменений и принять взвешенные решения.

• Найм: Расчет Bus Factor поможет сформулировать критерии отбора и обосновать потребность в конкретном специалисте.

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

• Показать возможности вашей команды к усилению других команд: Вы сможете оценить, какие ресурсы и знания ваша команда может предложить другим.

• Показать потребности вашей команды в усилении со стороны других команд: Если Bus Factor слишком низкий, это может сигнализировать о необходимости привлечения дополнительных людей.

Как часто стоит считать Bus Factor

Рекомендуется считать Bus Factor раз в полгода на пересмотрах (performance review), фиксируя зоны ответственности сотрудника по договоренности с ним.

Важно помнить!
Bus Factor — это всего лишь один из показателей, который нужно учитывать при принятии решений. Он не должен рассматриваться как единственный критерий оценки рисков в команде.

Как считать Bus Factor

Шаг 0. Напутствие

Не усложняйте!

Пройдите инструкцию до конца и получите результат. Текущая модель хороша своей простотой.

У вас может появиться желание сделать оценку точнее, усложнить систему.

Не делайте это сразу. Сперва получите результат и уже после исследуйте ваши идеи по улучшению.

Шаг 1. Подготовка

1. Перейдите в браузере в Bus Factor Шаблон;

2. Выберите в меню Файл => Создать копию;

3. В графе «Название» меняем слово «Копия» на название Своей Команды. Например: Контур.Экстерн;

4. Если вы хотите обсудить свой результат с авторами данной статьи — поставьте галку «Скопировать настройки доступа» и мы ответим на ваши вопросы в комментариях;

5. Нажмите кнопку «Создать копию».

6. 

   Ваш рабочий документ готов!

 Шаг 2. Рабочий документ

Первая вкладка называется «Шаблон». Ее вам предстоит заполнить.

Справа от нее есть вкладки с примерами:

• «Пример общих итогов» — сводный Bus‑фактор по нескольким подкомандам/ролям;

• «Бэк, Фронт, Тестирование, Аналитика и Дизайн» — вкладки с примерами зон ответственности.

Загляните на них, если есть сложности с формулировкой зон ответственности.

Шаг 3. Заполняем таблицу

Составляем таблицу зон ответственности (ЗО) по команде (подкомандам или ролям): 

• по вертикали члены команды;

• по горизонтали список ЗО.

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

Фиксация зон ответственности — это всегда и внутренний контракт между членами команды, и внешний контракт с соседними командами.

В качестве зоны ответственности можно использовать:

• функциональность,

• модуль,

• подсистему проекта,

• продуктовую зону или ее часть,

• пользовательский сценарий,

• ветвь в дереве функционала вашего продукта.

Зоны ответственности могут быть связаны с различными моделями и взаимосвязаны друг с другом.

Шаг 4. Проводим экспресс-оценку

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

Не раздумывайте долго, пишите первый откликнувшийся вариант:

Вписывайте в таблицу именно числовые значения, согласно таблице.

Шаг 5. Оцифровка результата

Формулы уже есть и они сделают расчет автоматически. Вам остается проверить корректность диапазона. При подсчете мы всегда округляем вниз, т. е. если у нас в ЗО суммарный результат 1.5, он будет округлен вниз до 1.

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

Иногда то, что в конкретной зоне нет резервирования (низкий Bus Factor), не является проблемой, например:

• Зона ответственности легкая или вряд ли будет меняться;

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

Тогда в соответствующей графе можно пометить зону ответственности как «неважно», и это исключит ее из общего расчета Bus Factor. 

Шаг 6. Целевой Bus Factor

Меняем целевой BF для вашей команды. Для этого корректируем формулу или значение в соответствующей ячейке.

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

Определение целевого Bus Factor: вопросы для обсуждения с бизнес-командой

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

Вопросы для обсуждения:

1. Как долго бизнес-команда может работать, если команда разработки работать перестанет? Этот вопрос поможет понять, насколько критична работа команды разработки для бизнеса и каковы последствия ее остановки.

2. Как долго бизнес-команда готова ждать при решении проблем в перечисленных зонах ответственности? Этот вопрос поможет определить, какие зоны ответственности являются наиболее критичными для бизнеса и насколько быстро должны решаться проблемы в этих зонах.

3. Какие из перечисленных зон ответственности производства могут застопорить активности бизнес-команды? Этот вопрос поможет выявить "узкие места" в работе команды разработки, которые могут негативно сказаться на работе бизнеса.

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

5. Какие затраты на ФОТ производства готов обеспечить CEO? Минимум, комфорт и максимум? Этот вопрос поможет понять, какие финансовые ограничения существуют для команды разработки и как они могут повлиять на целевой Bus Factor.

6. В каких областях планируется активное развитие? Где стратегически важно поддерживать хороший уровень Bus Factor, чтобы не сработали бизнес-риски.

7. Планируется ли наполнение продукта принципиально новыми фичами? Появятся ли какие-то новые предметки, в которых потребуются эксперты?

8. В каких областях, на ваш взгляд, команде сейчас не хватает знаний/компетенций? Почему и каких?

К бизнес-команде (или к СЕО) нужно прийти с уже подготовленными ЗО и посчитанной табличкой.

Как использовать: от выявления рисков к оптимизации команды

Bus Factor — это не просто число, а мощный инструмент для анализа и оптимизации. Он помогает выявить «узкие места», оценить риски, связанные с потерей сотрудников, и даже понять потенциал команды для роста и развития.

Расчет и интерпретация

Минимальное значение: Bus Factor по команде определяется минимальным значением среди всех зон ответственности (ЗО). Если в большинстве ЗО Bus Factor равен 3, а в одной из них равен 0, то общекомандный Bus Factor будет 0. Это указывает на необходимость обратить внимание на эту конкретную ЗО.

«Симуляция автобуса»: Для лучшего понимания рисков, попробуйте удалить из таблицы строки с именами сотрудников и посмотрите, как изменится расчет Bus Factor. Это поможет вам оценить, насколько критична выпадение конкретного сотрудника.

Не критичные ЗО: Если Bus Factor для какой-то ЗО равен 1 или 0, это не всегда плохо. Возможно, эта ЗО не критична для бизнеса и ее можно исключить из расчета?

Анализ по уровням: Для больших команд с подкомандами удобно считать Bus Factor для каждой подкоманды, а затем определить общекомандный Bus Factor как минимальное значение среди всех подкоманд.

Дополнительные данные из Bus Factor

Помимо самого показателя, инструмент предоставляет ценную информацию о вашей команде:

Широта контекста: Показывает, насколько каждый член команды погружен в ее дела. Сложите данные в строке напротив каждого имени, разделите на количество ЗО и умножьте на 100, чтобы получить процент. Эта метрика полезна для оценки личного вклада, постановки целей и оценки потенциала сотрудника к мобильности.

Риски по архитектурному развитию: Отметки желтым маркером наглядно помогают понять, останется ли кто-то в команде, кто может развивать конкретную ЗО. Обратите внимание на грейды сотрудников — если на сложной ЗО есть Senior и Junior, а Senior рискует уйти, то нужно привлекать еще одного специалиста на эту ЗО.

Риски по управлению: Эти риски можно проанализировать отдельно, добавив соответствующие ЗО в таблицу или проведя самостоятельный анализ.

Потенциал команды: Высокий Bus Factor говорит о том, что команда устойчива к потере сотрудников и может делиться ресурсами с другими командами.

Дизайн команды: Слабо пересекающиеся по людям кластеры ЗО могут указывать на уже существующие подкоманды.

Пример: Команда стабильного продукта (18 человек) имеет Bus Factor, совпадающий с целевым и равный 9. Это означает, что при исчезновении половины команды скорость производства замедлится, но производство не остановится. Следовательно, команда имеет хорошее резервирование и потенциал для усиления других команд, если будет такая бизнес-потребность.

Личный опыт: как избежать ловушек при определении ЗО

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

Чаще всего, руководитель берет на себя бремя определения ЗО, полагаясь на свой опыт и знание команды. Это, безусловно, ускоряет процесс, но таит в себе риски.

Человеческий фактор может сыграть злую шутку

• Неточность: Вы можете неверно оценить компетенции членов команды или необходимость определенной ЗО.

• Субъективность: Личные предпочтения или предвзятость могут повлиять на распределение ЗО.

• Искушение «улучшить» результат: Некоторые руководители склонны корректировать цифры, чтобы они выглядели «красивее».

Как избежать этих ловушек?

Социальный контракт и его фиксация — вот ключ к успеху!

1. Фиксируйте ЗО и уровень компетенции каждого члена команды.

2. Используйте HR-системы: Матрицы, Стаффы, HRы и т.д. — это идеальное место для хранения этой информации.

3. Определите время для фиксации: Performance Review — удобный момент, но можно договориться и на общих встречах или 1-2-1.

4. Автоматизируйте процесс: Если ваша HR-система это позволяет, сохраняйте данные о ЗО и уровне компетенции и выгружайте их в BI-систему.

5. Привлекайте команду к решению этой задачи: Техлидам и тимлидам может быть полезно узнать об этом подходе по работе с рисками, а еще из этого можно сделать интересную командную активность :)

Преимущества такого подхода

• Повышение достоверности данных: Меньше субъективности, больше объективности.

• Автоматическая генерация отчетов: Получайте актуальную информацию о ЗО и компетенциях команды в любой момент.

• Визуализация иерархии: Постройте карту ЗО по всему продукту/компании и выявите слабые места.

Как часто обновлять информацию?

Рекомендую проводить оценку ЗО 1–2 раза в год, совмещая ее с Performance Review.

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

Снижаем критичность зон ответственности

Метрика Bus Factor главным образом описывает резервирование зон ответственности людьми.

Иными словами, это весомый аргумент к тому, чтобы изменить численность штата (расширить, а может и уменьшить).

Но никакой бизнес не любит растить бюджеты, а ФОТ — один из его главных пожирателей в ИТ-компаниях.

Поэтому возникает резонный вопрос: как снизить критичность ЗО, чтобы плохой Bus Factor по ней не был проблемой?

Видим два варианта:

1. Быстрее передавать контекст.

2. Снижать человеческий фактор.

Важно понимать, что у каждого из них есть своя стоимость, свои накладные расходы. Так случается, что иногда люди (ФОТ) дешевле.

Быстрее передаем контекст (Артефакты)

1. Документация: Создайте и поддерживайте актуальную документацию по всем процессам, проектам и продуктам.

2. База знаний: Соберите в одном месте FAQ, best practices, решения типовых проблем.

3. Фиксация решений: Переносите обсуждения и принятые решения из чатов в issue-трекеры.

4. Комментарии в коде: Делайте их краткими, ясными и актуальными.

5. Чистая архитектура: Модульность и простота архитектуры облегчают понимание и поддержку системы.

Снижаем человеческий фактор

Снизить человеческий фактор можно за счет автоматизации процессов.

Используйте CI/CD, скрипты, RPA для автоматизации рутинных задач.

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

Можем дать рекомендации.

Ищите:

• Ищите "обезьянью" работу: Анализируйте рабочие процессы и выявляйте повторяющиеся действия, которые можно автоматизировать.

• Упрощайте рутину: Используйте шаблоны, чек-листы, автоматические напоминания.

• Разбивайте сложные процессы: Делите их на более простые этапы, документируйте каждый этап.

• Сокращайте инструкции: Делайте их более наглядными, используйте визуальные aids.

• Превращайте регламенты в автоматику: Где это возможно.

Реагируйте на триггеры:

• «Катим релиз»

• «Делаем сборку»

• «Смотрим глазами на метрики»

• «Вручную регулярно проверяем» что‑то (в нашем случае — отслеживали законодательство)

• «Устал это делать»

• «Я запутался»

• «Мне непонятно»

Снижение критичности ЗО — это инвестиция в будущее вашей компании. Она позволит вам:

• Уменьшить зависимость от отдельных сотрудников.

• Повысить эффективность работы команды.

• Снизить риски при увольнении сотрудников.

• Освободить время для более стратегических задач.

Bus Factor — это не просто число, а индикатор, который помогает вам оценить риски и принять меры по их минимизации. Используйте различные подходы к его расчету, чтобы получить полную картину.