Pull to refresh

8 с ½ способов приоритизировать функциональности

Reading time4 min
Views4.5K

В 99% случаев всего не попробовать, все задачи не закрыть, все баги не исправить. Один из ключевых навыков — из всего потока выбирать те задачи, решение которых, даст максимально пользы.


Выбирать такие задачи помогают методы приоритезации и здравый смысл.


Делюсь методами приоритезации, которые собрал из ряда статей. У меня мало опыта в переводах. Буду рад комментариям и пожеланиям к формулировкам.


1. Аналог матрицы Эйзенхауэра (сложность — польза)


Одна из простых и общих техник приоритезации. Горизонтальная ось — сложность, вертикальная — польза. Цель — выделить простые задачи с максимальной пользой.



Пример осей: стоимость разработки и увеличение конверсии. Т. е., среди всех задач выделяем задачи с минимальной стоимостью разработки и максимальным увеличением конверсии.


2. Оценка по параметрам


Выбираем параметры, по которым будем ранжировать функциональности. К примеру, две группы параметров:


Выгода:


  1. увеличит оборот,
  2. ценность для клиента,
  3. ценность для компании.

Стоимость:


  1. сложность внедрения,
  2. стоимость разработки,
  3. риски.


Расчёт по параметрам в Google Spreadsheet.


Для каждого параметра указываем вес и оцениваем функциональности по пятибалльной шкале:


  • 1 балл: мало выгоды, высокая стоимость;
  • ...
  • 5 баллов: максимальная выгода, низкая стоимость.

Та функциональность, что наберёт больше всех баллов — искомая важная функциональность.


Обратите внимание, что в группе «Стоимость» максимальный балл означает минимальную стоимость.


2.1 Пиратские метрики (AARRR)


Частный случай оценки по параметрам. В качестве параметров используем AARRR и оцениваем вклад задачи в каждую метрику:


  1. привлечение,
  2. активация,
  3. удержание,
  4. распространение
  5. и доход.


Расчёт в Google Spreadsheet.


Как и в общем случае, метрикам назначаем вес.


Самая важная задача — задача с максимальным количество баллов.


3. Модель Кано


Модель Кано — метод оценки эмоциональной реакции потребителей на конкретные характеристики продукта.


Опуская детали, выводы из этой модели:


  1. базовые функциональности для текущего продукта, аудитории должны быть по умолчанию и работать стабильно;
  2. имея базовые и основные функциональности, инвестируйте в разработку восхищающих функциональностей. Они выделят на фоне конкурентов, благодаря им о продукте рассказывают друг другу.


Формируя список работ, спросите себя:


  1. Мы реализовали все базовые функции?
  2. А сколько у нас основных?
  3. Исследуем аудиторию, разыскиваем восхищающие функции?
  4. Помним, что восхищающие станут основными впоследствии, а позже и базовыми?

4. Купи функциональность


Суть:


  • назначьте каждой функциональности стоимость, например, в рублях (стоимость привяжите к стоимости разработки);
  • раздайте стейкхолдерам, клиентам некоторую сумма денег и предложите им купить понравившиеся функциональности;
  • результаты продаж и есть ранжированный список функциональностей.

5. Аффинити-группировка


  1. Каждый член команды записывает свои идеи на стикерах (одна идея — один стикер);
  2. затем в командах объединяют схожие идеи в группы и дают группам имена;
  3. в конце мероприятия каждый член команды голосует или указывает важность группы в баллах.

Итог: ранжированные группы с идеями для новых задач.


6. Иерархия потребностей пользователя


Аарон Уолтер предложил версию пирамиды Маслоу для потребностей пользователя. Соль: не переходи на следующий уровень пока не удовлетворил потребности на текущем.



Выбирая задачи для разработки, спросите себя:


  • на каком уровне мы сейчас?
  • Что сделать сейчас, чтобы завтра мы перешли на новый уровень?
  • Результаты задач, которые мы выбрали, нужны пользователям?

7. Спроси у продаж


Общайтесь с менеджерами по продажам: спрашивайте о каких функциональностях люди спрашивают, чего им не хватает в продукте.


Получив запрос на функциональность от отдела продаж, узнайте у них:


  • Почему потребители спрашивают об этом?
  • Это задача — часть более крупной тенденции?

8. RICE


Для каждой функциональности оцениваем:


  1. охват (Reach). Как много пользователей это коснётся за конкретный период времени?
  2. Влияние (Impact). Как сильно это повлияет на конверсию? (максимально — 3, сильно — 2, средне — 1, мало — 0,5 и минимально — 0,25).
  3. Надёжность (Confidence). Насколько вы уверены в своих предположениях? (Максимально — 100%, средне — 80% и низко — 50%).
  4. Трудоёмкость (Effort). Сколько человеко-месяцев это потребует? (Минимум полмесяца и целые числа).

Собираем данные в таблицу и рассчитываем оценку по формуле:



Смысл результирующей метрики — общее увеличение конверсии за определённое время разработки. Функциональность с максимальной оценкой — самая важная.



Расчёт в Google Spreadsheet.


Подытоживая


Приведённые методы не помогут создать продукт, определить потребность и готовность платить за её удовлетворение. Максимальное количество баллов RICE не гарантирует, что после внедрения функциональности произойдёт чудо.


Готовых рецептов успеха нет, но знание инструментов, здравый смысл и культура ранжирования задач в команде увеличивают шансы на успех.


Источники


Tags:
Hubs:
Total votes 17: ↑16 and ↓1+15
Comments0

Articles