Если сократить до одной мысли: MVP нужен не для того, чтобы «сэкономить на разработке», а чтобы не потратить весь бюджет на продукт, который никому не нужен в предложенном виде. Правильный MVP отвечает на конкретный вопрос — станут ли люди делать целевое действие в вашем приложении — и делает это как можно быстрее и дешевле, даже ценой неполноты остального функционала.
Что такое MVP и чего им не считать
MVP — версия продукта с минимальным набором функций, которой достаточно, чтобы решить одну задачу пользователя от начала до конца и получить от этого измеримый результат. Термин широко известен благодаря предпринимателю Эрику Рису и методологии Lean Startup: идея — не строить продукт «по наитию», а быстро проверять гипотезы на практике.
Ключевое слово — «жизнеспособный», а не «минимальный»: продукт должен реально работать для узкого сценария, а не быть заготовкой с заглушками. Отсюда три условия MVP:
- Решает реальную задачу целиком. Если приложение для записи к мастеру не даёт довести запись до конца — это не MVP, а демонстрация экрана.
- Проверяет конкретную гипотезу. До начала работы должно быть сформулировано, что именно вы хотите узнать и по какому показателю это поймёте.
- Можно выпустить быстро. Если MVP занимает столько же времени, сколько полноценный продукт, смысл проверки теряется.
MVP — это не «сырой продукт с багами». Ограниченный функционал и низкое качество — разные вещи. В MVP может не быть истории заказов, но то, что в нём есть, должно работать без критических ошибок: терять данные, ронять оплату или пускать чужие аккаунты в личный кабинет нельзя даже на раннем этапе.
Прототип, MVP, MMP, пилот — в чём разница
Эти термины часто путают, хотя они отвечают на разные вопросы.
| Формат | Проверяет | Получает ли пользователь рабочий продукт | Есть ли код | Типичный срок | Чем заканчивается |
|---|---|---|---|---|---|
| Прототип | Логику экранов и сценариев, удобство интерфейса | Нет, только имитация | Обычно нет (кликабельный макет) | 2–6 недель | Список правок к дизайну или отказ от идеи |
| MVP | Готовы ли люди пользоваться продуктом и платить/возвращаться | Да, для одного основного сценария | Да, минимальный | 2–4 месяца* | Решение: развивать, дорабатывать гипотезу или закрыть |
| MMP (minimum marketable product) | Готов ли продукт к полноценному продвижению и масштабированию | Да, с расширенным функционалом | Да | от нескольких месяцев после MVP | Запуск маркетинга, публичный релиз |
| Пилот | Работает ли продукт в конкретных условиях (например, у одного клиента-компании) | Да, часто с ручной поддержкой | Да, MVP или ближе к MMP | от 1 месяца | Договор на внедрение или отказ |
* Срок MVP с одним сценарием — ориентир из статьи «Этапы разработки мобильного приложения», зависит от сложности сценария и готовых сервисов.
Частая ошибка — называть MVP то, что по сути прототип (макет без кода), или, наоборот, тратить на «MVP» столько же ресурсов, сколько на полноценный продукт, добавляя функции про запас. Оба случая обесценивают саму идею проверки.
Начните с гипотезы, а не со списка экранов
Прежде чем обсуждать функции, стоит сформулировать, что именно вы проверяете. Удобный шаблон: «Мы считаем, что [аудитория] будет [действие], потому что [причина]; поймём это по [метрика] за [срок]».
| Проект | Гипотеза |
|---|---|
| Сервис записи к мастеру | Клиенты будут записываться через приложение вместо звонка, потому что это быстрее вечером; метрика — доля записей через приложение за месяц |
| Приложение для выездных сотрудников | Мастера будут закрывать заявки через приложение без звонка диспетчеру, потому что не нужно ждать ответа; метрика — доля заявок без звонка за две недели |
| Личный проект-трекер привычек | Пользователи будут отмечать привычку минимум 4 дня в неделю, потому что напоминание приходит вовремя; метрика — доля активных пользователей на 7-й день |
Такая формулировка сразу задаёт границы MVP: если гипотеза про запись без звонка администратору, в первую версию не обязательно включать историю визитов, отзывы о мастерах или программу лояльности — они не проверяют главный вопрос.
Как проверить идею до разработки приложения
Часть гипотез можно проверить ещё до того, как написана хоть одна строка кода мобильного приложения. Это дешевле и быстрее, чем сразу собирать даже минимальную версию. Как устроен сам этап прототипирования — в статье «Прототип и дизайн мобильного приложения».
Лендинг со smoke-тестом
Одностраничный сайт с описанием продукта и кнопкой «Оставить заявку» или «Узнать первым». Показывает интерес к идее, но не отвечает на вопрос, будут ли люди пользоваться продуктом регулярно. Если даже на этом этапе никто не оставляет заявку, стоит пересмотреть формулировку проблемы, прежде чем тратиться на разработку.
«Консьерж»-MVP
Задачу пользователя выполняют вручную люди, а не автоматизированная система: например, заявки на подбор специалиста обрабатывает менеджер в мессенджере, хотя снаружи это выглядит как сервис. Метод хорошо проверяет саму ценность услуги, но не масштабируется — годится для первых 10–30 клиентов, не больше.
«Волшебник из страны Оз»
Пользователь видит интерфейс продукта, но за «автоматической» логикой на самом деле стоит человек: например, «умные» рекомендации на деле составляет сотрудник вручную. Метод проверяет, ценен ли пользователю результат, до того как вложены силы в саму автоматизацию. Требует аккуратности: если подмена раскроется, это ударит по доверию.
Кликабельный прототип и юзабилити-тест
Макет без кода в редакторе прототипов (например, Figma или аналогах), который тестируют 5–8 человек из целевой аудитории: дать задачу («запишитесь на пятницу к любому мастеру») и молча наблюдать. Хорошо показывает, понятен ли сценарий и где люди теряются, но не отвечает на вопрос, вернутся ли они к продукту через неделю — для этого нужно наблюдать поведение не в лаборатории, а в жизни.
PWA или веб-версия вместо нативного приложения
Прогрессивное веб-приложение или адаптивный сайт с похожей логикой можно выпустить быстрее и без публикации в сторах. Ограничение — часть возможностей телефона (push-уведомления на iOS, некоторые датчики, офлайн-режим) доступна ограниченно или недоступна вовсе, поэтому для гипотез, завязанных именно на них, способ не подходит.
Чат-бот
Если основной сценарий — это последовательность вопросов и ответов (запись, подбор, заявка), его можно временно реализовать чат-ботом в мессенджере. Это проверяет логику сценария почти без разработки, но не подходит, если ключевая часть ценности — визуальный интерфейс, карта, камера или другая функция, которую в чате не показать.
Эти способы проверяют интерес и понятность сценария, но не заменяют MVP целиком, если продукту важны свойства именно мобильного приложения — офлайн-режим, push-уведомления, геолокация. В этом случае они полезны как предварительный фильтр перед разработкой.
Как выбрать функции первой версии
Когда гипотеза сформулирована, следующий шаг — решить, какие функции войдут в MVP, а какие подождут. Здесь помогают два инструмента.
Карта пользовательского пути
Опишите по шагам путь пользователя от запуска приложения до результата, который проверяет гипотезу: открыл → выбрал услугу → выбрал время → подтвердил запись → получил уведомление. MVP должен закрывать этот путь целиком, без обрывов на середине. Всё, что в стороне от пути — профиль, история, избранное, — кандидат на исключение из первой версии.
Приоритизация по методу MoSCoW
Каждую функцию относят к одной из групп: must have — без этого продукт не решает задачу; should have — важно, но можно выпустить без этого; could have — приятное дополнение; won't have — сознательно отложено. В MVP входит только must have и, по ресурсам, часть should have.
| Функция | Категория | Почему |
|---|---|---|
| Выбор услуги, мастера и времени | Must have | Это и есть проверяемый сценарий |
| Подтверждение и push-напоминание | Must have | Без напоминания часть клиентов не приходит — исказит результат |
| Отмена и перенос записи | Must have | Без этого клиенты будут звонить администратору |
| История прошлых визитов | Should have | Полезно, но не критично для первой проверки |
| Отзывы о мастерах | Could have | Не влияет на основной сценарий |
| Программа лояльности | Won't have | Отдельная гипотеза про удержание |
Правило одного сценария
Если в MVP закладывается больше одного независимого пользовательского сценария, часто оказывается, что ни один из них не сделан достаточно хорошо, чтобы дать честный ответ. Лучше довести до уверенного качества одну цепочку действий, чем сделать три сценария наполовину.
Чем нельзя жертвовать даже в MVP
- Стабильность основного сценария. Если ключевое действие падает или зависает, вы проверяете не гипотезу о продукте, а терпение пользователей.
- Безопасность персональных данных. Шифрование при передаче, разумное хранение паролей и токенов, отсутствие доступа к чужим данным. Подробнее — в статье «Персональные данные в мобильном приложении».
- Удаление аккаунта и данных. Требование магазинов приложений и части законодательства; без этого публикацию могут отклонить.
- Минимальная аналитика. Без базовых событий (открытие приложения, начало и завершение сценария) метрики для проверки гипотезы неоткуда взять.
Технологии для MVP
Выбор технологии определяется скоростью и стоимостью проверки, а не тем, на чём в итоге будет построен долгосрочный продукт.
- Кроссплатформенная разработка (например, на Flutter или React Native) позволяет собрать приложение для iOS и Android из одной кодовой базы — обычно быстрее и дешевле, чем две нативные версии. Сравнение подходов — в статье «Нативная или кроссплатформенная разработка».
- No-code и low-code инструменты позволяют собрать рабочее приложение без написания кода с нуля — конструктор экранов, готовые блоки логики, настройка интеграций вместо программирования. Стоит заранее проверить конкретный сервис на ограничения: экспорт данных при переходе на другую платформу и работу с пользователями и оплатой из России на момент выбора.
- Готовые бэкенд-платформы (BaaS) закрывают типовые задачи — авторизацию, хранение данных, push-уведомления — без разработки собственного сервера, что сокращает время на MVP с личным кабинетом или синхронизацией данных.
Ловушка «потом перепишем». Часть решений, принятых ради скорости, придётся пересмотреть при масштабировании — это нормально, если продукт подтвердил гипотезу. Проблема — когда решение изначально несовместимо с ростом настолько, что миграция стоит дороже новой разработки: например, сервис без выгрузки данных или без открытого API. Такие ограничения лучше проверять до начала работы, а не постфактум.
Как выпустить MVP к первым пользователям
Для проверки гипотезы MVP не обязательно публиковать в открытом доступе в сторах — есть форматы ограниченного распространения, рассчитанные на тестирование. Полную публикацию в магазинах разбирает статья «Публикация приложения в RuStore, App Store и Google Play».
iOS: TestFlight
Официальный инструмент Apple. Внутреннее тестирование (до 100 участников команды в App Store Connect) доступно почти сразу после загрузки сборки. Внешнее (до 10 000 тестировщиков, можно разбить на группы) требует, чтобы первая сборка каждой версии прошла проверку Apple (Beta App Review, обычно от нескольких часов до пары суток). Тестовая сборка доступна 90 дней с момента загрузки, дальше её нужно обновить.
Android: закрытое тестирование в Google Play
Для личных (не организационных) аккаунтов разработчика, созданных начиная с 13 ноября 2023 года, закрытое тестирование по списку тестировщиков обязательно перед доступом к публикации: нужно набрать не менее 12 тестировщиков, непрерывно участвующих в тесте минимум 14 дней подряд. Если тестировщик выходит из теста раньше срока, отсчёт по нему не засчитывается — стоит сразу договориться с людьми, что тест идёт две недели.
RuStore
Российский магазин RuStore поддерживает альфа-тестирование: сборка скрыта от общего каталога и доступна только приглашённым тестировщикам (по идентификатору или ссылке). Это ближайший аналог закрытого тестирования. Отдельно есть публичное бета-тестирование для более широкой аудитории. Правила могут уточняться — перед запуском стоит свериться с текущей документацией RuStore для разработчиков.
Корпоративная раздача
Для приложений, которые используются только внутри одной компании, у Apple и в экосистеме Android есть форматы распространения вне публичных сторов — через программы корпоративного распространения или MDM-системы. Это отдельный трек, который подходит не для проверки гипотезы у внешних пользователей, а для внутреннего использования.
Метрики: как понять, что гипотеза подтвердилась
Ощущение «вроде людям нравится» не заменяет измеримый результат. Формулы и настройка аналитики подробно разобраны в статье «Метрики мобильного приложения». До запуска MVP стоит заранее решить, какие цифры будут означать успех, а какие — провал, — иначе результат легко подогнать под желаемый вывод задним числом.
- Активация — доля людей, которые не просто установили приложение, а дошли до ключевого действия (первая запись, первая заявка).
- Удержание (D1/D7/D30) — доля пользователей, вернувшихся в приложение через 1, 7 и 30 дней после первого использования. Показывает, возвращаются ли люди сами.
- Доля выполнивших основной сценарий целиком — не просто открывших форму записи, а завершивших её.
- Качественная обратная связь — короткие интервью после использования: что понравилось, что было непонятно, вернулись бы к продукту в жизни.
Мы намеренно не приводим «нормальные» цифры удержания или активации — они сильно различаются в зависимости от типа продукта, частоты использования и аудитории, и общие ориентиры без источника легко вводят в заблуждение. Порог успеха стоит определить заранее, вместе с самой гипотезой, а не после того, как увидели результат — иначе легко подогнать вывод под желаемый.
Если порог не достигнут, дальше три пути: pivot — изменить гипотезу или аудиторию и попробовать снова, persevere — продолжить с текущей гипотезой при частичных обнадёживающих сигналах, или stop — признать, что идея в этом виде не подтвердилась, и не вкладывать бюджет без пересмотра подхода.
Сроки и бюджет MVP
Точные суммы в рублях без описания функций назвать нельзя — подробно почему, разобрано в статье «Из чего складывается стоимость разработки мобильного приложения». Но по срокам есть рабочие ориентиры, которые можно использовать, чтобы оценить реалистичность предложения подрядчика:
| Формат | Срок |
|---|---|
| Прототип для проверки идеи (без кода) | 2–6 недель |
| MVP с одним основным сценарием | 2–4 месяца |
Если вам предлагают собрать MVP с личным кабинетом, оплатой и несколькими интеграциями за пару недель, стоит уточнить, что войдёт в такую версию — вероятно, безопасность данных и полноценное тестирование в оценку не заложены.
Частые ошибки при создании MVP
- MVP на 30–40 функций. Попытка заложить в первую версию всё, что «может понадобиться», убивает саму идею быстрой проверки.
- Нет явной гипотезы и метрики успеха. Без них любой результат теста можно трактовать как угодно.
- Тестирование только на друзьях и знакомых. Они не хотят вас расстраивать и не похожи на целевую аудиторию — обратная связь искажается.
- Экономия на базовой аналитике. Без событий в приложении метрики для проверки гипотезы неоткуда взять.
- «Вечный MVP». Продукт годами остаётся в статусе «минимальной версии» без решения — развивать его дальше или остановить.
- Выбор технологии, которую невозможно развивать. Сервис без экспорта данных или API может ускорить старт, но сделать следующий шаг дорогим или невозможным.
- Игнорирование требований магазинов и закона о персональных данных. Отклонённая публикация или юридические риски способны сорвать тест сильнее недоделанной функции.
- Смешение нескольких гипотез в одном тесте. Если MVP одновременно проверяет спрос, готовность платить и удобство интерфейса, сложно понять, что именно не сработало.
Частые вопросы
Сколько функций должно быть в MVP?
Универсального числа нет — ориентир не количество функций, а закрытый до конца один пользовательский сценарий, от начала действия до результата, ради которого человек открыл приложение. Обычно это несколько связанных экранов, а не десятки разрозненных функций.
Можно ли сделать MVP вообще без мобильного приложения?
Да, если гипотезу можно проверить лендингом, чат-ботом, «консьерж»-сервисом или веб-версией — это дешевле и быстрее. Мобильное приложение как MVP оправдано, когда гипотеза завязана именно на возможностях телефона: push-уведомления, офлайн-режим, камера, геолокация или иконка на главном экране.
Сколько пользователей нужно, чтобы проверить гипотезу?
Зависит от формата: юзабилити-тест кликабельного прототипа обычно достаточно провести на 5–8 людях, чтобы найти основные проблемы сценария. Для метрик вроде удержания нужна выборка побольше и период наблюдения не менее нескольких недель.
Нужно ли публиковать MVP в открытом доступе в App Store и Google Play?
Не обязательно сразу. Форматы ограниченного распространения — TestFlight для iOS, закрытое тестирование Google Play, альфа-тестирование RuStore — дают доступ ограниченной группе без полноценной публикации, а для новых личных аккаунтов Google Play такое тестирование даже требует перед открытием публичного доступа.
Чем отличается MVP для внутреннего корпоративного приложения?
Гипотеза касается не спроса на рынке, а того, экономит ли инструмент время сотрудников или снижает число ошибок в процессе. Распространяется такой MVP через корпоративные каналы (программы Apple, MDM-системы), а метрикой успеха чаще становится измеримая экономия времени, а не удержание.
Что делать после того, как MVP подтвердил гипотезу?
Сформулировать новую гипотезу для следующего этапа — например, про удержание, монетизацию или новый сегмент, — и решить, какие функции из отложенного списка should have и could have понадобятся именно для неё. Так продукт постепенно движется от MVP к MMP — версии, готовой для полноценного продвижения.
MVP готов к запуску, если…
- гипотеза сформулирована одной фразой с метрикой и сроком проверки;
- основной сценарий проходится от начала до конца без обрывов;
- функции разложены по MoSCoW, в первую версию вошли только must have и часть should have;
- есть базовая аналитика ключевых событий сценария;
- данные пользователей защищены, есть возможность удалить аккаунт;
- заранее определён порог успеха и план действий при провале (pivot/persevere/stop);
- выбран формат ограниченного распространения под платформу — TestFlight, закрытое тестирование Google Play, альфа RuStore или корпоративная раздача.
Итог
MVP — это инструмент проверки, а не уменьшенная копия финального продукта. Он работает, только если перед разработкой сформулирована конкретная гипотеза с метрикой и сроком, а в первую версию попадает исключительно то, что необходимо для проверки одного сценария целиком. Технологии и форматы тестирования на этом этапе выбираются в пользу скорости, но не в ущерб безопасности данных и базовой стабильности — иначе результат теста покажет не отношение людей к идее, а их терпение к багам.
Если гипотеза подтвердилась — повод сформулировать следующую и решить, какие из отложенных функций понадобятся для неё. Если не подтвердилась — это тоже результат, причём куда более дешёвый, чем тот же вывод после полноценной разработки.