Модель приоритизации MoSCoW

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

Как работает приоритезация MoSCoW

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

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

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

Категории приоритетов MoSCoW

1. Обязательные инициативы (Must-have)

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

Категория «must-have» требует от команды выполнения обязательной задачи. Если вы не уверены, относится ли что-то к этой категории, задайте себе следующие вопросы.

Если продукт не будет работать без инициативы или релиз станет бесполезным без нее, инициатива, скорее всего, является обязательной.

2. Необходимые инициативы (Should-have)

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

Should-have  инициативы отличаются от Must-have инициатив тем, что их можно запланировать для будущего выпуска, не влияя на текущий. Например, улучшения производительности, исправления мелких ошибок или новые функции могут быть Should-have инициативами. Без них продукт все равно работает.

3. Возможные инициативы (Could-have initiatives)

Еще один способ описания Could-have initiatives инициатив — Nice to have. Could-have initiatives инициативы не являются необходимыми для основной функции продукта. Однако по сравнению с Must-have инициативами, они имеют гораздо меньшее влияние на результат, если их не учитывать.

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

4. Не будет (Will-not-have)

Одним из преимуществ метода MoSCoW является то, что он помещает несколько инициатив в категорию Will-not-have. Категория может управлять ожиданиями относительно того, что команда не будет включать в конкретный выпуск (или другие временные рамки, которые вы определяете в качестве приоритетных).

Помещение инициатив в категорию Will-not-have — это один из способов предотвратить расползание масштабов. Если инициативы относятся к этой категории, команда знает, что они не являются приоритетом для данного конкретного периода времени.

Некоторые инициативы в группе Will-not-have будут иметь приоритет в будущем, в то время как другие вряд ли осуществятся. Некоторые команды решают провести различие между ними, создав подкатегорию внутри этой группы.

 

История метода MoSCoW

Эксперт по разработке программного обеспечения Дай Клегг создал метод MoSCoW во время работы в Oracle. Он разработал структуру, чтобы помочь своей команде определить приоритеты задач во время разработки выпусков продуктов.

Вы можете найти подробный отчет об использовании приоритезации MoSCoW в справочнике по методу динамической разработки системы (DSDM). Но поскольку MoSCoW может определять приоритеты задач в рамках любого ограниченного по времени проекта, команды адаптировали этот метод для широкого спектра применений.