Аббревиатуру MVP используют так часто и так по-разному, что смысл почти стёрся. Для одних это «дешёвая версия с урезанными функциями», для других — «прототип на коленке». На практике MVP решает ровно одну задачу: проверить, нужен ли продукт вообще, потратив на проверку минимум денег и времени.
Главный вопрос: какую гипотезу вы проверяете
До обсуждения функций и сроков стоит сформулировать, что именно вы хотите узнать. «Будут ли люди платить за автоматическую подготовку отчётов?» — гипотеза. «Сделать платформу для бизнеса» — не гипотеза, а направление, под которое можно потратить любой бюджет и не понять результат.
Из чёткой гипотезы сразу становится ясно, что в первую версию входит, а что нет: остаётся только то, без чего гипотезу не проверить.
Если в списке функций MVP есть пункт, который не влияет на проверку гипотезы, — его место во втором этапе. Это простое правило экономит больше бюджета, чем любые переговоры о ставках.
Что почти всегда входит в MVP
- Один основной сценарий целиком — от входа пользователя до получения результата, ради которого он пришёл
- Минимальная авторизация, если сценарий требует личных данных
- Способ получить деньги, если проверяете готовность платить — даже вручную выставленный счёт подходит
- Базовая аналитика, чтобы видеть, где люди отваливаются
Что откладывают почти всегда
- Админ-панель с тонкой настройкой прав — на старте хватает прямого доступа к данным
- Второй и третий сценарии использования, «пока делаем — давайте сразу и это»
- Мобильное приложение параллельно с веб-версией
- Сложная автоматизация процессов, которые пока можно делать руками при десяти клиентах
- Идеальный дизайн всех состояний интерфейса — достаточно опрятного и понятного
Ручная работа на старте — это нормально и часто разумно: пока пользователей мало, человек справляется дешевле, чем разработка автоматизации, которая может и не понадобиться.
Реалистичные сроки
Один понятный сценарий с авторизацией и базовой логикой — 6–10 недель. Продукт с несколькими ролями, платежами и парой интеграций — 3–4 месяца. Всё, что обещают сделать «за две недели под ключ», обычно оказывается либо конструктором, либо разговором, после которого сроки едут.
Сроки сильно зависят и от вашей стороны: скорость согласований и наличие человека, который принимает решения, влияет на график не меньше, чем скорость разработки.
Ошибки, которые дороже всего обходятся
MVP превращается в полноценный продукт. Классика: по ходу добавляются «маленькие» функции, и через полгода вы всё ещё не запустились и не проверили гипотезу. Помогает жёсткая договорённость: всё новое идёт в список второго этапа, без исключений.
Технические решения «на вырост». Проектировать архитектуру под миллион пользователей, когда не проверено, придёт ли первая сотня, — дорого и обычно бессмысленно. Разумно закладывать возможность роста, а не строить его заранее.
Экономия на аналитике. Запустить MVP и не понимать, что делают пользователи, — значит потратить деньги и не получить ответ. Базовая аналитика стоит копейки и окупается сразу.
Отсутствие плана после запуска. MVP — это начало, а не финиш. Стоит заранее договориться, какие цифры считаются подтверждением гипотезы и что делаете, если она не подтвердится.
Сколько это стоит
Простой MVP с одним сценарием — от 300–500 тысяч рублей. Продукт со сложной логикой, ролями и интеграциями — от 800 тысяч до полутора миллионов. Существенно дешевле выходит связка no-code инструментов, если задача типовая, — о том, где это работает, а где превращается в ловушку, мы писали в статье «No-code и low-code».
И последнее: чем чётче сформулирована гипотеза на входе, тем точнее оценка и тем меньше шансов, что смета поедет. Подробнее о том, как описать задачу так, чтобы получить то, что нужно, — в статье «Техническое задание на разработку».
Расскажите, что хотите автоматизировать или разработать — оценим сроки и стоимость за один звонок.