Как убедиться, что мы не расходуем зря время коллег и ресурсы компании, а занимаемся по-настоящему важными делами?
Представим себе, что мы организовали мозговой штурм, изобрели множество путей усовершенствования продукта и сбора обратной связи. Теперь мы в состоянии создать дорожную карту развития продукта. Но в какой последовательности всё это реализовывать? Нужно установить приоритеты.
Гипотеза
Таких гипотез будет много. Будем определять приоритетность каждой из них, чтобы ранжировать их в том порядке, который будет определять последовательность разработки продукта.
Почему это сложно?
1. Работать над своими идеями приятно, над чужими — не особенно.
2. Интереснее фокусироваться на идеях, чем думать в категориях глобальной целеполагания.
3. Увлекательно разрабатывать новые идеи, знакомый и продуманный проект — скучно.
4. Тяжело держать в уме детали различных частей большого проекта.
Общие вопросы, которые нужно задать
1. Как часто возникает проблема? (число обращений)
2. Сколько пользователей затронуто? (процент пользователей)
3. Насколько это важно для пользователя? (серьёзность проблемы)
4. Есть ли способ решить эту проблему вручную? (сложность решения)
5. Сколько ресурсов потребуется, чтобы решить проблему? (человеко-часы)
6. Можно ли применить решение к другим проблемам? (эффект от решения)
RICE
Reach (Охват)
Скольким пользователям мы улучшим жизнь?
Измеряется количеством людей/событий за определённый период времени. Важно использовать реальные метрики.
Например, «функцией будет пользоваться 800 пользователей в месяц» или «1000 пользователей участвуют в онбординге, и 70% (700 пользователей) увидят эту функцию».
Impact (Эффект)
Насколько сильно мы улучшим жизнь нашим пользователям?
Например, в компании Hygger (B2B SaaS) для текущего квартала функции получают высокую оценку, если они:
1. Улучшают trial-to-paid конверсию. 2. Помогают привлечь новых пользователей. 3. Помогают сохранить текущих пользователей (например, не менее 15% удержания) 4. Добавляют ценности продукту и отличают нас от конкурентов (влияние сложно измерить; используются условные шкалы, например, пятибалльная).
Confidence (Уверенность)
Насколько мы убеждены в том, что действительно можем что-то улучшить? Если вы полагаете, что функция может оказать значительное влияние, но у вас нет подтверждающих данных, Confidence помогает урегулировать этот аспект. Измеряется в процентном соотношении.
Проект A: у руководителя продукта имеются количественные данные об эффекте функции и оценка затрат на труд. Следовательно, проект получает 100%-ную оценку уверенности.
Проект B: у руководителя продукта есть информация об охвате и затратах на труд, но он не уверен в отношении влияния функции. Проект получает коэффициент доверия 80%.
Проект C: данные об охвате и влиянии могут оказаться ниже ожидаемых. Затраты на труд могут превысить расчёты. Проект получает оценку доверия в 50%.
Источники данных
● UX-исследования; ● опросы; ● интервью; ● наблюдения; ● MVP; ● A/B-тесты; ● внешние исследования; ● аналитика; ● личные убеждения; ● глобальные тренды; ● мнения команды, экспертов, руководителей; ● «все конкуренты это делают»; ● обращения в поддержку; ● запросы от менеджеров по продажам; ● запросы от клиентов.
Если гипотеза является лишь вашим собственным мнением, то её значимость минимальна. Поэтому, прежде чем отправлять что-либо на разработку, важно обдумать, как проверить реальную необходимость этой функции, и возможно ли её реализовать с минимальным участием программистов.
Effort (Издержки)
Как много времени потребуется нам для воплощения наших планов в жизнь? Затраты на труд измеряются в «человеко-часах».
Проект A потребует приблизительно одну неделю на планирование, две недели на дизайн и три недели на разработку, таким образом, общие трудозатраты составят два человеко-месяца.
Для проекта B будет необходима только одна неделя планирования и от одной до двух недель на разработку, без необходимости в дизайне. Общие трудозатраты в этом случае равны одному человеко-месяцу.
ICE
Ease (Простота реализации)
Это степень лёгкости, с которой можно реализовать идею: сколько усилий и ресурсов требуется.
В методе ICE используется шкала от 1 до 10 для того, чтобы все факторы равномерно влияли на итоговую оценку. Вы можете интерпретировать значения от 1 до 10 так, как считаете нужным, главное, чтобы они были последовательными.
Пример
Влияние: насколько эффективной будет эта функция? Что она принесёт нашим пользователям и как повлияет на их цели и задачи?
Лёгкость реализации: насколько просто будет разработать, протестировать и запустить эту функцию?
Уверенность: как я могу быть уверен в том, что эта функция даст ожидаемое улучшение, как описано в Impact, и потребует указанное количество времени?
ICE Scoring критикуют за необъективность
Одна и та же функция может оцениваться по-разному одним и тем же человеком в разное время, что может влиять на итоговый список приоритетов.
Если разные люди оценивают функции, они будут делать это по-разному.
Члены команды, желающие, чтобы их функции были приоритетными, могут манипулировать результатами для получения одобрения.
Как применять RICE и ICE
Разберём проект завоевания Земли рептилоидами с планеты Нибиру.
Вся власть рептилоидам!
Hygger. io — «Trello на стероидах».
Функции и идеи продукта собираем на kanban-доске.
Организуем их с помощью «дорожек» Swimlanes и используем Labels для структурирования.
Определяем этапы работы с функциями через Columns.
Затем рассчитываем приоритеты с помощью внутреннего калькулятора.
ICE
Backlog — идеи функций, появившиеся в ходе мозгового штурма.
Next Up — сюда перемещаем функции, над которыми планируем работать в ближайшее время.
Specifications — требования и спецификации к функциям.
Development — функции в процессе разработки, мы можем отслеживать их статус.
Done — эти функции реализованы и доступны пользователям.
Описание задачи
Push!
Создаётся задача для реализации функции на Канбан-доске разработки в Hygger.
Задача на бэклог-доске и задача на доске разработки связаны между собой.
После полного выполнения задачи на доске разработки, соответствующая задача на бэклог-доске также перемещается в колонку done.
Ещё несколько методов приоритизации
Матрица Impact/Effort
Этот метод сравнивает усилия, затраченные на реализацию функции, с получаемой отдачей. Усилия (Effort) измеряются, например, в человеко-часах, а влияние (Impact) оценивается по пятибалльной шкале или по шкале high — medium — low. Однако выбор подходящих метрик может быть сложным. Приоритеты реализации устанавливаются следующим образом:
1. Высокое влияние и низкие усилия.
2. Низкое влияние и низкие усилия.
3. Высокое влияние и высокие усилия.
4. Функционал с низким влиянием и высокими усилиями обычно игнорируется.
1. Quick Wins (Быстрые победы).
2. Big Bets (Крупные ставки).
3. Maybes (Возможные варианты).
4. Time Sinks (Пустая трата времени).
Kano Model
Основана на эмоциональном восприятии пользователем различных функций.
Must-Be: обязательные функции; их отсутствие приводит к неудовлетворенности пользователя.
Indifferent: функции, наличие или отсутствие которых для пользователя не имеет значения.
Performance: вызывают удовлетворение, если хорошо реализованы, и разочарование, если плохо.
Attractive: приносят удовлетворение, если присутствуют; их отсутствие не критично.
Реализуются сверху вниз, за исключением Indifferent.
Buy the Feature
Подходит при наличии множества заинтересованных сторон. Используются купоны из игры «Монополия», приравниваемые к бюджету проекта. Купоны распределяются между функциями, приоритетность которых определяется суммой «вложенных» средств.
Karl Wiegers Method
Оцениваются польза (benefit), вред от отсутствия (penalty), стоимость (cost) и риск (risk) по шкале от 1 до 9. Пользователи оценивают полезность функции и вред от её отсутствия, а разработчики — стоимость её внедрения и связанные риски. Затем данные подставляются в некую формулу (уникальную для каждой компании и каждого конкретного продукта) — для расчёта коэффициента приоритетности.
Feature Buckets
Этот подход, разработанный бывшим руководителем соцсети LinkedIn Адамом Нэшем, предполагает разделение всех продуктовых фич на 3 категории:
Metric Movers: функционал, влияющий на ключевые метрики (вовлеченность, рост, доход и т. д.).
Customer Requests: функционал, запрашиваемый пользователями. Не все запросы пользователей могут быть удовлетворены.
Customer Delight: функции, которые могут явно не запрашиваются пользователями, но точно добавят им ценности.
Feature Bucket больше фокусируется на характеристиках продукта, нежели на требованиях к нему. В контексте приоритизации первостепенное значение имеют элементы из категорий Metric Movers и Customer Requests, при этом важно находить равновесие между функциями, необходимыми как бизнесу, так и потребителям. Применяя анализ Кано, предпочтение следует отдавать реализации тех функций, которые пользователи ожидают от продукта по умолчанию, а также тех, которые способны вызвать положительную эмоциональную связь с продуктом.
Дополнительное чтение
