Расстановка приоритетов: MoSCoW и Must, Should, Want

Мы решили максимально подробно осветить проблему постановки задач и выбора приоритетов. В этом материале расскажем о двух популярных на Западе подходах: MoSCoW (дословный перевод «Москва», но в реальности к Москве никакого отношения не имеет) и немного упрощённом варианте – Must, Should, Want.

Несмотря на то, что в основном обе методики применяются в отношении личной продуктивности, их вполне можно адаптировать к рабочим задачам, по аналогии с матрицей Эйзенхауэра.

Метод расстановки приоритетов MoSCoW

Аббревиатура MoSCoW образуется от первых букв каждой из четырех категорий приоритетов:

M — Must have (Должен иметь),

S — Should have (Следует иметь),

C — Could have (Могу иметь),

W — Won’t have (Не хочу/не буду иметь).

Буквы «o» в названии намеренно пишутся строчными, чтобы показать, что они не несут смысловой нагрузки. Однако в некоторых источниках метод иногда упоминается только в верхнем регистре: MOSCOW.

На русский язык слово можно перевести как «МОСКВА», но делать этого не стоит, поскольку это аббревиатура, и смысл после перевода теряется.

MoSCoW – это один из методов расстановки приоритетов, основанный на классификации требований в 4-х категориях: обязательные (Must have, здесь это фактически требования к минимально жизнеспособному продукту/проекту); важные, но не критичные (Should have); желательные (Could have) и те, которые точно не нужно внедрять(Won’t have).

Метод был разработан и описан Даем Клеггом в 1994 году в рамках книги о быстрой разработке приложений (подход RAD, Rapid Application Development). Позже такой подход широко использовался в паре с методом DSDM (Dynamic Systems Development Method, «Метод разработки динамических систем»).

Деление требований проекта на указанные категории позволяет параллельно проставлять приоритетность задач:

Must have – всё, что попадает сюда, должно реализовываться в первую очередь (получает наивысший приоритет). Такие задачи должны иметь свои блоки времени (подробнее о тайм-боксинге и тайм-блокинге). Время ограничивается намеренно, чтобы задачи были реализованы в выделенный интервал или итерацию. Иногда слово MUST используется в качестве аббревиатуры: Minimum Usable SubseT — «Минимально используемый набор». Получается своего рода аналог MVP (минимально жизнеспособного продукта).
Should have – это тоже важные задачи, но без их реализации проект вполне может работать. От таких задач можно отказаться, чтобы как минимум не нарушить сроки поставки или разработки. Работать над задачами с категорией «Should have» следует только тогда, когда у команды остаётся свободное время и ресурсы после реализации задач с признаком «Must have».
Could have – это больше пожелания, которыми можно заняться, если реализованы все обязательные и важные задачи. По факту, это уже полировка качества. Работы с признаком «Could have» не должны существенно повышать стоимость разработки проекта. Иными словами, их оценочная стоимость должна составлять небольшую долю от стоимости реализации задач из первых двух категорий. Подробнее об оценке задач.
Won’t have – это список требований, которые всеми заинтересованными сторонами считаются «пока ненужные» (не в этот раз/итерацию). То есть технически они есть и даже могут влиять на потенциальную архитектуру продукта или проекта. Возможно, когда-нибудь их приоритет повысится, но не в блоке времени, который отведён на разработку основного и даже вспомогательного функционала.

Нюансы методики MoSCoW

Если проект не может реализовать требования из категории «Must have», он считается провальным. Чтобы избежать такого варианта развития событий, команда должна пересмотреть или понизить приоритет некоторых требований. Но сделать это можно только по согласованию со всеми стейкхолдерами.
В любой момент времени приоритет задач с признаком «Should have» может повыситься до уровня «Must have», что может привести к перерасходу ресурсов (времени, бюджета и т.п.). Поэтому изменение приоритета для таких задач также должно происходить по согласованию со стейкхолдерами.
MoSCoW не дает рекомендаций, как осуществлять выбор задач, если у них одинаковый приоритет. Мы советуем воспользоваться методикой «Eat that frog» (то ест сначала «съесть» самую большую и мерзкую «лягушку»).
MoSCoW не предоставляет четких критериев для выбора того или иного требования. Это может сделать только команда по согласованию со стейкхолдерами. Поэтому, если у вас есть сомнения по поводу критичности или некритичности задач, проведите предварительное исследование (подробнее о ресёрчах и R&D).
Технически подход MoSCoW совместим со всеми гибкими методологиями управления и разработки.

