У любой команды всегда много задач в бэклоге. Они туда попадают из различных источников: собственные идеи команды, создателей, инвесторов, ожидания пользователей и так далее. Зачастую список задач для проработки разрастается до невероятных размеров.
В этой ситуации возникает необходимость выбора того, что делать в первую очередь. И бывает, что этот процесс идет интуитивно. Команда сама решает что и как делать в первую очедерь. А это не всегда лучшее решение.
Разбираемся как приоритизировать задачи из бэклога для наиболее эффективного развития продукта.
- Как подойдти к задаче выбора приоритетов
- Подходы к приоритизации
- Количественный и качественный подход в приоритизации
- Внешний и внутренний подходы
- Первичная и глубинная оценки бэклога
- Оценка в виде отношения пользы и трудозатрат
- Двухшаговый скоринг
- Первичный скоринг
- Финальный скоринг
- Метод с оценкой влияния и уверенности
- Модель Кано — измерение влияния
- Иерархия меток для приоритизации
- Базовый расчет ROI
- Детализируем подметрики
- Добавляем разные сценарии
- Плюсы и минусы приоритизации на основе ROI
- Ошибки в процессе приоритизации бэклога
- Итоговый пошаговый план приоритизации
Как подойдти к задаче выбора приоритетов
В чем надо разобраться в первую очередь
- Подходы к приоритизации.
- Методы выбора приоритетов для развития продукта.
- Плюсы и минусы подходов и методов.
- Основные ошибки при выборе задач для проработки.
Подходы к приоритизации
С точки зрения самого продукта подходы к приоритизации могут быть количественные и качественные. А относительно компании и команды: внутренние и внешние.
Количественный и качественный подход в приоритизации
Количественный подход — мы реализуем как можно больше функций, фич.
Качественный — мы реализуем самый важный и полезный функционал и не гонимся за числом релизов.
Внешний и внутренний подходы
Внешний — ориенитруемся на обратную связь пользователей, клиентов. Основная польза на старте проекта, когда нужно лучшее понимание потребностей клиента. Можно определить характеристики, которые не приносят ценности клиентам.
Внутренний подход к приоритизации состоит в том, что выбираем задачи командой проекта. Дальнейшее уточнение результатов, полученных внешними методами. Приоритет задач, в которых есть уверенность на основе ожиданий пользователей. Также внутренние подходы хорошо подходят для быстрой приоритизации “дешевых” с точки зрения разработки задач.
Разные подходы можно распределить на осях координат, где ось Х: от внутренних к внешним, а ось Y: от качественных до количественных показателей.
Первичная и глубинная оценки бэклога
Практически всегда можно провести двухшаговую оценку бэклога.
Первичная оценка позволяет отбросить все Не подходящие задачи по определенным критериям. Глубинная проработка направлена на выбор из оставшихся.
Например рассмотрим два параметра: охват и частота использования функции.
Охват — это сколько пользователей пользуются/будут пользоваться функцией. Возможный диапазон от “никто” до “все”.
Частота — как часто пользуются (предполагаем что будут пользоваться) клиенты. Диапазон: от “никогда” до “всегда”.
Ряд идей (гипотез) из бэклога можно распределить на в диапазонах этих параметров.
Охват / Частота | Никто | Мало кто | Некоторые | Большинство | Все |
Никогда | Гипотеза 10 | Гипотеза 8 | |||
Иногда | Гипотеза 9 | ||||
Редко | Гипотеза 1 | Гипотеза 3 | |||
Часто | Гипотеза 5 | Гипотеза 6 | Гипотеза 4 | ||
Всегда | Гипотеза 7 | Гипотеза 2 |
Оценка в виде отношения пользы и трудозатрат
Еще один способ выделить приоритетные идеи — это оценить пользу и трудозатраты.
Например, нам надо оценить пять фич, из которых мы хотим выбрать.
Последовательность такая:
- Проводим опрос среди клиентов, просим расставить баллы полезности фичи. Каждом по 3 балла. 1 — низкая оценка. 3 — высшая оценка.
- Суммируем баллы и делим на число опрашиваемых, получаем Среднюю оценку Пользы.
- Уточняем в команде разработки трудоемкость каждой из фич также баллами, получаем Среднюю оценку.
- Делим Среднюю балл “Пользы” на Средний балл “Трудозатрат” и получаем результаты.
Средняя оценка пользы | Средняя оценка трудозатрат | Польза / Трудозатраты | |
Фича 1 | 1,75 | 1,00 | 175% |
Фича 2 | 3,00 | 2,00 | 150% |
Фича 3 | 3,00 | 1,50 | 200% |
Фича 4 | 2,25 | 3,00 | 75% |
Фича 5 | 3,50 | 4,00 | 88% |
Очевидно, что Фича 3 по отношению Пользы к Трудоемкости лидирует относительно остальных. Вот и приоритет.
Двухшаговый скоринг
На первом шаге провести опрос среди клиентов и команды с расстановкой баллов. Потом финально оценить исходя из некоторых параметров.
Первичный скоринг
Есть 5 гипотез. Выдать каждому участнику по 5 баллов и попросить проголосовать за гипотезы, используя только эти 5 баллов. То есть участник может использовать максимум 5 баллов и при этом свободен в их распределении. Хоть одному проекту 5, а остальным по 0. Хоть всем по 1.
Андрей | Кирилл | Сергей | Марина | Олег | Даша | Саша | Скоринг | |
Фича 1 | 1 | 0 | 0 | 1 | 1 | 2 | 3 | 8 |
Фича 2 | 0 | 1 | 2 | 2 | 2 | 1 | 2 | 10 |
Фича 3 | 0 | 1 | 1 | 0 | 1 | 0 | 0 | 3 |
Фича 4 | 3 | 2 | 2 | 0 | 0 | 2 | 0 | 9 |
Фича 5 | 1 | 1 | 0 | 2 | 1 | 0 | 0 | 5 |
5 | 5 | 5 | 5 | 5 | 5 | 5 |
Фича 2 набрала 10 голосов
Фича 4 — 9
Фича 1 — 8
Это лидеры. Теперь переходим ко шагу 2.
Финальный скоринг
Надо отдельно углубится в оценку лидеров из первой итерации.
Выделяем важные параметры. Например: Аудитрия, Конверсия, Выручка и стомость Разработки.
При этом начисляем баллы фичам исходя из заданных условия.
Аудитория
1 балл — десятки пользователей
2 балла — сотни
3 балла — тысячи пользователей
Конверсия
1 балл — <1%
2 балла — <5%
3 балла — >5%
Выручка
1 балл — десятки тысяч
2 балла — сотни тысяч
3 балла — миллионы
Разработка оценивается отдельно исходя из трудозатрат.
Аудитория (А) | Конверсия (К) | Выручка (В) | Разработка (Р) | Итого | |
Фича 1 | 1 | 2 | 2 | 10 | 0,17 |
Фича 2 | 2 | 2 | 2 | 2 | 1,00 |
Фича 4 | 3 | 1 | 3 | 15 | 0,16 |
Финальная формула: Итого = (А/3+К/3+В/3)/Р.
После расчетов видим, что Фича 2 в приоритете для реализации благодаря низкой стоимости разработки.
Метод с оценкой влияния и уверенности
Есть охват пользователей, которых затронет новая фича.
Есть влияние этой фичи на пользователя. Например, на всех — 3, высокое влияние — 2, среднее влияние 1, минимальное — 0.25.
Есть наша уверенность в этой фиче. Например, высокая 100%, средняя — 80%, низкая — 50%.
И есть оценка затрат на реализацию: сколько человеко-часов трудозатрат.
Охват | Влияние | Уверенность | Разработка | Итого | |
Фича 1 | 300 | 3 | 100% | 2 | 450,00 |
Фича 2 | 2 500 | 2 | 80% | 4 | 1 000,00 |
Фича 4 | 900 | 1 | 50% | 1 | 450,00 |
Итого = (Охват * Влияние * Уверенность)/ Разработку.
После расчетов видны приоритеты для поднятия из бэклога.
Модель Кано — измерение влияния
Проводя опрос важно задать вопрос про отношение пользователя к наличию и отстутствию функции. Желательно между этими двумя вопросами интегрировать другие вопросы.
Если фича попала в красную область — значит, если ее убрать, клиенты будут расстроены, не будут пользоваться вашим продуктом.
Зеленая зона — зона роста продукта.
Белая область — клиентам все равно.
Иерархия меток для приоритизации
- Важно ранжировать метрики в соответствии с иерархией. То есть начинаем движение от метрик, а не проектов.
Например, может быть такая вложенность для метрик активности пользователя. Чем ближе метрика к Глобальной метрике — тем она больше влияет на продукт и удовлетворенность пользователя.
Глобальная | Уровень 1 | Уроверь 2 | Уровень 3 |
Активность -> | Вовлеченность-> | Длительность просмотра-> | % Дочитывания |
- Выбираем 3 метрики для дальнейшей работы.
- Далее отталкиваемся от гипотез, связанных с метриками.
То есть выбираем метрику, формулируем гипотезу для роста показателя метрики и проекты (фичи), которые по нашему мнению могут продвинуть эту метрику.
Желательно выбираить гипотезы с соотношением 20/80 (затраты/влияние).
- Оцениваем Влияние по каждой гипотезе.
- Оцениваем Затраты по каждой гипотезе.
- Делаем приоритизацию проектов/фич внутри каждой из метрик.
Базовый расчет ROI
Детализируем подметрики
Добавляем разные сценарии
Плюсы и минусы приоритизации на основе ROI
Преимущества:
- Цифрам больше доверия.
- Получаешь оценку в деньгах и понимаешь сколько принисет доработка.
Недостатки:
- Трудозатратный метод.
- Многое зависит от скиллов продакта.
- Функции, которые не понятно как оценить — не будут сделаны.
Ошибки в процессе приоритизации бэклога
- Когда оценка задач из бэклога проводится в одиночку.
- Не учитывается влияние новой фичи на другие части продукта.
- Количественная оценка не обязательно лучше, чем качественная.
- Отталкиваться в первую очередь от мнения “дотошных” клиентов.
- Постоянно закапываться в мелких доделках.
Итоговый пошаговый план приоритизации
- Выбираем несколько ключевых метрик.
- Собираем перечень гипотез для проверки.
- Используем качественные методы если рынок и продукт новый.
- Проводим быструю оценку и отбрасываем слабые гипотезы.
- Проводим детальную оценку оставшихся кандидатов.