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

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

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

Сначала определить, что именно запускаем

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

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

Полезно заранее ответить на три вопроса:

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

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

Из каких частей складывается срок

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

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

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

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

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

Почему одинаковое число экранов даёт разный календарь

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

На срок влияют четыре вещи:

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

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

Три разумных масштаба первой версии

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

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

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

Как не растянуть MVP

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

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

Частые ошибки

• Считать срок только разработки. Тогда в календаре не остаётся места на разговоры, данные, тестирование и первые исправления.
• Сначала делать универсально. Универсальность почти всегда требует больше ролей и исключений, чем кажется в начале.
• Называть MVP сырой версией. В первой версии можно убрать лишнее, но нельзя просить пользователя терпеть критические ошибки и непонятный путь.
• Не назначать критерий успеха. Тогда после запуска невозможно отличить полезный сигнал от просто активной команды.

Короткий чек-лист перед оценкой

• Описан один пользователь и один завершённый сценарий.
• Понятно, какие данные и доступы нужны в первый день.
• Отделены обязательные элементы от желательных.
• Названо, как будет выглядеть первый реальный результат.
• Есть время на работу с первыми пользователями после запуска.

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

Связанные вопросы

• Чем прототип отличается от MVP?
• Сколько пользователей нужно для первого пилота?
• Нужна ли интеграция с CRM уже в первой версии?
• Когда MVP пора превращать в полноценный продукт?

Как выглядит здоровый календарь MVP

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

Такой порядок кажется медленнее, чем «сразу отдать в разработку». На практике он экономит время. Ошибка в понимании задачи, найденная на схеме, стоит разговора. Та же ошибка, найденная после интеграции и обучения сотрудников, стоит недель переделок и потерянного доверия.

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

Когда срок растёт по правильной причине

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

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