Как определить функционал MVP, если хочется сделать всё и сразу? Не начинать со списка функций. Сначала формулируют гипотезу, затем выбирают один ключевой сценарий, раскладывают его на карте пользовательских историй и только потом отсеивают лишнее по методу MoSCoW. Ниже — пошаговая инструкция на примере условного приложения доставки питьевой воды, чтобы вы могли повторить те же шаги со своей идеей.
- Функционал MVP выводится из гипотезы, а не из списка пожеланий.
- Один ключевой сценарий от начала до конца важнее десяти недоделанных.
- User story map показывает весь путь пользователя, MoSCoW помогает провести линию первой версии.
- Перед разработкой состав проверяют на прототипе: после теста он часто меняется.
Шаг 1. Сформулируйте гипотезу и метрику
Гипотеза отвечает на три вопроса: кто пользователь, какую проблему он решает и какое действие докажет, что решение ему нужно. Из гипотезы следует метрика, которая её подтвердит или опровергнет.
Наш пример. Компания доставляет питьевую воду по Алматы, заказы принимают по телефону и в WhatsApp. Гипотеза: «Семьи и небольшие офисы, которые заказывают воду регулярно, будут повторять заказ через приложение, если это займёт меньше минуты». Метрика успеха: доля клиентов, сделавших второй заказ через приложение в течение месяца.
Обратите внимание: гипотеза не про «удобное приложение», а про конкретное поведение — повторный заказ. Это сразу задаёт фокус всей приоритизации. Формулировка гипотезы — первая задача продуктовой сессии, с которой у нас начинается разработка MVP мобильного приложения.
ПРАВИЛОЕсли по итогам MVP нельзя ответить «да» или «нет» на вопрос гипотезы, функционал выбран неправильно.
Шаг 2. Выберите один ключевой сценарий
Ключевой сценарий — путь, по которому пользователь проходит от проблемы к результату. В нашем примере: открыл приложение, выбрал воду, указал адрес и время, оплатил, получил, через неделю повторил заказ.
Всё, что не лежит на этом пути, кандидат на вычёркивание. Курьерское приложение, программа лояльности, отзывы — не на пути. Это не значит, что они не нужны бизнесу. Это значит, что гипотезу о повторных заказах они не проверяют.
Шаг 3. Постройте user story map
Карта пользовательских историй раскладывает сценарий по горизонтали на крупные действия, а под каждым действием — по вертикали — конкретные истории от самых необходимых к желательным. Для приложения доставки воды верхний ряд выглядит так: найти и выбрать — оформить — оплатить — получить — повторить.
- Найти и выбрать: каталог из нескольких позиций, цена, количество бутылей; ниже — фильтры, акции, описание источника воды.
- Оформить: вход по номеру телефона, адрес, окно доставки; ниже — несколько адресов, комментарий курьеру.
- Оплатить: Kaspi или картой, оплата при получении; ниже — сохранённая карта, бонусы.
- Получить: статус и push «курьер в пути»; ниже — отслеживание курьера на карте.
- Повторить: повтор прошлого заказа одной кнопкой; ниже — напоминание, когда вода должна закончиться, подписка на автозаказ.
Теперь проводим горизонтальную линию: всё, что выше неё, — первая версия. Важно, чтобы над линией оказался хотя бы один пункт в каждой колонке, иначе сценарий оборвётся. Карту удобно рисовать на онлайн-доске вместе с теми, кто знает клиентов: операторами, менеджерами, курьерами.
Шаг 4. Отсейте функции по методу MoSCoW
Метод MoSCoW делит функции на четыре группы: Must have — без этого гипотезу не проверить; Should have — важно, но можно обойтись; Could have — приятно, если останется время; Won't have — сознательно не делаем в этой версии. Ключевое слово — «сознательно»: список Won't фиксирует договорённость, чтобы к этим функциям не возвращаться посреди разработки.
| Функция | Группа | Почему |
|---|---|---|
| Вход по номеру телефона | Must | Без него нет истории и повтора |
| Каталог, адрес, окно доставки | Must | Ядро сценария заказа |
| Повтор заказа одной кнопкой | Must | Прямо проверяет гипотезу |
| Статус и push о доставке | Must | Заменяет звонок «где курьер» |
| Онлайн-оплата | Should | Можно начать с оплаты при получении |
| Несколько адресов | Should | Нужно офисам, но не всем |
| Напоминание о новом заказе | Could | Усиливает повтор, но не обязательно для проверки |
| Бонусы и промокоды | Won't | Искажают метрику повторных заказов |
| Приложение для курьеров | Won't | Диспетчер работает из админки |
| Отслеживание на карте, чат | Won't | Удобно, но гипотезу не проверяет |
Обратите внимание на бонусы: их не просто отложили, а исключили сознательно. Если повторный заказ стимулирован скидкой, вы не узнаете, удобно ли приложение само по себе. А вот онлайн-оплата спорная: иногда для проверки гипотезы достаточно оплаты при получении или кнопки «оплатить» с ручной обработкой. Это решают на продуктовой сессии.
Забыть про вторую роль. Каждая роль — клиент, курьер, диспетчер, администратор — это свои экраны и права, и каждая заметно увеличивает смету. В MVP оставляют одну пользовательскую роль и простую админку для сотрудников, остальное — после проверки гипотезы.
Как удешевить обязательные функции
Приоритизация отвечает на вопрос «что делать», но не «как». Даже функции из группы Must можно сделать дешевле, если не писать их с нуля. Авторизация, push-уведомления, платежи, чат, карты и аналитика подключаются готовыми сервисами вроде Firebase и SDK провайдеров — это недели экономии в первой версии. Заменить готовый сервис на собственный модуль можно позже, когда продукт докажет спрос. В примере с водой это значит: вход по SMS, push о доставке и аналитика повторных заказов — из коробки, а своя разработка уходит только на логику каталога, заказа и повтора.
Шаг 5. Проверьте состав на прототипе
Список функций на доске — это ещё предположение. Его проверяют на кликабельном прототипе: даём 5–10 людям из целевой аудитории пройти сценарий на телефоне и смотрим, понимают ли они ценность и где теряются. В примере с водой тест может показать, что людям важнее всего видеть дату следующей доставки, а выбор окна времени они считают лишним — и состав меняется до того, как написана строчка кода.
Прототип в Figma со всеми экранами и переходами, отчёт по тесту и смета по функциям — результат отдельной работы, которую мы делаем в рамках прототипирования интерфейсов: для приложения или сервиса — от 450 000 ₸ и 1–2 недели. Почему правки на прототипе дешевле правок в коде, мы объясняли в статье о стоимости прототипа.
Шаг 6. Зафиксируйте первую версию и план второй
Итог приоритизации — два документа. Первый: функции MVP с метрикой, которую каждая из них помогает измерить. Второй: бэклог второй версии — всё из групп Should, Could и Won't с пометкой, по каким данным вы решите, нужна ли функция. Например: «напоминание о заказе — делаем, если больше трети клиентов повторяют заказ с интервалом в неделю».
С таким составом смета становится честной: каждая строка — функция, убрали функцию — минус в смете. У нас первая версия с одним ключевым сценарием, бэкендом, аналитикой и публикацией — от 4 500 000 ₸ и 8–10 недель.
Чек-лист: какие функции включить в MVP
- Гипотеза сформулирована одной фразой и её можно опровергнуть цифрами
- Есть одна метрика успеха и понятно, где её смотреть
- Ключевой сценарий проходит от начала до конца без «позвоните нам»
- В каждой колонке user story map есть хотя бы одна функция первой версии
- Каждая функция Must проверяет гипотезу или без неё рвётся сценарий
- Список Won't записан и согласован
- В первой версии одна пользовательская роль
- Авторизация, платежи, push и аналитика — на готовых сервисах, а не самописные
- Аналитика событий ключевого сценария заложена до релиза
- Состав проверен на прототипе с 5–10 пользователями
Что делать дальше
Возьмите свою идею и пройдите шаги 1–4 за один рабочий день: гипотеза, сценарий, карта, MoSCoW. Если список Must занимает больше десятка строк, скорее всего, в нём спряталась вторая гипотеза — разделите их и выберите более рискованную. Затем проверьте состав на прототипе. Если хотите пройти эти шаги с командой, которая потом будет разрабатывать, — продуктовая сессия с прототипом и тестом на пользователях занимает 2 недели и стоит от 900 000 ₸; подробнее о форматах — на странице MVP мобильного приложения, а о бюджете — в статье «Сколько стоит MVP приложения», вилки по мобильным форматам — на странице цен на приложения.
Что такое метод MoSCoW простыми словами?
Способ разделить функции на четыре группы: обязательно, желательно, можно, точно не сейчас. В MVP попадает только первая группа.
Сколько функций должно быть в MVP?
Универсального числа нет. Критерий один: без функции нельзя проверить гипотезу или прерывается ключевой сценарий.
Нужна ли онлайн-оплата в MVP?
Только если гипотеза про готовность платить в приложении. Иногда достаточно оплаты при получении или кнопки «оплатить» с ручной обработкой.
Что делать, если вся команда считает свою функцию обязательной?
Спросить про каждую: какую метрику гипотезы она двигает. Если ответа нет — функция уходит в Should или Won't, а решение о ней принимают по данным после запуска.
