Метод MoSCoW
Тема дорожной карты · Business Analysis
Метод MoSCoW — это популярный инструмент для приоритизации требований в проектах. Разработанный Dai Clegg и используемый в методологии DSDM (Dynamic Systems Development Method), он помогает командам сфокусироваться на ключевых элементах, которые необходимы для успешного выпуска продукта. Этот метод особенно полезен для проектов, где важно четко определить границы и приоритеты, чтобы избежать перегрузки и сбоя в работе.
Как это работает
MoSCoW включает четыре категории: Must-have (обязательно), Should-have (желательно), Could-have (полезно), Won't-have (необязательно). Каждый элемент требований классифицируется в одну из этих категорий, что помогает команде определить, какие функции или элементы критически важны для релиза, а какие могут быть отложены или исключены.
Проведите MoSCoW-воркшоп с Product Owner (PO), 2-3 инженерами и ключевыми стейкхолдерами. Для каждого элемента задайте вопросы: "Если выпустим без этого, провалится ли релиз?" (Must), "Есть ли приемлемый workaround?" (Should), "Заметят ли пользователи отсутствие?" (Could), "Явно вне scope этого релиза?" (Won't). Целитесь примерно в 30-40% Must, 30-40% Should, 20-30% Could, остальное Won't. Дрейф к "всё Must" указывает, что команда не принимает компромиссы.
Когда применять
MoSCoW лучше всего работает для release-level приоритизации (что войдёт в v1.0), а не для непрерывного упорядочивания backlog (RICE подходит лучше). Используйте раз на план релиза, обновляйте при значимых изменениях scope. Этот метод особенно эффективен при подготовке к выпуску продукта, где важно определить, какие функции являются критически важными, а какие могут быть отложены или исключены.
Типичные ошибки
(1) 'Всё Must' — каждый стейкхолдер аргументирует, что его элементы Must; результат — нет реальной приоритизации. Пушбэчите "если бы отрезали 30% Must-элементов, какие были бы?". (2) Нет списка Won't — без явного out-of-scope scope creep невидим. (3) MoSCoW для непрерывного backlog — каждый элемент "Must для следующего спринта" даже когда не должен быть; используйте RICE или подобное для продолжающейся приоритизации.