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

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

Суть MoSCoW Как же команде разработки продукта понять, какие требования отнести к каждой из категорий (Must have, Should have, Could have или Won't have)? Для этого можно использовать следующую подсказку: Must have (обязательные требования) • Без этих требований продукт не будет выполнять свои основные функции. • Регуляторные и законодательные требования, которые необходимы для соответствия законам, стандартам или нормативам. • Требования, которые обеспечивают базовый уровень безопасности и надежности. • Требования, которые должны быть выполнены для того, чтобы другие ключевые функции могли работать. • Требования, которые должны быть реализованы для выпуска первой версии минимально жизнеспособного продукта (MVP). Should have (важные требования) • Требования, которые значительно улучшают использование продукта, но не критичны для его базовой работы. • Требования, которые помогают продукту выделиться на рынке, но не являются жизненно важными для запуска продукта. • Улучшают производительность, удобство использования или другие аспекты, но без них продукт функционален. • Важные для значительной части пользователей, но не для всех. Could have (желательные требования) • Эти требования добавляют ценность и улучшают пользовательский опыт, но не являются критически важными. • Требования, которые можно реализовать, если останутся ресурсы (время, бюджет). • Требования, которые важны для небольшой группы пользователей, но не для большинства Won't have (можно отказаться) • Требования, которые не приносят существенной ценности или улучшения продукта. • Требования, которые не соответствуют текущей стратегии продукта.

Давайте попробуем на примере шариковой ручки разделить вот эти требования к ней на 4 группы: ➖ Удобство хвата. ➖ Наличие клипсы для крепления к одежде или блокноту. ➖ Сопротивление усилию при письме (например, для комфортного использования). ➖ Интегрированный механизм для изменения толщины линии. ➖ Писать ➖ Возможность заправки ручки новым стержнем. ➖ Резервуар для дополнительных стержней. ➖ Интегрированный фонарик или лазерный указатель. ➖ Выдвижение/подтягивание стержня.

Пишите в комментариях какие их этих требований вы бы отнесли к группе Must have, какие к Should have, что в Could have , и какие к Won't have… А в следующем посте я дам свой вариант.