скоринг фич что это
RICE и ICE Scoring: простые техники приоритизации для продвинутых менеджеров продукта
Каждый менеджер продукта рано или поздно сталкивается с вопросом приоритизации при планировании стратегии и роадмапа продукта. Всегда ли просто и быстро можно решить над чем работать в первую очередь?
Product roadmap требует четкого порядка. Только качественно разложив все «по полочкам» можно получить достойный и успешный релиз продукта. В этом случае не обойтись без удобного способа приоритизации.
Качественная система определения приоритетов поможет рассмотреть каждую фичу или идею, каждый проект или задачу и последовательно объединить все эти факторы.
Сегодня к услугам PM — множество популярных методологий для приоритизации от игровых до самых сложных, количественных и качественных. Все они помогают менеджерам и командам ответить на очень важный вопрос: как правильно выбрать фичи для разработки?
В этой статье мы рассмотрим две простые, но весьма полезные техники — RICE Scoring и метод определения приоритетов ICE.
Метод RICE Score
Если у вас в плане для реализации есть несколько важных и срочных фичей, как понять к какой приступить сначала?
Этот важный вопрос установления приоритетов лежит в основе всего product management. Плата за выбор неправильного варианта может быть слишком высокой.
RICE — это метод приоритизации идей и фич продукта. Аббревиатура включает 4 фактора, которые менеджер продукта может смело использовать для оценки и приоритизации продуктовых фич:
Reach (Охват)
Уровень охвата измеряется количеством людей/событий за определенный период времени. Этот фактор предназначен для оценки того, на какое количество людей каждая фича или проект повлияет в течение определенного периода времени, и сколько ваших пользователей увидят такие изменения.
Важно акцентировать внимание на реальных метриках, а не использовании непонятных чисел.
Например:
Фичей будет пользоваться 800 пользователей в месяц.
1000 пользователей вовлечены в онбординг, и 70% — только 700 пользователей увидят эту фичу.
Impact (Влияние)
Влияние показывает какой вклад приносит эта фича продукту.
Ценность понимается по-разному в каждом продукте. Например, в Hygger (B2B SaaS) для текущего квартала фичи получают высокое значение, если они:
1. Улучшают trial-to-paid конверсию (metric movers)
Исходя из ваших текущих целей у вас будут свои метрики.
2. Помогают привлечь новых пользователей
Это фичи, которые помогают нам получить новых пользователей во время онбординга. Но не стоит забывать о том, что большинство пользователей «отпадают» на второй день.
Например, в SaaS отличным индикатором удержания в первый день является показатель 15%. Это означает, что 85% людей просто уходят на второй день. Поэтому здесь вы должны подумать о фичах, которые большинство новых пользователей смогут увидеть в первой сессии.
3. Помогают сохранить текущих пользователей
Клиенты купили подписку и теперь просят сделать некоторые фичи. Мы не «спешим» слепо делать все подряд. Мы накапливаем статистику по каждой фиче — сколько клиентов просили об этом. И тогда мы реализуем самые популярные фичи.
4. Добавляют ценности продукту и отстраивают нас от конкурентов
На рынке сегодня более пяти сотен систем для управления проектами. Чтобы выжить и добиться успеха, нам нужно сделать что-то совершенно новое, желательно увеличить срок службы для пользователей или сократить затраты в несколько раз. Здесь мы ищем возможности, которые могут дать нам конкурентное преимущество, создадут причину, по которой клиенты конкурентов перейдут к нам. Это конкурентное преимущество должно быть уникальным, трудно повторяемым и, в идеале, не воспроизводимым.
К слову, влияние трудно измерить точно. Так, мы выбираем из шкалы с множеством вариантов: 3 для «массового влияния», 2 для «высокого», 1 для «среднего», 0,5 для «низкого» и, наконец, 0,25 для «минимального». Эти цифры умножаются на итоговый результат, чтобы масштабировать его ниже или выше.
Confidence (Уверенность в оценке)
Если вы считаете, что фича может иметь огромное влияние, но у вас нет данных для доказательства этого, Confidence позволяет проконтролировать этот момент. Confidence измеряют в процентах.
Effort (Трудозатраты)
Трудозатраты оцениваются как количество «человеко-месяцев», недель или часов, в зависимости от потребностей.
Например:
Проект A займет около недели планирования, 2 недели дизайна и 3 недели для разработки, поэтому трудозатраты составят 2 человеко-месяца.
Для проекта B потребуется только неделя планирования, 1-2 недели для разработки и не потребует дизайна. Трудозатраты будут равны 1 человеко-месяцу.
Метод оценки ICE
Метод определения приоритетов ICE был придуман Шоном Эллисом, который известен авторством термина Growth Hacker.
Первоначально ICE был предназначен для приоритизации экспериментов по росту. Позже ICE стали использовать и для приоритизации фичей.
ICE Scoring: Как это работает?
Рассчитайте оценку для каждой фичи или идеи, согласно формуле:
В ICE используется шкала от 1 до 10 чтобы все факторы сбалансированно влияли на итоговый бал. Вы можете подразумевать под 1-10 то что вам нужно, лишь бы значения были согласованы между собой.
В качестве примера, применим это к фиче «Виджеты для Dashboard»:
Недостатки ICE
ICE Scoring иногда подвергается критике за его субъективность:
Как использовать RICE и ICE Scoring?
Рассмотрим пример использования обеих моделей в сервисе для управления продуктами и проектами Hygger.io.
Оценка в Hygger по RICE
Сперва вам нужно оценить каждую фичу по критерию Reach, Impact, Confidence и Effort.
Все фичи также можно увидеть в таблице:
Так вы сортируете все фичи, оценивая их и выбираете “победителей” из верхушки списка, затем отправляя их в разработки с помощью фичи Push.
Оценка в Hygger по ICE
Такой же алгоритм и в случае с выбором модели оценки ICE.
Вам нужно оценить каждую фичу по критериям Impact, Confidence и Ease.
Удобная таблица также визуализирует все ваши фичи:
Другие способы приоритизации в Hygger
Приоритизация Value & Effort (aka Lean Prioritization)
Это простой способ приоритизации, основанный на матрице 2×2 с двумя осями: Сложность и
В Hygger, визуализировать матрицу помогает инструмент Priority Chart (доступен только для Value & Effort приоритизации):
Что дальше? Или как правильно выбрать фичи для разработки
Грамотно и вовремя выбирать фичи для разработки и не прогадать – это про искусство приоритизации. Как найти критерии оценки, необходимые для своего продукта, вырастить стратегические показатели, предложить клиентам еще больше ценности, наладить все внутренние процессы в команде и добиться других наглядных показателей с помощью качественной приоритизации?
Эта статья написана по материалам доклада “Что дальше? Или искусство приоритизации”, с которым я выступил 26 июня на конференции BDS. Marketing.
В докладе я рассказал о том, как мы приоритизируем фичи в компании Hygger.io — системе управления проектами для продуктовых команд.
Прежде чем перейти к описанию нашего процесса, хочу кратко напомнить о том, почему приоритизация так важна.
Почему без приоритизации не выжить?
«Управление продуктом» означает принятие решения о том, что мы делаем для продукта, а затем его реализацию.
Райан Сингер, продуктовая стратегия Basecamp
Управление продуктом состоит из трех больших блоков:
И не будем кривить душой — я думаю, что многие product managers кайфуют от такой «лепки». От возможности влиять на то, каким будет продукт.
Отвлекающие факторы буквально убивают стартапы. Строительство ради строительства подобно самоубийству. Поэтому наличие строгого и честного процесса приоритизации для разработки функций имеет решающее значение для контроля внимания и устранения лишнего.
Бен Йосковитц, автор Lean Analytics, инвестор и стартап ментор.
Легко взять и потратить бесценное время команды на разработку фич, которые никому не нужны. Особенно эта проблема актуальна для стартапов, время и бюджет которых очень сильно ограничены.
Заблуждается тот, кто считает, что новая добавленная фича сразу заставит людей захотеть использовать весь продукт.
Джошуа Портер, UX директор в HubSpot
Стоит вспомнить интуицию — нашего лучшего «помощника», который постоянно «шепчет» нам на ухо: «Вот эта фича ну точно всех порвет!» И в другое ухо: «А вот эта фича догонит и порвет всех, кого не порвала первая фича».
Мы делаем такие фичи и потом удивляемся, почему вообще ничего не изменилось в продукте.
Известный в Силиконовой долине Marty Cagan в своей книге Inspired выделил три типа менеджеров продукта:
Процесс приоритизации в Hygger
Теперь я хочу рассказать о процессе, который помогает нам в Hygger выбирать будущие фичи и делать продукт все лучше и лучше.
На самом деле, все просто: мы ставим себе цели на 2 месяца, выбираем метрики для контроля, собираем и отбираем идеи, которые могут улучшить эти метрики. Далее мы проводим бережливую приоритизацию идей, делаем скоринг фич, и, наконец, пишем ТЗ на фичи, которые выиграли. Вот и все — фичи готовы к разработке.
Если все это систематизировать:
Формулируем Цели
У нас в продукте есть 2-х недельный trial. Мы хотим увеличить число компаний, которые после триала покупают платную подписку. Это наша основная цель на ближайшие 2 месяца. Также нам нужно отстроиться от конкурентов, ибо на рынке порядка 500 систем для управления проектами.
Выбираем Метрики
У нас есть основная метрика и вспомогательные. Важно, что все эти метрики находятся в нашей зоне влияния.
Основная метрика — конверсия trial-to-paid.
У каждого продукта своя ценность. Например, в Tinder это успешный обмен сообщениями, в Facebook — просмотр непустой ленты в течение какого-то времени.
Пользователей, которые прочувствовали эту ценность мы называем активированными. Наша задача увеличить число таких пользователей. В Facebook посчитали и выяснили, что на активацию влияет число друзей — чем больше друзей, тем больше лента и тем больше времени юзер зависает в ленте и больше рекламы смотрит.
Собираем идеи
Вот главные источники обратной связи для нашего продукта:
Организуем идеи
Так как фидбэка у нас очень много, то мы постоянно наводим порядок в нашем продуктовом бэклоге. Это помогает нам быстро находить нужные вещи и не отвлекаться на ненужные.
Как мы структурируем наш product backlog:
Делаем Lean-приоритизацию
Периодически, по мере накопления новых идей мы оцениваем их с помощью метода Lean Prioritization. Это простая матрица 2×2 c двумя осями — сложность и ценность:
1) Улучшают метрики конверсии trial-to-paid (metrics movers)
2) Помогают привлечь новых пользователей (aha-момент)
Это фичи, которые помогают нам зацепить новых пользователей во время онбординга. Но не нужно забывать про то, что большинство юзеров «отвалиться» уже на второй день. Например, в SaaS отличным показателем для day 1 retention считается 15%. То есть 85% людей попросту уходят на второй день. Поэтому здесь следует думать про фичи, которые увидит как можно больше новых пользователей как можно ближе к моменту регистрации.
3) Помогают удержать старых пользователей
Клиенты купили подписку и теперь просят сделать какую-то фичу. Мы не «бросаемся» слепо делать все подряд. Мы накапливаем статистику по каждой фиче — сколько клиентов ее просили. И потом делаем самые востребованные фичи.
4) Добавляют ценности продукту и отстраивают нас от конкурентов
На рынке порядка 500 систем управления проектами. Чтобы выжить и преуспеть, нам нужно делать что-то совершенно новое, желательно кратно улучшающее жизнь пользователей или кратно сокращающее издержки.
Здесь мы ищем фичи, которые могут дать нам конкурентное преимущество, то есть создадут причину, из-за которой клиенты конкурентов придут к нам. Это конкурентное преимущество должно быть уникально, трудно повторимо и, в идеале, не воспроизводимо.
Planning Poker
Для оценки идей мы используем Planning Poker:
Техники приоритизации
Daniel Zacarias собрал в коллекцию 20 техник приоритизации и сгруппировал их по двум свойствам — внешняя/внутренняя и количественная/качественная техника.
Пример внешней количественной техники — модель Кано, где мы даем опросник пользователям. А пример внутренней количественной техники — Lean Prioritization (или Value vs Cost). Я описал этот метод выше.
Скоринг Фичей
Скорим мы не все фичи, а только те, которые выиграли в Lean Prioritization, потому что скоринг — трудозатратная операция.
Мы оцениваем каждую фичу по выбранным критериям, по шкале от 0 до 10. Далее эти значения умножаем на веса и получаем некую финальную числовую оценку, которая позволяет нам сравнивать фичи между собой.
Критерии для скоринга
Вот различные критерии, которые можно использовать для скоринга:
Результаты
Итак, какие результаты принес нам этот процесс:
Что такое скоринг и как он помогает организовывать задачи при разработке продукта
Если вы планируете запуск какого-либо продукта, вам нужно не только правильно определить цели (об этом мы писали здесь), но и расставить их в определенном порядке. Для этого подойдет скоринг (scoring) задач. Какие методы расстановки задач существуют и как они помогают сделать выбор в сложных ситуациях, нам рассказал Юрий Бранковский, продакт-менеджер с 7-летним опытом работы в ИТ, ментор и член жюри хакатонов Emerge и Epam engineering jam.
Юрий Бранковский
Ментор и член жюри хакатонов Emerge и Epam engineering jam
— Скоринг задач (приоритизация списка задач) — один из инструментов, который регулярно используют при разработке и запуске продукта. Скоринг нужен для очистки бэклога от ненужных, бесполезных или утративших актуальность задач или для определения состава роадмэпа продукта, продуктового портфеля компании. Сам по себе скоринг ничего не дает и как любой инструмент может принести компании и пользу, и вред. Поэтому важно понимать, как, где и когда его применение актуально.
Бэклог — это журнал оставшейся работы, которую необходимо выполнить команде.
Относительный скоринг
Если просто применять ту или иную модель скоринга, без глубокого анализа данных, существует риск начать оценивать экспертно, то есть — основываясь на собственном опыте, интуиции и выводах. Например, менеджер говорит фразу: «Компания N произвела такие-то действия и получила такие-то результаты, поэтому считаю, что нам необходимо сделать так же». Это — экспертная оценка, которая не учитывает специфику текущей ситуации, продукта и факта, что компания N уже вышла на рынок. В данной ситуации менеджер пытается перенести чужой опыт на свою компанию без каких-либо оснований. Или, например, менеджеру просто так нравится его идея, что он пытается «подогнать» итоговый балл скоринга, чтобы «фича» (идея с неким рыночным преимуществом) пошла в разработку.
Поэтому даже те формулы скоринга, которые используют множество параметров, могут дать нерелевантный итоговый балл. Не стоит оценивать что-то «в лоб», необходимо понимать, относительно чего выставляется оценка: относительно цели, влияния на фокус компании, метрики, выручки и пр. Выбор ключевого параметра зависит от специфики продукта и команды.
Например, продуктовые команды концентрируются на LTV (lifetime value) и Retention (коэффициент удержания пользователя/клиента). А «команды роста» (отвечают за разработку проектов, потенциально сулящих компании кратный рост) оценивают проекты и «фичи» относительно выручки или количества пользователей.
Если проект оценивать относительно влияния на фокус компании, глобальную цель, то все равно стоит любому фокусу и цели сопоставлять цифры. Поэтому лучше всего для скоринга использовать понятную метрику, которую просто посчитать и проще спрогнозировать степень ее изменения.
Например, фокус компании на международную экспансию можно оцифровать количеством активных зарубежных пользователей, количеством стран, количеством заключенных контрактов с компаниями и т.д. Чтобы команды понимали, как их работа и отдельные «фичи» влияют на движение компании относительно фокуса, лучше всего использовать дерево метрик. Этот метод позволяет декомпозировать глобальные цели до фундаментальных показателей, с которыми проще работать продакт-менеджерам.
Рис. 1. Пример дерева метрик маркетплейса курсов.
Важно, чтобы метрики сопоставлялись с P&L компании (profit & loss report, отчет о прибыли и убытках). Таким образом продакт-менеджеры и команды будут чувствовать большую ответственность, так как влияют не на абстрактный параметр, а на деньги. То есть буквально дерево метрик должно быть математическим «скелетом» компании.
Например, на рисунке 1 показано верхнеуровневое дерево метрик маркетплейса образовательных курсов, в котором количество оплаченных курсов определяется более низкоуровневыми метриками:
Количество оплаченных курсов = трафик х конверсию в заявку х конверсию в оплату.
При этом объем трафика зависит от количества партнеров. И если декомпозировать дерево дальше, можно составить ветвь метрик для отдела продаж, где партнеры будут разбиты на категории (например, по объему трафика), а менеджеры будут обзванивать те сегменты, которые приводят больше потенциальных покупателей.
Таким образом, команды получат четкую метрику, которая:
1) позволяет производить скоринг, опираясь на четкие, понятные данные (количество оплаченных курсов, конверсия в заявку и оплату)
2) дает понимание, как именно команды своей работой влияют на глобальную цель компании (что повышает и эффективность работы, и мотивацию).
Модели скоринга
Существует много моделей скоринга, начиная от подсчета «по здравому смыслу» и заканчивая формулами, позволяющими рассчитать конкретный балл для каждого проекта или «фичи». Одни компании используют стандартные модели, другие кастомизируют их «под себя». Единого подхода нет, главное, чтобы модель решала основную задачу — делать то, что приводит компанию или продукт к поставленной цели (о правильной расстановке целей мы писали вот здесь).
Скоринг проектов относительно показателя Return On Investment (коэффициент окупаемости инвестиций). Чем выше ROI проекта, тем раньше этот проект необходимо сделать, закончить. При этом можно устанавливать минимальный порог проекта: например, проекты с ROI меньше 300% — вообще не брать в работу. Хорошим ROI считается показатель от 300%, в остальных случаях получается, что проект сработал практически «в ноль». Больше 1000% — это уже подозрительный показатель. Но рост до 10 раз вполне возможен, если, например, очень дешевая в реализации идея принесла много новых пользователей.
Фото: iq-adv.ru
((Доход от вложений — размер вложений) / Размер вложений)*100% = ROI (коэффициент окупаемости вложений)
Это хороший метод для расчета маркетинговых проектов и «фичей», профит которых достаточно просто посчитать. Если оценить профит от проекта сложно, то показатель может быть сильно завышен. Однако, с другой стороны, необходимость максимально точного расчета дохода от проекта позволяет лучше проанализировать сам проект (продукт, «фичу») и понять, как она («фича») влияет на финансовые показатели.
Для SaaS-сервисов можно использовать другую формулу:
((Жизненная ценность клиента — стоимость приобретения клиента) / стоимость приобретения клиента)*100% = ROI, где жизненная ценность клиента = CLV = (средняя стоимость покупки х среднее количество повторных покупок).
Например, у вас есть две кампании. Одна стоит 100 тыс. руб. РФ, вторая — 200 тыс. руб. РФ. Потенциально первая может принести 1000 новых пользователей, вторая — 4000 пользователей. Сперва вторая кажется более выгодной, так как стоимость привлечения клиента в два раза меньше. Но разработка первой кампании будет стоить 60 тыс. руб., а второй — 150 тыс. руб. Например, за счет необходимости партнерских интеграций и дополнительной разработки. При этом в первом случае вы ведете пользователя на свой лендинг, где он покупает услугу за 200 рублей, а во втором случае вы даете скидку 50% (100 руб.) в рамках акции с партнером.
Таким образом, считая все данные и полагая CLV одинаковыми для обоих случаев, получаем:
Получается, что обе компании невыгодны при подобной экономике (ROI 
Рис. 2. Формула расчета RICE
Уровень охвата (Reach) измеряют количеством людей/событий за определенный период времени. Например, «фича» для онбординга будет касаться всех новых пользователей, но не будет важна для старых пользователей. При этом надо учитывать, что если онбординг пользователи проходят один раз, то при уменьшении трафика охват также будет меняться. В отличие, например, от основных (старых) пользователей, количество которых не сильно меняется, если Retention вышел на плато.
Онбординг (onboarding) — это процесс, через который проходят пользователи от начала своего пути до становления клиентом и далее.
Если в продукте речь идет о миллионах пользователей, то лучше разбить их на сегменты, например, где 1 — «меньше миллиона пользователей», а 10 — «10 миллионов», и в расчете указывать цифры от 1 до 10, чтобы не считать «фичи» в миллионах.
Влияние (Impact) показывает, какой вклад приносит эта «фича» продукту. Измеряться может в баллах (1 — слабое влияние, 3 — сильное влияние). Ценность показателя понимается по-разному в каждом продукте. Лучше всего делать этот показатель минимально субъективным. Например, оценить, насколько новая «фича» может потенциально увеличить в онбординге конверсию в первую оплату. Таким образом, можно будет сравнивать разные «фичи» относительно единого показателя — денег.
Показатель Confidence призван снизить влияние экспертности в оценке предыдущих показателей, однако опыт показывает, что и уверенность часто завышают. Чаще всего 100%-ный показатель ставят для «фичи», у которой есть оценка трудозатрат, данные аналитики или АБ-теста либо исследования, которые могут подтвердить необходимость релиза. Однако даже наличие всего этого не гарантирует 100%-ного результата.
Вдобавок, одно дело — оценка гипотезы (9 из 10 гипотез проваливаются, получается, что confidence вообще не поднимется выше 10%), другое — «фичи», которые разрабатывают уже после экспериментов. Однако бывают ситуации, когда после раскатки эксперимента он показывает результаты хуже, хотя во время теста все было ок. Например, такое может быть в сложных операционных продуктах. Также этот показатель может быть рассчитан более субъективно, в баллах, где 1 — «слабо верим», 2 — «верим», 3 — «сильно верим». Но я бы советовал все-таки прописывать критерии оценок «сильно, слабо», чтобы снижать субъективность и экспертность скоринга.
Трудозатраты (Effort) оценивают как количество «человеко-месяцев», недель, дней или часов, в зависимости от специфики разработки и ее уровня. Главное, чтобы оценка всех проектов была в одних единицах.
Например, у вас две «фичи»: одна — в онбординге, вторая — в основном продукте. Охват первой составляет 1000 пользователей, второй — 500. Влияние «фичи» оцениваем по шкале 1–3: «не сильно», «сильно», «кардинально». И для первой она составляет 3, для второй 2. То есть «фича» в онбордниге может кардинально повлиять на конверсию в оплату, а та, что в продукте — сильно повлиять на retention. Сложность первой 4 (недели разработки), второй — 2. Для альтернативного примера посчитаем уверенность не в процентах, а также по трехбалльной шкале («слабо верим», «верим», «сильно верим»): 1 для первой и 2 для второй. Таким образом, получаем:
То есть берем в работу вторую «фичу», для продукта.
Этот метод определения приоритетов был придуман Шоном Эллисом, который известен авторством термина Growth Hacker.
В ICE используется шкала от 1 до 10, чтобы все факторы сбалансировано повлияли на итоговый балл (все составляющие оцениваются в баллах, а не в реальных показателях). Оценивать можно то, что вам нужно, лишь бы все значения были согласованы между собой (руководствуясь логикой). Оценка получается достаточно субъективной, потому что перевод в баллы не имеет четкого критерия. Но этот метод можно кастомизировать «под себя», чтобы он стал точным. Также можно использовать комбинированные модели, которые сочетают в себе несколько моделей оценки (например, как в весовой модели).
Весовая модель
Такая модель даже может содержать в себе вышеупомянутые системы, чтобы сделать оценку более сбалансированной и учитывающей специфику команды. Также это позволяет не забывать про стратегические и блокирующие проекты, у которых другие показатели могут быть относительно невысокими.
В любом случае важно описывать принцип проставления баллов, чтобы оценка была максимально прозрачной для всей компании.
Также важно проверять, что все показатели оцениваются в одинаковых единицах. То есть некорректно сравнивать проекты, где Impact в одном случае оценивается в деньгах, а в другом — в степени влияния на метрику, тогда лучше все пересчитать в деньги. Также комбинированный метод позволяет оценивать стоимость всех проектов и сравнивать со стоимостью команды. Продуктовый портфель нужно составлять таким образом, что даже если из 10 проектов «выстрелит» 1, то он должен окупить команду с положительным показателем.
Рис. 4. Пример весовой модели.
Как оценить уверенность (confidence)
По своему опыту могу сказать, что уверенность вызывает всегда больше вопросов и у менеджеров, и у разработки. Если остальные показатели можно оценить достаточно точно, то как оценить уверенность? И как снизить влияние «желания запилить эту красивую «фичу», чтобы не получилось так, что подсознание подгоняет результаты скоринга под желаемую «фичу»? Лучше всего договориться внутри команды или компании о том, какие могут быть уровни уверенности при использовании в скоринговых моделях. Например, можно использовать инструмент, предложенный Итамаром Гиладом, продакт-менеджером Google и Microsoft с более чем 20-летним стажем работы.
Рис. 5. Определение уровня уверенности.
Рассмотрим уровни подробнее:
Так как не все «фичи» доходят до запуска, то при скоринге проектов на этапе планирования можно умножать уровень уверенности на 0,1 (исходя из того, что «выстреливает» лишь 1 гипотеза из 10). Таким образом, можно начать с проектов, у которых много подтверждений, и параллельно дополнить данными другие проекты — для повышения уровня уверенности, который в итоге повлияет на место проекта или «фичи» в общем бэклоге.
Вывод
Вне зависимости от инструмента, который вы выберете для скоринга, важно помнить про три ключевых момента:
Также важно презентовать вашу систему скоринга стейкхолдерам и команде, чтобы оценка была максимально прозрачной. Во время презентации вы еще и дополнительно проверите ваш метод «на прочность».