Метод MoSCoW - это техника приоритезации, используемая во многих сферах управления для достижения консенсуса по части того, что наиболее важно стейкхолдерам и потребителям.
Этот термин - акроним, в котором каждая согласная буква обозначает одну из возможных категорий приоритетов (с буквами O, добавленными для лучшего запоминания). Таким образом, приоритеты классифицируются как:
-
Must have (обязательно) - все, что под этой категорией, является критичным, и должно быть включено в продукт. Если что-то из нее не включено, то релиз провален. Впрочем, этот приоритет может быть понижен, если на это есть согласие стейкхолдеров.
-
Should have (должно быть) - это требования важные, но не критичные для релиза. Это первый уровень “хотелок”, и как правило, по уровню важности они соответствуют Must-требованиям, но не настолько чувствительны ко времени.
-
Could have (хорошо бы и было) - это требования желательные, но необязательные для релиза. Как правило, это недорогие улучшения продукта. Несмотря на свою низкую важность, это второй уровень “хотелок”.
-
Won’t have (не надо) - это функциональные возможности, которые наименее критичны, либо вообще не соответствуют стратегии продукта. Их нужно отставить в сторону, либо иметь ввиду для последующих релизов продукта.
Данный метод предлагает быстрое и простое решение по приоритезации. Но могут быть проблемы, связанные с недостаточно четкими границами между категориями. Например, откуда мы знаем, какие из Should или Could требований важнее прочих? Из-за этого ограничения, метод MoSCoW скорее всего неплохо подойдет к внутренним проектам, но не к продуктам со многими покупателями - поскольку обсуждать приоритеты с несколькими стейкхолдерами всегда проще, чем ввести полномасштабную работу со всеми конечными пользователями.
Экскурс по 20 техникам приоритезации продукта
