Метод особенно хорош в ситуациях, когда нужно быстро договориться о приоритетах внутри команды. С MoSCoW каждый участник понимает, почему одни задачи важнее других, чем в проекте можно пожертвовать, а чем нельзя. Впрочем, метод полезен не только в командной работе — его можно применять в личных проектах и даже в повседневном тайм-менеджменте.
В статье выясним, как устроен метод MoSCoW, покажем его работу на конкретных примерах и разберем некоторые тонкости, которые помогут использовать его более эффективно.
Что такое MoSCoW и как он работает
MoSCoW — это аббревиатура, где каждая буква обозначает категорию приоритета. Гласные «o» добавлены просто для благозвучия (чтобы получилось запоминающееся слово «MoSCoW» — Москва), смысловой нагрузки они не несут.
Must have (должно быть) — это критически важные задачи, без которых проект не имеет смысла. Если хотя бы одна такая задача не выполнена, продукт нельзя запустить. Например, для интернет-магазина это каталог товаров и возможность оплатить заказ. Без этого магазин просто не будет магазином.
Should have (следует сделать) — важные задачи, которые сильно влияют на качество продукта, но их отсутствие не критично. Продукт можно запустить и без них, но пользователи сразу почувствуют, что чего-то не хватает. Для того же интернет-магазина это может быть фильтр товаров по цене или размеру — без него неудобно, но покупки совершать всё-таки можно.
Could have (можно сделать) — приятные дополнения, которые улучшат продукт, но их отсутствие мало кто заметит. Это то, что делается, если осталось время и ресурсы. Например, возможность добавить товар в список желаний или посмотреть 3D-модель продукта.
Won’t have (не будет сделано) — задачи, от которых команда сознательно отказывается в текущей итерации (в рамках текущего этапа работы). Это не значит, что идея плохая: просто именно сейчас она не приоритетна. Например, интеграция с программой лояльности партнерской сети — хорошая фича, но для первого запуска она не нужна.
Метод приоритизации MoSCoW предложил в середине 1990-х разработчик Дай Клегг, работавший в Oracle. Изначально метод использовали в разработке ПО для приоритизации требований к продукту. Сегодня технику MoSCoW применяют в управлении проектами, маркетинге, event-менеджменте — везде, где нужно выбирать задачи при ограниченных ресурсах.
Метод хорош для задач в рамках одного проекта с общей целью, но не подходит для сравнения задач из разных проектов: там критерии важности могут сильно различаться. Также MoSCoW становится неудобным при работе с большим количеством задач (несколько десятков или сотен), поскольку их сортировка занимает слишком много времени.
Теперь посмотрим, как всё это работает на практике.
Примеры использования
Главное правило методики MoSCoW — сначала нужно четко сформулировать цель. Приоритеты всегда относительны: то, что критично для одной ситуации, может быть совершенно неважным для другой. Перед тем как раскладывать задачи по категориям, необходимо ответить на вопрос: чего именно мы хотим достичь сейчас?
Пример 1. Сборы в командировку
Начнем с самого простого примера. Предположим, вам нужно на три дня уехать в другой город на рабочую встречу. Цель — приехать вовремя, провести переговоры и вернуться домой. У вас ограниченное место в багаже и мало времени на сборы.
Вот вещи, которые вы теоретически можете взять с собой:
Давайте порассуждаем. Паспорт и билеты — это Must have, без них вы просто не попадете в самолет. Телефон, зарядка, ноутбук — тоже критичны для рабочей поездки. Смена белья и зубная щетка — Should have: технически можно купить на месте, но лучше взять с собой. Любимый шампунь или книга — Could have, приятные дополнения. А беговые кроссовки для трехдневной командировки — это, скорее всего, Won’t have, если только бег не часть вашей встречи.
Теперь рассортируем первоначальный список. Если вы выполняете приоритизацию в современном планировщике (например, в SingularityApp), то можете использовать для сортировки подпроекты, секции, теги или значки приоритета — как вам удобнее. Для наглядности воспользуемся секциями:
Анализ MoSCoW показывает, чем можно пожертвовать, если чемодан не закрывается. Сначала убираем кроссовки, потом книгу и подушку. А вот ноутбук точно должен остаться в чемодане.
Пример 2. Приложение для заметок
Небольшая команда разработчиков создает мобильное приложение для заметок. Цель первой версии — выпустить минимально рабочий продукт за два месяца, чтобы протестировать идею на реальных пользователях и получить обратную связь.
Команда может рассуждать так: без создания, редактирования и удаления заметок приложение бессмысленно — это Must have. Папки и теги тоже очень важны — без них все заметки превращаются в кашу, и пользоваться приложением неудобно, поэтому это Should have. Темная тема и синхронизация улучшат опыт, но для первой версии не критичны — Could have. Голосовой ввод, шифрование и шаринг — интересные фичи, но для MVP (минимально жизнеспособного продукта) избыточны — Won’t have в первой версии.
Такая приоритизация позволит команде сфокусироваться на главном и выпустить продукт в срок, не распыляясь на второстепенные функции. После запуска можно собрать отзывы пользователей и решить, какие функции из категорий Could добавить в следующих обновлениях. Возможно, окажется, что пользователи очень просят синхронизацию — тогда она переедет в приоритет для второй версии.
Пример 3. Интернет-магазин одежды
Компания запускает новый интернет-магазин одежды. Цель — открыться к началу сезона распродаж через три месяца. Бюджет ограничен, команда небольшая. Приоритизация бэклога по методу MoSCoW поможет понять, какие функции нужно реализовать в первую очередь.
Без каталога, корзины и оформления заказа магазин не может работать — это Must have. Фильтры и регистрация очень желательны, но технически можно запуститься и без них — Should have. Отзывы и система промокодов улучшат конверсию, но не обязательны для старта — Could have. Виртуальная примерочная и сложная программа лояльности — слишком затратные фичи для первого запуска — Won’t have.
Такой подход позволяет команде уложиться в сроки и бюджет, запустить магазин вовремя и начать зарабатывать. А дополнительные функции можно добавить постепенно, на основе реальной статистики и запросов клиентов. Например, если многие уходят из-за отсутствия фильтров, их делают в первую очередь.
Во всех трех примерах техника MoSCoW работает одинаково: помогает отделить критически важное от желательного и второстепенного. Главное — честно ответить себе на вопрос: без чего цель действительно недостижима, а что можно добавить потом?
Тонкости и нюансы
Напоследок — несколько рекомендаций, которые помогут использовать метод MoSCoW эффективнее и избежать типичных ошибок.
1. Приоритеты привязаны к итерации
Каждый раз расставляйте приоритеты заново, не копируйте слепо из прошлого спринта. Контекст меняется: то, что было Could have в прошлом месяце, может стать Must have сейчас. Например, интеграция с платежной системой была не критична для тестовой версии приложения, но перед публичным запуском она становится обязательной.
2. Must have имеет свойство раздуваться
Если в категории Must have оказалось больше половины всех задач — приоритизация не работает. Применяйте строгий критерий: задача попадает в Must have только в том случае, если без нее продукт или результат теряет смысл либо вообще не работает. «Очень хочется» и даже «важно для бизнеса» — это еще не Must have.
3. Граница между Should и Could
Проверочный вопрос: «Что случится, если мы это не сделаем в этой итерации?» Если последствия переноса заметны для пользователей или бизнеса — это Should have. Если перенос безболезнен, и никто особо не расстроится — Could have. Например, отсутствие поиска по сайту пользователи точно заметят (Should), а отсутствие возможности поделиться товаром в соцсетях — вряд ли (Could).
4. Won’t have — не мусорка
Категория Won’t have — это не место для плохих идей, а осознанный отказ делать что-то прямо сейчас. Сохраняйте эти задачи в бэклоге и проводите ревизию перед каждой итерацией: возможно, условия изменились, и задача стала актуальной. Например, виртуальная примерочная могла быть слишком дорогой полгода назад, но сейчас появились доступные готовые решения.
5. Фиксируйте аргументы
Записывайте, почему задача попала в ту или иную категорию. Это избавит команду от повторяющихся споров и поможет при пересмотре приоритетов. Через месяц вы можете забыть, почему отложили определенную функцию, а краткая заметка быстро освежит контекст.
| Задача | Категория | Аргумент |
|---|---|---|
| Оплата картой | M | Без нее невозможно завершить покупку |
| Фильтр по цене | S | Пользователи ожидают эту функцию, но можно запуститься без нее |
| Отзывы | C | Повысит доверие, но не критично для старта |
| Программа лояльности | W | Сложная в реализации, отложим на вторую версию |
| AR-примерочная | W | Требует 3 месяца разработки, не укладываемся в сроки запуска |
6. Делите крупные задачи
Большая задача может содержать и Must have, и Could have внутри. Выполняйте декомпозицию таких задач и распределяйте части по категориям.
Например, «Личный кабинет пользователя» — слишком крупная задача. Разбейте ее на «Просмотр истории заказов» (Should have), «Редактирование профиля» (Could have), «Управление подписками на рассылки» (Won’t have). Задачи должны соответствовать размеру итерации — так проще планировать и контролировать прогресс.
7. Метод работает только при четкой цели итерации
Без понимания, что именно вы хотите получить на выходе, расстановка приоритетов в MoSCoW превращается в угадайку. Сформулируйте цель конкретно: не «улучшить сайт», а «запустить интернет-магазин к началу сезона распродаж» или «выпустить MVP приложения для тестирования гипотезы». Четкая цель — компас для всех решений о приоритетах.
