Оптимізуємо роботу команди через рефайнмент беклогу (aka грумінг)

UPD: Дякую спільноті DOU за коментарі та обговорення терміну «грумінг» — справді, наразі він переважно не вживається через негативні конотації в англійській мові. Тому підтримую думку колег і пропоную використовувати слово рефайнмент.

Привіт! Я Юля, Product manager на продукті Coupler.io, створеному командою Railsware. Свою роботу дуже люблю та вважаю, що продакт-менеджер — незамінна роль в процесі розробки якісних та корисних продуктів. Коли мене питають, що саме я роблю, моя відповідь може зайняти й годину, і дві. Але одним з моїх пріоритетних завдань є робота з беклогом.

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

Що таке грумінг беклогу?

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

Під час розробки продуктів «прибирання» є ще більш важливим. Грумінг потрібен, щоб:

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

Не плутати з плануванням спринту

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

Ось вам ще кілька відмінностей.

Сподіваюсь, тепер різниця помітніша. Повертаємось до грумінгу.

Як часто проводити грумінг?

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

Постарайтеся проводити грумінг десь посередині спринту. Так ви зможете безболісно спланувати майбутній спринт і не будете відволікатися на обов’язкові мітинги, прив’язані до кінця спринта, як-от демо. А щоб не пропускати мітинги, просто забронюйте час у календарі та зробіть зустріч регулярною.

Як довго має тривати грумінг?

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

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

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

Як класифікувати пункти беклогу?

У команді Coupler.io беклог зазвичай формується із таких елементів:

• scope та дорожня карта продукту;
• відсортовані запити клієнтів;
• ідей техспеціалістів;
• інсайти, отримані з dashboards продуктів.

Через розмір і складність беклогу ми ділимо його на розділи. Це допомагає всім стейкхолдерам і учасникам зустрічі оцінювати та пріоритезувати роботу. Ось які розділи ми для себе виділили:

• Проєкти спринтів — приблизний список проблем і завдань, які ми вже хочемо додати в майбутні спринти. Цей список є відкритим для змін.
• Списки з пунктами, класифікованими за типами. У нашому беклозі можна побачити список багів, технічного боргу, продакт-менеджменту, безпеки, інфраструктури тощо.
• Загальний беклог — пункти, які або не стосуються жодної з категорій, або ті, що поки не описані належно.
• «Заморозка» (Icebox) — пункти-мрії, які ми навряд чи зможемо втілити найближчим часом.

Що стосується інструментів: для керування беклогом та сортування пунктів наша команда зазвичай використовує Jira (для великих проєктів) та Trello (для менших).

Готуємось до сесії

Перш ніж перейдемо до деталей підготовки сесії, спочатку з’ясуймо, хто ж насправді є відповідальним за процес грумінгу?

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

1. Огляд пунктів беклогу

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

2. Перехресна перевірка нових та старих пунктів щодо відповідного епіку та продукту в цілому

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

3. Планування не дуже щільної адженди, щоб вам точно вистачило часу на обговорення

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

Кого запросити на сесію?

Як я вже згадувала, продакт-менеджери та власники продукту є основними учасниками грумінг-сесії, як і основні члени команди розробки. Також варто запросити QA-інженерів, щоб вони могли проговорити вимоги до тестування та оцінити необхідний час для кожної задачі.

Однак, не існує якогось фіксованого «списку учасників» грумінгу. Кого запрошувати, насправді, залежить від розміру вашої продуктової команди та складності й зрілості вашого проєкту. У команді Railsware ми керуємо кількома внутрішніми та клієнтськими проєктами, кожен з яких перебуває на різних етапах життєвого циклу розробки. Унаслідок цього на деяких сесіях грумінгу присутні лише 4-5 учасників (продакт-менеджер та кілька ключових інженерів), тоді як інші можуть мати до 10 присутніх (проєкти з більшою командою розробників, QA-інженерів, дизайнерів тощо).

Ось приблизний огляд того, хто і що має робити на сесії грумінгу.

Найкращі практики грумінгу для проведення продуктивної сесії

Ось декілька порад, що можна вважати найкращими практиками в роботі з беклогом.

Бути послідовним

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

