Что такое MVP и как запустить его за 3–⁠6 недель

MVP — минимальная версия продукта, которая работает с живыми людьми и отвечает на один конкретный вопрос: нужен ли продукт, будут ли за него платить, выдержит ли схема реальную нагрузку. Это не макет и не презентация, а работающий продукт с админкой и аналитикой — просто без всего, что на ответ не влияет. Запустить MVP за 3–⁠6 недель можно, если до старта зафиксировать вопрос, главный сценарий и список того, что уходит во вторую версию. Самый короткий срок, на который я берусь, — 21 день.

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

Эти слова путают, а за ними разные деньги и разные ответы.

Про прототип подробнее — в заметке «Зачем прототип до разработки».

Честный пример пилота — Digital Control: мобильное приложение с QR-чекином и CRM для отчётности о посещаемости обучения по госпрограмме. В пилоте было 11 учебных центров, работу продолжил один. Это тоже ответ — и он стоил в разы меньше полноценной системы. Без пилота тот же вывод пришлось бы делать после разработки всего продукта.

Какой вопрос должен проверять MVP

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

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

Что положить в MVP, а что убрать

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

Что почти всегда остаётся:

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

Что обычно уходит во вторую версию:

• вторые и третьи роли, если вопрос — про главного пользователя;
• настройки, профили, уведомления во все каналы сразу;
• автоматизация того, что первые недели спокойно делается руками;
• красивые мелочи — анимации, иллюстрации, редкие сценарии.

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

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

Как уложиться в 3–⁠6 недель

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

Потом — объём. Я фиксирую функции первой версии, а всё, что не влезает, честно переношу во вторую. Дальше дизайн и разработка идут параллельно, короткими итерациями. Раз в неделю — демо работающей версии, а не слайдов: так ошибки видны, пока их дёшево исправить. Как я держу объём и почему это освобождает всех, — в заметке «Дисциплина освобождает».

Со стороны заказчика нужен человек, который принимает решения быстро. В проекте на три недели вопрос, который ждёт ответа неделю, съедает заметную часть срока.

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

Пример — платформа голосования за 3,5 недели

Freedom Ticketon Awards — строго говоря, не проверка гипотезы, а продукт с датой, которая не двигается: премия. Но приёмы те же. Я сначала разобрал схемы накрутки голосов, потом сделал дизайн, фронт, бэк, антифрод, админку и наполнил каталог номинантов. От нуля до запуска — три с половиной недели, итог — 142 868 голосов.

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

Когда MVP — не то, что вам нужно

MVP проверяет неизвестное. Если неизвестного нет — например, вы автоматизируете учёт, который уже работает в таблицах, — проверять спрос не нужно. Тогда первая версия — это первый модуль, который снимает главную боль. Об этом — в заметке «Когда бизнесу нужна ERP, а когда хватит таблиц».

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

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

MVP за 3–⁠6 недель — это дисциплина объёма, а не скорость кода. Если у вас есть идея и дедлайн, посмотрите, как устроен MVP за 21 день, — или напишите, и я помогу понять, что стоит проверить первым.