Що таке bus-фактор та як завадити йому «збити» ваш проєкт

Мене звати Тимофій Вертоградов, я Product Owner картографічного сервісу в Uklon.

Уявіть ситуацію — команда, де люди разом працюють доволі давно. Робота максимально злагоджена, взаєморозуміння на найвищому рівні, таски закриваються вчасно. Але при всіх очевидних плюсах є і мінуси. Наприклад, людина хоче у відпустку. Але на ній зав’язана сила силенна процесів. І якщо вона піде, проєкт просто встане.

На жаль, це розповсюджена ситуація у командній роботі. Спочатку здається: «Та хай іде у відпустку, що може статися за цей час?» А станеться класична проблема розробки ПЗ: якщо є хоча б крихітна ймовірність, що щось піде не за планом — так і станеться.

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

Що таке bus-фактор

Bus-фактор — це показник концентрації даних чи обов’язків серед учасників проєкту. Дослівно bus-фактор перекладається «фактор автобуса». Інші назви — truck-фактор чи brick-фактор. Чому саме автобус, вантажівка чи цегла у назві?

Ось абстрактний приклад. Маємо команду з 15 людей. У ній лише один керівник. Він ставить завдання, менеджерить процеси та комунікує з іншими командами. В один день цього керівника збив автобус, вантажівка чи йому на голову впала цегла прямо перед входом в офіс. Людина автоматично випадає з процесу. А решта співробітників, що залишилися, не мають тих ані даних керівника, ані його знань. Тому швидкість роботи падає до нуля.

Bus-фактор показує, скільки людей має випасти з обойми, щоб проєкт неможливо було продовжити чи завершити. Чим вище цей показник — тим більше ймовірність, що залишок команди не завершить роботу. У абзаці вище я навів приклад, коли усі необхідні дані консолідовані у руках однієї людини. Це високий bus-фактор. А може бути і так, що у цій команді з 15 людей залишиться половина, але проєкт продовжить своє існування, бо усі мають однаковий доступ до знань та вмінь, і можуть страхувати у разі потреби.

Одразу зазначу: цей показник не є панацеєю від проблемних ситуацій у колективі. Втім, він допоможе знайти недоліки та усунути їх. Щоб зменшити bus-factor або взагалі його позбутися, розберемо сценарії, які найчастіше до нього призводять. І що робити, щоб протидіяти йому.

Сценарій перший. Людина-оркестр

Ця людина може все. Учасник команди, повз якого не проходить жодна задача. Наприклад, це може бути senior, що працює в компанії з перших днів. І лише він володіє всіма необхідними знаннями.

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

Що робити? Ділитися знаннями. Дієвий спосіб розвантажити людину без розширення команди — навчити цим знанням інших. Регулярні зустрічі для поширення знань всередині команди дозволяють розділити обсяг знань чи скілів з однієї людини на всіх. В Uklon ми активно використовуємо таку практику як knowledge sharing, що розконцентровує знання однієї людини на інших членів команди, робіть такі зустрічі регулярно.

Але не забувайте і про розподіл навантаження. Можливо, лише шерингом знань не обійтися і розширення команди не завадить.

Сценарій другий. Як це працює

Постійне оновлення продукту — це чудово. Втім, вже створений функціонал не зникає. У команді завжди є людина, що пояснює принцип роботи «бази». А тепер уявіть, що ця людина раптово випала з команди, а детально розписувати наявні бізнес та технічну логіки нікому. Це автоматично створить колапс.

Що робити? Документуйте все. Завжди записуйте всі зміни, які з’являються у вашому продукті. Безумовно важливо створювати нове. Робити все, щоб користувачу було зрозуміло і зручно. Але так само зрозуміло і зручно має бути і розробникам, щоб вони завжди могли дізнатися, що і як працює всередині, та не смикали інших людей. Повірте, ви та інші члени команди неодноразово повертатиметеся до того, що вже було.

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

Документуючи все, не забувайте і про здоровий глузд — коротко, але максимально зрозуміло для усіх, бо не всі ми — талановиті технічні райтери.

Сценарій третій. З чого це починалося

Буває таке, що дивишся на задачу — і не розумієш, навіщо її створили. Мета не прослідковується, жодних деталей також не викладено. Через це складно уявити цілісну картину. У повному обсязі задачу розуміє лише «репортер» — людина, що її створила. А цей «репортер» може випасти з робочого процесу — піти у відпустку чи не відповідати днями на повідомлення. Через це робочий процес максимально гальмується. З часом таких задач стає все більше. У якийсь момент Jira перетворюється на місце відстеження поточних статусів робіт. Бо кожен заводить задачу за власним баченням.

Що робити? Створіть правила заповнення задач. У кожної дії має бути початок і кінець. Так само з тасками: вони мають складатися як пазл, щоб можна було подивитись і зрозуміти, що до чого. Наприклад, коли завдання береться з беклогу чи зі списку завершених, у співробітника не повинно виникати складнощів з розумінням того, з якої частини продукту він її витягнув. Тобто, необхідності з’ясовувати самотужки, з чого усе почалося.

У нас в робочому процесі є чітка затверджена культура створення задач, яка складається з п’яти рівнів:

1. Ініціатива — нова велика частина функціонала, що стратегічно важлива для розвитку продукту.
2. Епік — контекст роботи кожної команди в межах ініціативи.
3. User Story — історія користувача в межах розробки нового функціоналу.
4. Improvement — зміна роботи раніше створеного функціонала.
5. Task — технічна задача.

Декілька правил при введенні задач:

1. Кожна задача — дочірня певному епіку, тож не забувайте його вказувати. А краще зробіть поле вибору епіку в Jira обов’язковим до заповнення, бо кожен може хоча б раз забути його вказати.
2. Якщо задачу потрібно буде перечитувати ще комусь, окрім вас та членів вашої команди, то принцип «Як думаю, так і описую» не ефективний. Кожна задача повинна мати свій власний шаблон заповнення.
3. Домовленості на словах залишаються лише у вас в пам’яті. Поспілкувавшись щодо ініціативи/задачі (в Slack чи усній розмові), зафіксуйте все текстом і перенесіть коментарем в задачу, тегнувши потрібних людей, від яких очікується відповідь.

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

Пам’ятайте найголовніше — інформація не повинна зникати чи губитися, а знання — концентруватися на одній людині.