Тому я наполегливо рекомендую зробити сеанси грумінгу регулярними — у той самий день, у той самий час, один раз за спринт. Сприймайте це як профілактичний захід, який заощадить вам (і всій команді) час і зусилля в довгостроковій перспективі.

Співпрацювати та заохочувати до щирого відгуку

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

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

Деякі agile-команди використовують такі тактики, як покер-планування або story points, щоб заохотити учасників і полегшити оцінку. Але наша практика показує, що основа продуктивних сесій — налагоджена комунікація. Тому в команді ми розвиваємо культуру відкритого зворотного зв’язку, у якій колеги, незалежно від стажу чи ролі, почуваються комфортно, коли діляться своїми думками.

Впевнитись, що всі пункти відповідають принципу DEEP

Розроблена експертом з управління продуктами Романом Піхлером, DEEP — це agile-концепція, яку можна застосовувати до всіх пунктів беклогу. DEEP — це абревіатура, що означає Detailed appropriately (деталізовані достатньою мірою), Estimated (оцінені), Emergent (актуальні) та Prioritized (пріоритезовані).

Ось який вигляд це має:

Зберігати фокус

І хоча дуже важливо отримати фідбек від членів команди під час сесії, все ж намагайтеся не занурюватись надто глибоко у складні невирішені питання. Пам’ятайте, грумінг — це не сесія для розв’язання проблем чи генерування ідей. Для цього є інші можливості та інструменти. Наприклад, в Railsware — це BRIDGeS.

Ви завжди можете дослідити питання після зустрічі, запланувавши сесію для співпраці з носіями знань (як-от інженерами, які працюють над певним епіком) та / або провівши власне дослідження.

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

Приклади грумінгу

Пропоную подивитися на процес грумінгу через призму двох B2B SaaS-продуктів на різних етапах життєвого циклу: стартапу та зрілого продукту.

Грумінг в стартапі

Уявімо, що платформи Asana ще не існує й ми працюємо над MVP-версією цього продукту. Як би виглядав типовий сеанс грумінгу в цьому випадку?

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

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

Скажімо, одним з епіків в Asana може бути «Дозволити користувачам створювати таски». Оскільки це дуже важлива функціональність платформи, вона обов’язково матиме десятки похідних доробок, таких як покращення продуктивності, потенційні розширення, налаштування та баги. Команда може обговорити та пріоритезувати ці пункти під час сеансу грумінгу (на ряду з іншими важливими епіками) та вирішити, що буде додано в наступний спринт.

Усі епіки та проблеми, що не є життєво необхідними для релізу MVP, мають бути депріоритезованими та доданими до беклогу V2. Як тільки ви отримаєте відгуки про продукт, можете починати грумінг списку V2 та вирішувати, які пункти є релевантними для продукту, що ви хочете побудувати.

Грумінг в зрілому продукті

Цього разу як приклад візьмемо Smart Checklist — один із власних продуктів Railsware. Smart Checklist — це додаток для Jira, який допомагає командам розбивати складні проєкти на невеликі задачі. Йому вже кілька років, він пройшов декілька ітерацій і має понад 2,2 мільйонів користувачів.

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

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

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

Що ж має вийти після сеансу

Найважливіший результат грумінгу — підтримка беклогу в актуальному і релевантному стані до поточної стратегії продукту.

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

А що буде, якщо ігнорувати грумінг

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

Гігієна беклогу є ключовим елементом lean-розробки, оскільки вона узгоджується з концепціями усунення марнотратства і створення цінності для клієнтів. По суті, грумінг дозволяє відсіяти завдання, які не є суттєвими для безпосередніх цілей і зосередитися на роботі, яка наближує до product-market fit.

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

Наприклад, уявімо, що в вашому беклозі є задачі з підʼєднання ШІ чат-бота до онбордингу користувачів. Звучить цікаво? Ба більше, це ще й може покращити показники утримання користувачів. Але якщо інший набір пунктів у беклозі пов’язаний з підʼєднанням платіжної системи для монетизації продукту, стає зрозуміло, які саме задачі слід додати до майбутнього спринта.

Наостанок

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

Залишилися питання про грумінг чи інші аспекти роботи з беклогом? Чи, можливо, у вас є власні методи ефективного грумінгу? Діліться в коментарях!