Как приоритизировать функции проекта: метод MoSCoW и другие способы уложиться в бюджет

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

Зачем приоритизировать функции до старта?

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

Что даёт приоритизация на практике:

• Понятную цену первой версии. Разработчик оценивает обязательное отдельно от желательного, и вы видите, сколько стоит каждая группа.
• Запас на неожиданности. Если интеграция с учётной системой окажется сложнее, чем казалось, есть что отложить без ущерба для запуска.
• Ранний запуск. Пользователи получают сервис раньше, а вы — данные о том, чем они пользуются на самом деле.
• Меньше споров на приёмке. Когда в ТЗ записано, что не входит в этап, никто не ждёт этого от готовой сборки.

Приоритизация не заменяет описание требований. Сначала нужен сам список функций — хотя бы в виде коротких историй пользователей, как в статье «User story и сценарии». Потом этот список сортируют.

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

MoSCoW — техника приоритизации, на которой строится планирование во фреймворке DSDM; его развивает Agile Business Consortium. Название — первые буквы английских категорий: Must have, Should have, Could have, Won't have this time. Строчные «o» вставлены, чтобы сокращение читалось как слово.

Определения категорий в описании метода у Agile Business Consortium сводятся к простым вопросам:

• Must have — минимальный работающий набор. Если хотя бы одного пункта нет, продукт не выпускают в намеченную дату.
• Should have — важное, но не жизненно необходимое. Без него неудобно, но есть временный обходной путь: сделать вручную, написать письмо, позвонить.
• Could have — желательное. Его отсутствие мало на что влияет, поэтому эти функции убирают первыми, когда срок или бюджет под угрозой.
• Won't have this time — то, что договорились не делать в текущем этапе. Ключевое слово — «this time»: функцию не выбрасывают, а записывают, чтобы она не вернулась в работу тихо, без пересчёта сроков.

У метода есть одно правило, которое часто пропускают. DSDM советует, чтобы обязательные функции занимали не больше 60 % трудоёмкости этапа, а около 20 % приходилось на желательные. Эти 20 % — подушка: если что-то пошло не так, их снимают, а обязательное и важное остаются. Если же 90 % объёма помечено как Must, запаса нет, и любая задержка бьёт по сроку запуска.

Считать долю нужно по трудоёмкости, а не по количеству строк. Десять мелких Could-функций могут весить меньше, чем одна обязательная интеграция.

Категория	Что значит	Проверочный вопрос
Must have — обязательно	Минимальный набор, без которого запуск не имеет смысла	Если функции не будет, выпускаем ли мы продукт в срок? Если нет — это Must
Should have — важно	Важное, но не жизненно: без него больно, но есть обходной путь	Можно ли первое время сделать это вручную, письмом или звонком?
Could have — желательно	Удобства, которые убирают первыми, если срок или бюджет под угрозой	Заметит ли пользователь отсутствие в первый месяц?
Won't have — не в этот раз	Договорились не делать в текущем этапе, но записали	Вернёмся ли к этому после запуска и по какому сигналу?

Как применить его к реальному списку функций?

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

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

Что видно из разбора:

• Обязательное собрано вокруг одной цели. Вход, роли, заказы со статусами, документы и выгрузка из учётной системы — ровно то, что нужно, чтобы клиент перестал звонить.
• Оплата ушла в Should. Для розничного сервиса она была бы обязательной, а оптовики привыкли платить по счёту. Решение зависит от вашего бизнеса, а не от метода.
• Аналитика закупок — Could, хотя звучит солидно. Никто из клиентов о ней не просил; это гипотеза, и проверять её разумнее на работающем кабинете.
• Мобильное приложение — Won't. Веб-кабинет и так открывается на телефоне, а приложение — отдельная разработка со своим бюджетом.

Обратите внимание: в Must попало пять функций из двенадцати, но по трудоёмкости это больше половины — одна выгрузка из учётной системы весит как несколько удобств. Так и должно быть. Проверку по правилу 60 % делают после того, как разработчик оценил каждую строку.

