От идеи до MVP за 2 недели: реалистичный процесс для маленькой команды
2 недели на MVP звучит нереалистично, пока не понимаешь, что большая часть провалов на этом сроке - не техническая, а из-за размытого брифа и попытки сделать сразу всё. Разбираю процесс, который реально укладывается в срок.
MVP за 2 недели реалистичен при трёх условиях: бриф зафиксирован письменно и не меняется на середине разработки, стек выбирается по принципу «что быстрее», а не «что интереснее», а первая версия закрывает одну ключевую гипотезу, а не весь продукт целиком. Типичный процесс: 1-2 дня на бриф и границы, 7-8 дней на разработку основного сценария, 2-3 дня на деплой и проверку, остаток - запас на непредвиденное. Без запаса срок почти никогда не выдерживается.
Провал случается раньше первой строчки кода
Когда MVP не укладывается в срок, причина реже в технической сложности и чаще - в том, что бриф не был зафиксирован до старта разработки. «Сделаем и решим по ходу» на короткой дистанции работает хуже всего: каждое доразмышление в процессе съедает время, которого и так мало. Первое условие уложиться в 2 недели - письменный бриф с чёткой границей: что входит в первую версию, а что осознанно откладывается на потом.
Процесс по дням
Дни 1-2: бриф и границы
Фиксируется одна ключевая гипотеза, которую должен проверить MVP, и явный список того, что НЕ входит в первую версию. Без письменной границы разработка расползается.
Дни 3-10: разработка
Основной сценарий пользователя от начала до конца - без второстепенных экранов и настроек, которые не влияют на проверку гипотезы.
Дни 11-13: деплой и проверка
Выкладка на реальный домен, ручная проверка основного сценария целиком, а не по частям - именно на стыках чаще всего находятся баги.
День 14: запас
Не план Б на случай катастрофы, а норма - что-нибудь на 14-дневном сроке идёт не по плану почти всегда, и без буфера это автоматически срывает дедлайн.
Выбор стека - по скорости, не по интересу
На двухнедельном сроке выбор технологии ради «хочу попробовать новое» - главный скрытый риск. Стек нужно выбирать по тому, с чем команда уже работала быстро и без сюрпризов, даже если он не самый модный. Изучение нового инструмента на короткой дистанции почти гарантированно съедает буферный день, а часто и больше - и именно в этот момент MVP перестаёт укладываться в срок.
MVP или полноценная разработка
Таблица прокручивается вбок на телефоне →
Параметр
MVP за 2 недели
Полноценная разработка
Цель
Проверить одну гипотезу
Закрыть продукт целиком
Функциональность
Один основной сценарий
Все сценарии и края
Технический долг
Осознанно допускается
Минимизируется с самого начала
Что после запуска
Либо доработка на основе реальных данных, либо остановка проекта
Поддержка и развитие по roadmap
Чек-лист перед стартом
Сохраните себе
Зафиксируйте бриф письменно - в том числе явный список того, что НЕ входит в первую версию.
Выбирайте стек по тому, что команда уже знает быстро, а не по тому, что хочется попробовать.
Заложите день на непредвиденное - без буфера двухнедельный срок почти никогда не выдерживается.
Проверяйте основной сценарий целиком после деплоя, а не по частям в процессе разработки.
Договоритесь заранее, что произойдёт с продуктом после проверки гипотезы - доработка или остановка.
Частые вопросы
Реально ли сделать MVP за 2 недели без опытной команды?
Сложнее, но реалистично при узком брифе - чем меньше опыта у команды, тем важнее максимально сузить объём первой версии.
Что делать, если бриф MVP начинает расти в процессе разработки?
Фиксировать новые идеи отдельным списком «после MVP», а не добавлять их в текущий срок.
Нужно ли закладывать в MVP хорошую архитектуру на будущее?
Не в ущерб сроку - осознанный технический долг нормален для MVP, если не мешает основному сценарию.