Почему 14 дней — это не маркетинг
Когда мы впервые написали «MVP за 14 дней» на главной, нам не поверил никто. Включая нас самих. Но за последний год мы запустили одиннадцать таких MVP — каждый в срок, каждый с актом, каждый с реальными пользователями в первый же день после релиза. Это не магия. Это очень узкая дисциплина, которая началась с одного простого правила: на 14-дневном проекте мы не обсуждаем, что не входит. Мы это написали в контракте до того, как клиент подписал.
День 0 — бриф и техзадание
Первый день — самый дорогой. Не по часам, по тому, что ошибка здесь стоит провала всего проекта. Мы проводим 90-минутный созвон, где клиент рассказывает не про дизайн и фичи, а про бизнес. Какая метрика главная. Какой пользователь нам нужен. Что произойдёт, если мы запустимся вовремя, а конверсия будет 0.5%. После созвона PM пишет техспек на одну страницу A4 — да, одну. Всё, что не помещается на страницу, идёт во вторую фазу проекта, после релиза.
Дни 1 — 3: дизайн ровно тех экранов, которые войдут в релиз
Главная ошибка на MVP — нарисовать всё. Мы рисуем только то, что войдёт в первый коммит. Если есть страница «О нас» в плане — но в техспеке её нет — мы её не рисуем. Если CMS будет в фазе 2 — мы делаем плоский контент в коде. Это не лень, это уважение к бюджету. Дизайн-лид и PM работают вместе с первой минуты, чтобы каждый сценарий имел понятный пользовательский путь без избыточных состояний.
Дни 4 — 11: разработка по двум потокам
Frontend и backend стартуют одновременно с мок-данных. Раз в день — синхронизация на 15 минут. Раз в три дня — деплой на staging для клиента. Никакого «покажем в конце» — клиент видит прогресс на четвёртый день. Если он что-то понимает не так — мы перерисовываем поток на пятый, не на тринадцатый.
- ▍Daily 15-min standup в Telegram-канале клиента
- ▍Staging deploy каждые 72 часа
- ▍Code review до мерджа, всегда
- ▍QA чек-лист в Notion после каждой фичи
Дни 12 — 14: QA, аналитика, релиз
Последние три дня — полностью наши. Клиент уже видел всё. QA-инженер прогоняет smoke-чеклист на 31 пункт. DevOps подключает аналитику и мониторинг. На 14-й день в 18:00 мы делаем deploy в продакшен и отправляем клиенту акт. Если что-то не успели — день 15 уже за наш счёт.
«Запущенный MVP, который уже узнал что-то про пользователя, ценнее красивого, который ждёт финального ревью.»
Что чаще всего ломается
За одиннадцать MVP мы поняли: ломается всегда одно и то же — изменения объёма проекта в середине. Поэтому в контракте есть пункт: на 14-дневном проекте scope заморожен в день 0. Любое изменение оплачивается отдельно после релиза. Без исключений. Это спасает и нас, и клиента — потому что без жёсткого scope-а мы оба теряем дедлайн.