Фактор автобуса, bus factor, truck factor, фактор кирпича (который на голову) – это то, насколько вы уязвимы, если ключевые люди, возможно, обладающие критически важными знаниями или навыками, попали под ... в общем не смогли продолжить работать и мы считаем это потерей.
Потерей может стать:
- увольнение, переход в другую команду
- больничный
- декрет
- длительный отпуск
- несчастный случай
💡 Альтернативная формулировка с меньшим числом жертв: «Что, если мы все выиграем в лотерею?» и поэтому решим заняться чем-нибудь другим.
Сегодня попробую ответить на вопрос, который возник у нас в команде: "Как нам погрузить разработчиков в большее количество сервисов и процессов?".
Чем выше тем лучше: 🔽низкий bus factor – наличие специфических знаний, которыми владеют лишь 1 или несколько участников команды 🔼высокий bus factor – работа будет вестись стабильно, даже если команду покинет много участников
Идеальная ситуация – все члены команды знают все части процесса/работы/системы/продукта, и поэтому потеря любого причинит минимальный урон для компании.
Что можно предложить для повышения bus factor:
- уменьшить сложность систем и упростить порог входа
- фиксировать знания в виде инструкций, схем, диаграмм и тд.
- использовать перекрестное review кода
- проводить демо продукта/фич
- автоматизировать процессы
- ротировать сотрудников между сервисами/функциями
И еще пара советов для лидов:
- сделайте ключевого сотрудника ментором, тогда он сможет шарить свои знания
- поощряйте обмен опытом. Для этих целей можно организовать регулярные встречи, на которых сотрудники будут делиться опытом, наблюдениями и лучшими практиками своей работы
📱 Расскажите про свой опыт повышения bus factor в своих командах.