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

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

Автор статьи – Максим Якубович, партнер Product Lab.

Из статьи вы узнаете: 

1. зачем нужна приоритизация требований;
2. что кроется за аббревиатурой MoSCoW;
3. в каких ситуациях есть смысл использовать MoSCoW;
4. как выполнить приоритизацию бэклога с помощью MoSCoW;
5. как этот подход работает на примере.

Что такое метод MoSCoW? 

MoSCoW — это аббревиатура от слов Must have (обязательно должен иметь), Should have (должен иметь), Could have (хорошо бы иметь) и Won’t have (не нужно иметь).

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

С помощью MoSCoW можно:

● определить, какие требования к продукту стоит включить в продукт (или его прототип/MVP);

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

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

Автором подхода MoSCoW считается Дай Клегг, сотрудник компании Oracle, который в 1994 г. впервые описал этот подход в статье „Case Method Fast-Track: A RAD Approach”. Изначально метод использовали для расстановки приоритетов в проектах по разработке ИТ-продуктов, но позже стали использовать его при работе и над другими типами продуктов.

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

Суть метода MoSCoW

Как же команде разработки продукта понять, какие требования отнести к каждой из категорий (Must have,  Should have, Could have или Won’t have)?

Для этого можно использовать следующую подсказку:

Must have (обязательные требования)

• Без этих требований продукт не будет выполнять свои основные функции.
• Регуляторные и законодательные требования, которые необходимы для соответствия законам, стандартам или нормативам.
• Требования, которые обеспечивают базовый уровень безопасности и надежности.
• Требования, которые должны быть выполнены для того, чтобы другие ключевые функции могли работать.
• Требования, которые должны быть реализованы для выпуска первой версии минимально жизнеспособного продукта (MVP).

Should have (важные требования)

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

Could have (желательные требования)

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

Won’t have (можно отказаться)

• Требования, которые не приносят существенной ценности или улучшения продукта.
• Требования, которые не соответствуют текущей стратегии продукта.

Как провести приоритизацию с помощью MoSCoW

Приоритизация с помощью метода MoSCoW проводится на встрече с командой и пользователями и проходит в несколько шагов.

1. Создание списка элементов для приоритизации 

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

2. Оценка важности каждого элемента

Вместе с командой и ключевыми заинтересованными сторонами (пользователями) оцените каждый элемент.

3. Разделение элементов на категории MoSCoW

Все элементы распределите по следующим категориям:

• Must have (обязательно) — выберите только те функции или задачи, без которых продукт не может быть реализован. Это могут быть минимально необходимые функции для запуска продукта.
• Should have (желательно) — выберите важные функции, которые существенно улучшают продукт, но не являются критичными для его базовой функциональности.
• Could have (можно было бы) — определите функции, которые будут приятным дополнением, но не являются обязательными. Они могут быть реализованы, если останется бюджет.
• Won’t have (не будет сделано) — это функции, которые на данном этапе не будут реализованы, но могут быть рассмотрены в будущем.

4. Обсуждение с заинтересованными сторонами

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

5. Постоянное обновление приоритизации

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

6. Использование при планировании дальнейших релизов 

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

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

Встреча для приоритизации списка требований по MoSCoW обычно состоит из трех ключевых этапов:

1. Обсуждение формулировок требований в списке.

Участники встречи обсуждают вопросы:

• Понятны ли  участникам встречи все требования из списка?

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

• Какие правила необходимы для обсуждения приоритетов?

Например, правила могут быть такими:

1. Идем по списку сверху вниз.
2. Продакт-менеджер каждое требование помещает в одну из 4-х категорий.
3. После этого обсуждаем каждую категорию.
4. В категории Must have должно находиться не более 60% требований из списка и т.д.

2. Присвоение одной из категорий каждому требованию.

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

• требования, которые необходимы для создания следующей версии  продукта (Must have);
• требования, которые являются важными для пользователей, но не критичны для планируемой версии продукта (Should have);
•  требования, которые стоит реализовать, только если останется время и деньги в бюджете (Could have);
•  требования, которые можно удалить из бэклога (Won’t have).

3. Обсуждение полученных результатов

Можно попросить каждого участника встречи высказаться по итогам приоритизации относительно требований, попавших в категорию Won’t have: согласен ли он, что без этих требований продукт сможет достигнуть тех целей, которые стоят перед ним в данном периоде?

После этого важно обсудить требования категории Must have: есть ли у кого-то желание убрать какие-то требования из этой категории в другую?

Есть смысл использовать метод MoSCoW для предварительного ранжирования списка требований. А для приоритизации требований категории Must have можно использовать дополнительный метод приоритизации, например, ICE или RICE.

Пример использования MoSCoW

Давайте рассмотрим использование метода на примере разработки приложения «Календарь».

