BUS factor или “один - плохое число для бизнеса”

Для тех, кому не знакомо понятие bus factor, обратимся к первому тезису из wiki, в котором говорится, что Бас фактор - это фактор, показывающий количество участников проекта, после потери которых (в оригинале — «попадания» которых под автобус), проект не сможет быть завершен оставшимися участниками.
Вы также могли встречать понятие truck factor (фактор грузовика) или brick factor (фактор кирпича), но суть от этого не меняется.
Если перевести с айтишного на человеко-понятный язык, bus factor - это про «а что случится с вашим бизнесом/проектом, если вы лишитесь вот этого конкретного участника или команды,  в руках или умах которых содержится  90-100% информации для работоспособности проекта?

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

Самое плохое число для бизнеса - это один:
- один канал продаж (может отвалиться или стать неэффектисным одномоментно и придется потратить уйму времени, чтоб настроить дополнительные источники получения трафика;;
- один клиент, пусть и крупный (если он уйдет, команда будет у разбитого корыта);
- один человек, который знает о том, как устроены все бизнес-процессы;
- один разработчик, у которого лежат все доступы, и они принадлежат не вам, и ваш бизнес в буквальном смысле зависите от того, чтоб он был онлайн был контактным;
- один разработчик, который разрабатывал вам ПО, но не оставил никакой технической документации, и никто, кроме него не знает как все реализовано и будет тратить дни, недели, или месяцы, чтобы разобраться в логике происходящего.
Продолжать можно бесконечно.

Суть в другом: если ваш бизнес или проект имеет одну или более зон уязвимости, где ресурс сосредоточен в руках одного специалиста, у вас высокий уровень бас фактора.
Бас фактором может выступить любое событие, от “попал под автобус”, до “внезапно заболел” и не вышел на связь тогда, когда был критично нужен.
Простой способ оцифровать ваш bus factor - это взять количество людей, задействованных на проекте. Раз уж мы пишем эту статью в блоге студии веб-разработки, давайте возьмем сценарий из этой области.
Допустим, у вас 7 человек задействовано на проекте, из них 1 проджект-менеджер, 1 бизнес-аналитик, 3 разработчика занимаются бекендом и пишут код, также есть 1 фронтент и 1 дизайнер. Бас фактор в контексте разработки ПО в этом проекте равен трем, потому как ключевая информация рассредоточена между 3-мя разработчиками бекенда.
Если у вас небольшая компания, и вы работаете с фрилансерами или индивидуальными разработчиками - ваш уровень бас-фактора также равен одному.
И здесь уже должно становиться более волнительно :)

5 базовых шагов как вы можете снизить риски  высокого bus factor проекта, если вы заказчик:

1. настоять на  регистрации домена на вас, а не на разработчика/маркетолога;

2. настоять на регистрации хостинга на вас, а не на разработчика, и уже из-под вашего аккаунта раздавать доступы всем, кому это будет необходимо;

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

4. договориться о работе по ТЗ (техническому заданию), чтобы любой другой специалист мог разобраться в том, что вы делали “до” того, как привлекли к проекту кого-то еще;

5. попросить составлять техническую документацию, особенно касается сложных архитектурных проектов, которые будут иметь вложенную структуру связей  и большое количество доработок функционала в будущем.
   
   
   Стоит отметить, что работа с составлением ТЗ и технической документации является более трудоемкой для специалиста или команды, в контексте нагрузки по человеко-часам работы, а значит и будет немного дороже стоить для вас как заказчика.
   Однако, это тот самый случай, когда уделив проявив должный уровень уважения и внимания сегодня - вы сэкономите больше времени и денег компании завтра, послезавтра и годы спустя.

7+1 базовых шагов как вы можете снизить риски  высокого bus factor проекта, если вы и есть та самая команда разработчиков или индивидуальный специалист:

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

1. Создавать базу знаний и техническую документацию по проекту, и хранить ее в облаке компании, а не в персональных облаках отдельных разработчиков, и уж тем более не локальных файлах на ноутбуке или компьютере отдельных специалистов;

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

3. Делайте регулярные бекапы важных данных, желательно не на том же сервере, где и продакшн.

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

5. Делайте код-ревью всех разработчиков, даже тех, кто пишет “как Боженька” (особенно, если он пишет “в своем стиле”.

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

7. Если какую-то часть работ (допустим CI/CD) настраивал один специалист, и никто не вдавался в детали как он его настроил - попросите составить его техническую документацию, чтоб не обращаться к нему каждый раз когда необходимо изменить pipeline. 

Подитожив вышесказанное, хочется добавить, что bus factor есть абсолютно во всех проектах и бизнесах. Вопрос только в том, насколько он высокий или низкий.
Как правило, небольшим компаниям и командам присущ более критичный уровень бас фактора, в силу сосредоточения большого количества информации именно в руках отдельных людей. По мере роста бизнеса и количества людей, задействованных в реализации поставленных задач, бас фактор становится ниже.
Однако, время от времени любой проект требует “ревизии” на предмет уязвимости в контексте bus factor.