Беклог продукту — що це і як його скласти?

Тема сьогоднішнього спічу — беклог продукту. Ми поговоримо про те, що це таке, навіщо це потрібно і як його правильно складати. Сьогодні вам про це розповість член нашої команди під умовним ім'ям "XXX". Приступимо?

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

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

Беклог продукту — основа для планування спринтів у Scrum або потоків робіт у Kanban. Там команда обирає елементи з беклогу для реалізації протягом майбутнього циклу розробки. Це гарантує, що робота команди завжди вирівнюється з поточними цілями та пріоритетами проєкту.

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

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

Тепер перейдемо до відмінностей між беклогом продукту і беклогом спринту:

1. Масштаб. Беклог продукту охоплює весь продукт: поліпшення, функції та виправлення, які можуть бути реалізовані в майбутньому. Беклог спринту фокусується на конкретному, обмеженому наборі завдань, обраних для виконання в майбутньому спринті.
2. Динаміка змін. Беклог продукту постійно еволюціонує й оновлюється залежно від змін вимог бізнесу, пріоритетів і зворотного зв'язку від користувачів. Беклог спринту може зазнавати незначних змін і здебільшого залишається стабільним протягом спринту, щоб команда могла сфокусуватися на досягненні конкретних цілей.
3. Рівень деталізації. Завдання в беклозі спринту зазвичай більш деталізовані та розбиті на менші задачі, порівняно з елементами беклогу продукту. Це гарантує команді чітке розуміння того, що потрібно робити, і які результати мають бути досягнуті до кінця спринту.
4. Учасники. Власник продукту відповідає за управління беклогом продукту і визначення пріоритетів завдань у ньому. Беклог спринту формується з командою розробки та власником продукту під час планування спринту, де команда обирає з беклогу продукту завдання, які вони вважають за можливе виконати протягом наступного спринту.

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

Як правильно складати беклог продукту? Що в нього входить? Про що не можна забувати?

1. Користувацькі історії (User Stories). Короткі описи функціональності з погляду кінцевого користувача. Вони допомагають команді зрозуміти, чого користувач хоче досягти та чому.
2. Функціональні можливості (Features). Більші блоки роботи, які можуть бути розбиті на дрібніші завдання або користувацькі історії.
3. Баги (Bugs). Записи про помилки або проблеми в наявному продукті, які потрібно виправити.
4. Технічний борг (Technical Debt) — вказує на необхідність поліпшення структури коду або архітектури системи, щоб полегшити додавання функціональності або поліпшення продуктивності в майбутньому.
5. Покращення (Improvements). Ідеї щодо оптимізації, поліпшення наявних функцій для підвищення зручності використання, продуктивності продукту.

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

Власник продукту (Product Owner)

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

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

Команда розробки

Команда розробки бере активну участь в обговоренні та уточненні елементів беклогу. Розробники допомагають оцінити складність запропонованих завдань і надають технічну експертизу для визначення найефективніших способів реалізації.

• Беруть участь у плануванні спринтів, де команда обирає завдання з беклогу продукту для внесення в беклог спринту.
• Обговорюють технічні аспекти та пропонують рішення для виконання елементів беклогу.
• Проводять оцінку часу і ресурсів, необхідних для реалізації завдань із беклогу.

Зацікавлені сторони (Stakeholders)

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

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

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

На основі нашого досвіду ми приготували для вас кілька корисних лайфхаків.

1. Використовуйте користувацькі історії.

Історії користувачів допомагають сформулювати функціональні вимоги до продукту з погляду кінцевого користувача. Є функціональний шаблон, який спрощує процедуру:

"Як [роль користувача], я хочу [мета], щоб [причина]".

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

2. Пріоритети MoSCoW.

Метод MoSCoW допомагає розставити пріоритети в елементах беклогу за категоріями:

• Must Have (Обов'язково);
• Should Have (Бажано);
• Could Have (Можна, але не обов'язково);
• Won't Have (Не буде цього разу).

Це гарантує ясність і узгодженість у розумінні того, над чим команда має працювати насамперед.

3. Регулярне оновлення та уточнення.

Беклог продукту не повинен бути статичним. Проводьте регулярні сесії уточнення беклогу з командою розробки, щоб обговорити та визначити майбутні завдання. Це допомагає виявляти непорозуміння й адаптуватися до змін у проєкті.

4. Візуальне відображення.

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

5. Обмежте кількість елементів у беклозі.

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

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

Будьте уважні, дотримуйтеся ключових правил і порад. Тільки тоді ви зможете створювати якісні продукти без затримок і плутанини в робочих процесах.