Блог: отзывы об учебе и статьи о карьере в ИТ
Методы приоритизации: MoSCoW, ICE, RICE – как выбрать подходящий
У продуктовой команды почти всегда больше идей, задач и запросов, чем времени и ресурсов на их реализацию. Пользователи просят новые функции, бизнес ожидает роста показателей, разработчики предлагают технические улучшения, а служба поддержки сообщает о проблемах клиентов.
Если выполнять задачи только в порядке их поступления, команда рискует тратить время на срочные, но не самые ценные инициативы. Методы приоритизации помогают сравнивать задачи по единым критериям и принимать более обоснованные решения.
Одними из наиболее популярных подходов являются MoSCoW, ICE и RICE. Они решают похожую задачу, но отличаются по уровню сложности, количеству используемых данных и ситуациям, в которых работают лучше всего.

1. Что такое приоритизация в Product Management

Приоритизация — это процесс определения порядка, в котором команда будет реализовывать задачи, функции или продуктовые инициативы.
Product Manager должен учитывать сразу несколько факторов:
  • ценность для пользователей;
  • влияние на бизнес-показатели;
  • количество затронутых клиентов;
  • сложность разработки;
  • доступные ресурсы;
  • риски и зависимости;
  • требования законодательства или безопасности;
  • соответствие продуктовой стратегии.
Главная цель приоритизации — не просто составить список задач, а направить ресурсы команды на работу, которая принесёт продукту наибольшую пользу.
priority
Важно понимать, что ни один метод не принимает решение вместо Product Manager. Формулы и категории помогают структурировать обсуждение, но итоговый выбор всё равно требует понимания пользователей, бизнеса и стратегии продукта.

2. Метод MoSCoW

MoSCoW — один из самых простых и понятных методов приоритизации. Он помогает распределить требования или задачи по четырём категориям.
mscw method

Must have — обязательно

Это функции или требования, без которых продукт, релиз или проект не может считаться рабочим. Если задача из категории Must have не будет выполнена, запуск продукта может оказаться невозможным.
Например:
  • пользователь не может зарегистрироваться;
  • невозможно оплатить заказ;
  • система не соответствует обязательным требованиям законодательства;
  • критическая ошибка блокирует основную функцию продукта.
В категорию Must have не стоит добавлять всё, что кажется важным. Основной проверочный вопрос:
Можно ли запустить продукт без этой функции?
Если ответ «да», задача, скорее всего, не относится к Must have.

Should have — желательно

Это важные задачи, которые приносят заметную ценность, но не блокируют запуск продукта.
Например:
  • сохранение истории заказов;
  • дополнительные способы оплаты;
  • улучшенный поиск;
  • уведомления о статусе доставки.
Без таких функций продукт может работать, но пользовательский опыт будет хуже.

Could have — можно реализовать

Сюда входят полезные, но необязательные улучшения. Их выполняют, когда после реализации более приоритетных задач остаются время и ресурсы.
Например:
  • дополнительные настройки интерфейса;
  • новые варианты оформления профиля;
  • анимации;
  • второстепенные фильтры.
Такие задачи часто называют nice-to-have.

Won’t have this time — не будем делать сейчас

Это функции, которые команда сознательно исключает из текущего релиза или этапа проекта.
Категория Won’t have не означает, что идея плохая или никогда не будет реализована. Она показывает, что сейчас команда не готова выделять на неё ресурсы.
Например:
  • запуск приложения для новой платформы;
  • сложная персонализация;
  • интеграция с внешним сервисом;
  • выход на дополнительный рынок.
Такие задачи можно сохранить в бэклоге и вернуться к ним позже.

Когда использовать MoSCoW

Метод хорошо подходит:
  • для определения объёма MVP;
  • при планировании релиза;
  • для согласования требований с заказчиком;
  • при ограниченном сроке разработки;
  • когда необходимо быстро разделить задачи на обязательные и дополнительные.
Главное преимущество MoSCoW — простота. Метод легко объяснить разработчикам, дизайнерам, заказчикам и другим участникам проекта.
Однако у него есть недостаток: задачи внутри одной категории не сравниваются между собой. Если команда добавила десять задач в Must have, метод не подскажет, какую из них выполнять первой.
Кроме того, участники проекта могут считать почти каждую задачу обязательной. Поэтому Product Manager должен заранее договориться с командой о критериях каждой категории.

3. Метод ICE

ICE используется для количественной оценки продуктовых идей, гипотез и экспериментов.
Название метода образовано от трёх критериев:
  • Impact — влияние;
  • Confidence — уверенность;
  • Ease — простота реализации.
Формула выглядит следующим образом:
ICE Score = Impact × Confidence × Ease
Каждому критерию присваивается оценка, например от 1 до 10. Затем значения перемножаются. Идеи с более высоким итоговым баллом получают более высокий приоритет.
ice formula