Функция	Категория	Почему так
Вход по почте и паролю, восстановление доступа	Must	Без входа нет кабинета
Роли «клиент» и «менеджер»	Must	Менеджер меняет статусы, клиент только смотрит свои заказы
Список заказов клиента со статусами	Must	Ради этого кабинет и заказывают: меньше звонков «где мой заказ»
Скачивание счетов и актов	Must	Второй по частоте вопрос клиентов
Выгрузка заказов из учётной системы	Must	Без неё статусы придётся вбивать руками
Онлайн-оплата счёта картой	Should	Оптовики платят по счёту; первое время хватит кнопки «скачать счёт»
Письмо клиенту при смене статуса	Should	Важно, но заказ всё равно виден в кабинете
Повтор прошлого заказа в один клик	Could	Удобно, но заказы пока оформляет менеджер
Чат с менеджером внутри кабинета	Could	Почта и телефон уже работают
Аналитика закупок для клиента	Could	Ценность не доказана: никто из клиентов о ней не просил
Мобильное приложение	Won't	Веб-кабинет адаптирован под телефон; приложение — отдельный проект
Программа лояльности и бонусы	Won't	Нужна отдельная бизнес-модель, а не функция кабинета

Какие ещё методы бывают?

Кроме MoSCoW, заказчику пригодятся два способа: матрица «ценность / трудоёмкость» и балльная оценка RICE. Первая хороша на старте, когда данных нет, вторая — для работающего продукта с пользователями.

Матрица «ценность / трудоёмкость». Каждой функции дают две оценки — ценность для бизнеса и трудоёмкость от разработчика — и раскладывают их по четырём квадратам:

• высокая ценность, низкая трудоёмкость — делать первыми;
• высокая ценность, высокая трудоёмкость — планировать, возможно, делить на части;
• низкая ценность, низкая трудоёмкость — делать, если остаётся время;
• низкая ценность, высокая трудоёмкость — не делать, пока не изменятся обстоятельства.

Ценность ставите вы, трудоёмкость — разработчик. Если обе оценки ставит один человек, матрица просто подтверждает его мнение.

RICE. Метод описал Шон Макбрайд в блоге Intercom. Каждая функция получает балл: охват (Reach — сколько людей затронет за период) умножают на влияние (Impact — по шкале 3, 2, 1, 0,5, 0,25) и уверенность (Confidence — 100, 80 или 50 %) и делят на трудоёмкость (Effort — в человеко-месяцах). Чем выше балл, тем раньше функция идёт в работу.

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

Практичная связка: для первой версии — MoSCoW, внутри каждой категории порядок по матрице «ценность / трудоёмкость», а после запуска, когда появятся данные, — RICE для списка доработок.

Как приоритизация меняет смету и срок?

Смета первой версии строится по Must и Should, а Could оценивают отдельной строкой — как опцию. Так вы видите цену каждой группы и решаете, брать ли желательное сейчас. Won't в смету этапа не входит вовсе.

Как это выглядит у нас. Личный кабинет считается по тарифу «Веб-приложение / SaaS» на странице личного кабинета: от 160 000 ₽ и от 10 дней. В тариф уже входят роли и права, база данных и API, таблицы с фильтрами и выгрузкой, вход и восстановление пароля, письма, приём оплаты и одна-две внешние интеграции. Значит, для примера выше большая часть Must и Should — это состав тарифа, а не надбавки. Выйти за «от» обычно заставляют то, что на странице цен указано как доплата: сложные интеграции сверх двух, нестандартные платёжные схемы, нативные мобильные приложения. Точную сумму называем после брифа.

Три правила, которые стоит знать до договора:

• Цена фиксируется по согласованному объёму. По типовому договору стоимость меняется только при изменении объёма по соглашению сторон, через дополнительное соглашение. Поэтому список Won't — часть ТЗ, а не черновик.
• Правки — не новые функции. В тарифе до 2 раундов правок на прототипе и до 2 на готовой сборке. Правка меняет согласованное; функция из Could, добавленная по ходу, — работа сверх ТЗ.
• Замена дешевле добавления. Если в середине работы функция становится обязательной, проще всего обменять её на Could равной трудоёмкости — тогда объём, а с ним цена и срок, остаются прежними.

Подробно о составе и этапах первой версии кабинета — в статье «Сколько стоит MVP личного кабинета».

Как договориться внутри компании о приоритетах?

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

