Метод MoSCoW: как сортировать задачи и расставлять приоритеты

Задач становится больше, времени — нет. Все кажется одинаково важным, поэтому в работу часто уходят самые срочные дела, а не те, которые действительно приближают к цели. Если над проектом работает несколько человек, к этому добавляются еще и споры о том, что делать первым.

Метод MoSCoW — это простой и эффективный способ расстановки приоритетов. Он делит задачи на четыре категории по степени важности. В этой статье мы объясним, как этот метод работает, как его использовать в проектах, командной работе и личных задачах, а также расскажем о распространенных ошибках при приоритизации.

Что такое метод MoSCoW простыми словами

MoSCoW — это метод, который помогает распределить задачи, требования или идеи по четырем категориям с учетом их значения для конкретной цели, проекта или этапа работы. Такая MoSCoW-приоритизация показывает, без чего нельзя обойтись, что желательно выполнить и что можно пока не включать в план.

Название методики MoSCoW образовано от четырех категорий: M — Must have, S — Should have, C — Could have, W — Won’t have. Две буквы «o» добавлены только для удобства произношения и отдельного значения не имеют.

При этом задача не бывает Must или Could сама по себе — ее приоритет всегда зависит от контекста. Например, мобильная версия сайта может быть обязательной для запуска сервиса, рассчитанного на пользователей смартфонов, но лишь желательной для внутреннего корпоративного портала.

Метод разработал Дай Клегг в 1994 году во время работы в Oracle для приоритизации требований в проектах с ограниченными сроками. Позднее подход вошел в практику DSDM и стал применяться не только в разработке, но и в управлении проектами и задачами.

Зачем использовать MoSCoW для приоритизации задач

MoSCoW помогает сделать приоритизацию задач понятной и реалистичной. Вместо попытки выполнить все сразу команда определяет, без чего нельзя достичь цели, что можно перенести без критичных последствий и на что стоит тратить ресурсы только при наличии времени. Такой подход помогает сосредоточиться на действительно важном, а не на том, что кажется срочным.

MoSCoW отвечает не на вопрос «Какая задача вообще важнее?», а на вопрос «Что важнее для этой цели и этого этапа?»

Например, перед запуском сайта команда выбирает между исправлением ошибки в оплате и новым оформлением профиля. Если без оплаты продукт не сможет работать, эта задача становится приоритетной, а визуальные улучшения можно перенести на следующий этап.

Важно понимать, что MoSCoW не принимает решения за команду. Метод лишь создает понятную рамку для обсуждения: итоговый выбор зависит от цели, сроков, доступных ресурсов и аргументов участников.

Как работают категории Must, Should, Could и Won’t

Все задачи в методе MoSCoW распределяются по четырем категориям в зависимости от того, насколько они важны для достижения текущей цели. Сначала сравните их между собой в таблице, а затем разберем каждую категорию подробнее.

Категория	Что означает	Главный вопрос	Что делать с задачей
Must have	Без нее нельзя достичь цели или завершить текущий этап	Можно ли достичь цели без этой задачи?	Выполнить в первую очередь
Should have	Важна для качества результата, но не блокирует его	Можно ли временно перенести ее без критичных последствий?	Запланировать после Must
Could have	Полезна, если после основных задач остаются ресурсы	Что мы потеряем, если не успеем ее выполнить?	Сделать при наличии свободных ресурсов
Won’t have	Осознанно исключена из текущего этапа	Готовы ли мы сейчас отказаться от этой задачи?	Зафиксировать и пересмотреть позже

Must have: что обязательно сделать

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

Задачу стоит отнести к Must, если:

• без нее нельзя выпустить продукт или завершить текущий этап;
• ее отсутствие блокирует другие критичные задачи;
• приемлемого обходного решения нет;
• перенос создает недопустимые риски;
• она связана с безопасностью, законом, договором или обязательством перед клиентом.

Например, к Must можно отнести исправление ошибки, из-за которой пользователь не может оплатить заказ, настройку отправки формы перед запуском сайта или подготовку обязательных документов к установленной дате. В личных делах такой задачей может быть назначенное медицинское обследование, которое нельзя перенести без риска для здоровья.

Must или просто важно?

• «Без этого запуск невозможен» — Must.
• «С этим запуск будет заметно лучше» — вероятнее всего, Should.