Метод расстановки приоритетов Must, Should, Want (нужно, следует, хочу)

Must, Should, Want (MSW) – это упрощённый вариант методики MoSCoW, который использует только три уровня расстановки приоритетов: нужно (обязательно), следует (желательно, но не критично) и хочу (на уровне просто пожеланий).

Обычно метод «Must, Should, Want» применяется для расстановки личных приоритетов. Например, его можно использовать при планировании дел на день:

Must — задачи, которые нужно выполнить обязательно. Это могут быть дела, которые имеют фиксированное время или истекающий срок. Наиболее сложные и ёмкие задачи делаются в самом начале (по принципам «Eat that frog»), но могут быть и другие варианты: когда задача должна реализоваться в определённом промежутке времени (например, вы не можете забрать ребёнка из садика сразу после того, как его туда отвели, хотя задача является очень важной и срочной);
Should — задачи, которые следует выполнить, но это не критично. Это тоже важные дела, но они уступают по приоритету делам с признаком «Must» (их можно отложить или пожертвовать ими). Такие задачи можно планировать в промежутке между блоками времени Must-задач, а также в оставшееся свободное время (уже после того, как сделаны большие Must-задачи);
Want — задачи, которые хотелось бы сделать, но у них наименьший приоритет. Например, если вы их не сделаете здесь и сейчас, в определённое время, то ничего страшного не случится. Тем не менее, если будет достаточно свободного времени, то им вполне можно уделить внимание.

Но этот подход вполне подходит и для использования в проектах. Собственно, это и есть MoSCoW, только без критерия «Won’t have» («не нужно делать»).

Как использовать MoSCoW или Must, Should, Want в планировщиках задач

Обычно приоритизация (расстановка приоритетов) проводится на основе готового списка задач.

Значит, шаги будут выглядеть примерно так:

Вы создаёте общий список всех дел (вместо задач в работе над проектом могут быть требования). Это может быть простой плоский список To-Do или иерархическая структура, с детализацией (про декомпозицию задач) или без. Методика совместима с любым инструментом для постановки задач.
Когда список готов, следует оценить задачи – сколько времени и каких ресурсов они могут потребовать.
Теперь можно распределить задачи по категориям. Сами категории и принципы соотнесения мы описали выше. Критерии приоритетности определяются либо владельцем задачи (когда задача ставится самому себе или спускается подчинённому), либо обсуждается группой (на отдельном мероприятии).
Признак приоритета проставляется в задачах. Это может быть текстовый атрибут (буква, символ, слово и т.п.) или готовая система таксономии планировщика: стандартные или настраиваемые приоритеты, флажки, цветовые обозначения, иконки, теги, списки, категории и прочее. Главное, чтобы при просмотре задачи или списков было легко увидеть информацию о приоритетности. И ещё лучше, если задачи можно быстро отсортировать по признаку приоритета.
Если задача имеет чёткие временные рамки, ей выделяются блоки времени (о методике блокирования задач). В первую очередь проставляются блоки с признаками «Must», в свободные места ставятся задачи с признаком «Should», остальные (Want или Could) – по остаточному признаку.
Задачи «Won’t have» выносятся в список «Когда-нибудь» или просто остаются без времени и дат.
По мере реализации задач приоритеты и сроки корректируются, чтобы они оставались актуальными.

Заключительная часть

Принцип выбора приоритетов по методу MoSCoW или Must, Should, Want весьма интересный. Он действительно не противоречит и легко сочетается с любыми методиками управления, прост в понимании и имеет свою изюминку.

Однако из-за своей простоты у него есть и слабые стороны. В частности, он не предусматривает детальной категоризации задач, поэтому приоритеты определяются по личным (субъективным) критериям, можно даже сказать — по ощущениям.

Технически идея фокусировки внимания на более важных задачах не нова. Тут сколько людей, столько и мнений. Для кого-то формулировка «Нужно, следует, хочу» окажется простой и очевидной.

Мы, в свою очередь, готовы предоставить эффективный планировщик задач, предназначенный для использования в управлении проектами – это онлайн-сервис Projecto.