Большинство MVP промахиваются мимо даты запуска не потому, что разработчик был медленный. Они промахиваются потому, что объём работ так и не был зафиксирован. Работа расширялась так, как всегда расширяется размытая работа — по фиче за разговор, по интеграции за встречу, по «заодно сделаем» в неделю.
Это процесс описания MVP, который я использую с клиентами, чтобы выйти за 12 недель или меньше. Ничего особенного. Письменный, скучный, рабочий.
Единственное правило, от которого всё зависит
Всё, что вы хотите в MVP, помещается на одну страницу текста до того, как написана первая строка кода. Если не помещается — у вас не MVP, а продукт.
Это не красивая формулировка. Это ограничение. Десять фич помещаются на страницу. Пятнадцать — нет. Упражнение по сокращению до десяти и есть то место, где принимаются самые важные решения.
Одностраничный бриф — что в нём
Пять разделов. Именно в таком порядке.
1. Одно предложение.
«Платформа, где [кто] может [делать что] чтобы [какой результат получить]».
Заполните три пропуска — и остальной бриф сложится сам собой. Не можете заполнить — продукт ещё недостаточно ясный. Потратьте неделю на это предложение, прежде чем тратить что-то ещё.
2. Три пользовательских сценария. Не больше.
Выберите три сценария, без которых продукт бесполезен. Всё остальное — вторая фаза.
Примеры из реальной платформы продажи билетов:
- Организатор создаёт событие и назначает цены
- Покупатель выбирает место, оплачивает
- Организатор сканирует билеты на входе
Три сценария. Это MVP. Восстановление пароля, возвраты, инвойсинг, права для нескольких организаторов — всё важное, всё во вторую фазу.
3. Единственная метрика успеха.
Одно число. Не три. Не дашборд.
«Мы поймём, что получилось, если в первые 90 дней будут 50 платных мероприятий».
Ценность единственной метрики не в измерении — она в принятии решений по ходу разработки. Каждый компромисс («добавить X?») меряется против этого одного числа. Если X не двигает метрику — X не делаем.
4. Интеграции, которые должны работать в день 1.
Stripe. Resend. Supabase. Sentry. Какой бы ни был ваш список.
Дисциплина здесь: каждая интеграция в списке стоит 3–8 дней реальной работы, включая пограничные случаи, вебхуки и производственные сбои, о которых никто не предупреждает (я писал про шесть таких для Stripe). «Маленьких» интеграций не существует. Каждая строчка в списке интеграций двигает запуск на неделю.
5. Дедлайн и причина.
«Запуск до 15 сентября, потому что демо на конференции X». «Запуск до 1 октября, потому что закрывается раунд и мы хотим показать траекцию».
Причина важна. Если у дедлайна нет причины — это пожелание, а пожелания сдвигаются. Если причина реальная (конференция, раунд, сезон) — дедлайн настоящий, и объём работ урезается под него.
Одна страница. Пишется за вечер. Если нужно два вечера — нормально, но не стартуйте разработку, пока её нет.
Сокращения объёма, которые больно, но работают
Основатели приходят с десятью «обязательными» фичами. Работа разработчика — найти те пять, что важны, и вежливо вырезать остальное. Какие-то сокращения основатели потом жалеют, большинство — нет. Вот те, что надёжно не болят:
- Роли и права больше 1–2 уровней. Отгружайте с «владельцем» и «пользователем». Админов — во вторую фазу.
- Красивые шаблоны писем. Отгружайте plain-text транзакционные письма. Дизайн — во вторую фазу.
- Сценарии онбординга и туториалы. Отгружайте с 3-шаговой регистрацией. Подсказки в стиле Intercom — когда поймёте, где люди спотыкаются.
- Админские дашборды. Отгружайте с прямым доступом к базе для вас. Нормальную админку — во вторую фазу.
- Аналитика сверх ключевой метрики. Базовая настройка PostHog — 20 минут. Кастомный дашборд аналитики — две недели. Отгружайте базовый.
- Мобильное приложение. Отгружайте адаптивный веб. Нативная оболочка — когда у вас будет 1K пользователей, не раньше.
- Многоязычность. Если рынок не требует нескольких языков (мои E7-проекты трёхъязычные, потому что иначе нельзя), отгружайте на одном.
Сокращения, которые основатели не хотят принимать, но не стоит спорить:
- Кастомная дизайн-система. Tailwind + shadcn/ui дают 80% полировки за 5% работы. Дизайн-систему можно делать, когда ваш бренд уже бренд.
- Multi-tenancy сверх того, что Stripe даёт бесплатно. Настоящая multi-tenant архитектура — это 4 недели инфраструктурной работы. Большинству MVP это не нужно.
Артефакты, которые удерживают объём после старта
Бриф есть. Теперь: как не допустить, чтобы он расползся на третьей неделе незаметно?
Артефакт 1: письменный запрос на изменение, по каждому изменению.
Любая фича не из исходного брифа идёт через документ на 5 строк: что, зачем, какую веху заменяет или сдвигает, новая цена если есть, подписано обеими сторонами. Пять строк. Не роман. Но письменно.
Большинство ползучести объёма случается, когда основатель говорит «а ещё давайте…» на Zoom-созвоне, а разработчик кивает. Ничего не подписано, ничего не оценено, и к седьмой неделе «а ещё» больше, чем исходный MVP.
Артефакт 2: демо каждую пятницу. Не обсуждается.
Каждую пятницу есть staging-ссылка, которую можно открыть. Поклацать, попробовать, найти сломанное, поговорить, что отгружаем на следующей неделе.
Это делает две вещи:
- Заставляет работу быть отгружаемой каждую неделю — а не когда-нибудь-завершённой одним большим выбросом.
- Даёт основателю момент, чтобы увидеть реальное vs воображаемое. Ничто не лечит ползучесть фич так, как использование собственного продукта.
Артефакт 3: счета по вехам, привязанные к демонстрируемой работе.
Каждая двухнедельная веха заканчивается демо и счётом. Не платите — если демо нет. Разработчик не работает вперёд — если демо не утверждено. У обеих сторон есть кожа в игре.
Структура на 12 недель, которая обычно работает
Грубый шаблон, подстраивается под проект:
Недели 1–2: Фундамент. Репозиторий, CI, вход и регистрация, заглушка Stripe, структура базы, staging-деплои. Вы кликаете по каркасу. Ничего «фичевого» ещё нет, но все рельсы проложены.
Недели 3–4: Сценарий 1 (самый важный) — сквозной. Страшный, но рабочий. Можно пользоваться на staging.
Недели 5–6: Сценарий 2 — сквозной. Сценарий 1 полируется.
Недели 7–8: Сценарий 3 — сквозной. Интеграции (Stripe-вебхуки, Resend, что угодно) — укрепляются.
Недели 9–10: Полировка. Тексты. Состояния ошибок. Состояния загрузки. Всё, что превращает прототип в продукт. Базовый SEO. Проход по Lighthouse.
Недели 11–12: Продакшн-деплои, Sentry, чек-лист запуска, контент, последний проход по багам. Мягкий запуск.
Форма гнётся. Если ваш сценарий 1 сложный (Stripe Connect с разделением платежей, кастомный календарь) — он съест больше недель, и что-то другое сокращается. Но форма — фундамент → сценарии → полировка → запуск — стабильна.
Что реально срывает 12-недельные планы
По частоте из моих собственных проектов и того, что слышал от коллег:
- Поздний дизайн. Дизайн, приходящий на 5-й неделе вместо 1-й, убивает первые два спринта продуктивности. Получите Figma (или аналог) до старта разработки. Хотя бы черновой.
- «Ещё одна фича» на 9-й неделе. Классика. Объём урезан, разработка идёт по плану, запуск уже виден, основатель загорается: «давайте ещё X». Каждая фича, добавленная в последней трети проекта, стоит в 2–3 раза дороже, чем в первый месяц. Говорите нет.
- Задержка согласований со стороны основателя. Вы отправили демо в пятницу. Обратная связь пришла в четверг. Это 6 дней неявного утверждения, которые губят половину следующего спринта. Основатель должен реагировать в течение 48 часов, иначе ритм ломается. Пропишите это в договоре.
- Сюрпризы с интеграциями от третьих лиц. Stripe не прошёл KYC. Apple 11 дней ревьюит. Google отключил ваш OAuth-приложение. Такое бывает. Заложите 2-недельный буфер в 12 недель и предполагайте, что как минимум одно из этого случится.
- «Надо бы переписать вход по-нормальному» посреди проекта. Не надо. Отгрузите скучный вход. Переписывайте, когда будут платящие пользователи.
Пункты договора, которые защищают объём
Если вы пишете (или подписываете) договор с фиксированной ценой на 12-недельный проект, эти пункты спасают:
- Бриф — это техзадание. «Бриф от [дата], приложенный как Приложение A, — полный объём работ. Всё, чего в брифе нет, — запрос на изменение».
- Запросы на изменение — письменные. «Изменения объёма требуют письменного запроса на изменение, подписанного обеими сторонами, с указанием изменения цены и сроков».
- Ритм согласований демо. «Результаты этапов рассматриваются в течение 48 часов с момента сдачи. Отсутствие реакции в течение 5 рабочих дней — неявное утверждение».
- Чистый выход. «В случае расторжения любой из сторон весь код, сданный к этому моменту, принадлежит клиенту, а разработчику оплачиваются только завершённые вехи».
Ни один из этих пунктов не враждебный. Это пункты, которые позволяют обеим сторонам расслабиться и сосредоточиться на отгрузке.
Самое короткое правило описания MVP, которое я знаю
Если вы не можете описать свой MVP тремя пользовательскими сценариями, одной метрикой успеха и пятью интеграциями — это ещё не MVP. Это мечта. Работа до разработки — это превращение мечты в бриф.
Большинство основателей сопротивляются этой работе. Провести вечер за написанием брифа кажется менее продуктивным, чем скорее посадить кого-то писать код. Это не так. Вечер на бриф стоит 3 недель сэкономленной разработки. Каждый проект, который я сдал вовремя, имел бриф до первого коммита. Каждый сдвинутый — не имел.
Я предлагаю фиксированный discovery-этап (1 неделя, €2.5K), где мы вместе пишем этот бриф. На выходе — одна страница, документ с объёмом работ, фиксированная цена на разработку. Если разработка не начнётся — бриф остаётся у вас, с ним можно идти к кому угодно. Записаться на discovery-созвон.