Методы приоритизации: MoSCoW
Мы поговорили на прошлой неделе о Story Map, а сегодня поговорим о методе MoSCoW — это акронимом из букв, стоящих за одной из возможных категорий приоритетов (с добавлением “Os”, чтобы сделать ее легко запоминающимся).
Требования классифицируются следующим образом:
- Must have (Должно быть) — они имеют решающее значение и должны быть включены в продукт. Если даже одно требование/задача не взяты в релиз, то он считается проваленным. Можно опустить только при коллегиальном согласии интересантов.
- Should have (Надо бы иметь) — эти требования важны, но не имеют решающего значения для релиза. Они являются первым уровнем «Nice to have» (Хорошо бы иметь) и, как правило, разделяют важность требований «Must have», не будучи настолько чувствительными к времени.
- Could have (Могут быть) — эти требования желательны, но не нужны для релиза. Обычно это недорогие доработки продукта. Из-за их меньшей важности они являются вторым уровнем «Nice to have».
- Won’t have (Не будем делать) — они считаются наименее критичными или даже не соответствуют стратегии продукта. Они должны быть отброшены или пересмотрены для будущих релизов.
Этот метод предлагает быстрое и простое решение для определения приоритетов. Проблема связана с отсутствием классификации по категориям. Например, как мы можем узнать, какие требования Must have быть или Should have более важными, чем другие?
Пример метода MoSCoW
В качестве гипотетического примера возьмем человеческое тело:
Сердце «Must». Без него нет живого организма. Что обязательно в вашем приложении?
Рука «Should». Без нее тяжело. Но можно выжить даже без рук. Ну, в большинстве случаев.
Волосы «Could». Хорошо, когда они есть, но мой опыт подсказывает, можно и без.
«Wont have»? Возможно, это аппендикс?
Метод идеально подойдет для приоритизации ранних релизов и MVP продукта, но в последствии нужно применять более сложные и комплексные методы.
__
Соберем огоньки для Модели Кано?
👍 — Круть, спасибо!
👎 — Не интересно
🔥 — Гоу!
Мы поговорили на прошлой неделе о Story Map, а сегодня поговорим о методе MoSCoW — это акронимом из букв, стоящих за одной из возможных категорий приоритетов (с добавлением “Os”, чтобы сделать ее легко запоминающимся).
Требования классифицируются следующим образом:
- Must have (Должно быть) — они имеют решающее значение и должны быть включены в продукт. Если даже одно требование/задача не взяты в релиз, то он считается проваленным. Можно опустить только при коллегиальном согласии интересантов.
- Should have (Надо бы иметь) — эти требования важны, но не имеют решающего значения для релиза. Они являются первым уровнем «Nice to have» (Хорошо бы иметь) и, как правило, разделяют важность требований «Must have», не будучи настолько чувствительными к времени.
- Could have (Могут быть) — эти требования желательны, но не нужны для релиза. Обычно это недорогие доработки продукта. Из-за их меньшей важности они являются вторым уровнем «Nice to have».
- Won’t have (Не будем делать) — они считаются наименее критичными или даже не соответствуют стратегии продукта. Они должны быть отброшены или пересмотрены для будущих релизов.
Этот метод предлагает быстрое и простое решение для определения приоритетов. Проблема связана с отсутствием классификации по категориям. Например, как мы можем узнать, какие требования Must have быть или Should have более важными, чем другие?
Пример метода MoSCoW
В качестве гипотетического примера возьмем человеческое тело:
Сердце «Must». Без него нет живого организма. Что обязательно в вашем приложении?
Рука «Should». Без нее тяжело. Но можно выжить даже без рук. Ну, в большинстве случаев.
Волосы «Could». Хорошо, когда они есть, но мой опыт подсказывает, можно и без.
«Wont have»? Возможно, это аппендикс?
Метод идеально подойдет для приоритизации ранних релизов и MVP продукта, но в последствии нужно применять более сложные и комплексные методы.
__
Соберем огоньки для Модели Кано?
👍 — Круть, спасибо!
👎 — Не интересно
🔥 — Гоу!