- PVSM.RU - https://www.pvsm.ru -
Каждый менеджер продукта рано или поздно сталкивается с вопросом приоритизации при планировании стратегии и роадмапа продукта. Всегда ли просто и быстро можно решить над чем работать в первую очередь?
Product roadmap [1] требует четкого порядка. Только качественно разложив все «по полочкам» можно получить достойный и успешный релиз продукта. В этом случае не обойтись без удобного способа приоритизации.
Качественная система определения приоритетов поможет рассмотреть каждую фичу или идею, каждый проект или задачу и последовательно объединить все эти факторы.
Сегодня к услугам PM — множество популярных методологий для приоритизации от игровых до самых сложных, количественных и качественных. Все они помогают менеджерам и командам ответить на очень важный вопрос: как правильно выбрать фичи для разработки [2]?
В этой статье мы рассмотрим две простые, но весьма полезные техники — RICE Scoring и метод определения приоритетов ICE.
Если у вас в плане для реализации есть несколько важных и срочных фичей, как понять к какой приступить сначала?
Этот важный вопрос установления приоритетов лежит в основе всего product management. Плата за выбор неправильного варианта может быть слишком высокой.
RICE — это метод приоритизации идей и фич продукта. Аббревиатура включает 4 фактора, которые менеджер продукта может смело использовать для оценки и приоритизации продуктовых фич:
Чтобы получить оценку по RICE, вам необходимо объединить эти факторы.
Уровень охвата измеряется количеством людей/событий за определенный период времени. Этот фактор предназначен для оценки того, на какое количество людей каждая фича или проект повлияет в течение определенного периода времени, и сколько ваших пользователей увидят такие изменения.
Важно акцентировать внимание на реальных метриках, а не использовании непонятных чисел.
Например:
Фичей будет пользоваться 800 пользователей в месяц.
1000 пользователей вовлечены в онбординг, и 70% — только 700 пользователей увидят эту фичу.
Влияние показывает какой вклад приносит эта фича продукту.
Ценность понимается по-разному в каждом продукте. Например, в Hygger (B2B SaaS) для текущего квартала фичи получают высокое значение, если они:
Исходя из ваших текущих целей у вас будут свои метрики.
Это фичи, которые помогают нам получить новых пользователей во время онбординга. Но не стоит забывать о том, что большинство пользователей «отпадают» на второй день.
Например, в SaaS отличным индикатором удержания в первый день является показатель 15%. Это означает, что 85% людей просто уходят на второй день. Поэтому здесь вы должны подумать о фичах, которые большинство новых пользователей смогут увидеть в первой сессии.
Клиенты купили подписку и теперь просят сделать некоторые фичи. Мы не «спешим» слепо делать все подряд. Мы накапливаем статистику по каждой фиче — сколько клиентов просили об этом. И тогда мы реализуем самые популярные фичи.
На рынке сегодня более пяти сотен систем для управления проектами. Чтобы выжить и добиться успеха, нам нужно сделать что-то совершенно новое, желательно увеличить срок службы для пользователей или сократить затраты в несколько раз. Здесь мы ищем возможности, которые могут дать нам конкурентное преимущество, создадут причину, по которой клиенты конкурентов перейдут к нам. Это конкурентное преимущество должно быть уникальным, трудно повторяемым и, в идеале, не воспроизводимым.
К слову, влияние трудно измерить точно. Так, мы выбираем из шкалы с множеством вариантов: 3 для «массового влияния», 2 для «высокого», 1 для «среднего», 0,5 для «низкого» и, наконец, 0,25 для «минимального». Эти цифры умножаются на итоговый результат, чтобы масштабировать его ниже или выше.
Если вы считаете, что фича может иметь огромное влияние, но у вас нет данных для доказательства этого, Confidence позволяет проконтролировать этот момент. Confidence измеряют в процентах.
Например
Проект A: У менеджера продукта есть количественные показатели для влияния фичи, и оценка трудозатрат. Таким образом, проект получает 100% -ную оценку уверенности.
Проект B: У менеджера продукта есть данные по охвату и трудозатратам, но он не уверен в отношении фактора влияния. Проект получает коэффициент доверия в 80%.
Проект C: Данные охвата и влияния могут быть ниже, чем предполагалось. Трудозатраты могут быть выше. Проект получает 50%-ную оценку доверия.
Трудозатраты оцениваются как количество «человеко-месяцев», недель или часов, в зависимости от потребностей.
Например:
Проект A займет около недели планирования, 2 недели дизайна и 3 недели для разработки, поэтому трудозатраты составят 2 человеко-месяца.
Для проекта B потребуется только неделя планирования, 1-2 недели для разработки и не потребует дизайна. Трудозатраты будут равны 1 человеко-месяцу.
Метод определения приоритетов ICE был придуман Шоном Эллисом, который известен авторством термина Growth Hacker.
Первоначально ICE был предназначен для приоритизации экспериментов по росту. Позже ICE стали использовать и для приоритизации фичей.
Рассчитайте оценку для каждой фичи или идеи, согласно формуле:
В ICE используется шкала от 1 до 10 чтобы все факторы сбалансированно влияли на итоговый бал. Вы можете подразумевать под 1-10 то что вам нужно, лишь бы значения были согласованы между собой.
В качестве примера, применим это к фиче «Виджеты для Dashboard»:
ICE Scoring иногда подвергается критике за его субъективность:
Рассмотрим пример использования обеих моделей в сервисе для управления продуктами и проектами Hygger.io.
С чего начать?
Во-первых, у вас должны уже быть собранными необходимые фичи и идеи продукта на вашей Kanban-доске. Используя Hygger, вы можете структурировать их с помощью горизонтальных колонок Swimlanes, а также применяя Labels. Вы также можете настроить процесс работы с фичами с помощью Columns. К примеру, можно создать следующий рабочий процесс:
В меню Hygger вы найдете варианты моделей для оценки и приоритизации фичей, в том числе, RICE и ICE:
Сперва вам нужно оценить каждую фичу по критерию Reach, Impact, Confidence и Effort.
Все фичи также можно увидеть в таблице:
Так вы сортируете все фичи, оценивая их и выбираете “победителей” из верхушки списка, затем отправляя их в разработки с помощью фичи Push.
Push работает так:
Если у вас Еpic на бэклог-доске, то вы можете сослаться из него на несколько задач по разработке (например, одна задача — на frontend разработку, вторая — backend, третья — мобильное приложение для ios, четвертая — для Android). Epic будет «выполнен» тогда, когда будут «выполнены» все задачи по разработке, на которые он ссылается.
Такой же алгоритм и в случае с выбором модели оценки ICE.
Вам нужно оценить каждую фичу по критериям Impact, Confidence и Ease.
Удобная таблица также визуализирует все ваши фичи:
Это простой способ приоритизации, основанный на матрице 2×2 с двумя осями: Сложность и
Ценность:
Как правило мы используем и рекомендуем использовать Value & Effort приоритизацию для оценки идей или первичного отбора фичей для последующей оценки по ICE/RICE или по своим критериям (Weighted Scoring).
В Hygger, визуализировать матрицу помогает инструмент Priority Chart (доступен только для Value & Effort приоритизации):
Кроме того, в меню Hygger вы можете выбрать приоритизацию по собственным критериям — Weighted Scoring. Но об этой системе оценки и ее преимуществах мы обязательно расскажем подробнее в одной из следующих статей.
Автор: Александр Сергеев
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/291476
Ссылки в тексте:
[1] Product roadmap: https://habr.com/company/hygger/blog/352294/
[2] как правильно выбрать фичи для разработки: https://habr.com/company/hygger/blog/416683/
[3] Источник: https://habr.com/post/422131/?utm_source=habrahabr&utm_medium=rss&utm_campaign=422131
Нажмите здесь для печати.