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

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

Вся пріоритезація має базуватися лише на користі для кінцевого споживача, тобто для бізнеса, а не на людино-годино-папугах. Сам процес оцінки задачі – ледь не половина роботи з розробки, бо треба зануритись, спроектувати дизайн та архітектуру, витратити відчутний проміжок часу ат сил. Але яка різниця, скільки коштує саме оця частина функціональності, якщо вона дрібʼязкова для споживача (для бізнеса) порівняно з іншими? Чи дійсно бізнес готовий оплачувати оцінку задачі, яка наврядчи буде реалізована? 

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

Для самої декомпозиції у вас вже повинна бути наглядна модель системи
Вам підійде опис UX-фловів, BPMN схема, прототип User Story Map’и чи якась інша візуалізація фічі. Не використовуйте UI-макети, бо на цьому етапі вони звузять розуміння фічі (особливо якщо у вас крутий дизайнер/ка, то це вплине на тверезість поглядів стекхолдерів – “вау! хочу оце і всюди“) . Краще, щоб у вас перед очима був загальна опис UX-фловів чи картина Івент Штормінга / Event Stormingʼа (ES)!

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

Гайд проведення воркшопу з декомпозиції та пріоритезації ІТ-системи

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

Сутності – будемо оперувати прото-сторіками, тобто прототипами інкрементів (логічних частин функціональності), які в майбутньому також будуть декомпозовані на меньші, вужчі user stories або use cases.

Запрошені – до 20 колег в онлайні, головне, щоб це були ті, хто дизайнів цю систему – розробники, бізнеси, маркетологи.  Мовчунів та я-за-кермом-але-буду-з-вами – нафіґ, або відпустити, або вибхати.

Очікувані результати – виокремлення (формулювання) інкрементальних частин системи та їх рівномірне розподілення (пріоритезація) по трьом етапах розробки.  

Інструменти – відео-чат з можливістю розбиватися по кімнатах (Zoom, MS Teams, Slack?) та веб-дошка для роботи (Miro, Lucidchart, FigJam).

Хронометраж – 1 година, +/- 15 хвилин. Обмежений час воркшопа є проекцією обмежень в пріоритетах декомпозуємої системи – треба витримати.

Ви, ведучій/а воркшопу, будьте готові активно фасилітувати командну роботу 
Дуже важливо витримати часові межі та правила, бо весь воркшоп саме про обмеження системи – «Є ось такий обʼєм, іншого не буде, чим цінним його заповнити?». Хтось постійно буде пхати слона в курник, чи курник в слона, тож будьте напоготові. Буде напружено, будуть суперечки, буде цікаво.

Перше, знайомство з правилами

Ведучій знайомить учасників з правилами та очікуваними результатами. Треба нагадати цінність ІТ-системи, яку будемо декомпозувати, пройтись по основних UX-послідовностях та озвучити критичні ризики.

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

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

Друге, робота в командах

Команди формулюють прото-сторіки
Прото-, тому що це саме прототипи майбутніх user stories або use cases, прототипи, які далі візьмуть в рефайнменти та виділять з них меньші, гожі, вужчі послідовності, якими будуть оперувати під час планування спринтів.

Для опису прото-сторіків можна використовувати одночасно і формат user story, і формат use case. Іноді логічніше сформулювати декілька uses cases та одну user story, аніж намагатись все привести до єдиного формату. Краще, щоб команда спочатку вписалась в 5-7 таких формулювань, потім при загальному обговоренні все одно будуть виникати нові прото-сторіків. 

Приклади прото-сторіків
Я, менеджер підтримки, хочу знати перелік звернень, щоб скласти план роботи (форматі user story)
Менеджер підтримки залогінився, йому відображено перелік звернень (формат use case)

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

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

Приклад послідовного підходу
пс 1 – відображення ресторанів на карті навколо клієнта
пс 2 – додати меню ресторанів
пс 3 – додати форму замовлення та оплати
– – – – – – клієнт може починати користуватись сервісом – – – – –
пс 4 – додати рекомендації для замовлень

Приклад підходу вдосконалення
пс 1 – відображення переліку ресторанів та контактні телефони менеджерів
(клієнт звертається, а менеджер по телефону опрацює замовлення)
– – – – – – клієнт може починати користуватись сервісом – – – – –
пс 2 – додати до переліку ресторанів їх меню
пс 3 – додати рекомендації для замовлень
пс 4 – відображення ресторанів на карті навколо користувача

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

Ведучій, дай командам 20-25 хвилин, хай спробують описати всю систему зручними для них підходами та форматами. Фокус – на самому головному, фінальний опис все одно зімниться.

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

Дублі прото-сторіків (у команд можуть співпадати дукми) прибираються, відмічаються влучні (чіткий бізнесовий та технічний контекст) формулювання. До 5 хвилин на команду, до 15 хвилин загалом.

Третє, визначення пріорітетів

Ведучій оголошує гвалт та хаос! Всі учасники (більше немає команд) разом намагаються намапити прото-сторіки на три етапи розробки. Хай вони тягають їх по дошці між етапами, поєднують та комбінують між собою, сперечаються та генерують альтернативні прото-сторіки. Ця вправа повинна вміститься в 20 хвилин і хай переможе сильніший.

Учасникам треба активно домовлятися, щоб рівномірно (бо зазвичай все пхають в перший етап) вписати фічу в три етапи розробки. Етап і є пріорітетом.

В продакт-менеджменті є багато цікавих методів пріорітезації, але у нас на воркшопі метод такий – учасникам треба домовитись за 15-20 хвилин, хай якими крітеріями кожен з них керується.

Це складно – і точно сформулювати інкременти, і рівномірно їх розподілити. Етап не дорівнює спринту, це умовний проміжок часу. Етап дорівнює пріорітету, перший етап містить в собі прото-сторіки найвищого пріорітету. Якщо прото-сторік потрапив в третій етап, це не означає, що “його ніколи не зроблять”, це означає, що його планують зробити після першого та другого пріорітету.

Ведучій загострює дискусію питаннями накшталт – “Тобто ми в перший етап всі прикольчики забираємо, а все мʼясо бізнеса на третій етап лишаємо? Оцей холіварний прото-сторік, він гроші приносить бізнесу, чи клієнта до нас привʼязує, чи він просто цікавий? Ага, 5 хв лишається, а у нас все-все в одному пріоритеті, тобто розробники самі потім оберуть з чого починати?”.

Учасники будуть випробовувати і самого ведучого – «За 20 хвилин таке не вирішити», «Неможливо все вмістити в 3 етапи, тут мінімум 5 треба», «Давайте все в перший етап, тут все важливо одночасно». Але для тебе, ведучій, це очікувана поведінка групи, тож допоможи їм витримати, а не розмити обмеження.

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

Завершення суперечки та підбиття підсумків

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

Результати воркшопа

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

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

P.S. Етапи та перелік інкерементів не є сталими, вони необхідні для випуску в прод перших функціональностей, щоб зрозуміти, як споживач (стейкхолдер?) реагує на це, а далі – скрам як він є 🏈

Гарних декомпозицій, грінчата!