Порядок, который помогает не утонуть в пожеланиях отделов:

1. Запишите цель одной фразой с измеримым признаком. Например: «клиенты узнают статус заказа без звонка менеджеру». Каждую функцию проверяйте вопросом: приближает ли она к этой цели?
2. Соберите список от всех, но сортируйте отдельно. Продажи, бухгалтерия и склад присылают пожелания письменно, с объяснением, какую проблему решает функция.
3. Назначьте владельца продукта. Это человек, который решает спорные случаи и подписывает ТЗ. Часто это директор или руководитель направления, но не комиссия.
4. Ограничьте Must заранее. Скажите участникам, что обязательного может быть не больше определённой доли бюджета. Ограничение заставляет выбирать.
5. Покажите, куда ушла каждая функция. Отложенное должно быть видно в общем списке с причиной — тогда автор пожелания знает, что его услышали.

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

Что делать с отложенными функциями?

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

Для каждой отложенной функции запишите три вещи:

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

Через месяц-два после запуска пересмотрите список. Часть пунктов окажется ненужной: пользователи справились иначе. Это нормальный результат — сэкономленные деньги. Развитие после запуска у нас идёт по поддержке и развитию, от 7 900 ₽/мес, или отдельным этапом с собственной сметой.

Когда приоритизация не нужна и какие ошибки бывают?

Формальная приоритизация не нужна, если объём и так маленький: лендинг, простой бот, сайт из нескольких страниц. Там все функции входят в тариф, и спорить о категориях дольше, чем сделать. Не нужна она и тогда, когда состав жёстко задан извне — договором с вашим клиентом или требованиями закупки.

Ошибки, которые встречаются чаще всего:

• Всё помечено как Must. Значит, приоритизации не было. Проверьте каждую строку вопросом: выпустим ли продукт, если её не будет?
• Приоритеты по разделам, а не по пути пользователя. «Сначала сделаем заказы целиком» даёт идеальный раздел и сервис, которым нельзя пользоваться. В первой версии путь должен проходить от входа до результата, пусть в простом виде — об этом в статье «MVP или полная версия».
• Безопасность и права доступа в Could. Вход, роли и защита данных не бывают «желательными». Урезают удобства, а не основу.
• Won't не записан. Через месяц функцию вспоминают как «мы же договаривались», и начинается спор на приёмке.
• Приоритеты без оценки трудоёмкости. Метки поставлены, но никто не знает, сколько весит каждая группа, и правило 60 % проверить нечем.
• Приоритеты один раз и навсегда. После запуска появляются данные; список доработок пересматривают, а не исполняют по старому плану.

Чек-лист: что подготовить к брифу

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

• Цель первой версии одной фразой и признак, по которому поймёте, что она достигнута.
• Список функций — коротко, по одной строке, с ролью пользователя.
• Метка MoSCoW и причина у каждой строки.
• Отдельный список Won't с сигналами для возврата.
• Системы, с которыми нужен обмен данными, — от этого сильнее всего зависит трудоёмкость.
• Имя человека, который принимает решения о составе и подписывает ТЗ.

Удобнее всего собрать это в пошаговом брифе: проект описывается по шагам, а оценку срока и цены мы присылаем в ответ. Если ТЗ ещё нет, начните со статьи «Как составить ТЗ без опыта» — отсортированный список функций станет его основой.

Короткие ответы на частые вопросы

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

Это способ разложить требования к проекту на четыре группы: Must have — без чего запускаться нельзя, Should have — важное с обходным путём, Could have — удобства, Won't have — то, что сознательно откладываем на следующий этап. Название собрано из первых букв категорий, буквы «o» добавлены для читаемости.

Сколько функций можно отнести к Must have?

Agile Business Consortium советует, чтобы обязательные требования занимали не больше 60 % трудоёмкости этапа, а около 20 % оставалось на желательные — это запас на непредвиденное. Считать стоит по трудоёмкости, а не по числу пунктов в списке.

Чем MoSCoW отличается от RICE?

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

Что делать с функциями из категории Won't have?

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

Можно ли поменять приоритеты во время разработки?

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

Услуги и кейсы по теме: разработка личного кабинета · поддержка сайта от 7 900 ₽/мес · цены и сроки