Приоритизация MoSCoW: что это и как применять

Автор

Дай Клегг (Dai Clegg) при участии Ричарда Баркера (Richard Barker), Oracle; принят в DSDM, 1994

Уровень

201 · Инструмент

Подходит

стартап, малый и средний бизнес, растущая компания

Время на внедрение

Полдня на разбор бэклога одного релиза; при смене срока или объёма — короткий повторный проход

Что понадобится

срок или дата релиза, которые не сдвинутся · полный список требований, которые кто-то просит сделать · один человек с полномочиями записать Won't have и добиться, чтобы это соблюдалось

Приоритизация MoSCoW делит список требований на четыре группы. Это Must have (обязательно), Should have (желательно), Could have (возможно) и Won’t have this time (не в этот раз). Команда заранее договаривается, что даст релиз при фиксированном сроке и бюджете. Метод отвечает на один вопрос до начала работы: что нужно, чтобы релиз стоило выпускать, и что подождёт следующего.

Дай Клегг (Dai Clegg) создал метод в Oracle в 1994 году, когда работал над проектами быстрой разработки приложений (RAD) с неподвижными сроками. Вторичные источники единодушно связывают его с книгой Case Method Fast-Track: A RAD Approach (Addison-Wesley, 1994), которую Клегг написал вместе с Ричардом Баркером (Richard Barker). Вскоре метод принял в число основных техник DSDM (Dynamic Systems Development Method, метод разработки динамических систем), который сейчас ведёт Agile Business Consortium. Основным рабочим описанием четырёх категорий остаётся руководство консорциума DSDM Project Framework Handbook.

Что означает каждая категория

Must have — минимальный набор требований, без которого релиз выпускать нельзя. Руководство DSDM называет его «Minimum Usable SubseT» (минимальное пригодное подмножество): то, что проект гарантированно поставит. Should have — работа, которая важна и без которой больно, но релиз остаётся жизнеспособным. Could have — список желаемого: нужно, но менее важно. Он же служит резервом проекта: эту работу берут, только если хватает времени и бюджета. Won’t have this time — требования, которые команда письменно согласовала не делать в этом релизе. Это не то же самое, что пункт, который никто не обсуждал.

DSDM предлагает прямой тест для колонки Must have: что будет, если требование не выполнить? Если ответ — отменить релиз, потому что выпускать решение без него бессмысленно, пункт относится к Must have. Тот же вопрос удобно задать иначе на встрече с заинтересованными сторонами. Если с пунктом Must have возникнет проблема накануне развёртывания, остановит ли команда развёртывание? Однозначное «да» подтверждает категорию. Если команда выпустила бы релиз без пункта, пусть неохотно, пункту не место в этой колонке.

Почему категории зависят от фиксированного срока

MoSCoW работает, только если зафиксированы срок и бюджет. DSDM применяет четыре категории сразу на трёх уровнях: ко всему проекту, к инкременту проекта и к текущему тайм-боксу. Тайм-бокс — короткий период работы с фиксированной датой окончания. Требование, которое на уровне проекта относится к Should have, часто становится Won’t have внутри тайм-бокса этой недели. В тайм-боксе гораздо меньше времени, чем во всём проекте. Категории описывают, что помещается в имеющиеся время и деньги. Желание получить функцию значения не имеет.

Ограничение Must have на уровне 60% трудозатрат

Руководство DSDM задаёт число, которое не даёт Must have поглотить весь список. В типичном проекте требования Must have занимают не более 60% общих доступных трудозатрат. Could have остаётся основным резервом, обычно около 20% трудозатрат. Ограничение считает трудозатраты, а не число пунктов в колонке. Если 95% трудозатрат закреплено за Must have, нет запаса на затянувшуюся оценку или непредвиденную ошибку. До пунктов Should have и Could have команда при таком плане не дойдёт.

Где MoSCoW даёт сбои

Первый сбой — пропущенный тест. Команды записывают четыре метки, но не задают каждому пункту вопрос DSDM: что будет, если этого не будет? В 2024 году Виджаякумар, Прасад К и Холла (Vijayakumar, Prasad K, Holla) изучили метод в разработке программ. Участники — 172 респондента — выполнили практическое упражнение по приоритизации и рассказали, что пошло не так. Чаще всего жаловались на путаницу: так ответили 83 человека. Отдельная группа назвала ровно ту проблему, для которой существует ограничение 60%: слишком много пунктов попадает в Must have. В той же работе отмечен структурный пробел: метод «лишён явных стандартов и указаний для оценки значимости и срочности требований». Авторы ссылаются и на более раннее исследование проекта библиотечной системы. Там слишком много пунктов с меткой «обязательно» вызвало именно ту задержку, которую MoSCoW должен был предотвратить.

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

