Как быстро создать рабочий MVP и сколько это может стоить

Большинство проектов затягивают запуск MVP по двум причинам. Первая — в первую версию пытаются заложить все, что потенциально может понадобиться. Вторая — экономят на критичных этапах и получают нестабильный продукт, который не может полноценно выполнять свои функции. В результате бюджет потрачен, сроки сорваны, а гипотеза не проверена.

С чего начинается MVP: гипотеза и ядро продукта

MVP начинается не с подбора подрядчика. Он начинается с ответа на два вопроса.

Первый — какую гипотезу вы проверяете. Формулировка должна быть конкретной. 

Плохо: Людям нужен сервис для автоматизации продаж.

Хорошо: Менеджеры по продажам в компаниях от 50 сотрудников готовы платить за инструмент, который сокращает время подготовки КП с двух часов до пятнадцати минут. 

Гипотеза, которую нельзя проверить цифрами, — не гипотеза.

Второй вопрос — какая функция продукта является ключевой. Здесь работают жесткие правила приоритезации. Вы выделяете одну-две функции, которые напрямую проверяют гипотезу. Все остальное — в бэклог на следующие итерации. 

Если вы не можете объяснить, как конкретная функция работает на проверку гипотезы, она не попадает в MVP.

Пример
Первая версия Uber: вызвать машину с геолокацией и оплатить картой. Никаких чатов с водителем, никаких программ лояльности, никаких корпоративных тарифов. Одна функция — проверка готовности рынка платить за быстрый вызов такси через приложение.

Результат этого этапа — документ на одну страницу. В нем: сформулированная гипотеза, критерии подтверждения, список из одной-двух ключевых функций. С этим документом вы заходите к подрядчику на Discovery-фазу. Без него разговор о сроках и бюджете не имеет смысла. 

Discovery-фаза и зачем она нужна

Discovery — это проектирование продукта до написания первой строки кода. Занимает две-три недели. Подрядчик, который предлагает пропустить этот этап, либо не понимает рисков, либо переложит их на вас.

Что вы получаете на выходе Discovery:

Первое — описанные пользовательские сценарии. Кто пользователь, какую задачу решает, каким путем идет к результату. Каждый шаг подробно расписан во избежание недопониманий: действие пользователя, отклик системы, переход на следующий экран. 

Второе — прототипы ключевых экранов. По сути это схема взаимодействия. Вы проходите по прототипу и видите будущий путь пользователя, где он попадает в тупик, какие элементы мешают дойти до цели. Правки на этом этапе — это изменения в схеме. Те же правки на этапе разработки — это переписанный код и кратно возросший бюджет.

Третье — архитектурный документ. Структура базы данных, состав API, точки интеграций с внешними сервисами. Если у вас есть технический директор, он получает документацию, с которой можно идти к любому другому подрядчику. Это снимает зависимость от одного исполнителя.

Discovery фиксирует объем и суть работ всей команды. После него подрядчик называет стоимость и сроки с отклонением не более 15%. Без него — отклонение от 40%. Поэтому Discovery-фаза — это стандарт современной разработки.

Выбор подрядчика: на что смотреть, кроме портфолио

Портфолио любого подрядчика показывает, что он делал, но не то, как он работает. Чтобы MVP оправдал ожидания, советуем обратить внимание на следующие аспекты.

Технологический стек
Для MVP критично важны скорость разработки типовых модулей и скорость поддержки. Фреймворки с готовыми компонентами для авторизации, платежей и админ-панели (Laravel, Django) существенно сокращают сроки и бюджет по сравнению с решениями, где все пишется с нуля. Обратите внимание, какое обоснование для фреймворка дает ваш подрядчик.

Наличие выделенного проектного менеджера
Для успешного проекта нужен профессионал, который грамотно будет обращаться со сроками, бюджетом и содержанием проекта, напрямую общаться с заказчиком. Если у компании-разработчика нет таких лиц — вы рискуете управлять командой подрядчика вручную, что негативно скажется на продукте.