Impact — влияние

Impact показывает, насколько сильно инициатива может повлиять на выбранную продуктовую или бизнес-метрику.
Например:
  • увеличить конверсию в регистрацию;
  • снизить количество отказов;
  • увеличить число покупок;
  • повысить удержание пользователей;
  • сократить количество обращений в поддержку.
Чем сильнее предполагаемое влияние, тем выше оценка.

Confidence — уверенность

Confidence показывает, насколько команда уверена в своих предположениях.
Высокую оценку можно поставить, если гипотеза основана на:
  • результатах пользовательских исследований;
  • данных аналитики;
  • A/B-тестах;
  • интервью с клиентами;
  • повторяющихся запросах пользователей;
  • результатах предыдущих экспериментов.
Если идея основана только на личном мнении или предположении, уровень уверенности должен быть ниже.

Ease — простота реализации

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

Пример расчёта ICE

Допустим, команда выбирает между двумя гипотезами.
Первая гипотеза — добавить упрощённую регистрацию:
  • Impact — 9;
  • Confidence — 8;
  • Ease — 6.
ICE Score:
9 × 8 × 6 = 432
Вторая гипотеза — изменить цвет основной кнопки:
  • Impact — 3;
  • Confidence — 5;
  • Ease — 10.
ICE Score:
3 × 5 × 10 = 150
Согласно ICE, упрощение регистрации имеет более высокий приоритет, несмотря на то что изменение цвета кнопки реализовать значительно проще.

Когда использовать ICE

ICE подходит:
  • для оценки продуктовых гипотез;
  • при планировании экспериментов;
  • для ранжирования идей;
  • когда точных данных ещё недостаточно;
  • когда решение нужно принять достаточно быстро.
Преимущество ICE заключается в том, что метод позволяет сравнивать большое количество идей без сложных расчётов.
Но оценки могут быть субъективными. Один специалист может поставить влиянию 8 баллов, а другой — 5. Чтобы результаты были полезными, команда должна заранее определить, что означает каждый балл.
Например:
  • 1–3 — низкое влияние;
  • 4–6 — среднее;
  • 7–8 — высокое;
  • 9–10 — очень высокое.
Конкретная шкала может отличаться. Важно, чтобы она использовалась последовательно для всех задач.

4. Метод RICE

RICE — более детальный метод количественной приоритизации. Он помогает учитывать не только предполагаемое влияние инициативы, но и количество пользователей, которых она затронет.
Название состоит из четырёх критериев:
  • Reach — охват;
  • Impact — влияние;
  • Confidence — уверенность;
  • Effort — трудозатраты.
Формула:
RICE Score = Reach × Impact × Confidence / Effort
Чем выше итоговый балл, тем более приоритетной считается инициатива.
rice

Reach — охват

Reach показывает, сколько пользователей или событий затронет изменение за определённый период.
Например:
  • 5 000 пользователей в месяц;
  • 800 новых регистраций за квартал;
  • 2 000 заказов в неделю;
  • 300 обращений в поддержку за месяц.
При расчёте всех инициатив необходимо использовать один и тот же период. Нельзя сравнивать охват одной функции за неделю, а другой — за год.

Impact — влияние

Impact показывает, насколько сильно изменение повлияет на одного пользователя или на выбранную метрику.
Для оценки можно использовать условную шкалу:
  • 3 — очень большое влияние;
  • 2 — большое;
  • 1 — среднее;
  • 0,5 — небольшое;
  • 0,25 — минимальное.
Команда может использовать собственную шкалу, но она должна быть одинаковой для всех инициатив.

Confidence — уверенность

Confidence отражает качество данных, на которых основана оценка.
Например:
  • 100% — высокая уверенность;
  • 80% — средняя;
  • 50% — низкая.
Низкая уверенность уменьшает итоговый балл инициативы. Это помогает не ставить непроверенные идеи выше задач, подтверждённых данными.

Effort — трудозатраты

Effort показывает, сколько ресурсов потребуется для реализации задачи.
Обычно показатель оценивается в человеко-месяцах. Если над задачей два специалиста будут работать один месяц, трудозатраты составят два человеко-месяца.
В расчёт стоит включать работу всех участников:
  • разработчиков;
  • дизайнеров;
  • аналитиков;
  • тестировщиков;
  • исследователей;
  • других специалистов.

Пример расчёта RICE

Команда рассматривает функцию автоматического напоминания пользователям.
Предполагаемые значения:
  • Reach — 4 000 пользователей за квартал;
  • Impact — 1;
  • Confidence — 80%, или 0,8;
  • Effort — 2 человеко-месяца.
Расчёт:
4 000 × 1 × 0,8 / 2 = 1 600
Теперь рассмотрим персонализированный дизайн профиля:
  • Reach — 1 000 пользователей;
  • Impact — 0,5;
  • Confidence — 50%, или 0,5;
  • Effort — 4 человеко-месяца.
