BUS factor або “один – погане число для бізнесу”

Для тих, кому не знайоме поняття bus factor, звернемося до першої тези з wiki, в якій говориться, що Бас фактор - це фактор, що показує кількість учасників проекту, після втрати яких (в оригіналі - «попадання» яких під автобус), проект не зможе бути завершений учасниками, що залишилися.

Ви також могли зустрічати поняття truck factor (фактор вантажівки) або brick factor (фактор цегли), але суть від цього не змінюється.

Якщо перекласти з айтішного на людину-зрозумілу мову, bus factor - це про «а що трапиться з вашим бізнесом/проектом, якщо ви втратите ось цього конкретного учасника чи команди, в руках чи умах яких міститься 90-100% інформації для працездатності проекту?

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

Найгірше для бізнесу - це один:

• один канал продажів (може відвалитися або стати неефективним одномоментно і доведеться витратити багато часу, щоб налаштувати додаткові джерела отримання трафіку;;
• один клієнт, хай і великий (якщо він піде, команда буде біля розбитого корита);
• одна людина, яка знає, як влаштовані всі бізнес-процеси;
• один розробник, у якого лежать всі доступи, і вони належать не вам, і ваш бізнес в буквальному сенсі залежить від того, щоб він був онлайн контактним;
• один розробник, який розробляв вам програмне забезпечення, але не залишив жодної технічної документації, і ніхто, крім нього не знає як все реалізовано і витрачатиме дні, тижні, або місяці, щоб розібратися в логіці того, що відбувається.

Продовжувати можна безкінечно.

Суть в іншому: якщо ваш бізнес або проект має одну або більше зон уразливості, де ресурс зосереджений в руках одного фахівця, ви маєте високий рівень бас фактору.

Бас фактором може виступити будь-яка подія, від "потрапив під автобус", до "раптово захворів" і не вийшов на зв'язок тоді, коли був потрібен.

Простий спосіб оцифрувати ваш bus factor – це взяти кількість людей, задіяних на проекті. Якщо ми пишемо цю статтю в блозі студії веб-розробки, давайте візьмемо сценарій з цієї галузі.

Припустимо, у вас 7 осіб задіяно на проекті, з них 1 проджект-менеджер, 1 бізнес-аналітик, 3 розробники займаються бекендом та пишуть код, також є 1 фронтент та 1 дизайнер. Бас фактор у контексті розробки ПЗ у цьому проекті дорівнює трьом, тому що ключова інформація розосереджена між трьома розробниками бекенда.

Якщо у вас невелика компанія, і ви працюєте з фрілансерами або індивідуальними розробниками - ваш рівень бас-фактора також дорівнює одному.

І тут уже має ставати більш хвилюючим :)

5 базових кроків як ви можете знизити ризики високого bus factor проекту, якщо ви замовник:

• наполягти на реєстрації домену на вас, а не на розробника/маркетолога;
• наполягти на реєстрації хостингу на вас, а не на розробника, і вже з-під вашого облікового запису роздавати доступи всім, кому це буде необхідно;
• наполягти на реєстрації сервера на вас, а не на розробника, та аналогічно видавати доступи іншим учасникам проекту, а не залежати від когось ззовні
• домовитися про роботу з ТЗ (технічного завдання), щоб будь-який інший фахівець міг розібратися в тому, що ви робили “до” того, як залучили до проекту ще когось;
• попросити складати технічну документацію, особливо щодо складних архітектурних проектів, які матимуть вкладену структуру зв'язків та велику кількість доопрацювань функціоналу в майбутньому.

Варто зазначити, що робота зі складанням ТЗ та технічної документації є більш трудомісткою для фахівця чи команди, в контексті навантаження по людино-годинах роботи, а значить і буде дорожче коштувати для вас як замовника.

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

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

       Пункт № 0. На кожен хоч скільки-небудь потрібний проект має бути репозиторій з описом, як розгортати проект.

1. Створювати базу знань та технічну документацію за проектом, і зберігати її в хмарі компанії, а не в персональних хмарах окремих розробників, і тим більше не локальних файлів на ноутбуці чи комп'ютері окремих фахівців;
2. Репозиторій має бути доступний більш ніж одного розробника з усіма повноваженнями;
3. Робіть регулярні бекапи важливих даних, бажано не на тому сервері, де і продакшн.
4. Систематизуйте вимоги до документування коду, неймінгу класів та змінних, до розташування модулів у проекті та інше. Чим більше моментів ви стандартизуєте – тим меншим буде рівень бас фактору на проекті з будь-яким числом розробників.
5. Робіть код-рев'ю всіх розробників, навіть тих, хто пише як Боженька (особливо, якщо він пише у своєму стилі).
6. Якщо у проекті є закоментовані шматки коду, завжди вказуйте, чому вони закоментовані і в яких випадках їх не можна чіпати і розкоментувати.
7. Якщо якусь частину робіт (припустимо CI/CD) налаштовував один фахівець, і ніхто не вдавався в деталі, як він його налаштував - попросіть скласти його технічну документацію, щоб не звертатися до нього щоразу, коли необхідно змінити pipeline.

Підсумувавши вищесказане, хочеться додати, що bus factor є абсолютно у всіх проектах та бізнесах. Питання тільки в тому, наскільки він високий чи низький.

Як правило, невеликим компаніям та командам притаманний більш критичний рівень бас фактору, через зосередження великої кількості інформації саме в руках окремих людей. У міру зростання бізнесу та кількості людей, задіяних у реалізації поставлених завдань, бас фактор стає нижчим.

Проте, іноді будь-який проект вимагає “ревізії” щодо вразливості у тих bus factor.