Зачем они это делают? Понятная приоритизация задач (Score)
На офисной кухне или в курилке невольно слушаешь разговоры коллег о том, зачем и почему они «все это» делают и как донести до всех причастных важность нашей работы. Как доказать, что мы не тратим время других сотрудников и деньги компании впустую, а занимаемся действительно важными вещами? Ведь часто думаешь, что ты делаешь самую нужную и крутую фичу, которую все ждут.
И у вас такое было? Тогда вам будет интересно.
Вся наша работа, по сути, сводится к поочередному выполнению задач. Поэтому их приоритизация чрезвычайно важна.
Методов и алгоритмов приоритизации очень много. Каждому этапу развития, на котором находится ваша компания, может подойти один из них. Возможно, в данный момент приоритизация задач вам вовсе не нужна. Если вы работаете с проектами, где понятна последовательность выполнения задач и ресурсы в полном вашем распоряжении, — скорее всего, вам это не пригодится.
О приоритизации
Приоритизация задач проекта помогает понять, что следует выполнять в первую очередь, чтобы донести до пользователя максимум ценности продукта и, вероятно, заработать больше денег для компании.
В каждой организации по-своему распределяются ресурсы. Бывают команды с общими — и ограниченными — ресурсами: несколько менеджеров могут задействовать в разработке одних дизайнеров, программистов, аналитиков. В таком случае начинается борьба за них: на общих митингах надо быстро и достоверно (на цифрах) обосновывать, почему именно твою фичу, а не коллеги, должны взять в будущий спринт.
О важном
Обычно у компании есть цель, к которой она глобально стремится, — а значит, все выполняемые задачи должны приближать к ее достижению. Цели могут быть долгосрочными — они описаны в стратегии, — и краткосрочными, которые изложены, например, в roadmap’е на несколько месяцев. Но не стоит забывать: на каком бы уровне цели ни находились, они всегда связаны друг с другом. И наши задачи всегда должны следовать вектору глобальной цели. Если это не так, задайте вопрос «почему?» и, предлагая гипотезу, обязательно сверьтесь с целью бизнеса.
Можно просчитывать затраты на разработку вплоть до подсчета ROI по каждой цели, прибыли с нее или потерь, если ее не достичь. Другой вариант — не углубляться, а просто разбить цели на четыре категории: «не принесет прибыли», «принесет мало», «даст среднюю прибыль», «обеспечит большую прибыль». Меры «много» и «мало» вы устанавливаете сами.
Приоритизация задач в несколько шагов
Шаг 1
Сначала рассмотрим способ, который поможет отбросить ненужные гипотезы.
Сделайте табличку из строчек с описанием гипотез, а по вертикали обозначьте коллег, которые участвуют в процессе разработки и обладают знаниями по этой фиче. Каждый проставляет в своей колонке по всем строкам баллы по определенной заранее шкале. Выводим сумму и видим, какие фичи команда считает топовыми.
В первый раз таблицу создают вручную, а потом делают ретроспективы, автоматизируя. Таким образом мы смотрим, действительно ли все произошло так, как мы прогнозировали. Через несколько итераций вы поймете свои реальные коэффициенты и сможете зашить их в формулу таблицы.
Потом приходит время для следующей, более глубокой приоритизации.
Шаг 2
Посмотрим, какие существуют инструменты приоритизации:
- RICE;
- ICE Score;
- Kano;
- WSJF;
- GIFT.
Разберем один из них — RICE. Это метод приоритизации гипотез по разработке фич. Расшифровка названия:
- Reach — охват;
- Impact — влияние;
- Confidence — уверенность в вашей оценке охвата, влияния и трудозатрат;
- Effort — трудозатраты.
Чтобы получить оценку по RICE, необходимо следовать следующему алгоритму приоритизации.
(Reach*Impact*Confidence)/Effort=Score
Reach — показывает, сколько пользователей будут применять новую функциональность. Посмотреть это можно по системам веб-аналитики, по прошлому опыту или по конкурентам.
Например, представим, что вы ставите баннер в новом формате на главной странице сайта, посещаемость которой — 10 000 уникальных пользователей в месяц. Получается, именно столько людей увидят вашу фичу. Если вы взяли месячный период, то используйте его при рассмотрении всех гипотез. Учитывайте это и тогда, когда начнете считать Impact в денежном выражении.
Impact — это величина, характеризующая влияние вашей фичи. В идеале ее нужно представлять в денежном эквиваленте, так как для бизнеса это понятнее всего. Но часто останавливаются на субъективной оценке.
Confidence — чтобы понять этот фактор, задайте себе вопрос: как быть уверенным в своих действиях? Правильно: подкрепить их.
Доказательства могут быть разными, и поэтому справедливо придать каждому из них свой вес.
Перечислим часто используемые и известные способы подкрепления:
- UX-исследования;
- опросы;
- интервью;
- наблюдения;
- MVP;
- A/B-тесты;
- сторонние исследования;
- аналитика;
- и другие пользовательские исследования.
Не нужно забывать, что помимо результатов качественных и количественных исследований есть более простые доводы, почему вашу фичу должны взять в работу. Среди них:
- собственные убеждения;
- мировые тренды;
- мнение команды, эксперта, руководителя;
- «все конкуренты делают это», «продукт не работает без этого».
Еще важные каналы информации:
- топ обращений в саппорт;
- топ запросов от сейлз-менеджеров;
- топ запросов от клиентов.
В итоге у нас сформировался перечень способов, как подкрепить гипотезу. Этот список с расставленными весами привел в удобный вид Itamar Gilad — продакт-менеджер Gmail и YouTube ☺. Рекомендую почитать его блог — https://itamargilad.com/.
Как видите, если гипотеза — это только ваше мнение, то у нее минимальный вес. Поэтому прежде чем что-то отдавать в разработку, подумайте, как проверить, насколько необходима эта фича, и сможете ли вы сделать ее с минимальным вовлечением программистов. Ведь все мы знаем, что самые большие затраты уходят в фонд оплаты труда разработки.
Effort — оценивается либо в часах разработки, либо в story point — это не меняет сути. Всегда можно привести к одной шкале.
В целом это все. Теперь можно заносить данные в таблицу, фильтровать по наибольшему значению Score и брать в работу.
Пример таблицы Score
Гипотезы |
Reach |
Impact |
Confidence |
Effore |
Score |
Гипотеза 1 |
1 |
10 |
0,2 |
10 |
0,2 |
Гипотеза 2 |
2 |
2 |
7 |
1 |
28 |
Гипотеза 3 |
3 |
1 |
0,5 |
10 |
0,15 |
Для каждого из параметров необходимо задать свою шкалу баллов. Рассмотрим это на примере Reach. Предположим, самую маленькую фичу могут увидеть/использовать 100 K уникальных пользователей, а самую крутую — 1 000 K. Берем 10-балльную шкалу и переводим наши значения:
Кол-во |
Балл |
больше 1000 K |
10 |
900 K–1000 K |
9 |
800 K − 900 K |
8 |
700 K – 800 K |
7 |
500 K – 600 K |
6 |
400 K – 500 K |
5 |
300 K – 400 K |
4 |
200 K – 300 K |
3 |
100 K – 200 K |
2 |
меньше 100 K |
1 |
Из таблицы видно, что гипотеза 2 наиболее приоритетна, — ее и нужно брать в работу первой.
Все это нужно, чтобы:
- сфокусироваться на главных задачах;
- обеспечить прозрачность работы;
- мотивировать команду.
Редко бывает так, что методология идеально, без изменений подходит вашему проекту или бизнесу в целом. Имеет значение множество факторов: от особенностей менталитета до специфики продукта. Поэтому всегда, прежде чем использовать метод, убедитесь, интегрируется ли он в вашу компанию.