Расчёт:
1 000 × 0,5 × 0,5 / 4 = 62,5
Согласно RICE, функция напоминаний должна получить значительно более высокий приоритет.

Когда использовать RICE

RICE подходит:
  • для планирования продуктового roadmap;
  • для сравнения крупных продуктовых инициатив;
  • когда есть данные о поведении пользователей;
  • когда важно учитывать охват;
  • при распределении ограниченных ресурсов;
  • для аргументированного обсуждения приоритетов со стейкхолдерами.
Метод позволяет сравнивать потенциальную ценность с затратами. Однако для его использования нужны достаточно надёжные данные.
Если команда не может оценить охват или трудозатраты, итоговый балл создаст лишь иллюзию точности. В такой ситуации лучше сначала провести исследование или использовать более простой метод.

5. Чем отличаются MoSCoW, ICE и RICE

MoSCoW, ICE и RICE используются для разных типов решений.
MoSCoW помогает разделить задачи на обязательные, важные, дополнительные и те, которые не войдут в текущий релиз. Метод не требует сложных расчётов и лучше всего подходит для определения объёма MVP или релиза.
ICE позволяет быстро сравнить идеи и гипотезы по предполагаемому влиянию, уровню уверенности и простоте реализации. Его удобно использовать, когда идей много, а точных данных пока недостаточно.
RICE учитывает охват пользователей, влияние, уверенность и трудозатраты. Он подходит для более детального планирования и сравнения инициатив разного масштаба.
Таким образом, MoSCoW отвечает на вопрос, что обязательно должно быть реализовано. ICE помогает понять, какую гипотезу стоит проверить первой. RICE показывает, какая инициатива может принести больше пользы с учётом охвата и необходимых ресурсов.

6. Как выбрать подходящий метод

Выбор зависит от задачи, стадии продукта и доступных данных.

Используйте MoSCoW, если:

  • необходимо определить минимальный объём продукта;
  • приближается релиз;
  • нужно согласовать требования;
  • есть жёсткий срок;
  • важно понять, без каких функций продукт не сможет работать.

Используйте ICE, если:

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

Используйте RICE, если:

  • нужно сформировать roadmap;
  • есть данные о количестве пользователей;
  • сравниваются инициативы разного масштаба;
  • важно учитывать затраты команды;
  • необходимо аргументировать приоритеты перед руководством или стейкхолдерами.
Методы можно комбинировать. Например, сначала при помощи MoSCoW определить обязательные задачи релиза, а затем использовать RICE для определения порядка реализации задач внутри категорий Should have и Could have.
Другой вариант — применять ICE для первичной оценки большого количества идей, а наиболее перспективные инициативы затем анализировать с помощью RICE.

7. Типичные ошибки при приоритизации

Считать все задачи обязательными

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

Подгонять оценки под желаемый результат

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

Сравнивать задачи по разным шкалам

Нельзя оценивать одну группу гипотез по десятибалльной шкале, а другую — по пятибалльной. Все инициативы должны сравниваться по одинаковым правилам.

Игнорировать стратегию продукта

Высокий ICE- или RICE-балл ещё не означает, что задачу обязательно нужно выполнять. Инициатива может не соответствовать текущей стратегии или целям компании.

Не пересматривать приоритеты

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

8. Что важно помнить

MoSCoW, ICE и RICE помогают сделать процесс выбора задач более прозрачным, но не заменяют продуктового мышления.
MoSCoW лучше всего отвечает на вопрос: что обязательно должно войти в релиз?
ICE помогает определить: какую гипотезу стоит проверить первой?
RICE позволяет оценить: какая инициатива принесёт больше пользы с учётом охвата и необходимых ресурсов?
Хороший Product Manager не выбирает один метод на все случаи. Он использует тот подход, который соответствует текущей задаче, доступным данным и зрелости продукта.

Совет эксперта

Перед использованием любой формулы договоритесь с командой о критериях оценки. Все участники должны одинаково понимать, что означают высокое влияние, высокая уверенность или большие трудозатраты.
Не стремитесь получить математически идеальный ответ. Цель приоритизации — не создать безошибочный рейтинг, а сделать логику принятия решений понятной для команды.
Если итоговый результат кажется нелогичным, не стоит автоматически следовать формуле. Проверьте исходные оценки, обсудите предположения и убедитесь, что приоритет соответствует стратегии продукта и реальным потребностям пользователей.

Если хотите не просто знать формулы, а научиться применять их на реальных продуктовых задачах и защищать приоритеты перед командой — на курсе Product Manager от Tallinn Learning вы разберёте MoSCoW, ICE и RICE на практике вместе с преподавателями-экспертами отрасли.

Статью подготовили

authors
27.07.2026