Не стоит записывать в Must все значимые задачи. Если обязательным становится почти весь список, категории перестают помогать в приоритизации: команда снова пытается сделать все одновременно и не видит, что действительно нельзя отложить.

Should have: что важно, но не блокирует результат

К категории Should have относятся важные задачи, которые заметно влияют на качество, удобство или эффективность результата, но не определяют, состоится ли он вообще. Проект может временно двигаться без них, хотя итог окажется слабее.

Главный проверочный вопрос: что произойдет, если перенести эту задачу на следующий этап? Если перенос создаст неудобства или снизит показатели, но не сделает цель недостижимой, задача, скорее всего, относится к Should.

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

Граница между Must и Should проходит по влиянию на результат. Must отвечает за его жизнеспособность, Should — за качество и эффективность. Поэтому Should-задачи планируют сразу после обязательных, но не выполняют за их счет.

Could have: что можно сделать при наличии ресурсов

К категории Could have относятся полезные улучшения, идеи и дополнительные возможности, которые повышают ценность результата, но не влияют на достижение основной цели. Отказ от них не создает заметных рисков и не мешает завершить текущий этап.

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

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

Could = полезно, но не за счет Must и Should.

Won’t have: что не делаем в этой итерации

К категории Won’t have относятся задачи, которые команда осознанно исключила из текущего периода, релиза, спринта или проекта. Это не забытые дела, а зафиксированное решение: сейчас на них не тратят время и ресурсы.

Категория Won’t помогает:

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

Например, команда может решить не запускать дополнительную языковую версию сайта в первой итерации и не добавлять новый канал продвижения до оценки текущих результатов. В личном планировании к Won’t можно отнести ремонт, отложенный до следующего месяца, или новый клиентский проект, который лучше не брать до завершения текущих обязательств.

Важно понимать, что Won’t — не мусорная корзина и не означает «никогда». Чаще всего это означает «не в этом релизе», «не на этой неделе» или «не в рамках текущего бюджета». Главное — сохранить задачу и причину такого решения, чтобы вернуться к ней позже.

Won’t now → сохранить аргумент → пересмотреть перед следующей итерацией.

Как понять, в какую категорию попадает задача

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

Проверочные вопросы помогают определить важность задачи и отличить обязательное условие результата от полезного улучшения.

Вопрос	Что помогает определить
Какова цель текущего этапа?	Контекст приоритизации
Что произойдет, если не выполнить задачу?	Критичность
Можно ли достичь цели без нее?	Must или не Must
Существует ли временное обходное решение?	Must или Should
Влияет ли задача на деньги, сроки, безопасность или обязательства?	Уровень риска
Заблокирует ли ее отсутствие другие задачи?	Зависимости
Заметит ли пользователь или клиент перенос?	Should или Could
Есть ли сейчас ресурсы на выполнение?	Could или Won’t
Не является ли задача просто привлекательной идеей?	Could
Готовы ли мы прямо зафиксировать, что сейчас ее не делаем?	Won’t

Ответы лучше не оставлять только в обсуждении. Вместе с категорией стоит записать короткое обоснование: «Must, потому что без этой интеграции клиент не сможет завершить оплату». Так участники понимают логику решения и не возвращаются к одному спору при каждом изменении плана.

Еще один важный критерий приоритизации — размер задачи. Слишком крупную формулировку сложно правильно отнести к одной категории, потому что внутри нее могут скрываться элементы разной важности.

Например, задача «Запустить сайт» слишком общая. Если разбить ее на части, рабочая форма обратной связи может оказаться Must, улучшение дизайна — Should, а дополнительная анимация — Could.

Поэтому перед тем как приоритизировать задачи, крупные пункты стоит разложить на конкретные действия.

Как применять метод MoSCoW: пошаговый алгоритм

Чтобы правильно расставлять приоритеты, недостаточно просто разнести задачи по четырем категориям. Сначала нужно задать контекст, собрать ограничения и договориться о критериях. Тогда приоритизация задач в проекте будет опираться не на личные предпочтения, а на понятную логику.

Шаг 1. Определите цель

Сформулируйте конкретный результат, к которому хотите прийти. Например:

• выпустить MVP;
• запустить сайт;
• подготовить рекламную кампанию;
• завершить клиентский проект;
• спланировать рабочую неделю.

