Разработка MVP в Москве

Прототипом проверяют интерфейс: по нему кликают, но за ним ничего нет. MVP работает по-настоящему — принимает пользователей, данные и оплату. Прототип отвечает на вопрос «понятно ли», MVP — на вопрос «нужно ли и платят ли».

Смету задаёт объём оставленного сценария, а не слово MVP: число ролей, наличие оплаты, число интеграций, нужна ли мобильная версия отдельным приложением. Самый надёжный способ снизить смету — сократить сценарий, а не качество. Опишите гипотезу — предложим срез объёма и расчёт по нему.

Срок задаёт срез. Если проверка требует трёх ролей, биллинга и интеграции с учётной системой, это уже не минимальный продукт, и честнее назвать его первой версией. Мы предлагаем срез, на котором срок остаётся коротким, и открыто говорим, что из ценного в него не попало.

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

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

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

Это результат, ради которого MVP и делают. Он экономит бюджет полноценной разработки. Дальше есть варианты: сменить сегмент, сменить сценарий или остановиться. Данные и код остаются у вас и годятся для следующей попытки.

Если аналоги работают и вопрос только в исполнении, минимальная версия теряет смысл — тогда речь о полноценной разработке онлайн-сервиса с планом релизов. MVP оправдан там, где есть неопределённость, которую нельзя снять анализом.

Для MVP работает связка: фиксируется гипотеза и срез объёма, а внутри идут короткие итерации с показом результата. Полностью фиксированный объём на неопределённости приводит к тому, что команда защищает смету вместо продукта.

Собирается план развития по данным: что подтвердилось, где пользователи выходят, какие ограничения упрутся в рост. Дальше продукт развивается версиями, а не одной большой переделкой.

С формулировки того, что именно проверяется. Не «сделать сервис», а «убедиться, что люди готовы платить за такое решение такой задачи». От этой формулировки зависит объём: всё, что не помогает получить ответ, из первой версии выбрасывается. Мы просим сформулировать проверяемое утверждение и признак, по которому вы признаете его подтверждённым или нет, — до начала разработки, а не после запуска.

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

На первой версии часто да — и это хороший способ сэкономить недели. Операции, которые пока делаются десять раз в день, может выполнять человек напрямую в данных или через простую таблицу. Административная часть строится тогда, когда объём делает ручную работу дороже разработки. Это сознательное решение с понятным сроком жизни, а не недоделка, и его стоит записать, чтобы позже не удивляться.

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

Сбор событий закладывается вместе с разработкой: сколько человек дошло до первого полезного результата, где обрывается путь, сколько вернулось, сколько заплатило. Общее число регистраций почти ничего не говорит. Эти величины и признак успеха согласуются до запуска — иначе после него начинается подгонка интерпретации под то, что получилось, и решение принимается по настроению.

Частично — и это нормально, если решено заранее, что именно временное. Мы разделяем слои: данные и бизнес-логика делаются аккуратно, потому что их дороже всего переделывать, а интерфейс и вспомогательные части могут быть простыми. Ручные операции и упрощения записываются отдельным перечнем с оценкой замены. Переписывание вслепую возникает там, где «временно» не было зафиксировано и расползлось по всему коду.

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

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

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

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

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

Целью. Обычный проект отвечает на вопрос «как сделать то, что описано», а здесь вопрос «что именно стоит делать». Отсюда другая работа: меньше согласования деталей оформления, больше обсуждения того, что выкинуть; короткие итерации с работающим результатом; готовность переделать направление по данным. Если продукт уже определён и рынок понятен, такой формат избыточен — тогда честнее вести обычный проект.