MoSCoW в сравнении с RICE, Kano и матрицей Эйзенхауэра

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

Шон Макбрайд (Sean McBride) создал RICE в Intercom. Метод оценивает идею как Reach (охват) × Impact (влияние) × Confidence (уверенность) ÷ Effort (трудозатраты). Результат — ранжированный список, а не четыре группы. RICE решает именно ту задачу, которую MoSCoW не решает: сравнивает пункты между собой. Модель Кано (Kano) опубликовал в 1984 году Нориаки Кано (Noriaki Kano) с тремя соавторами. Она задаёт другой вопрос: просто ли функция работает или радует клиента. Простой тест необходимости в MoSCoW для этого не предназначен. Матрица Эйзенхауэра внешне похожа: те же четыре подписанных квадранта. Но она сортирует личные задачи человека по срочности и важности, а не общий релиз команды при общем сроке. Используйте матрицу Эйзенхауэра, когда проблема в календаре одного человека. Используйте MoSCoW, когда нужно решить, что вся команда выпустит к дате, которая не сдвинется.

Такая сортировка бэклога — та же дисциплина, на которой строится работа Pushers над операционными системами. Срок выдерживается, только если до начала работы все согласились, что именно нужно сдать.

Как применять: Приоритизация MoSCoW: что это и как применять по шагам

1. Соберите все требования в один список. Перенесите в единый список каждое требование, функцию и исправление, о которых кто-то просил. Формулировку оставьте такой, как её дал автор запроса, а не пересказ отдела. Запросы, разбросанные по почте, чатам и старым задачам, нельзя приоритизировать как группу. Результат: один список, о котором спорят все, вместо нескольких частичных.
2. Примените тест Must have к каждому пункту. Для каждого пункта задайте вопрос: что будет, если его не сделать? Если релиз провалится или нарушит правило, которое бизнес нарушать не вправе, это Must have. Если команда всё равно выпустила бы релиз без пункта, это не Must have. Результат: в колонке Must have остаются только пункты, без которых никто не выпустил бы релиз.
3. Разделите остальное на Should и Could. Should have — важная работа, которую неприятно пропускать, но релиз без неё работает. Could have — список желаемого: полезно, если хватит времени. Он же служит резервом. Результат: две колонки, которые отделяют важное от «хорошо бы иметь».
4. Запишите Won't have и объявите его открыто. Укажите явно, какие требования в этот раз не будут выполнены, и сообщите об этом тем, кто их просил. Пункт, который никто не разбирал, просто забывается и позже возвращается неожиданностью. Результат: граница объёма, известная всей команде, а не только автору списка.
5. Сложите трудозатраты по категориям. Оцените трудозатраты на каждый пункт и просуммируйте их по категориям. Если Must have превышает примерно 60% трудозатрат, которые вмещает тайм-бокс, часть пунктов в этой колонке лишняя. Либо нужно сдвинуть сам срок. Результат: список Must have рассчитан на имеющееся время, а не на ожидания участников.
6. Привяжите разбор к тайм-боксу и повторяйте при его изменении. Закрепите категории за фиксированным периодом этого релиза. Когда меняются срок, команда или объём, проведите разбор заново, а не правьте старый. Результат: список остаётся точным и не устаревает в первую же неделю.

Примеры

Запуск платёжной функции в финтехе

Иллюстративный пример: компания, которая проводит трансграничные платежи, добавляет новый способ выплаты к дате запуска, назначенной партнёрской интеграцией. Проверка личности клиента и проверка по санкционным спискам, которые нужны потоку выплат, — Must have: релиз без них нарушает закон, которому выплата должна соответствовать. Список сохранённых получателей для повторных переводов — Should have: он упрощает повторные переводы, но без него дата запуска и закон остаются в силе. Собственный звук уведомления о завершённой выплате — Could have.

Перестройка сайта клиники

Иллюстративный пример: клиника физиотерапии перестраивает сайт к началу ежегодного периода, когда работодатели продлевают договоры ДМС и выбирают клиники. Онлайн-запись и анкета пациента, соответствующая обязательствам клиники по обработке данных, — Must have: пациентам нужно записываться, а собирать сведения о здоровье через незащищённую форму клиника не вправе. Страница о сотрудниках — Should have. Редизайн блога — Could have: его снимают, как только тайм-бокс становится тесным.

Когда применять

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

Когда не применять

Не используйте метод, если нет жёсткого срока, который вынуждает выбирать. Тогда у категорий нет давления, и всё постепенно уходит в Must have. MoSCoW также не ранжирует два пункта внутри одной категории. Когда сложный вопрос — какой из двух Must have делать первым, сочетайте MoSCoW с методом скоринга, например с RICE, а не требуйте от четырёх букв ответа, для которого они не предназначены.

