Разработка MVP редко бывает линейной, но порядок вопросов остаётся почти всегда одинаковым: что проверяем, кому это нужно, что собираем, как поймём результат. Ниже — шесть этапов, которыми удобно пользоваться как чек-листом.
Сроки и стоимость зависят от задачи и определяются после разбора. Ориентир один: рабочая версия для ограниченной аудитории вместо готового «всего».
1. Гипотеза и аудитория
Запишите, кто ваш пользователь, какую проблему вы решаете и по каким признакам поймёте, что она решена. Хорошая гипотеза проверяема: у неё есть измеримый результат и срок. «Людям нужно удобнее» — не гипотеза, «Владельцы кафе сами создают QR-меню за 5 минут» — гипотеза.
2. Ключевой сценарий и список «не делаем сейчас»
Выберите один путь пользователя, который подтверждает или опровергает гипотезу, и опишите его от первого действия до результата. Рядом запишите, что сознательно не делаете: дополнительные роли, интеграции, красивые отчёты. Этот список защищает проект от разрастания.
3. Прототип и проверка на людях
Прежде чем писать код, покажите схему или кликабельный макет нескольким представителям целевой аудитории и попросите пройти сценарий самостоятельно. Наблюдайте, где они останавливаются. Исправлять непонятное на макете в разы дешевле, чем в готовом продукте.
4. Реализация небольшими проверяемыми частями
Разбейте работу на части, каждую из которых можно проверить отдельно и целиком, вместе со всем путём пользователя. Сразу заложите базовое: хранение и защиту данных, резервную копию, сообщения об ошибках, возможность откатить релиз. Использование AI ускоряет черновую работу, но результат проверяет человек.
5. Запуск для узкой аудитории
Не открывайте продукт всем сразу: пригласите ограниченную группу, которая соответствует гипотезе. Заранее решите, что будете измерять: сколько людей начали сценарий, сколько дошли до результата, сколько вернулись. Без этих данных запуск превращается в мнение.
6. Наблюдение и решение
Через оговорённый срок соберите цифры и разговоры с пользователями и примите одно из трёх решений: продолжать в том же направлении, изменить гипотезу или сценарий, остановиться. Остановка после честной проверки — тоже результат: она экономит месяцы разработки.
Типичные ошибки
Начинать с полного набора функций вместо одного сценария. Пропускать проверку на людях, потому что «и так понятно». Не закладывать измерения и потом спорить о впечатлениях. Оценивать успех по количеству посетителей, а не по завершённым сценариям.