Разработка MVP

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

Как мы определяем MVP

MVP не является прототипом. Прототип отвечает на внутренний вопрос «работает ли это технически» и живёт в тестовых условиях. MVP выходит наружу, касается реальных пользователей и в узких границах работает полностью: человек регистрируется, платит, видит экран ошибки. Существует ещё и версия v1, то есть первый релиз с заранее закрытым списком функций и без всякой гипотезы. Версия v1 представляет собой законную работу, но её сроки, цена и риски отличаются от MVP, поэтому на первой встрече мы говорим, к какому из двух вариантов относится ваш запрос. Есть и работа, за которую мы не берёмся: проекты без определения успеха, запросы вида «давайте сначала выпустим, а потом посмотрим», и измерения, по которым никто не станет принимать решение. Историю понятия, виды MVP и нынешнее состояние практики мы разобрали в руководстве по разработке MVP.

Как мы строим MVP

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

Отсечение объёма: решить, что делаться не будет

Отсечение объёма не сводится к удалению функций. Оно состоит в том, чтобы связать каждую функцию с одним вопросом: какое предположение она проверяет? Функция без ответа не выбрасывается, а попадает в список «после MVP», и этот список передаётся вам в конце проекта. Нагляднее всего такое решение видно в проекте BiTalih: командам нужно было выпускать контент для социальных сетей, и инструмента дизайна они сознательно не получили. Были заданы неизменяемые шаблоны, а пользователю оставили право менять только переменные поля, такие как место, время и сумма. Это было решением, а не пробелом: целостность оформления сохранилась, и выпуск контента сократился с часов до минут.

Проектирование проверки: какой вопрос и какое измерение

До первой строки кода записываются три строки: проверяемое предположение, метрика, которая его измерит, и порог, начиная с которого ответ считается положительным. Если порог не задан заранее, любой исход потом удаётся истолковать в свою пользу, поэтому метрика остаётся двоичной: порог взят или не взят. В том же документе фиксируется, на ком проводится измерение и как до этих пользователей дойти, ведь MVP без трафика производит догадки вместо измерений. Сбор событий включается вместе с первым релизом, потому что аналитика, добавленная позже, не вернёт данные первых недель.

Постоянный контакт и прозрачность через pre-prod

Мы поддерживаем с клиентом постоянный контакт на протяжении всего проекта; прогресс сообщается практически каждый день, когда это возможно. В начале проекта мы разворачиваем тестовое окружение, которое почти неотличимо от рабочей системы, но ещё не открыто реальным пользователям; мы называем его pre-prod, и изменения там обычно можно наблюдать почти в реальном времени. Доказательством прогресса служит не снимок экрана, а работающая программа по настоящему адресу, и возможным это делает конвейер выкладки, поднятый с самого начала. В проектах Lextum AI, Biletico, Anneekspres и World Summer Schools автоматизация CI/CD была построена на Jenkins. Выкладка обязана перестать быть событием, иначе такую прозрачность не удержать.

Чем демонстрация инвестору отличается от проверки на пользователях

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

Переход от MVP к эксплуатации и решение о техническом долге

Не всякий технический долг возвращается; определяется очерёдность. В конце MVP мы обычно передаём письменную оценку, разделяющую то, что обязано измениться до роста, и то, что может долго жить как есть; это разделение зависит от проекта и не всегда укладывается в одни и те же жёсткие категории. Смысл в том, чтобы решение принималось коммерчески, а не технически. Наглядный пример того, что относится к эксплуатационной части, даёт Lextum AI: система построена на микросервисной архитектуре с асинхронной обработкой через RabbitMQ, а ролевой доступ и полный журнал аудита входят в ту же конструкцию. Высоконагруженное корпоративное применение и делает эти пункты обязательными. Когда трудность создаёт нагрузка, а не спрос, работа выходит за пределы MVP и переходит в масштабирование бэкенда.

Когда MVP оказывается неверным ответом

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

Пакет передачи проекта

По завершении MVP у вас остаются четыре вещи. Код со всей историей, в репозитории на вашей учётной записи, а не в виде архива, так что видно, кто, что и когда менял. Работающая инфраструктура: сервер, база данных и конвейер выкладки поднимаются на учётных записях, открытых на ваше имя, и передача благодаря этому не превращается в отдельный переезд. Данные и измерения: схема базы, записи событий и отчёт, который отвечает на исходный вопрос. И документ передачи: как система поднимается локально, как выкладывается, какие решения были приняты сознательно и что накопилось в списке «после MVP». Все четыре пункта передаются независимо от того, продолжаете ли вы проект с нами.