Без четкой цели категории становятся субъективными. Нельзя определить приоритет задачи «вообще» — только относительно выбранного результата.

Например, подготовка страницы оплаты может быть Must перед запуском интернет-магазина, но Could на этапе внутреннего тестирования продукта.

Шаг 2. Ограничьте период или итерацию

Определите, для какого отрезка времени вы сортируете задачи:

• рабочий день;
• неделю;
• спринт;
• релиз;
• этап проекта;
• маркетинговый запуск.

Одна и та же задача может быть Won’t в текущем спринте и Must в следующем. Поэтому приоритет всегда привязан не только к цели, но и к конкретному периоду.

Шаг 3. Соберите задачи в один список

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

Сначала полезно увидеть весь объем работы. Иначе часть задач останется за пределами обсуждения, а приоритеты придется менять уже после начала работы.

Шаг 4. Определите ограничения

Перед тем как сортировать задачи, зафиксируйте условия, в которых предстоит работать:

• срок;
• бюджет;
• количество исполнителей;
• доступное время;
• обязательства перед клиентами;
• технические зависимости;
• возможные риски.

Ограничения помогают понять, что команда действительно успеет выполнить, а что придется перенести. Без них даже логичная приоритизация быстро превращается в перегруженный план.

Шаг 5. Согласуйте критерии

До распределения задач команда должна договориться, что именно считается критичным. В одном проекте главным критерием будет возможность запустить продукт, в другом — соблюдение договора или безопасность данных.

К критериям могут относиться:

• влияние на оплату;
• обязательства перед клиентом;
• безопасность;
• зависимость других задач;
• влияние на ключевую метрику;
• возможность завершить этап в срок.

Так спор о приоритетах превращается из обмена мнениями в обсуждение конкретных последствий.

Шаг 6. Распределите задачи по категориям

Теперь разберите список по Must, Should, Could и Won’t. Очевидные случаи не требуют долгого обсуждения — больше времени стоит уделить задачам, по которым у участников разные аргументы.

Чтобы сортировать задачи быстрее, задавайте последовательные вопросы:

• без этого цель недостижима?
• перенос заметно ухудшит результат?
• это полезное улучшение при наличии ресурсов?
• готовы ли мы отказаться от задачи на текущем этапе?

Шаг 7. Еще раз проверьте Must

После первого распределения отдельно пересмотрите обязательные задачи. По каждой спросите:

Действительно ли без нее невозможно достичь цели текущего этапа?

Если задача просто важна, удобна или заметно улучшает результат, ей, скорее всего, место в Should или Could. Когда Must занимает почти весь план, метод перестает помогать расставлять приоритеты.

Жесткого универсального процента здесь нет: состав категорий зависит от проекта, сроков и рисков. Главное, чтобы список Must оставался действительно обязательным, а не превращался в перечень всех пожеланий команды.

Шаг 8. Зафиксируйте аргументы и ответственных

Для каждой задачи запишите:

• категорию;
• причину выбора;
• ответственного;
• срок;
• зависимости;
• принятое решение.

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

Шаг 9. Пересматривайте приоритеты

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

Например, дополнительная аналитика сначала может быть Could, но после первых жалоб пользователей перейти в Should. А задача, которую команда откладывала несколько итераций, может стать Must перед важным релизом.

Регулярный пересмотр помогает не только расставлять приоритеты, но и сохранять актуальность плана по мере развития проекта.

Примеры сортировки задач по MoSCoW

Один и тот же список нельзя приоритизировать без контекста. Ниже — четыре примера, которые показывают, как сортировать задачи по MoSCoW в проектах, продуктовой разработке, маркетинге и личном планировании.

Пример 1. Запуск сайта

Компания готовит новый сайт к фиксированной дате. Команда ограничена по времени, поэтому реализовать все идеи до запуска не получится.

Задача	Категория	Почему	Что делать дальше
Проверить отправку форм	Must	Без этого заявки не попадут менеджерам	Исправить до запуска
Настроить мобильную версию основных страниц	Must	Значимая часть пользователей зайдет со смартфонов	Проверить до публикации
Подготовить базовые метатеги	Should или Must	Важно для поиска, но не всегда блокирует технический запуск	Оценить цель страницы
Добавить дополнительные кейсы	Should	Повышают убедительность, но сайт может работать без них	Добавить после критичных блоков
Сделать сложную анимацию	Could	Улучшает впечатление, но не влияет на основную функцию	Выполнить при наличии времени
Перевести сайт на второй язык	Won’t	Не входит в текущий запуск	Вернуться на следующем этапе

