Матрица приоритетов: RICE и MoSCoW для эффективного управления проектами

Что считает матрица приоритетов и по какой формуле?

Кратко по делу: матрица приоритетов превращает спор о задачах в число. RICE считает так: охват умножаем на влияние, умножаем на уверенность и делим на трудозатраты. Получается балл, по которому бэклог выстраивается сверху вниз. MoSCoW работает проще и раскладывает те же задачи по четырём корзинам обязательности. Оба инструмента закрывают один вопрос: что команда берёт в работу первым.

Формула RICE открытая, её считают на калькуляторе за минуту:

Балл = (Reach × Impact × Confidence) ÷ Effort

Расшифрую каждую букву своими словами, потому что в переводах их постоянно путают.

Reach, охват. Сколько человек задача заденет за выбранный период. Период фиксируется один раз для всего списка: месяц или квартал. Смешивать нельзя.

Impact, влияние. Насколько сильно задача сдвинет нужную метрику у одного человека. Шкала условная, от четверти балла до тройки.

Confidence, уверенность. Доля от единицы, которая показывает, насколько команда доверяет двум предыдущим числам. Есть замеры, ставим единицу. Есть только мнение менеджера, ставим половину.

Effort, трудозатраты. Сколько недель работы одного человека съест задача целиком, включая аналитику, тестирование и выкатку. Когда оценка расползается вдвое, сначала разбивают эпик на задачи поменьше, и только потом считают.

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

MoSCoW обходится без арифметики. Must have, без этого релиз не состоится. Should have, важно, но переживём. Could have, приятная добавка. Won’t have, сознательный отказ на этот раз. Четвёртая корзина полезнее трёх остальных: она письменно фиксирует, чего команда делать не будет, и через месяц спор не повторяется.

Какие коэффициенты подставлять: таблица вводных

Кратко по делу: подставлять надо четыре числа. Охват в людях за фиксированный период, влияние по шкале от 0,25 до 3, уверенность долей от единицы и трудозатраты в неделях работы одного человека. Три числа команда берёт из данных, четвёртое из честного разговора об оценке. Шкалы фиксируются до расчёта, иначе баллы окажутся несопоставимыми между собой.

Шкалу влияния команда согласовывает один раз и записывает рядом с таблицей. Тройка означает, что человек ради этой функции меняет своё поведение. Единица означает заметное удобство. Четверть балла означает косметику, которую половина пользователей не заметит вовсе.

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

Сценарий первый: какая задача выиграет спринт в магазине одежды?

Кратко по делу: в спринт просятся фильтр по размеру и оплата частями. Оплата звучит громче, её продвигает коммерческий отдел, фильтр выглядит мелочью. По формуле фильтр набирает 3200 баллов против 333 у оплаты, потому что задевает в шесть раз больше людей и стоит вдвое дешевле по времени. Разрыв почти десятикратный, и спор на этом заканчивается.

Вводные фильтра: каталог смотрят 12 000 человек в месяц, влияние среднее, ставим единицу. Уверенность 0,8, потому что жалобы на поиск нужного размера лежат в поддержке пачками. Трудозатраты три недели.

Считаем: 12 000 × 1 × 0,8 ÷ 3 = 3200.

Вводные оплаты частями: до страницы оплаты доходят 2000 человек в месяц, влияние сильное, ставим двойку. Уверенность 0,5, потому что данных по своей аудитории нет, есть отраслевая молва. Трудозатраты шесть недель: подключение сервиса, юридическая часть, тестирование.

Считаем: 2000 × 2 × 0,5 ÷ 6 = 333.

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

Числа сойдутся только в одном случае: обе задачи описаны одинаково подробно. Расплывчатая формулировка ломает оценку трудозатрат сильнее всего, поэтому задачу формулируют так, чтобы её выполняли без уточняющих вопросов.

Сценарий второй: стоит ли чинить внутренний инструмент ради двадцати человек?

Кратко по делу: внутренняя панель для двадцати менеджеров всегда проигрывает клиентской задаче по охвату. В примере ниже ручной экспорт отчётов набирает 60 баллов, новая витрина 937. Прямое сравнение тут врёт: у задач разные аудитории и разные единицы пользы. Внутренние задачи считают отдельным списком и режут под них фиксированную долю мощности спринта.

