Три месяца — реальный срок для первой версии продукта. Не для системы «как у больших», а для MVP: одного главного сценария, который решает задачу пользователя от начала до конца. В мобильном приложении это обычно 5–8 экранов, вход, работа с данными через API и простая админ-панель.
Чтобы этот срок выдержать, важно не столько быстро писать код, сколько вовремя отказаться от лишнего. Ниже — как выглядят эти три месяца и что в них помещается.
Что такое MVP на самом деле
MVP — минимальная версия продукта, с которой пользователь может решить свою задачу целиком. Ключевое слово здесь «целиком». Не прототип, не набор экранов-заглушек и не первая треть большой системы, а маленький, но законченный продукт.
Удобно проверять так: можно ли дать MVP реальному человеку и не стоять у него за спиной с объяснениями? Если пользователь сам проходит путь от входа до результата — это MVP. Если на полпути он упирается в «эта функция будет позже» — это пока демо.
Хорошая первая версия отвечает на один вопрос: нужен ли продукт людям в таком виде. Всё, что не помогает ответить на этот вопрос, можно отложить.
Как распределяются три месяца
Примерный план, если задача понятна и решения принимаются быстро:
| Период | Что происходит | Результат |
|---|---|---|
| Неделя 1 | знакомство, оценка, план этапов | сроки, стоимость, состав первой версии |
| Недели 2–3 | требования, дизайн, техническое задание | согласованные макеты и ТЗ |
| Недели 4–10 | разработка итерациями по 2 недели | рабочая версия на демо после каждой итерации |
| Недели 11–12 | тестирование, доработка, запуск | первая версия у пользователей |
Получается три-четыре итерации разработки. После каждой вы видите работающий продукт, а не отчёт о проценте готовности. Это важно: если на втором демо выясняется, что пользователю нужно другое, план меняется сразу, а не после запуска.
Подготовка занимает меньше трёх недель, и это не время, потраченное впустую. Каждый день на согласовании макета экономит несколько дней переделок в коде.
Что включить в первую версию
Начните с одного сценария, ради которого продукт вообще существует. Для сервиса заказов это «найти — заказать — оплатить — получить статус». Для внутреннего инструмента — «подать заявку — увидеть, что с ней происходит». Всё остальное строится вокруг.
Обычно в MVP входят:
- главный сценарий целиком, без заглушек;
- вход — по телефону, почте или корпоративной учётной записи;
- данные, без которых сценарий не работает, — каталог, справочники, профили;
- простая админ-панель, чтобы команда могла управлять контентом без разработчиков;
- аналитика — какие экраны открывают, где пользователи останавливаются;
- уведомления, если без них сценарий ломается: например, статус заказа.
Этого достаточно, чтобы продукт можно было показать первым пользователям и получить честный ответ.
Что смело отложить
Здесь проходит основная экономия времени. Типичные кандидаты на «после запуска»:
- вторая и третья роли пользователей, если первая может работать без них;
- сложная аналитика и отчёты — в первые месяцы хватит базовых метрик;
- настройки, темы оформления, персонализация;
- редкие сценарии — то, что случается раз в месяц, можно какое-то время делать вручную;
- интеграции «на всякий случай» — подключать стоит только те, без которых не работает главный сценарий;
- автоматизация того, что пока проще сделать руками — например, выгрузки для бухгалтерии.
Хороший вопрос для каждой функции: что случится, если в первой версии её не будет? Если ответ «пользователь не сможет решить задачу» — функция нужна. Если «будет немного неудобно» — она подождёт.
Где обычно теряется время
Три месяца легко превращаются в пять. Причины почти всегда одни и те же:
- решения принимаются медленно. Демо прошло, а обратная связь пришла через две недели. Итерация потеряна;
- объём растёт по ходу. Каждая новая функция кажется маленькой, но вместе они съедают месяц;
- внешние системы не готовы. Интеграция зависит от API, к которому ещё нет доступа или документации;
- доступы приходят в последний момент — к серверам, магазинам приложений, платёжному сервису.
Многое из этого решается заранее: назначить человека, который принимает решения по продукту, договориться о сроке обратной связи после демо и запросить доступы в первую же неделю.
Как проверить идею
Запуск MVP — начало проверки, а не её итог. До разработки полезно решить, какой результат будет считаться успехом. Например:
- сколько пользователей должно пройти главный сценарий за первый месяц;
- сколько из них вернутся во второй раз;
- на каком шаге пользователи уходят и почему;
- сколько времени экономят сотрудники, если продукт внутренний.
Цифры зависят от продукта, но сам подход одинаковый: сначала договориться о критерии, потом смотреть на данные. Без этого любая первая версия кажется «в целом нормальной», и решения о развитии принимаются по ощущениям.
После запуска следующие функции добавляются теми же итерациями по две недели — но уже по данным реальных пользователей, а не по списку пожеланий из первого месяца.
Сколько стоит такой MVP
Мобильное приложение-MVP на iOS и Android (5–8 экранов, вход, работа с API) стоит от 2,1 млн ₽ и делается за 2–3 месяца. Для веб-продуктов первая версия с ключевым сценарием тоже выходит за 2–3 месяца, стоимость зависит от состава. Точную оценку мы даём бесплатно, после короткого разговора о задаче. Подробнее — на страницах разработки ПО на заказ и мобильных приложений.
Три месяца — немного. Но для того, чтобы узнать, нужен ли продукт людям, обычно хватает. Остальное подскажут сами пользователи.