Категорию нельзя назначить только по названию задачи. Например, базовые SEO-настройки могут быть Must для посадочной страницы, которая должна получать поисковый трафик сразу после публикации. Для внутренней тестовой страницы они, скорее всего, останутся Should.

Пример 2. MVP приложения

Продуктовая команда готовит первую рабочую версию приложения. Ее цель — проверить основную гипотезу и дать пользователям возможность пройти ключевой сценарий.

В этом случае функции можно распределить так:

• регистрация и вход — Must;
• создание основной сущности продукта — Must;
• восстановление пароля — Should или Must в зависимости от условий запуска;
• дополнительные варианты оформления — Could;
• расширенная статистика — Won’t для первой версии.

Крупные функции лучше не относить к одной категории целиком. Например, раздел «Уведомления» может включать обязательное сообщение о критическом событии и выбор звука. Первое окажется Must, второе — Could.

Поэтому перед приоритизацией большие функции стоит разбивать на отдельные пользовательские сценарии. Так команда точнее определит, что действительно нужно для MVP, а что можно добавить после проверки основной версии.

Короткий пример: маркетинговая кампания

Команда запускает рекламную кампанию с ограниченным бюджетом и сроком:

• настроить отправку заявок — Must;
• подготовить основную посадочную страницу — Must;
• создать дополнительный вариант объявления — Should;
• протестировать новый формат креатива — Could;
• подключить еще одну площадку — Won’t в текущей кампании.

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

Короткий пример: личная неделя

Метод MoSCoW подходит не только для проектов. Например, задачи на неделю можно распределить так:

• оплатить счет до крайнего срока — Must;
• подготовиться к важной встрече — Must или Should в зависимости от последствий;
• записаться к врачу — Should;
• разобрать фотографии — Could;
• начать новый необязательный курс — Won’t на этой неделе.

При этом нельзя автоматически относить все задачи, связанные со здоровьем, к одной категории. Срочность зависит от самочувствия, возможных рисков и рекомендаций врача: плановая запись может быть Should, а назначенное обследование с ограниченным сроком — Must.

Где можно применять метод MoSCoW

Метод MoSCoW применяют везде, где задач больше, чем времени и ресурсов: в проектах, командной работе, маркетинге, клиентских задачах и личном планировании.

В проектах и продуктовой разработке

MoSCoW помогает работать с бэклогом, планировать MVP, релизы, спринты и отдельные этапы проекта. Метод особенно полезен, когда требований больше, чем команда успеет выполнить за отведенный период.

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

В командной работе

Команда сначала согласует цель и критерии, затем обсуждает спорные задачи, фиксирует решение, аргументы, ответственных и сроки.

MoSCoW не должен превращаться в директивное распределение сверху или обычное голосование. Категория определяется последствиями для проекта, а не количеством сторонников.

В маркетинге и контенте

Метод помогает расставлять приоритеты в рекламных кампаниях, контент-плане, публикациях, гипотезах и подготовке запусков. Категория определяется влиянием задачи на дату запуска, бюджет, лиды, обязательства перед партнерами и возможностью переноса без ущерба.

Например, настроить отправку заявок — Must, подготовить дополнительный вариант объявления — Should, протестировать новый формат креатива — Could, а подключение новой площадки можно перенести в Won’t.

В клиентских проектах и работе фрилансера

MoSCoW помогает разделить обязательства по договору, критичные правки, полезные улучшения и дополнительные пожелания клиента.

Особенно полезна категория Won’t. Она позволяет сразу зафиксировать задачи, которые не входят в текущий объем работ, и избежать бесконтрольного расширения проекта.

Например, исправление критичной ошибки перед сдачей проекта может быть Must, дополнительный вариант дизайна — Should, а новая функция, которой нет в договоре, — Won’t до согласования сроков и бюджета.

В личных задачах

В личном планировании Must — это обязательства и дела с критичными сроками, Should — важные действия, Could — полезные задачи при наличии времени, Won’t — то, что человек сознательно откладывает на другой период.

