Блог CosySoft
2025-03-20 13:37 Разработка

MoSCoW never sleeps: методология, которая помогает расставить приоритеты

Разработка ПО напоминает эквилибриста на канате, который пытается удержать равновесие между жесткими сроками, бюджетными ограничениями и растущим списком требований. Каждая новая вводная еще сильнее раскачивает эту тонкую нить, и команда рискует не выполнить проект в срок.
Чтобы не потерять фокус и успеть к дедлайну, нужен понятный метод приоритезации. Один из таких подходов — MoSCoW. Он делит требования на четыре категории: Must-Have, Should-Have, Could-Have и Won’t-Have. Это показывает, что критично для успеха и что можно временно отложить. MoSCoW особенно полезен в ситуациях, где все быстро меняется и требования пересматриваются на ходу. То есть во всех ситуациях.

Москва не сразу строилась

MoSCoW возник в рамках DSDM — одного из первых гибких подходов к управлению проектами.
DSDM (Dynamic Systems Development Method) — это гибкий подход к управлению проектами, появившийся в середине 1990-х. Его создали для быстрой итеративной разработки: команда постоянно получает обратную связь, корректирует курс и выпускает продукт небольшими «порциями». В отличие от классических «водопадных» моделей, DSDM нацелен на гибкость, прозрачность и совместную работу со стейкхолдерами.
Дэй Клегг из Oracle разработал MoSCoW, чтобы упростить расстановку приоритетов, ведь при итеративном подходе не все функции можно внедрять одновременно. Так MoSCoW дополнил DSDM инструментом для управления объемом работ, позволяя сначала решать самые критичные задачи.

Как это связано с городом?

Никак. Слово «MoSCoW» — это мнемоника (такая же, как про охотника и фазана), чтобы запомнить четыре категории требований: Must-Have (обязательное), Should-Have (желательное), Could-Have (можно добавить) и Won’t-Have (не в этот раз). А гласные «o» в нее включили ради удобства произношения.
Главная задача MoSCoW — дать структуру для разбивки требований по важности и срочности, чтобы команда сосредоточилась на самых критичных аспектах и решила, что можно отложить или исключить.

Must-Have (Обязательное)

Must-Have — это безоговорочно важные элементы проекта. Без них продукт не сможет выполнить ключевую задачу или не будет соответствовать бизнес-целям. Must-Have — это фундамент продукта. Даже при ограниченных ресурсах Must-Have реализуют в первую очередь, чтобы продукт отвечал основным целям.

Примеры критериев Must-Have:

  • Основная функциональность, без которой система не работает.
  • Законодательные или обязательные требования.
  • Критически важные процессы и функции.
В онлайн-банке Must-Have — это возможность безопасной авторизации и выполнения основных операций вроде перевода средств и оплаты счетов. Без этого приложение не решает свою основную задачу обслуживания финансовых транзакций.

Should-Have (Желательное)

Should-Have — это функции, без которых продукт будет работать, но их отсутствие может ухудшить удобство, качество или ценность.

Примеры критериев Should-Have:

  • Улучшают пользовательский опыт и ключевые процессы.
  • Учитывают запросы пользователей или стейкхолдеров.
  • Дают конкурентное преимущество или близки к бизнес-целям.
Например, для онлайн-банкинга Should-Have — это отдельная вкладка «Аналитика расходов». Без нее банк-приложение все равно выполняет ключевые функции, но удобные диаграммы и статистика помогают клиенту лучше понимать свои траты.
Should-Have можно отложить, если возникает нехватка времени или ресурсов. Should-Have оставляет пространство для адаптации, сохраняя общую ценность продукта.

Could-Have (Можно добавить)

Could-Have — это функции или улучшения, которые делают продукт привлекательнее, но не влияют на базовую работоспособность.

Примеры критериев Could-Have:

  • Не влияют на использование, если их не включать.
  • Предлагают второстепенные улучшения, не затрагивающие основные цели.
  • Можно отложить без ущерба для основной функциональности.
В том же онлайн-банке Could-Have — это темная тема интерфейса или анимированные переходы между экранами. Эти украшения приятны пользователю, но не критичны для основных операций и не влияют на возможности перевода средств или оплаты счетов.
Функции Could-Have стоит добавлять, если есть ресурсы и время. Они нравятся пользователям и дают конкурентное преимущество. Главное — не жертвовать функциями из Must-Have и Should-Have.

Won’t-Have (Не в этот раз)

Won’t-Have — это элементы, которые исключаются из текущего релиза и планируются на будущее.
Примеры критериев Won’t-Have:
  • Не укладываются в сроки и бюджет.
  • Усложняют систему или несут повышенный риск.
  • Не имеют высокого спроса со стороны пользователей или стейкхолдеров.
