Разработка13 октября 202610 мин чтения

MVP: как не переплатить за первую версию продукта

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

MVP — это срез, а не урезанная версия

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

Отсюда главное различие, которое определяет и стоимость, и пользу. Первую версию можно резать двумя способами. Горизонтально — сделать все экраны, отложив «на потом» логику и данные. Получается красивый продукт, в котором ничего не работает и на котором ничего нельзя проверить. И вертикально — взять одну функцию и довести её насквозь, от интерфейса до базы данных.

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

Зачем вообще MVP, если можно сразу сделать хорошо

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

Деньги на разработку уходят примерно с одной скоростью в любом случае. Разница в другом — в какой момент вы узнаёте правду.

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

Поэтому корректнее говорить так: MVP не дешевле продукта — он дешевле ошибки.

Где на первой версии переплачивают чаще всего

Функции «на всякий случай». Каждая выглядит небольшой, но вместе они удваивают объём, а проверить их по отдельности на старте всё равно нельзя.

Своё вместо готового. Авторизация, платежи, админка, рассылки — для большинства задач есть надёжные готовые решения. Писать их с нуля на первой версии — платить за то, что ничем не отличает ваш продукт.

Полировка непроверенного. Сложные анимации и проработка редких сценариев в функции, про которую ещё неизвестно, будут ли ей пользоваться.

Архитектура «на миллион» без первой тысячи. Микросервисы и сложная инфраструктура там, где пока нет нагрузки, усложняют каждое изменение — а на старте менять придётся много.

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

Как отбирать функции

Работает один вопрос к каждой функции: решает ли продукт главную задачу без неё? Если да — функция ждёт. Если нет — она в первой версии.

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

Хороший признак правильного отбора: в первой версии остаётся меньше, чем хочется. Если всё, что придумали, влезло в MVP, скорее всего, резали недостаточно.

На чём нельзя экономить даже в MVP

«Минимальный» относится к объёму, а не к качеству. Есть вещи, которые в первой версии должны быть сделаны так же, как в зрелом продукте:

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

Ядро архитектуры. Модель данных и структура, на которую будут ложиться следующие функции. Если её сделать «на выброс», выброшенным окажется весь продукт.

Аналитика. MVP делается, чтобы что-то узнать. Если не измерять, что делают пользователи, вы потратите деньги на версию, которая ничего не скажет.

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

Как мы делаем MVP

Мы делаем MVP для стартапов и для компаний, которые запускают новый продукт рядом с основным бизнесом. Порядок работы у нас один и тот же, а меняется только масштаб.

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

Иногда MVP — это одна функция, отданная узкой группе людей. Инвестиционное приложение мы начали с раздела новостей: закрытое тестирование на первой сотне пользователей и сбор аналитики. Продукт, выросший из этого старта, получил 4,6★ в App Store, больше 10 000 скачиваний и 1800 активных пользователей в день.

А иногда первая версия проверяет не спрос, а саму возможность. Для криптокошелька в экосистеме Polkadot мы составили приоритизированный список функций под MVP — баланс, история, приём и перевод токенов — и сознательно сделали ставку на простоту, отложив уникальные возможности сети на следующий этап. От идеи до продукта прошло шесть месяцев.

Когда MVP — неправильный путь

Мы говорим об этом прямо, потому что иногда «давайте начнём с минимальной версии» ведёт в тупик.

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

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

Задача уже проверена. Внутренний инструмент под известный процесс не нуждается в проверке спроса — его нужно просто сделать хорошо.

Коротко

MVP — это тонкий, но сквозной срез продукта, а не набор красивых неработающих экранов.

Он не дешевле продукта — он дешевле ошибки: правда о спросе приходит раньше, пока потрачено немного.

Резать стоит объём, а не качество: деньги, данные, ядро архитектуры и аналитика делаются по-взрослому с первой версии.

Расскажите, что хотите проверить. За два рабочих дня вернёмся с оценкой объёма и сроков первой версии — и с предложением, что в неё войдёт, а что честнее отложить.

Частые вопросы

Сколько стоит разработка MVP?

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

Сколько времени занимает MVP?

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

Чем MVP отличается от прототипа?

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

Можно ли потом развивать MVP или придётся переписывать?

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

Вы делаете MVP для стартапов?

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