Разберу по числам. Ручной экспорт отчётов отнимает время у 20 менеджеров, влияние тройка, потому что боль ежедневная, уверенность единица, работы на неделю. Балл: 20 × 3 × 1 ÷ 1 = 60.

Витрина для клиентов: охват 30 000 человек, влияние 0,5, уверенность 0,5, трудозатраты восемь недель. Балл: 30 000 × 0,5 × 0,5 ÷ 8 = 937.

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

Рабочее решение простое. Два отдельных списка, клиентский и внутренний, плюс заранее оговорённая доля мощности команды на второй: например, пятая часть спринта. Внутри каждого списка RICE считает нормально. Между списками решает договорённость с руководителем.

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

Сценарий третий: что делать с гипотезой, в которую команда не верит?

Кратко по делу: гипотеза персональной подборки в рассылке набирает 2000 баллов, скучное ускорение карточки товара 10 000. Красивая идея проигрывает впятеро, потому что уверенность в ней половинная, а работы на месяц. Выход лежит в знаменателе: в очередь ставится дешёвая проверка гипотезы за полнедели, и она набирает 16 000 баллов.

Гипотеза целиком: охват 8000 подписчиков, влияние двойка, уверенность 0,5, трудозатраты четыре недели. Балл: 8000 × 2 × 0,5 ÷ 4 = 2000.

Ускорение карточки товара: охват 40 000, влияние 0,5, уверенность единица, трудозатраты две недели. Балл: 40 000 × 0,5 × 1 ÷ 2 = 10 000.

Дешёвая проверка: та же подборка, собранная руками на небольшой выборке подписчиков, без единой строчки кода. Охват и влияние прежние, трудозатраты полнедели. Балл: 8000 × 2 × 0,5 ÷ 0,5 = 16 000.

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

После теста уверенность превращается в измеренное число, и гипотеза возвращается в список с честными вводными. В командах, которые живут спринтами, такой цикл ложится ровно на планирование, если роли, спринты и церемонии в Scrum уже расставлены.

Как посчитать приоритет под свой бэклог за пять шагов?

Кратко по делу: шагов пять. Зафиксировать период и шкалы, выписать задачи в одну таблицу, проставить по каждой четыре числа, посчитать балл формулой прямо в таблице, отсортировать по убыванию. На бэклог из тридцати задач у команды уходит примерно полдня, дальше любой пересчёт занимает минуты и делается прямо на встрече.

1. Зафиксируйте период и шкалы. Месяц или квартал для охвата, значения влияния и уверенности. Запишите правила в шапке таблицы, чтобы через две недели никто не собирал их заново.
2. Соберите задачи в один список. Одна строка, одна задача сопоставимого размера. Эпики дробите заранее, иначе трудозатраты будут врать.
3. Проставьте числа. Охват и уверенность заполняет тот, у кого есть данные. Трудозатраты называют исполнители, менеджер их не правит.
4. Посчитайте балл. Формула вбивается в таблицу один раз и дальше считает сама, руками ничего перемножать не придётся.
5. Отсортируйте по убыванию и остановитесь. Верхние строки уходят в работу, нижние остаются в списке. Возвращаться к сортировке имеет смысл раз в спринт.

Место хранения влияет на живучесть таблицы сильнее, чем кажется. Когда баллы лежат отдельным файлом на личном диске менеджера, их перестают обновлять через месяц. Держите поля прямо в трекере: как это настраивается, я разбирал в обзоре Trello, Notion и Jira под конкретный проект.

Что делать с полученными баллами дальше?

Кратко по делу: балл задаёт черновик очереди и не отменяет решения людей. Верхнюю часть списка переводят в Must have, следующую в Should have, остальное в Could have, явные отказы записывают в Won’t have. Дальше очередь показывают заказчику и команде, фиксируют письменно и пересматривают раз в спринт.

Перевод баллов в MoSCoW снимает главную претензию к чистой сортировке: голый список не показывает, где проходит граница обязательного. Отсечку ставят по ёмкости спринта. Всё, что влезло, уходит в Must have. Следующая треть в Should have. Остаток в Could have, а отказы в Won’t have с датой пересмотра.

