MVP за две недели: что вырезать, чтобы успеть

MVP за две недели получается только одним способом: вы делаете один сценарий для одного типа пользователя и всё остальное делаете руками. Технически невозможного тут мало, невозможен объём — четырнадцать дней вмещают примерно пять-семь экранов с логикой. Ниже порядок, по которому режут, и список того, что резать нельзя.

Сначала назовите одно действие

Возьмите лист и напишите одно предложение: что человек делает в вашем сервисе и что получает взамен. Не список возможностей, а одно действие.

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

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

Правило первое. Один тип пользователя

Каждый дополнительный тип пользователя — это отдельный набор экранов, отдельные права и отдельная логика. Двусторонняя площадка удваивает работу, а не добавляет к ней четверть.

Что делать: оставьте того, кто платит или приносит основную ценность. Вторая сторона на старте живёт в переписке с вами. В платформе Papa BU рабочая часть — сбор поискового ядра и подготовка объявлений — тоже начиналась с узкой задачи, а не со всех возможностей сразу.

Правило второе. Ручное вместо автоматического

Это главный рычаг сокращения срока. Почти любую автоматизацию на старте заменяет человек, и пользователь этого не замечает.

Модерацию, рассылку писем, выставление счетов, назначение исполнителя, проверку документов — всё это первые недели делает администратор из простой админки. Автоматизируется то, что реально повторяется каждый день и отнимает часы.

Что делать: пройдите список функций и напротив каждой напишите, сколько раз в день она выполняется при десяти пользователях. Всё, что реже двух раз в день, отправляется в ручной режим.

Побочная польза от такого подхода — вы узнаёте, как процесс работает на самом деле. Автоматизировать то, что месяц делали руками, вдвое дешевле: понятны исключения, из-за которых логика обычно и переписывается.

Правило третье. Один способ оплаты и один сценарий отмены

Оплата — обязательная часть, если сервис платный, но она не обязана быть богатой. Одна карта, один тариф, одна кнопка. Без промокодов, партнёрских программ, рассрочек и трёх валют.

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

Что делать: оставьте один тариф с одной ценой. Тарифная сетка появляется тогда, когда есть, кого по ней делить.

Правило четвёртое. Уведомления в один канал

Почта, СМС, пуши и мессенджер — это четыре разные интеграции. Выберите один канал, где ваша аудитория точно есть.

Чаще всего это телеграм-бот: он подключается быстрее СМС, ничего не стоит за сообщение и заодно даёт простой вход в сервис. Почту добавляют вторым этапом.

Правило пятое. Отчёты не делают в MVP

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

Что делать: две недели смотрите на выгрузку руками. Через месяц станет понятно, какие три числа вы действительно смотрите каждый день — их и выведете на экран.

Правило шестое. Никакого приложения на старте

Мобильное приложение — это отдельная разработка, магазины с проверками и обновления, которые нельзя выкатить за час. Две недели оно не помещается ни при каком объёме.

Что делать: сделайте адаптивную веб-версию, которая нормально работает с телефона. Курьеру, мастеру или менеджеру этого достаточно, а вы сохраняете возможность править интерфейс в тот же день, когда нашли проблему.

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

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

Есть вещи, экономия на которых стоит дороже самой экономии.

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

Второе — роли и изоляция данных. Даже в самой простой версии клиент А не должен видеть данные клиента Б, а сотрудник не должен видеть настройки. Мы закладываем такое разделение в любом проекте: сборщик видит заказы, но не деньги.

Третье — вход и восстановление доступа. Пользователь, потерявший пароль без возможности его вернуть, потерян насовсем.

Четвёртое — чек при онлайн-оплате. Это не функция, а требование, и оно не откладывается.

Как выглядят четырнадцать дней

Примерный порядок такой. Первые два дня — сценарии, экраны, структура данных.

Дни с третьего по девятый — рабочая часть и админка. Дни десятый и одиннадцатый — оплата и уведомления. Двенадцатый — наполнение и тестовые прогоны. Тринадцатый и четырнадцатый — правки после того, как систему потрогали живые люди.

Из этого расписания видно главное: на согласования почти нет времени. Если вы отвечаете на вопросы подрядчика раз в два дня, срок растягивается вдвое, и никакая скорость разработки этого не компенсирует.

Кому MVP за две недели не подходит

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

Не подходит он и там, где цена ошибки высокая: деньги клиентов, медицинские данные, обязательная отчётность. Такие вещи не проверяют на скорую руку.

MVP хорош, когда идея не проверена и нужно понять, будут ли ей пользоваться. У нас платформа стоит от 150 000 ₽ и делается от 14 дней — в две недели помещается именно проверка гипотезы, а не полный продукт.

Коротко

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