Страдали ли вы от того, что задачи делаются не те, которые нужны, а те, которые вам "проталкивают" стейкхолдеры? Или может столкнулись с тем, что задач так много, они срочные и конечно же важные. Так что же делать?
Нужно расставить приоритеты!
Не смотря на то, что мы говорим о разработке программного обеспечения, метод RICE может быть адаптирован под любой пул задач, который возможно приоритезировать.
И вы спросите, а причем тут рис (RICE) вообще? Давайте разберем по буквам:
Reach - это охват, он измеряется количеством людей или событий на которые мы повлияем за определенный промежуток времени. Задаем вопрос: сколько пользователей увидят этот функционал?
Например, опросом или тестами вы выяснили, что 40% ваших пользователей будут пользоваться новой фичей.
Impact - влияние новой функциональности на продукт. Так мы измеряем ценность новой доработки. Задаем вопрос: что хорошего произойдет с продуктом, когда мы внедрим фичу.
Например, мы выяснили что при заполнении анкеты 20% новых пользователей отваливаются на четвертом шаге из пяти. Доработка позволит сократить анкету до одного шага, что увеличит конверсию.
Confidence - наша уверенность в том, что новый функционал имеет такое значение. Задаем вопрос: на сколько я уверен что эта фича нужна?
Выставляйте в процентах.
Например, у нас есть данные по охватам, но мы не знаем трудоемкость и влияние посчитать получается только приблизительно. Менеджер в таком случае выставил оценку в 50%
Effort - затраченные усилия или трудозатраты. Команда разработки должна выставить свою оценку по предполагаемым усилиям что бы затащить данный функционал. Это могут быть часы, сторипоинты или другие численные измерения. Задаем вопрос: сколько это будет стоить в трудозатратах?
Вот мы и выставили все коэффициенты, что дальше? А дальше у нас вот такая незамысловатая формула:
Подставляем свои данные в формулу выше и получим некоторое число - это будет Rice Score.
Важно! Чем больше Rice Score, тем выше приоритет у задачи
Ошибки при использовании RICE
1. Приоритезировать все только с помощью RICE
Это чревато тем, что баги и технические улучшения будут задвигаться бизнесом на самый низкий приоритет. Попробуйте принцип, что сначала должна быть завершена уже начатая работа, к которой относятся и баги и уже начатые фичи.
2. Заниматься RICE в одиночку
В таком случае менеджер будет осознанно или нет, но двигать свои задачи вверх по приоритетам "подкручивая" метрики. Подключайте команду, подключайте других заинтересованных лиц. Чем больше соберете мнений - тем лучше.
Конец
Также, залетайте в телеграм, там общаемся о всяком, но в основном про IT, буду рад всем :)
На этом все, пишите в комментариях, как вы подходите к формированию приоритета задач.