Заказчику показывают вводные, из которых собрался балл, потому что спорить об охвате продуктивнее, чем об итоговом порядке строк. Когда посреди квартала приходит новое требование, пересчёт занимает минуты и становится лучшим аргументом в разговоре о сдвиге сроков. Механику такого разговора я разбирал в материале про управление изменениями в проекте.

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

Где расчёт врёт и как это заметить?

Кратко по делу: формула врёт в пяти местах. Разные аудитории в одном списке, заниженные трудозатраты, уверенность как рычаг давления, задачи вовсе без охвата и невидимые зависимости между строками. Признак поломки один и тот же: очередь перестаёт совпадать со здравым смыслом у людей, которые в этом проекте работают руками.

Разные аудитории. Клиентские и внутренние задачи в одной таблице несравнимы, разбирали выше. То же самое с задачами для новых и для действующих пользователей: одна и та же тройка влияния означает у них разные вещи.

Заниженные трудозатраты. Знаменатель стоит внизу дроби, поэтому вдвое заниженная оценка вдвое завышает балл. Самая частая манипуляция в бэклоге, причём чаще неосознанная.

Уверенность как рычаг. Тот, кто продавливает свою задачу, ставит единицу там, где честно 0,5. Лечится правилом: уверенность выше 0,8 требует ссылки на конкретный замер.

Задачи без охвата. Технический долг, безопасность, требования регулятора. Reach в привычном смысле у них отсутствует, формула выдаёт ноль, и они вечно оказываются в хвосте. Такие задачи выносят в защищённую квоту и через матрицу не пропускают. Сюда же попадает работа по проверкам и приёмке, о которой я писал в разборе базовых инструментов управления качеством.

Невидимые зависимости. Сортировка по баллу игнорирует порядок исполнения. Задача с баллом 200 может быть входом для трёх задач с баллом 5000, и тогда очередь приходится разворачивать вручную. Проверять это удобно по критическому пути проекта.

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

Остались вопросы

Подходит ли RICE проекту, где нет продуктовых метрик?

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

Как часто пересчитывать баллы по всему бэклогу?

Полный пересчёт имеет смысл раз в квартал, когда меняются цели. Точечный пересчёт делается в момент появления новой задачи: считаете только её и вставляете в готовую очередь. Ежеспринтовый пересчёт всего списка выжигает время команды и почти никогда не меняет верхние пять строк.

Кто должен проставлять оценки: менеджер или команда?

Охват и влияние остаются за тем, кто отвечает за результат продукта. Трудозатраты называет только исполнитель, иначе знаменатель поедет вниз и вся дробь потеряет смысл. Уверенность выставляют вместе, вслух, потому что именно в ней прячутся все несогласия. Если оценки собирает один человек в одиночку, очередь никто не будет считать своей, и вопрос вовлечённости перерастает в вопрос мотивации проектной команды.

Что делать, если у двух задач баллы почти совпали?

Разница меньше десяти процентов внутри погрешности оценок, поэтому арифметика тут молчит. Берите ту задачу, которая дешевле по трудозатратам: она быстрее вернёт данные и уточнит уверенность по второй. Второй рабочий критерий, если трудозатраты равны, это риск. Первой идёт задача, чья неопределённость мешает планировать остальные.

Можно ли работать по одному MoSCoW без всякого расчёта?

Можно, и на коротких проектах с жёсткой датой сдачи это разумно. Слабое место у метода одно: границу между Must have и Should have каждый участник видит по своему, и без числового аргумента спор упирается в статус спорящих. Как только корзина Must перестаёт влезать в срок, приходится доставать формулу и резать список по баллам.

Источники

• Intercom, описание метода RICE от его авторов: intercom.com
• Agile Business Consortium, руководство DSDM и правила приоритизации MoSCoW: agilebusiness.org
• Project Management Institute, материалы по управлению содержанием проекта: pmi.org
• Собственная практика ведения продуктовых и проектных бэклогов, все расчёты в статье разобраны по рабочим заметкам.