Допустим, продакт-менеджер провел исследования и определил основные требования к календарю:

1. Отображение дат и событий: просмотр дней, недель и месяцев с возможностью добавления событий.

2. Добавление событий: возможность создания новых событий с указанием даты, времени, места и описания.

3. Напоминания и уведомления: оповещения о предстоящих событиях и задачах.

4. Просмотр событий по категориям: группировка событий по категориям или цветам для удобства отображения.

5. Разделение на личный и общий календарь: возможность создания нескольких календарей для личных и рабочих задач.

6. Синхронизация с другими календарями: интеграция с «Google Календарь», „Outlook“ и другими популярными календарями.

7. Поиск и фильтрация: возможность быстрого поиска событий и фильтрации по различным параметрам.

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

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

10. Интеграция с задачами и заметками: возможность связи событий с задачами или заметками для более эффективного планирования.

После этого продакт-менеджер организовал встречу с командой разработки, и после обсуждения команда распределила эти функции по четырем категориям:

Обязательные (Must have)

1. Отображение дат и событий

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

2. Добавление событий

Это также основная функция, которая позволяет пользователям создавать новые события, указывая дату, время, место и описание.

3. Напоминания и уведомления

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

Желательные (Should have)

4. Поиск и фильтрация

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

5. Разделение на личный и общий календарь

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

6. Поддержка приглашений и совместного доступа

Очень удобная функция, но команда решила сделать ее во второй версии продукта.

Возможные (Could have)

7. Просмотр событий по категориям

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

8. Синхронизация с другими календарями

Проведенные исследования показали, что меньше 10% пользователей используют одновременно несколько календарей. Команда решила отложить реализацию этой функции.

9. Поддержка повторяющихся событий

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

Не включать (Won’t have)

10. Интеграция с задачами и заметками

Возможность связи событий с задачами или заметками для более эффективного планирования команда решила вообще не делать в ближайшем будущем.

Плюсы и минусы MoSCoW 

К плюсам подхода можно отнести следующие:

1. Простота.

Сам метод довольно прост в понимании, а встреча по приоритизации может пройти всего за полчаса.

2. Вовлечение заинтересованных сторон в принятие решений.

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

Минусы подхода  MoSCoW следующие:

1. Отсутствие анализа сложности реализации и затрат.

MoSCoW не включает в себя анализ затрат на реализацию каждого требования.

2. Встреча требует участия модератора.

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

3. Результаты приоритизации субъективны.

Метод не предполагает использования каких-то формул или чисел, поэтому всегда останутся сомнения по поводу верности полученных результатов.

4. В категории Must have может оказаться довольно много требований. Если команда разработки работает по итерациям (или спринтам), то ей нужно будет понять уникальные приоритеты для требований, попавших в категорию Must have. Придется менеджеру продукта расставить приоритеты внутри этой категории.

Выводы

Подход MoSCoW — достаточно простой в использовании инструмент, который:

1. Его можно использовать для первичной приоритизации списка требований к продукту.
2. Метод подойдет для использования как на внутренних проектах по созданию ИТ-продуктов, где владельцы не готовы использовать слишком сложные подходы к приоритизации списка требований, так и при создании продукта на внешний рынок.
3. Несмотря на свою простоту, у MoSCoW есть очевидный недостаток: элементов в категории Must have может оказаться много, и тогда придется расставлять приоритеты внутри этой категории.
4. Если элементов в категории Must have слишком много, то  менеджеру продукта лучше использовать еще один подход к приоритизации, чтобы присвоить уникальный приоритет каждому требованию.

Полезные Telegram-каналы по методологии Product Focus и управлению продуктами в целом:

Присоединяйтесь к каналам в Telegram, чтобы быть в курсе новостей и новых статей из методологии Product Focus!

• Telegram-канал «Product Focus» – здесь можно будет получать свежие статьи по методологии Product Focus
• Telegram-канал «Product Lab» – здесь можно изучить больше статей из разных источников по продакт-менеджменту, а также видеть новости по внедрению методологии Product Focus
• Telegram-канал Андрея Бадина «Управляй иначе» – здесь можно узнать о том, что еще не появилось в методологии Product Focus, мысли архитектора методологии еще до выхода статей

Как правильно расставлять приоритеты, выстроить управление продуктом и командой?

Рассказываем на курсе «Полное погружение в продакт-менеджмент»!

На курсе вы:

• Научитесь запускать внутренние и внешние продукты и управлять ими
• Улучшите метрики существующего продукта
• На практике систематизируете свои знания и освоите все аспекты продакт-менеджмента
• Освоите 50+ инструментов и фреймворков из мира продакт-менеджмента
• Научитесь использовать Искусственный Интеллект в целях продакт-менеджмента

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

Также вы можете оставить заявку на наш корпоративный тренинг по Product Management.