Фреймворки приоритизации (RICE / MoSCoW) — Примеры

Пример 1 — Четыре кандидата, одна таблица

У владельца продукта четыре элемента бэклога, и аргументированного порядка между ними нет. Исходные цифры ниже: сведите их в одну таблицу с названным каждым фактором, проранжируйте оценки, а затем переопределите ранжирование там, где этого требует суждение.

Элемент                     Reach/мес  Impact   Confidence   Effort
A  возвраты и статус           900         3        0.8        2
B  сохранённая карта          1900         2        0.6        1
C  выгрузка оптовых заказов    300         2        1.0        3
D  мультивалютность            700         3        0.2        5

Решение

Элемент                       R     I    C     E   Оценка  Ранг
A  возвраты и статус        900    3    0.8   2   1080     2
B  сохранённая карта       1900    2    0.6   1   2280     1
C  выгрузка оптовых заказов 300    2    1.0   3    200     3
D  мультивалютность         700    3    0.2   5     84     4

Оценка = R x I x C / E
Переопределение: D всё равно выходит первым. Правило о счетах в ЕС
вступает в силу в июле, значит D — срок, а не предпочтение. Confidence
у B выглядит завышенной: две из трёх команд её не тестировали.
Решение: D в этом квартале, B следующим, перепроверив его Confidence.

Таблица выносит все четыре входных данных на свет, так что каждый из них можно оспорить, и сразу показывает две полезные вещи: B — самая дешёвая крупная победа, а C — элемент, в котором команда наиболее уверена. Однако суть упражнения не в таблице, а в переопределении: формула не видит юридического срока, поэтому фреймворк, который никогда не переопределяют, используют вместо суждения, а не для него. Ловушка — принять верхнюю оценку за приговор и поставить B на догадке.

Пример 2 — Список MoSCoW без ёмкости

В плане релиза ниже всё свалено в верхнюю корзину MoSCoW, а ёмкость не названа. Перепишите его для релиза в шесть недель работы разработчика и назовите ограничитель, который придаёт корзинам смысл.

Must   возвраты, статус возврата, сохранённая карта, выгрузка оптовых
       заказов, мультивалютность, переработка дашборда
Should -
Could  -

Решение

Ёмкость: 6 недель работы разработчика.
Must (5н)    возвраты, статус возврата - без них релиз недействителен
Should (1н)  сохранённая карта         - больно опустить, но поставляемо
Could        выгрузка оптовых заказов, мультивалютность
Will not     переработка дашборда в этом релизе

Must означает только то, без чего релиз недействителен, но это предложение бессмысленно, пока ёмкость не записана: при заявленных шести неделях корзина Must должна в них уместиться, иначе это не Must. Вторая половина урока — Confidence, ведь элементы, которых команда хочет больше всего, получили высший балл, поэтому каждому значению нужно основание: проверено, видно в аналитике или догадка не дороже 0.5. Ловушка — пустой список Will not, а называние исключений не даёт им вернуться.