При этом давно отложенная бытовая задача не становится Must автоматически. Ее приоритет зависит от цели, срока и последствий переноса.

Ошибки при использовании метода MoSCoW

Метод MoSCoW перестает работать, когда категории назначают формально или используют для подтверждения уже принятых решений. Ниже — основные ошибки, из-за которых приоритизация задач становится субъективной и быстро теряет актуальность.

Ошибка	Почему мешает	Как исправить
Все задачи становятся Must	Участники считают обязательным каждое значимое требование и боятся отказаться от своих предложений. В результате список приоритетов почти не отличается от исходного.	По каждой задаче спрашивать: «Станет ли цель недостижимой, если ее не выполнить?» Если нет — рассмотреть Should или Could.
Нет конкретной цели	Команда пытается приоритизировать общий бессрочный список, поэтому одна и та же задача оценивается в разных контекстах.	Сначала определить результат и период: релиз, спринт, рабочую неделю или этап проекта.
Решения принимаются по эмоциям	Более высокий приоритет получает задача, которую громче защищают или которую предложил руководитель.	Заранее согласовать критерии: влияние на цель, сроки, деньги, обязательства, риски и зависимости.
Задачи сформулированы слишком крупно	Целое направление сложно отнести к одной категории, потому что внутри него есть элементы разной критичности.	Разбить крупную задачу на отдельные действия. Например, в блоке «Уведомления» критичное сообщение может быть Must, а выбор звука — Could.
Won’t превращается в мусорную корзину	Задачи откладывают без объяснения и больше к ним не возвращаются, поэтому полезные идеи теряются.	Записывать причину отказа и указывать, перед каким этапом или в какую дату задачу нужно пересмотреть.
Приоритеты считают постоянными	Команда продолжает работать по старому списку после изменения цели, срока, бюджета или уровня риска.	Пересматривать категории перед новой итерацией и при существенном изменении условий.

Например, если почти весь план оказался в Must, проблема обычно не в количестве критичных задач, а в слишком широкой цели или нежелании выбирать. Стоит еще раз проверить обязательные пункты и перенести задачи, которые лишь улучшают результат, в Should или Could.

Когда метод MoSCoW не подходит

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

Метод также не решает ситуации, когда у команды нет общей цели или конфликт между стейкхолдерами нельзя устранить простым обсуждением категорий.

MoSCoW не заменяет:

• продуктовую аналитику;
• оценку трудозатрат;
• управление рисками;
• финансовые расчеты;
• решение руководителя;
• переговоры со стейкхолдерами.

Например, если команда выбирает функции для большого продукта, MoSCoW поможет быстро отсеять второстепенные задачи. После этого оставшиеся функции стоит дополнительно оценить по ценности, сложности реализации и рискам.

MoSCoW подходит, когда есть конкретная цель, ограниченный период и понятный список задач.

MoSCoW недостаточно, когда требуется точное ранжирование по множеству числовых критериев.

Поэтому метод лучше использовать как первый фильтр, а затем дополнять его другими способами оценки.

MoSCoW, матрица Эйзенхауэра, RICE и ICE: что выбрать

Методы приоритизации решают разные задачи. MoSCoW помогает согласовать состав этапа, матрица Эйзенхауэра — организовать текущие дела, а RICE, ICE и Value/Effort — сравнить инициативы по заданным критериям.

Метод	Для чего подходит	Как оценивает задачи	Ограничение
MoSCoW	Проекты, релизы, командное согласование	Распределяет задачи по четырем качественным категориям	Не дает точного рейтинга внутри одной категории
Матрица Эйзенхауэра	Личные и операционные задачи	Сравнивает важность и срочность	Не учитывает продуктовую ценность и доступные ресурсы
RICE	Продуктовые гипотезы и функции	Учитывает охват, влияние, уверенность и трудозатраты	Требует данных и расчетов
ICE	Быстрая оценка гипотез	Сравнивает влияние, уверенность и простоту реализации	Оценки могут быть субъективными
Value/Effort	Выбор задач по ценности и сложности	Сопоставляет пользу и затраты	Может не учитывать обязательства, зависимости и риски

Выбор зависит от того, какой результат нужен:

• MoSCoW — быстро договориться, что войдет в текущий этап;
• матрица Эйзенхауэра — распределить личные дела по важности и срочности;
• RICE и ICE — сравнить продуктовые инициативы и гипотезы;
• Value/Effort — сопоставить ожидаемую пользу и затраты.

Методы можно сочетать. Например, сначала с помощью MoSCoW исключить задачи, которые не войдут в релиз, а затем оценить оставшиеся инициативы по RICE или Value/Effort.

Как организовать приоритеты по MoSCoW в LeaderTask

Метод MoSCoW можно использовать на бумаге, в таблице или любом планировщике. LeaderTask не определяет приоритет автоматически, но помогает зафиксировать выбранные категории и работать с ними каждый день.

Создайте проект

Создайте отдельный проект под конкретную цель: «Запуск сайта», «Релиз приложения», «Маркетинговая кампания» или «План на неделю». Соберите внутри все связанные задачи, а крупные — разбейте на подзадачи.

Добавьте метки Must, Should, Could и Won’t

Создайте четыре метки и назначьте их задачам. Так категории будут сразу видны, а список можно быстро отфильтровать.

Не усложняйте систему лишними обозначениями. При необходимости сохраните в описании короткое обоснование, например: «Must: без формы заявки запуск не достигнет основной цели».

Выделите Must-задачи

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

Назначьте ответственных и сроки

После определения приоритета укажите исполнителя, срок и при необходимости добавьте подзадачи, файлы и комментарии. Так команда понимает не только важность задачи, но и кто отвечает за ее выполнение.

Используйте канбан-доску

После того как задачи распределены по категориям MoSCoW, перенесите их на канбан-доску для контроля выполнения. Здесь уже важно не то, к какой категории относится задача, а на каком этапе работы она находится.

Для этого удобно использовать колонки «Запланировано», «В работе», «На проверке» и «Готово». Если потребуется уточнить приоритет конкретной задачи, его всегда можно посмотреть в карточке.

Пересматривайте приоритеты

Перед новым этапом откройте задачи проекта, отфильтруйте их по меткам, проверьте сроки и при необходимости измените категории. Так система приоритетов остается актуальной даже при изменении условий.

FAQ о методе MoSCoW

Что такое метод MoSCoW?

MoSCoW — метод приоритизации задач, при котором список дел делят на четыре категории: Must have, Should have, Could have и Won’t have. Такая сортировка помогает определить, что обязательно выполнить в текущем периоде, что желательно сделать, а что можно перенести.

Чем Must отличается от Should?

Must — задача, без которой не получится достичь цели или завершить выбранный этап. Should заметно влияет на результат, но ее временный перенос не блокирует работу. Например, для запуска сайта исправная форма заявки может быть Must, а дополнительная страница с ответами на вопросы — Should.

Может ли задача менять категорию MoSCoW?

Да. Приоритет зависит от цели, срока и текущих условий, поэтому одна и та же задача может относиться к разным категориям на разных этапах. Например, онлайн-чат может быть Won’t при первом запуске сайта, но стать Should после роста количества обращений. Поэтому категории стоит пересматривать перед новой итерацией.

Как часто нужно пересматривать приоритеты?

Категории проверяют перед началом нового этапа, релиза, спринта или рабочей недели, а также при изменении срока, бюджета, ресурсов или рисков. Ежедневно пересматривать весь список обычно не требуется. В LeaderTask для такого обзора можно открыть задачи проекта, отфильтровать их по меткам, проверить сроки и обновить категории там, где изменились условия.

Как начать использовать MoSCoW в задачах

Начните с небольшого проекта или списка задач на неделю. Этого достаточно, чтобы понять, как работает метод на практике.

Дальше действуйте по шагам:

1. Определите цель.
2. Выберите период.
3. Соберите все задачи в одном месте.
4. Распределите их по категориям Must, Should, Could и Won’t.
5. Проверьте, не оказалось ли слишком много Must.
6. Зафиксируйте сроки, ответственных и причины выбранных приоритетов.
7. Выполните обязательные задачи.
8. Перед следующим этапом обновите приоритеты.

Попробуйте применить MoSCoW к своему текущему проекту в LeaderTask: создайте проект, добавьте метки Must, Should, Could и Won’t, выделите обязательные задачи в фокус и начните работу с них. Когда этап завершится, пересмотрите категории и сформируйте новый план.