Частые ошибки

• Позволять Must have расти сверх того, что вмещает срок. Метка перестаёт означать «обязательно» и начинает означать «всё, на чём кто-то настоял».
• Проводить разбор без фиксированного срока. Без срока исчезает давление, из-за которого пункт становится Should have или Could have, а не Must have.
• Считать Won't have остатком, а не решением. Тогда пункты, которые никто не разбирал, по умолчанию превращаются в обещания.
• Ждать от MoSCoW ранжирования внутри категории: метод лишь отделяет одну категорию от другой.
• Разобрать список один раз на старте и не повторять, когда изменились объём или срок.

Вопросы и ответы

Как расшифровывается MoSCoW?

MoSCoW — это Must have, Should have, Could have и Won't have this time (не в этот раз). Лишние буквы «o» добавлены только для того, чтобы аббревиатуру можно было произнести как слово. Сами по себе они ничего не обозначают. Дай Клегг (Dai Clegg) ввёл метод в Oracle в 1994 году, а вскоре DSDM принял его как одну из основных техник.

Как определить, что пункт относится к Must have?

Задайте вопрос: что будет, если этого не сделать? Тест DSDM: если ответ — отменить релиз, потому что без этого пункта выпускать решение бессмысленно, пункт относится к Must have. Если команда выпустила бы релиз и без него, пусть неохотно, пункт относится к Should have или ниже.

Какую долю релиза должен занимать Must have?

Рекомендация DSDM: Must have занимает не более 60% общих доступных трудозатрат. Could have остаётся основным резервом, обычно около 20%. Ограничение относится к оценке трудозатрат, а число пунктов в списке значения не имеет.

MoSCoW и матрица Эйзенхауэра — это одно и то же?

Нет. MoSCoW сортирует требования к одному релизу при фиксированном сроке и бюджете. Матрица Эйзенхауэра сортирует задачи по срочности и важности для времени одного человека, без общего релиза и срока. У обоих методов по четыре категории, и на этом сходство заканчивается.

В чём главная слабость MoSCoW?

Метод не ранжирует два пункта внутри одной категории и не мешает Must have вырасти сверх того, что вмещает срок. Исследование метода 2024 года показало: среди самых частых жалоб тех, кто только что его применил, — путаница и перегруженная колонка Must have.

Источники

1. Agile Business Consortium, DSDM Project Framework Handbook, MoSCoW Prioritisation
2. Agile Business Consortium, What is MoSCoW Prioritization?
3. Dai Clegg and Richard Barker, Case Method Fast-Track: A RAD Approach, Addison-Wesley 1994, Internet Archive record
4. Association for Project Management, How to manage multiple projects (and prioritise like a pro)
5. Vijayakumar, Prasad K and Holla M, Assessing the Effectiveness of MoSCoW Prioritization in Software Development, EAI Endorsed Transactions on Internet of Things, 2024
6. Kravchenko, Bogdanova and Shevgunov, Ranking Requirements Using MoSCoW Methodology in Practice, Springer, Cybernetics Perspectives in Systems, 2022
7. Kano, Seraku, Takahashi and Tsuji, Attractive Quality and Must-Be Quality, Journal of the Japanese Society for Quality Control 14(2), 1984
8. Intercom (Sean McBride), RICE Prioritization Framework for Product Managers
9. ProductPlan, MoSCoW Prioritization
10. ProductPlan, Kano Model
11. Productboard, Product Prioritization Frameworks
12. Aha!, Product Prioritization Frameworks: 12 Common Models
13. TechTarget, What is the MoSCoW method?
14. Smartsheet, All about Project Prioritization
15. Mindtools, The MoSCoW Method
16. US Financial Crimes Enforcement Network, CDD Rule FAQs
17. PRINCE2.com, The MoSCoW method explained
18. IAPM, The MoSCoW method: balancing needs and resources
19. Dwight D. Eisenhower, Address at the Second Assembly of the World Council of Churches, 19 August 1954 (The American Presidency Project)
20. Kurt Matzler and Hans H. Hinterhuber, How to make product development projects more successful by integrating Kano's model of customer satisfaction into quality function deployment, Technovation 18(1), 1998

Обновлено 30 октября 2026

Илья ПушинОснователь PUSHERS & COO Fintech ServiceИлья строит операционные системы для растущих компаний в медицине и финтехе. С 2021 года руководит трансграничными платежами в ARBI Exchange, лицензированном обменнике в Таиланде, включая KYC, AML и выход в новые юрисдикции.Об автореLinkedIn