Comments 13
В заголовке поправьте пожалуйста: "приоритЕзировать".
Спасибо.
«Приоритизация» как раз через «и». Такое вот неочевидное слово. Вот тут об этом можно почитать :)
Приложение долго висело на лоадере и после неожиданно для них выдавало результат. Они думали: «Приложение, наверное, сломалось» и просто уходили.
Больше похоже на проблему с реализацией функционала в приложении, чем на плохую изначальную идею. Странно из такого результата делать выводы вида "теперь мы ответили себе на вопрос: а почему наши ключевые конкуренты это еще не сделали?"
Спасибо, за интересный опыт. А как вы поступаете, если задача по RICE набрала мало баллов, но её "надо" сделать? Просто делаете не взирая на баллы или поднимаете ей I и C, чтобы поднять ей баллы?
Во как, думать не думал что работу продакта можно формализовать. С фреймворками:-) Полагал что это бесконечный компромисс человеческих несовершенств. А приоритизировать приходится, в основном, интересы сторон)
Подскажите, а вот эта метрика, RICE, является аргументом в дебатах сторон: стейкхолдеров, архитекторов, разработчиков etc… Или это только ваше личное основание в принятии решений?
Спасибо. Сам коэф интересен скорее интересен в продуктовом отделе, но цифры для его подсчета всегда делают позицию более рациональную и измеряемую, что несомненно экономит время на дискуссии
Количественные метрики типа RICE хорошо себя показывают когда вы конкурируете за ресурсы. Например, одна команда делает несколько продуктов. По количественной оценке вы сможете выстроить очередь из двух беклогов.
Если же у вас один продукт и полностью выделенная команда на него, то можно применять и качественные модели (типа того же KANO).
Никогда не понимал этого прикола с делением в RICE, какая то очень сложная логика получается. Не проще ли выровнять все шкалы и просто перемножать?
Как продакту приоритизировать задачи и не сойти с ума