Про автобус
Bus factor — это минимальное количество членов команды, которые должны внезапно исчезнуть из проекта, прежде чем разработка полностью остановится. Термин описывается гипотетической ситуацией: «Сколько членов команды может сбить автобус до того, как вся команда потерпит неудачу?». В реальности причины могут быть не на столько ужасны. Например, сотрудник может сменить компанию или уйти в длительный отпуск.
Данная метрика показывает, почему опасно сосредотачивать специфичные знания у одного сотрудника. Если в компании есть рок-звезда который обладает уникальными знаниями, необходимыми для проекта, ваш бас фактор равен единицы и вам следует напрячься. Что можно сделать, чтобы увеличить бас фактор?
В первую очередь разберитесь, насколько все плохо. Можно начать с составление матрицы. Опишите ключевые навыки/знания и перечислите всех сотрудников. Расставьте баллы (или +/-) в зависимости как каждый сотрудник разбирается в теме. Дальше посмотрите, есть ли у вас такие области, за которые отвечает только один-два человека. Наличие таких ситуаций — это потенциальная угроза проекту. Периодически возвращайтесь к этой матрице, актуализируйте данные и смотрите на динамику изменений.
Сделайте шеринг знаний частью вашей рутины. Это можно сделать несколькими способами. Например:
⁃ Поддерживайте культуру менторства или buddy.
⁃ Запланируйте общие встречи отделов и поощряйте людей за активное участие и обсуждение.
⁃ Организуйте внутренние митапы и помогайте сотрудникам с подготовкой докладов.
⁃ Сделайте код-ревью доступным не только для «экспертов». Посмотреть код и оставить комментарий должен иметь возможность каждый для каждого.
⁃ Практикуйте парное программирование или работу в мини группах над одной задачей.
Очень редко люди целенаправленно хотят сохранить свои знания в тайне. Обычно им просто не дают возможности поделиться. Если вы найдете удобный для вас формат, это поможет вам в прокачке новых сотрудников и в распределении знаний между разработчиками и командами.
Наличие документации в проекте — это ваши гарантии, что в любой ситуации работу выбившегося сотрудника смогут взять на себя его коллеги. Документация может быть абсолютно в любом виде: частичная документация только критически важных участков, вики по всему проекту, история изменений в jira пролинкованная между релизами, набор скринкастов по фичам и т.д. Важно, чтобы документацию было легко обновлять, потому что наличие устаревшей документации создает больше проблем, чем полное ее отсутствие.
Автоматизируйте рутинные процессы, чтобы не зависеть от человеческого фактора. Любые проверки перед деплоем, релизами, в начале или в конце рабочего дня, которые повторяются изо дня в день, должны выполняться автоматически и не зависеть от присутствия или отсутствия людей на рабочем месте. В случае если автоматизация не отработала, позаботьтесь о логировании, нотификациях о проблеме и инструкциях для людей, которым нужно будет разбираться в случившемся.
Периодически переводите сотрудников из одной команды в другую. Такой процесс максимально приближен к найму нового сотрудника. Новый человек в команде сможет подсветить существующими проблемы, с которыми мирились все остальные. Вы сможете проверить, как быстро пройдет адаптация человека в команде. При этом сотрудник, который перешел в другую команду, все еще остается доступным и может помочь при возникновении вопросов.
Делать ставку на ключевых людей в компании очень рискованно. Контролировать бас фактор — трудоемкий процесс, но если вы озаботитесь этим до наступления критических моментов, вы получите больше контроля над проектом.