Как запустить MVP и не потратить бюджет на лишние функции
Жуков Сергей ·
MVP — первая версия продукта, с помощью которой можно проверить конкретное предположение о пользователях и бизнесе. Полезный первый релиз даёт возможность пройти основной сценарий и собрать данные для следующего решения. Список функций имеет смысл только в связи с этой проверкой.
Сформулируйте одну проверяемую гипотезу
Вместо «хотим маркетплейс» опишите: кто будет пользоваться продуктом, какую проблему решает сервис и какое действие подтвердит интерес. Например, смогут ли заказчики найти подходящего исполнителя и отправить ему заявку. Число регистраций само по себе не отвечает на этот вопрос.
Заранее выберите срок проверки и признаки успеха. Это могут быть завершённые заявки, повторные обращения или оплаченные заказы. Порог задаётся вашей экономикой и каналами привлечения; универсальной нормы для всех продуктов нет.
Нарисуйте один путь от входа до результата
Запишите последовательность: пользователь узнаёт о сервисе, открывает каталог, выбирает предложение, отправляет заявку и получает ответ. Для каждого шага определите, что делает интерфейс, что делает сервер и где участвует человек.
Так обнаруживаются пропуски: заявку можно отправить, но никто не получает уведомление; оплатить можно, но статус заказа не меняется. Первый релиз должен закрывать весь выбранный путь, включая работу администратора.
Разделите функции на необходимые и отложенные
Необходимая функция поддерживает основную гипотезу или делает сценарий безопасным и работоспособным. В каталоге может понадобиться простой поиск, но не персональная рекомендательная система. Для первых обращений может хватить ручного распределения заявок вместо автоматического назначения исполнителей.
Отложенные функции запишите отдельно вместе с причиной. Это защищает бюджет от добавлений в середине разработки и помогает вернуться к идеям после проверки. Ручной процесс допустим, пока известны его ограничения и есть ответственный.
Согласуйте результат каждого этапа
Для первой версии зафиксируйте роли, сценарии, интеграции, требования к данным и критерии приёмки. Проверка «пользователь отправляет заявку, администратор видит её и получает уведомление» полезнее формулировки «разработать модуль заявок».
Разбивайте работу на этапы с демонстрацией работающих сценариев. Изменение требований должно сопровождаться обсуждением влияния на бюджет и дату запуска. Регулярное демо помогает увидеть расхождение раньше, чем готов весь продукт.
Подготовьте запуск и измерение
До публикации проверьте ключевой сценарий на мобильном устройстве, обработку ошибок, права доступа и доставку уведомлений. Назначьте ответственного за обращения пользователей и определите, где фиксируются ошибки.
Настройте события для основной цепочки: начало сценария, отправка заявки, успешное завершение. После запуска сравнивайте шаги: если пользователи не доходят до каталога, проблема может быть в привлечении; если открывают карточки, но не обращаются, нужно изучить предложение и интерфейс.
Когда переходить к следующей версии
Следующий этап выбирайте по результатам: разговорам с пользователями, фактическим обращениям и затратам на ручную работу. Иногда полезнее упростить уже существующий шаг, чем добавить новый раздел.
Для обсуждения MVP достаточно описания аудитории, главного сценария и ограничения по бюджету. На этой основе можно определить состав первой версии и список задач, которые разумно оставить на потом.