Как определить состав MVP с помощью приоритизации функций
Практика3 минРедакция Innovialabs
Коротко
Опишите один ключевой путь пользователя от проблемы до результата, разложите функции по MoSCoW и оставьте в MVP только Must — всё, без чего этот путь не проходит.
Коротко: что должно попасть в MVP
MVP — это минимальная версия продукта, которая позволяет проверить главную гипотезу на реальных пользователях. В него попадает только то, без чего пользователь не сможет пройти основной сценарий от начала до конца. Всё остальное — во второй и следующие релизы.
Самый надёжный способ найти эту границу — совместить два инструмента: карту пути пользователя и приоритизацию MoSCoW.
Шаг 1. Сформулируйте гипотезу
Прежде чем выбирать функции, ответьте одним предложением: кто ваш пользователь, какую проблему он решает и какой результат должен получить. Например: «Владелец небольшого кафе хочет принимать заказы через Telegram без звонков».
Если гипотеза не помещается в одно предложение, MVP получится размытым.
Шаг 2. Нарисуйте путь пользователя
User journey map — это последовательность шагов, которые человек проходит, чтобы получить результат. Для примера с кафе:
- Клиент открывает бота.
- Видит меню.
- Выбирает блюда и количество.
- Оформляет заказ и указывает адрес.
- Владелец получает уведомление.
- Клиент узнаёт, что заказ принят.
Под каждым шагом выпишите функции, которые нужны для него. Так вы увидите скелет продукта — минимальный набор, без которого цепочка рвётся.
Шаг 3. Разложите функции по MoSCoW
MoSCoW делит все функции на четыре группы:
| Группа | Значение | Пример для кафе |
|---|---|---|
| Must have | Без этого основной путь не работает | Меню, корзина, оформление заказа, уведомление владельцу |
| Should have | Важно, но можно временно обойтись | Онлайн-оплата, статусы заказа |
| Could have | Приятно, но не критично | Программа лояльности, отзывы |
| Won't have (now) | Осознанно не делаем в этом релизе | Мобильное приложение, аналитика |
Правило простое: в MVP идёт только Must. Если Must получилось слишком много, проверьте каждую функцию вопросом: «Пользователь сможет получить результат без неё, пусть и неудобно?» Если да — это Should.
Шаг 4. Ищите ручные обходные пути
Многие функции на старте можно заменить ручной работой:
- вместо онлайн-оплаты — оплата при получении;
- вместо админки — таблица или уведомления в чат;
- вместо автоматических рассылок — сообщения вручную;
- вместо сложного поиска — короткий список категорий.
Это не костыли, а способ быстрее проверить спрос. Автоматизируйте то, что действительно используют.
Шаг 5. Определите, как измерить успех
MVP без метрики — просто первая версия. До запуска решите, какой сигнал подтвердит гипотезу: сколько людей прошли путь до конца, вернулись ли повторно, готовы ли платить. Без этого невозможно понять, что делать дальше.
Частые ошибки
- Слишком много Must. Каждая лишняя функция удлиняет запуск и размывает проверку.
- Отсутствие Won't. Без явного списка «не делаем» функции незаметно возвращаются в план.
- MVP без качества. Минимальный не значит сломанный: основной путь должен работать стабильно.
- Приоритизация по мнению команды. Опирайтесь на путь пользователя, а не на то, что интересно разрабатывать.