Как удерживаются бюджет и объём

Бюджет удерживает не фиксация цифры, а письменная фиксация объёма. Срок оценивается заранее, а поскольку прогресс остаётся видимым через pre-prod окружение, дата не превращается в сюрприз; гибким остаётся объём. Каждый новый запрос, пришедший в ходе проекта, оценивается одним вопросом: если это войдёт, что выйдет, или откроется отдельная строка? Решение принимаете вы, обмен фиксируется письменно, и в конце проекта не возникает спора о том, где и почему объём вырос. Право остановиться остаётся за вами в любой момент, а поскольку всё созданное к этому моменту уже ваше, остановка становится решением, а не потерей. Расходы третьих сторон, то есть комиссия платёжного провайдера, счёт за облако и сборы магазинов приложений, выписываются отдельной строкой с самого начала и оплачиваются с ваших счетов, а не прячутся внутри стоимости разработки.

Рамки измерения

Мы измеряем завершение основного потока: смог ли пользователь выполнить действие, ради которого продукт существует, за сколько шагов, где отвалился, вернулся ли. В продукте, который берёт деньги, шаг оплаты отслеживается отдельно, потому что разрыв между намерением и оплатой представляет собой самое дорогое знание. Есть и то, что мы намеренно не измеряем: просмотры страниц, число регистраций само по себе, средние показатели вовлечённости по времени и оценки удовлетворённости на малых выборках. Продукт способен провалиться, пока всё перечисленное растёт, поэтому решение на этих числах не строится. Наша собственная скорость тоже не является метрикой успеха: то, сколько пунктов мы закрыли, относится к внутреннему учёту. Окно измерения и нужный размер выборки зависят от проекта; если данных пока недостаточно для вывода, мы говорим об этом прямо, а не выдаём результат за более определённый, чем он есть.

Наши критерии выбора технологии

MVP плохо подходит для изучения новой технологии, поэтому выбор делается из узкого набора: инструменты, которые мы уже держим в эксплуатации и которые сможет вести кто-то другой после передачи. Когда преобладают сложность операций, ролевая структура и корпоративные интеграции, бэкенд получается на .NET, как в Lextum AI, World Summer Schools и Welldone. Когда основная тяжесть лежит в модели данных и административных экранах, быстрее приводят к результату Python и Django: маркетплейс Anneekspres построен именно так. Интерфейс несёт React и Next.js, а для единой кодовой базы, которая должна дойти до полевых сотрудников и на iOS, и на Android, мы обращаемся к Flutter или React Native. Выбор определяют три признака: кто будет обслуживать систему после передачи, находятся ли на рынке люди с этой технологией и может ли хостинг остаться на ваших учётных записях.

Как это выглядит на практике

Перечисленные ниже работы либо запущены, либо завершены. У каждого проекта есть своя страница в разделе историй успеха.

• Lextum AI: подготовка документов, разбор договоров, совместное редактирование и версионирование для юридических команд. Выведено в эксплуатацию на микросервисной архитектуре с RabbitMQ, ролевым доступом и журналом аудита.
• Biletico: платформа с готовым основанием, где почти ничего не работало, была принята в работу; оплата, поиск, профиль и управление билетами заработали, добавился план рассадки на канвасе.
• World Summer Schools: сотни программ летних школ собраны в один каталог с поиском, ввод контента ускорен интеграцией с OpenAI, настроен ролевой доступ.
• Anneekspres: маркетплейс товаров для матери и ребёнка построен с нуля: панель продавца, оплата и поток заказов, инфраструктура на PostgreSQL и RabbitMQ.
• BiTalih: платформа выпуска контента на неизменяемых шаблонах и переменных полях; вместе с ролевым доступом выпуск контента сократился с часов до минут.
• Welldone: мобильное приложение на Flutter, панель управления на React и сервисы на .NET для промышленной прачечной, с упаковкой по QR-коду в цеху и отчётностью в реальном времени для руководителей.
• Terazzi: работа над существующей платформой: улучшения дизайна и клиентской панели, видимость в поиске и производительность бэкенда.