Коли в беклозі одночасно є нові фічі, продуктові гіпотези, технічні задачі та запити стейкхолдерів, команді потрібно вирішити, за що братися насамперед. Аби вибір не залежав лише від інтуїції або найгучнішого аргументу, використовують методи пріоритизації.
У цьому матеріалі HBJ розбирає три з них — RICE, ICE та WSJF: як вони працюють, які дані потрібні для скорингу та як вибрати підхід під конкретний продукт і команду. Практичним досвідом поділилася Олена Тімченко, ех-Product Manager у HOLYWATER.
Навіщо продуктовій команді формальна пріоритизація
У продуктової команди зазвичай більше задач, ніж часу й ресурсів на їхню реалізацію. Тому питання не лише в тому, що варто робити, а й у тому, що робити першим.
Без зрозумілих критеріїв такі рішення легко стають суб'єктивними. Пріоритет може отримати ідея, яка здається перспективнішою, запит важливого клієнта або чергова «термінова» задача від стейкхолдера. У результаті пріоритети постійно змінюються, а команда перемикається між ними.
Формальна пріоритизація допомагає порівнювати ініціативи за спільними критеріями: потенційним впливом, охопленням, необхідними ресурсами, впевненістю в оцінках або ціною затримки — залежно від методу. Так логіка рішення та припущення, на яких воно базується, стають зрозумілішими.
«Скоринг іноді корисний не лише для ранжування, а й для перевірки того, чи правильно ми взагалі сформулювали задачу. Тобто оцінювання допомагає не лише визначити місце задачі в backlog, а й за потреби переглянути саму продуктову гіпотезу до того, як команда витратить ресурси на її реалізацію», — каже Олена Тімченко, ех-Product Manager у HOLYWATER.
Що таке RICE Framework і як рахувати RICE Score
RICE framework створили в Intercom для порівняння продуктових ініціатив за чотирма критеріями: Reach, Impact, Confidence та Effort. Формула RICE score виглядає так.
Наприклад, якщо покращення онбордингу має Reach 10 000, Impact 2, Confidence 80% та Effort 4, його RICE score становитиме 4 000. Advanced dashboard із Reach 2 000, Impact 3, Confidence 100% та Effort 3 отримає 2 000. Тобто вищий Impact сам по собі ще не означає вищий пріоритет: RICE prioritization враховує також охоплення, впевненість в оцінці та ресурси.
Найбільше простору для суб'єктивності залишають Impact і Confidence. Олена Тімченко радить у зрілих продуктах не використовувати їх як абстрактні оцінки:
«Краще адаптувати ці параметри під власну історію даних і домовитися про єдину шкалу для всієї продуктової команди. Тоді всі продакти розуміють, що означає, наприклад, Impact 5 або Confidence 3, і оцінюють задачі за однаковою логікою».
У команді Олени під час оцінювання Impact враховували стратегічний пріоритет та очікуваний вплив на ARPU. Confidence оцінювали на основі конкретних сигналів: попередніх тестів, досвіду інших продуктів компанії, власних даних та наявності фічі в конкурентів.
«Ми не просто ставили суб'єктивний Confidence від 1 до 5, а розкладали його на конкретні сигнали. Це допомагало всім продактам однаково розуміти, звідки береться оцінка і що саме означає кожен бал».
Так суб'єктивність не зникає повністю, але критерії оцінювання стають спільними й зрозумілими для команди.
Що таке ICE Method і як рахувати ICE Score
ICE method — простіший метод пріоритизації, який оцінює ідею за трьома параметрами.
Що вищий ICE score, то вище ідея буде в списку пріоритетів. На практиці зустрічаються й інші способи розрахунку ICE, тому важливо насамперед послідовно застосовувати однакову систему оцінювання до всіх ініціатив.
Водночас простота робить ICE framework більш залежним від суб'єктивних оцінок. Якщо команда не домовилася, що означають, наприклад, Impact 8 або Ease 6, різні люди можуть оцінити ту саму ідею по-різному. Тому ICE допомагає швидко впорядкувати гіпотези, але сам по собі не робить оцінювання об'єктивним.
Що таке WSJF Prioritization
WSJF prioritization (Weighted Shortest Job First) — метод із SAFe (Scaled Agile Framework, фреймворк для масштабування Agile у великих організаціях), який визначає пріоритет задач через ціну затримки та обсяг роботи. Базова формула така:
Логіка WSJF проста: що вища ціна затримки й менше ресурсів потребує задача, то вищий її пріоритет.
Наприклад, велика фіча з Cost of Delay 24 і Job Size 12 отримає WSJF 2. Менше покращення з Cost of Delay 15 і Job Size 3 — WSJF 5. Отже, друга задача піде першою, хоча її абсолютна бізнес-цінність нижча.
Такий підхід особливо корисний, коли затримка має конкретні наслідки: наприклад, означає втрату revenue, збільшує ризики, наближає команду до критичного дедлайну або блокує інші задачі.
RICE vs ICE: у чому різниця
Основна різниця між RICE та ICE у глибині оцінки та кількості даних для скорингу. ICE prioritization не враховує Reach окремо, тому ICE score можна швидше розрахувати навіть за обмеженої продуктової аналітики. Це зручно для первинного сортування великої кількості гіпотез і growth-експериментів.
RICE prioritization додатково враховує охоплення та Effort, тому потребує більше даних, але дозволяє краще порівнювати ініціативи різного масштабу. Тому ICE частіше використовують для швидкого скорингу growth backlog, а RICE — для продуктового roadmap, де важливо зіставити потенційний вплив із охопленням і витратами на реалізацію.
RICE vs WSJF: який підхід вибрати
RICE та WSJF по-різному визначають, що має бути зроблено раніше. RICE framework оцінює потенційний вплив ініціативи з урахуванням охоплення користувачів, упевненості в оцінці та необхідних ресурсів. WSJF натомість ставить у центр Cost of Delay — економічну ціну відкладання роботи.
Тому RICE зручний для продуктових команд, які порівнюють фічі з різним Reach та Effort. WSJF prioritization частіше застосовують у масштабніших delivery-процесах, де на черговість роботи впливають дедлайни, ризики, залежності та бізнес-можливості. Тобто важливо оцінити не лише потенційну користь задачі, а й те, що команда втратить, якщо зробить її пізніше.
Водночас Олена Тімченко не вважає, що заради цього обов'язково переходити з одного фреймворку на інший:
«Я особисто WSJF не використовувала. Для мене RICE достатньо гнучкий, тому що розмір задачі вже враховується через Effort, і за потреби в нього можна закласти додаткові параметри».
У її команді, наприклад, в Effort враховували не лише час розробки, а й роботу дизайнерів, тестувальників та продуктової команди. Тобто RICE адаптували під реальні витрати ресурсів конкретного продукту.
«Якщо WSJF у конкретній команді зрозуміліший, його простіше рахувати і він краще відповідає вашому процесу — чому ні. Для мене важливіше не те, який саме фреймворк використовується, а чи допомагає він команді швидше й аргументованіше приймати рішення», — додає Олена.
Як вибрати метод пріоритизації для своєї команди
Універсального методу пріоритизації немає. Вибір залежить від зрілості продукту, розміру команди, доступності даних, кількості ініціатив і швидкості, з якою потрібно ухвалювати рішення.
Для зрілого продукту з великою командою та кількома продактами Олена Тімченко радить:
«Я б використовувала адаптований під команду RICE з єдиною шкалою для всієї команди. Це допомагає зменшити суб'єктивність: усі продакти розуміють, як оцінювати ідеї, і можуть порівнювати їх між собою. Якщо ж продукт на ранньому етапі, даних мало, а продакт один, ускладнювати систему не варто. У такій ситуації продакт, скоріш за все, приблизно однаково оцінюватиме всі ідеї, а швидкість прийняття рішення важливіша за точність скорингу. Я сама в таких ситуаціях використовувала максимально простий підхід, щоб він хоча б був і не забирав час».
Тому метод можна змінювати разом із продуктом: те, що працює на ранньому етапі, не обов'язково залишиться оптимальним після появи більшої команди та даних.
Чому навіть хороший framework не приймає рішення замість команди
Будь-який score базується на оцінках і припущеннях команди. Reach можна спрогнозувати неточно, Impact — переоцінити, а Cost of Delay — по-різному трактувати. Тому результат формули варто сприймати не як готове рішення, а як основу для обговорення разом зі стратегією, ризиками, технічними залежностями та продуктовим контекстом.
Частину цього контексту можна закласти безпосередньо у скоринг. Олена Тімченко розповідає, що в її команді стратегічну важливість враховували в Impact:
«Звичайна задача отримувала 1 бал, пріоритетна „на зараз” — 10 балів, якщо без неї продукт надалі стратегічно страждатиме, а задача високого пріоритету для інвесторів — 20 балів».
Так важливі для стратегії або інвесторів задачі піднімалися вище всередині спільної системи, а не ставали винятками з неї.
«Для мене краще адаптувати скоринг під реальні правила продукту, ніж постійно робити винятки із системи».
Однак, навіть добре налаштований фреймворк може перетворитися на формальність. Олена виділяє кілька типових помилок:
PM оцінює все сам. Якщо продакт проставляє score «для галочки», команда його не перевіряє, а Effort оцінюється без розробників та інших залучених фахівців, точність такого скорингу сумнівна.
Прогноз не звіряють із фактом. Команда не повертається до попередніх оцінок і не перевіряє, наскільки реальні Effort та Impact збіглися з очікуваннями. У результаті система не враховує власні помилки.
Усі задачі отримують схожі бали. Якщо майже кожна ідея має однаковий Impact або близькі коефіцієнти, score перестає реально розділяти пріоритети.
Команда сперечається про цифри, а не про припущення. Дискусія «чому 7, а не 8» мало що дає, якщо ніхто не обговорює, на яких даних і аргументах базується ця оцінка.
Скорять усе підряд. Оцінювати 200 ідей, більшість із яких навіть не потрапить на планування, — зайва робота. За словами Олени, насамперед варто скорити ті ініціативи, між якими команді справді доведеться обирати.
У підсумку важлива не сама наявність формули, а те, чи покращує вона реальні рішення:
«Якщо скоринг не впливає на реальні рішення, не перевіряється фактами і не допомагає команді сперечатися про припущення, а не про цифри — це вже не інструмент пріоритизації, а просто ще одна таблиця чи дошка в таск-менеджері», — додає Олена.
FAQ
Що таке RICE prioritization?
RICE prioritization — метод пріоритизації продуктових ініціатив за чотирма параметрами: Reach, Impact, Confidence та Effort. Він допомагає порівнювати потенційний вплив задач, їхнє охоплення та необхідні для реалізації ресурси.
Як розрахувати RICE Score?
RICE Score = (Reach × Impact × Confidence) / Effort. Що вищий score, то вище за інших рівних умов ініціатива опиняється в пріоритеті.
Що таке ICE Method?
ICE method оцінює гіпотези за Impact, Confidence та Ease. Він потребує менше даних, ніж RICE, тому зручний для швидкого сортування великої кількості ідей і growth-експериментів.
Як працює WSJF?
WSJF prioritization порівнює Cost of Delay із Job Size. Чим дорожче команді обходиться затримка і чим менший відносний обсяг роботи, тим вищий пріоритет отримує задача.
Що краще для пріоритизації — RICE, ICE чи WSJF?
Універсального варіанта немає. ICE зручний для швидкого скорингу та роботи з невеликою кількістю даних, RICE — для порівняння продуктових ініціатив різного масштабу, а WSJF — коли важливо враховувати ціну затримки. Вибір залежить від зрілості продукту, доступних даних, структури команди та типу рішень, які вона ухвалює.
