Метод MoSCoW: как расставить приоритеты требований после встречи
Как применить MoSCoW к требованиям из обсуждения: Must, Should, Could и Won’t на текущий период. Пример распределения, вопросы команде и шаблон решения.
Приоритет существует относительно цели и периода
На встрече каждый участник назвал свою функцию обязательной. Такой список не помогает выбрать объём. Сначала нужно договориться, какой результат должен дать ближайший выпуск и что означает его непригодность. Для другого этапа распределение может быть совершенно иным.
MoSCoW использует четыре категории: Must Have, Should Have, Could Have и Won’t Have this time. Последняя означает осознанное исключение на рассматриваемый период. Она не равна обещанию выполнить позже и не означает, что идея навсегда бесполезна.
Обсудите последствия исключения
Опишите цель выпуска
Запишите пользователя, задачу и условия применения. Уточните ограничения и срок планирования. Пока цель звучит как «улучшить продукт», участники будут оценивать требования по разным основаниям и относить почти всё к обязательному.
Проверьте кандидатов в Must
Для каждого спросите, можно ли получить пригодный результат без него. Рассмотрите допустимые обходные пути и зависимости. Обязательность должна иметь конкретное объяснение; фраза «руководитель попросил» фиксирует источник, но не раскрывает последствия исключения.
Разделите важное и желательное
Should — важная часть, без которой результат заметно слабее, но остаётся пригодным. Could — полезное дополнение, которым проще пожертвовать. Объясните различие через сценарий пользователя и стоимость отсутствия, а не только через эмоциональные слова «очень нужно».
Согласуйте исключения и пересмотр
Для Won’t на этот период укажите причину и условие возвращения к обсуждению. Проверьте зависимости между требованиями и выполнимость выбранного объёма. Если обязательного больше доступной возможности, пересмотрите границы или план; смена буквы проблему ресурсов не решает.
Первый выпуск формы регистрации на событие
Ниже — вымышленный учебный пример. Имена, условия и результаты приведены только для объяснения метода.
Нам нужно принять заявку и подтвердить место. Выбор любимого цвета бейджа приятен, но мероприятие без него состоится. Личный кабинет пока не успеваем обсуждать.
В учебном примере цель — зарегистрировать участника и дать понятное подтверждение. Возможность подать заявку относится к Must, потому что без неё исчезает основной сценарий. Напоминание может стать Should, если команда временно справится согласованным обходным способом.
Цвет бейджа можно отнести к Could, а личный кабинет — исключить на текущий период. Это не универсальная классификация функций: для другого события или аудитории последствия окажутся другими.
| Требование | Категория | Основание |
|---|---|---|
| Подать заявку | Must | Иначе основной сценарий отсутствует |
| Получить напоминание | Should | Важно, возможен временный обход |
| Выбрать цвет бейджа | Could | Не мешает регистрации |
| Личный кабинет | Won’t сейчас | Вне согласованного объёма |
Карточка обоснования приоритета
Сохраняйте не только категорию, но и логику выбора. Это поможет вернуться к решению, когда изменятся условия.
Выпуск / период / цель: Требование: Пользовательский сценарий: Что случится без требования: Есть ли допустимый обходной путь: Зависимости: Категория MoSCoW: Основание выбора: Кто подтвердил решение: Условие пересмотра: Исключения на этот период:
Проверьте, помогает ли список выбирать
- Цель и период указаны рядом с категориями.
- Для Must описано последствие исключения.
- Временный обходной путь оценён явно.
- Won’t сейчас не прочитан как обещание на следующий выпуск.
Разберём детали
Может ли требование сменить категорию?
Да, если изменилась цель, период, зависимость или появились новые данные. Зафиксируйте причину и согласуйте влияние на объём вместо незаметного переноса.
Что делать, если все требования Must?
Попросите показать непригодность результата без каждого пункта, проверьте обходные пути и сузьте цель. Если обязательный объём всё равно слишком велик, нужен пересмотр плана.