MVP мобильного приложения — первая версия продукта, с помощью которой проверяют важное предположение о пользователях. В ней должен работать выбранный сценарий от начала до результата. Перед разработкой полезно решить, какой вопрос проверяем, кого приглашаем и по каким наблюдениям выберем следующий шаг.
Сформулируйте вопрос, на который нужен ответ
«Выпустить приложение» описывает работу команды, но не объясняет, чему должен научить запуск. Более полезный вопрос: смогут ли постоянные клиенты самостоятельно записываться на повторную услугу и будут ли пользоваться этим способом?
Это условный пример, а не результат клиентского проекта. Для него нужно проверить выбор услуги, доступного времени, подтверждение записи и работу сотрудника с заявкой. Если запись никто не получает, одни красивые экраны не помогут проверить предположение.
В методологии Lean Startup минимальный продукт связан с проверкой гипотез и циклом создания, измерения и обучения. Для заказчика это означает: договориться о вопросе до выбора функций, затем собрать наблюдения и решить, что менять.
Запишите гипотезу обычным предложением: «Такая группа пользователей сможет сделать такое действие и получит такой результат». Рядом укажите, что заставит вас пересмотреть идею. Если любое поведение аудитории объявляется успехом, проверка не поможет принять решение.
Выберите одну группу пользователей
У новых посетителей, постоянных клиентов и сотрудников разные задачи. При попытке обслужить всех одновременно быстро появляются несколько кабинетов, разные права и длинный список экранов.
Для первого этапа выберите группу, которую можете пригласить и с которой можно обсудить результат. Уточните, где люди сейчас решают задачу, что им мешает и какие устройства используют. Не заменяйте эти сведения предположением, что всем удобнее приложение.
Иногда вопрос можно проверить раньше разработки: показать прототип, предложить запись через существующий сайт, наблюдать работу с ручным процессом. Такой способ полезен, если риск связан с понятностью предложения или самим спросом. Если проверяется работа на устройстве, прототип без реальной функции может быть недостаточен.
Как разделить функции для MVP и следующих этапов
Начните с последовательности действий. Для условной записи на услугу это: выбрать услугу, выбрать время, оставить контакт, получить подтверждение. Затем проверьте, что необходимо для каждого шага.
| Функция в условном приложении записи | Решение для первой версии | Обоснование |
|---|---|---|
| Выбор услуги и времени | Включить | Это основа проверяемого сценария |
| Отправка и подтверждение записи | Включить | Пользователь должен завершить действие |
| Получение записи сотрудником | Включить | Иначе услуга не будет оказана |
| Сообщение об ошибке и занятое время | Включить | Сценарий встречается при обычной работе |
| Бонусные уровни | Отложить | Не отвечают на вопрос о самостоятельной записи |
| Несколько филиалов | Обсудить | Зависит от выбранной группы и места проверки |
| Онлайн-оплата | Обсудить | Нужна, если без неё нельзя проверить предложение |
В другом проекте распределение будет другим. Например, для проверки оплачиваемого цифрового сервиса платёж может быть центральной функцией. Нельзя применять универсальное правило «оплату всегда отложим».
Для спорного пункта задайте вопрос: если убрать его, сможем ли мы получить ответ на гипотезу? Если да, функция может подождать. Если нет, она входит в минимальный сценарий или сама гипотеза требует пересмотра.
Не забывайте работу за пределами экранов
Для мобильного приложения могут понадобиться сервер, админка, API и обмен с существующими системами. Попросите включить их в состав первой версии. Иначе оценка нескольких экранов будет описывать только видимую часть проекта.
Определите источник данных: откуда берутся услуги, расписание и статус записи. Кто исправляет ошибку и связывается с клиентом? Что делать, если приложение отправило запрос, но связь оборвалась до подтверждения?
В некоторых проверках часть работы может выполняться сотрудником вручную. Это нужно согласовать и учитывать при оценке результата. Не обещайте пользователю мгновенное подтверждение, если сотрудник отвечает только в рабочее время.
Доступы и сохранность данных тоже входят в рабочий сценарий. Пользователь не должен видеть чужую запись; ошибка сети не должна незаметно терять его действие. Урезать дополнительные функции можно, но делать основное действие ненадёжным ради быстрого запуска опасно для самой проверки.
Как выбрать платформы и подход к разработке
Исходите из устройств приглашённой аудитории и функций, которые нужны для проверки. Заранее выясните требования к камере, уведомлениям, фоновым задачам и внешним сервисам. Возможность реализовать обычный экран не подтверждает работу специфической интеграции.
Flutter позволяет использовать общий код для разных платформ и обращаться к платформенным службам. Из этого не следует одинаковая трудоёмкость всех функций на Android и iOS. Совместимость зависимостей и необходимые проверки на устройствах оценивают отдельно.
При сравнении вариантов попросите показать состав работ: пользовательскую часть, сервер, интеграции, тестирование, подготовку распространения и поддержку. Выбор технологии не заменяет такое сравнение и не даёт универсального процента экономии.
Если приложению нужен только простой повтор существующего сайта, отдельно обсудите, зачем пользователю его устанавливать. Ответ может быть связан с регулярной задачей, доступом к устройству или другими условиями. Его нужно проверить на конкретной аудитории.
Что измерять после первого запуска
До выпуска выберите события, которые соответствуют сценарию. В примере записи полезно видеть начало выбора, отправку, подтверждённую запись и состоявшееся посещение, если этот факт можно получить корректно. Установки показывают интерес к загрузке, но не подтверждают выполнение задачи.
Дополняйте числа разговорами: почему человек остановился, что понял неправильно, как решил задачу другим способом. Маленькая группа полезна для поиска ошибок, но по ней нельзя уверенно прогнозировать весь рынок.
Запишите период проверки, условия приглашения и критерии следующего шага. Конкретные целевые значения выбирают по экономике и исходным данным проекта. Внешнее число «хорошей конверсии» без контекста может привести к неверному решению.
Что должно остаться после проверки
Соберите наблюдения по гипотезе, обнаруженные ошибки и предложения пользователей. Разделите исправления основного сценария и новые идеи. Не переносите каждое пожелание автоматически в следующую версию.
Возможные решения: улучшить тот же сценарий, проверить другую группу, изменить предложение или остановить разработку. Польза MVP состоит в том, чтобы принять обоснованное решение, даже если оно не ведёт к большому приложению.
Для обсуждения разработки MVP подготовьте гипотезу, выбранную аудиторию, путь пользователя и список существующих систем. По ним можно определить первую версию и условия, при которых будет понятно, стоит ли продолжать проект.