Производственный процесс
У профессиональной команды, как правило, устоявшиеся производственные процессы с регулярным обменом обратной связью с заказчиком. Выясните, как часто подрядчик будет демонстрировать результат. Если одну итерацию нужно ждать от четырех недель, есть риск увидеть не тот результат, который ждете.

DevOps-компетенции
Наличие DevOps-инженера в команде — маркер зрелости рабочих процессов. Именно он настроит CI/CD, тестовое окружение и мониторинг, без которых вы получите продукт с большим количеством багов.

Проверка всех этих параметров выше спасет вас от подрядчика, который не сможет выпустить нужный продукт в срок и в рамках бюджета.

Подробнее про процесс разработки

Профессиональная команда работает по четкому процессу. Вы не обязаны погружаться в детали, но должны понимать ключевые элементы, чтобы оценить, все ли идет по плану. Вот четыре маркера здорового производственного процесса.

Короткие итерации
Разработка разбита на спринты по две недели. В начале спринта команда фиксирует, какие задачи берет в работу. В конце — показывает промежуточный результат. Вы тестируете продукт каждые две недели, а не получаете «сюрприз» через три месяца. 

Промежуточные билды на staging-окружении
Staging — это копия боевого сервера, скрытая от пользователей. Все изменения сначала выкладываются туда. Вы заходите, проверяете функционал, подтверждаете — только после этого код идет в продакшен. Это исключает ситуацию, когда после обновления сайт «лег» для всех пользователей.

Управление изменениями
В процессе разработки появляются новые вводные. Это нормально. Ненормально, когда их берут в работу без оценки последствий. Профессиональный PM фиксирует запрос, оценивает влияние на сроки и бюджет, согласовывает с вами. Вы принимаете решение на основе новой оценки сроков и бюджета.

Регулярная отчетность
Вы получаете еженедельный срез: что сделано, что в работе, какие риски появились и как команда их закрывает. Без запросов с вашей стороны. Если вы начинаете выяснять статус проекта через неделю молчания — процесс не выстроен.

Из чего складывается стоимость MVP

Стоимость MVP от 3 млн рублей — не цифра с потолка. Это сумма, за которой стоят конкретные этапы и роли. Разбираем по статьям.

Хороший подрядчик не прячет затраты за словами «индивидуальная оценка». Вы видите структуру, понимаете, за что платите, и можете сопоставить с рыночными ставками квалифицированных команд.

После запуска

MVP запущен — это не повод выдохнуть и взять паузу. С этого дня начинается этап, ради которого продукт создавался — сбор данных и проверка гипотезы. Без системного подхода здесь вы рискуете потратить бюджет на разработку и не получить ответа на главный вопрос.

Метрики с первого дня
Подключите аналитику до запуска, а не после. Минимальный набор: количество регистраций, активаций, конверсия в целевое действие. Эти цифры покажут, работает ли гипотеза. Если пользователи регистрируются, но не доходят до ключевой функции — проблема в знакомстве с продуктом. Если не возвращаются — ценность не подтверждена. Без метрик вы не поймете, в чем проблема, и либо будете продолжать тратить деньги на неработающую механику, либо потеряете потенциально хороший продукт.

Сбор обратной связи
Настройте канал для обратной связи внутри продукта: форма, чат, кнопка «сообщить об ошибке». Каждую неделю анализируйте входящий поток и выделяйте повторяющиеся запросы. Это ваш бэклог на ближайшие итерации. Приоритезируйте баги от критичных до важных, которые пойдут в бэклог.

Решение о масштабировании
Есть два сценария по итогам первых недель после запуска. Первый — метрики подтверждают гипотезу. Вы масштабируете, добавляете функции из бэклога, увеличиваете команду, готовитесь к следующему раунду инвестиций. Второй — метрики не подтверждают гипотезу. Вы меняете гипотезу или ключевую функцию и запускаете новую итерацию.

MVP без пост-аналитики — это просто код. Инструмент проверки гипотезы становится таковым только когда вы собираете данные и принимаете на их основе продуктовые решения.