Для онлайн-банка Won’t-Have — это поддержка криптовалют. Ее можно рассмотреть в будущем, когда появится спрос или соответствующая стратегия.

Преимущества MoSCoW

Улучшенная коммуникация со стейкхолдерами

MoSCoW задает четкую систему категорий (Must-Have, Should-Have, Could-Have, Won’t-Have) и общие правила обсуждения. Так команде проще объяснить, что будет включено в текущий релиз, а что отложено. Если стейкхолдеры хотят добавить новые функции, команда указывает на приоритеты в MoSCoW, чтобы избежать путаницы и разрастания задач.

Повышение эффективности спринтов в Scrum

В Scrum MoSCoW помогает выбирать задачи для спринта, начиная с Must-Have, затем добавляя Should-Have и Could-Have при наличии ресурсов. Это позволяет стабильно достигать минимально жизнеспособного продукта (MVP) и улучшать его в следующих итерациях.

Эффективное распределение ресурсов

При ограниченных сроках или бюджете MoSCoW помогает сосредоточиться на Must-Have и не тратить силы на менее важные задачи. Should-Have и Could-Have выполняют лишь при наличии свободных ресурсов.

Улучшенное управление рисками

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

А минусы будут?

Возможные недопонимания

Разные участники проекта могут по-своему трактовать категории MoSCoW. Например, команда относит задачу к Should-Have, а заказчик уверен, что это Must-Have.

Согласование ожиданий стейкхолдеров

Некоторые заинтересованные лица на проекте настаивают, что их функции обязательны, и хотят расширить Must-Have. Это вызывает споры и раздувает объем работ.

Перегрузка категории Must-Have

Самая распространенная ошибка — включать слишком много требований в Must-Have. Тогда приоритизация теряет смысл, и проект рискует захлебнуться в объеме задач. Нужно четко отделять то, без чего продукт не работает, от улучшений, без которых проект все же остается жизнеспособным.

Если все задачи — Must-Have. 10 советов по назначению приоритетов

Включайте в процесс приоритезации всех, кто влияет на решение. Это помогает учесть разные точки зрения и избегать конфликтов в дальнейшем.
  1. Начните с Won’t Have. Сначала присвойте всем требованиям статус Won’t Have, а затем обоснуйте, почему они должны получить более высокий приоритет.
  2. Установите лимит на число Must-Have на каждую фазу или спринт.
  3. Устанавливайте четкие правила для Must-Have, Should-Have, Could-Have и Won’t-Have. Приводите конкретные примеры, чтобы все участники понимали, почему та или иная задача попадает в соответствующий раздел.
  4. Проверка Must-Have. Для каждого требования, предложенного как Must-Have, задайте вопрос: «Что произойдет, если это требование не выполнено?» Если ответ: «Проект придется отменить» — это действительно Must-Have. В противном случае рассматривайте его как Should-Have или Could-Have.
  5. Проверка перед развертыванием. «Если за день до развертывания я скажу, что это требование не выполнено, вы отмените релиз?» Если ответ «да», то это Must-Have. В противном случае пересмотрите приоритет.
  6. Зависимости от других требований. Must-Have не может зависеть от задач с более низким приоритетом (Should-Have или Could-Have), так как это создает риски для основной функциональности проекта.
  7. Разные приоритеты для критериев приемки. Например: «Процедуры резервного копирования должны восстанавливать сервис как можно быстрее». Should-Have: восстановление в течение 4 часов. Must-Have: восстановление в течение 24 часов.
  8. Декомпозиция требований. Можно ли разбить требование на части? Нужно ли реализовать каждую часть для выполнения задачи? Все ли элементы имеют одинаковый приоритет?
  9. Привязка к цели проекта. Если проектная цель не Must-Have, то и требование, связанное с ней, вероятно, также не Must-Have.
  10. Изменение приоритета со временем. Например, в первом релизе требование — Should-Have, но в последующих версиях оно становится Must-Have.

Заключение

Метод MoSCoW помогает не сбиться с пути, когда дедлайны поджимают, а требования множатся. Разделение задач на Must-Have, Should-Have, Could-Have и Won’t-Have позволяет команде не метаться от одной задачи к другой, а четко понимать, что делать в первую очередь, а что можно отложить.
Особенно хорошо MoSCoW работает в гибких методологиях: Scrum, Kanban, XP. Когда приоритеты меняются чуть ли не каждую неделю, этот метод помогает держать проект в рамках и не терять фокус на главном.
Если подходить к MoSCoW без формальностей, это просто удобный инструмент, который помогает не только завершить проект в срок, но и сохранить здравый рассудок. Устанавливая приоритеты заранее, команда меньше спорит, лучше управляет ресурсами и быстрее достигает целей.