Comments 19
Был опыт с системой похожей на WSJF, но только в которой продукт сам выбирал критерии (в том числе сложность, бизнес эффект и т.д.) у которых были веса, там было порядка 12 критериев и вес каждого менялся в зависимости от ситуации, формула выглядела очень сложной, но вся суть сводилась к примерно этому:
критерий 1 * вес критерия 1 + критерий 2 * вес критерия 2 + ... критерий N + вес критерия N = результат / размер задачи = score
бэклоги?
это что за "дата"?
тут не про информационный мусор, случайно?
Вопрос не с целью подколоть, но почему вы используете скоринговые системы? Они имеют смысл только если несколько менеджеров продукта конкурируют за ресурсы. Или несколько проектов конкурируют за ресурсы. В остальных случаях упрощенной модели (круто / не круто) типа Kano будет достаточно.
Вначале статьи сказано:
В любом планировании однажды наступает момент, когда требуется выработка новой стратегии, расстановки приоритетов. Многие менеджеры сталкиваются с хаотичными предложениями и мнениями, что сбивает с верного пути и как итог – важные фичи брошены или не начаты, цели не ясны, команда теряет мотивацию.
Возникает вполне логичный вопрос – «Как эффективно расставить приоритеты работы команды?»
Однако в таком скоринге нет необходимости, если вы живёте по какому нибудь OKR, у вас есть Research отдел и цели проробатываются с менеджментом выше
У меня был опыт с обоими подходами, оба подхода хороши и имеют право на жизнь в зависимости от того, как выстроены процессы внутри организации
Я возможно был неточен. В статье приведен список методик, но интересно был ли практический смысл в скоринговых методиках в вашем случае? В чем было преимущества этого подхода вместо качественной оценки?
Такой подход наиболее эффективен при очень большом бэклоге для компании на b2c рынке. Там фишка в том, что 80% бэклога никогда не будет сделано и надо делать то, что горит прям сейчас ибо конкуренты не дремлют. Отсюда довольно простая логика сводящаяся к сравнению циферок.
Готов поспорить, качественная модель будет быстрее для больших беклогов, так как параметр всего один или два. Количественная требует оцифровки. Для 1000 требований по модели RICE вам нужно будет оценить 4000 параметров. Рынок не имеет значения.
Я вижу только два случая когда нужна количественная оценка: когда одна команда работает над несколькими продуктами, или когда менеджмент требует пояснений на основе цифр; фичу А надо делать так как она оценена в 300 попугаев, а фича Б, напротив, в 100. Не встречал других случаев. Поэтому и интересуюсь реальным применением. Возможно есть еще ситуации.
Не очень понятно что вы понимаете под "качественной" моделью. Так-то I в ICE/RICE это тоже вполне себе качество.
Оценки вида: будет ли удовлетворен пользователь, сможем ли мы реализовать фичу полностью. Сводится все к оценке удовлетворенности в итоге: понравится или нет результат. И опросы проводить проще.
"I" это единственный параметр, который можно связать с качественной оценкой. Остальные нужно оцифровывать, т.е. сначала описать как вы начисляете баллы, а потом эти баллы считать. Надо ли это делать в вашем конкретном случае? Что произойдет если вы не будете использовать ICE/RICE, а просто разметите свой беклог тегами удовлетворенности пользователей, в зависимости от того будете ли вы делать эту фичу или нет?
Пример
В вашем примере не хватает параметра типа "охват", т.к. какие то фичи хороши для одной группы пользователей, а другим нет или в одном сценарии использования полезно, а вдругом нет.
имхо, reach&impact разумно оценивать количественно в каких то единицах, а остальное выглядит не очень полезным именно для большого беклога, т.к. это же все нужно еще периодически переоценивать
Ок. Мы проставили теги. Возможно мы много тегов проставили, поскольку оцениваем несколько качеств. Как дальше мы на основе текстовых тегов приоритезируем бэклог?
При всех этих подходах необходимо разделение бэклогов (даже для одно приложения) на пользовательские и, скажем так, системные. Все что связанно с архитектурными изменениями, рефакторингами и т.д. должно оцениваться в разрезе снижения костов или повышения качества, а это уже не ICE/RICE.
Так вот почему до рефакторинга дело никогда не доходит! Там же impact для пользователя как правило 0. А стабильность приложения почему-то воспринимается как данность, а не как фича, над которой тоже нужно работать.
Не очень понятно зачем все параметры сворачивать в один показатель.
Оценка бизнес-ценности все равно обладает большим весом в принятии решения и не нужно её размывать. Оценка трудоемкости, конечно нужна и влияет на принятие решений, но она вполне может жить отдельно, например, в виде оценки задач estimate.
ICE, RICE, WSJF или как эффективно организовать бэклог