«MVP за месяц» звучит как маркетинг. На практике срок рабочий — но только если понимать, что в него помещается, а что нет. Разбор без обещаний.
Что помещается
За 2–4 недели реально собрать продукт, у которого есть:
- один сквозной сценарий целиком — пользователь пришёл, зарегистрировался, сделал главное действие, получил результат;
- вход — почта или телефон, при необходимости роли;
- основные экраны для этого сценария, адаптивные;
- аналитика — события и воронка, чтобы гипотеза проверялась данными, а не ощущениями;
- одна-две интеграции — оплата, уведомления или CRM;
- деплой в прод — на домене, с сертификатом, с базовым мониторингом.
Этого достаточно, чтобы дать продукт живым людям, показать инвестору и получить фактический ответ, работает идея или нет.
Что не помещается
Честный список того, что не влезает в месяц:
- несколько разных сценариев сразу — «и маркетплейс, и соцсеть, и личный кабинет для трёх типов пользователей»;
- сложные интеграции с legacy — самописная учётная система без документации съест срок сама по себе;
- нативные мобильные приложения в сторах — сама разработка возможна, но модерация живёт по своему календарю;
- высокие нагрузки — архитектуру под рост закладывают, но оптимизация под пиковый трафик делается по реальным данным, а не заранее;
- идеальный дизайн — аккуратный и консистентный да, авторский и вылизанный — нет;
- все краевые случаи — обрабатываются главные, остальные всплывут на первых пользователях. Это нормально для MVP.
Что съедает срок незаметно
Опыт показывает: срок ломают не задачи разработки, а вещи вокруг.
Несформулированная гипотеза. Если на старте нет ответа «что именно проверяем и как поймём, что сработало», скоуп начинает плыть на второй неделе. Это главная причина срыва сроков.
Доступы. Ключи к платёжке, доступ к CRM, права в облаке, домен. Каждый добытый на третьей неделе доступ — минус дни. Собирать надо в первый день.
Согласование на стороне заказчика. Если решения принимают три человека и один в отпуске, календарь встанет независимо от скорости разработки.
Контент. Тексты, фото, описания, юридические документы. Обычно всплывает в последний момент и обнаруживается, что их некому написать.
Расширение по ходу. «Раз уж делаем, давайте ещё вот это». Каждое такое «ещё» стоит срока — и это нормально, если решение принимается осознанно, а не по инерции.
Как повысить шансы уложиться
Ограничьте скоуп до одного сценария. Не «платформа для X», а «пользователь делает Y и получает Z». Всё остальное — во вторую итерацию.
Определите метрику успеха заранее. Что должно произойти, чтобы гипотеза считалась подтверждённой? Без этого MVP превращается в бесконечную стройку.
Соберите доступы в первый день. Списком, все сразу.
Назначьте одного человека с правом решать. Не комитет.
Смотрите демо каждую неделю. Если первое демо через месяц — вы узнаете о расхождении, когда чинить поздно.
Чем MVP отличается от прототипа
Путаница дорого стоит, поэтому зафиксируем:
- Прототип — показать идею. Может быть кликабельным макетом, данные ненастоящие, внутри может быть что угодно. Живёт до первой демонстрации.
- MVP — рабочий продукт с ограниченной функциональностью. Настоящие пользователи, настоящие данные, настоящий код. Живёт дальше и развивается.
Прототип дешевле и быстрее. Если задача — показать концепт на встрече, MVP избыточен. Если нужно проверить, будут ли люди этим пользоваться, прототип бесполезен — он не даёт поведенческих данных.
И главное
MVP — это не «урезанная версия большого продукта», а инструмент проверки гипотезы. Успех — не «сделали в срок», а «получили честный ответ». Иногда ответ отрицательный, и это тоже результат: месяц работы вместо года и бюджета, потраченного на продукт, который никому не нужен.
Пишу из практики студии MKDGRUPP: собираем MVP за 2–4 недели — настоящий код на React/Next.js/Node, аналитика с первого дня, фикс-цена, репозиторий у вас. Оценка и план за час: mkdgrupp.ru/uslugi/mvp.
