Как мы разрабатываем MVP: процесс по шагам

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

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

Почему первая версия должна быть короткой (и когда это не так)

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

Если окно слишком короткое, получается прототип, а не MVP. Если слишком длинное, получается небольшой продукт со всеми его рисками. Короткая первая версия держит дисциплину объёма: в неё попадает только то, что проверяет идею.

Такой формат работает, когда:

• основной сценарий пользователя это один-три экрана или шага;
• интеграций одна-две (например, Kaspi, 1С или платёжная страница банка);
• дизайн функциональный, а не выставочный;
• команда уже делала похожие проекты.

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

Процесс по шагам

Шаг 1. Объём на бумаге и техническая основа

Первый шаг не про код. Он про то, чтобы все одинаково понимали, что будет сделано, а что нет.

Это значит письменное техническое задание (не слайды), описанный путь пользователя и выбранный стек. Любая неясность здесь потом обходится вдвое дороже. Бывает, клиент говорит «система записи», а разработчик слышит совсем другое. ТЗ с прототипами экранов закрывает этот разрыв.

К концу шага:

• объём зафиксирован письменно и стал приложением к договору;
• стек выбран;
• среда разработки и сервер подготовлены;
• назначен первый показ.

Шаг 2. Основной сценарий

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

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

Шаг 3. Интеграции и крайние случаи

Здесь основа подключается к внешнему миру: оплата через банк или Kaspi, вход по номеру телефона, обмен с 1С, CRM или ИС ЭСФ, сторонние API. Здесь же закрываются крайние случаи, которые остались после второго шага: ошибки, пустые экраны, проверка ввода.

Тестирование начинается параллельно с разработкой, а не после неё. Отложить тесты на конец это верный способ сорвать срок.

Шаг 4. Доводка, тестирование и передача

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

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

Шаг 5. Запуск и гарантия

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

Что реально помещается в первую версию

Колонка «что входит» важна не меньше срока. Короткий MVP значит конкретный объём, а не сжатую версию продукта, который обычно строят полгода.

Сколько стоит MVP: как считают цену на рынке

Цена сильно зависит от того, с кем вы работаете.

Что стоит знать об этих форматах:

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

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

Расходы после запуска. Хостинг, домен, аккаунты разработчика в App Store и Google Play оплачиваются клиентом напрямую, на его компанию. Нормальная студия не прячет их в стоимость проекта и не делает на них наценку.

Как мы ведём MVP в Pazl

Мы работаем по фиксированной цене. Цена и срок попадают в договор после того, как утверждено ТЗ, а не до. Это защищает обе стороны: клиент знает, сколько платит, а мы знаем, что строим.

Наш порядок:

1. Звонок-знакомство. Разбираемся в идее продукта, в главном предположении, которое нужно проверить, и в ограничениях: есть ли уже код, какие нужны интеграции, на какой платформе продукт.
2. Предложение. Объём письменно, цена и срок.
3. Договор и ТЗ. Договор с вашим ТОО или ИП, цена в тенге. ТЗ это приложение к договору; всё, что вне его, оформляем отдельным соглашением с ценой до начала работы.
4. Разработка короткими итерациями. После каждой итерации вы видите работающую версию и даёте обратную связь до начала следующей.
5. Передача. Исходный код, документация по развёртыванию, доступы и гарантия 6 месяцев на всё, что мы сделали.

Гарантия важна. Если в течение шести месяцев после запуска что-то ломается из-за нашего кода, исправляем бесплатно. Сервер, продление домена и платные сторонние сервисы клиент оплачивает напрямую, мы не делаем на них наценку.

Веб-приложение или MVP у нас стоит от 1 000 000 ₸, мобильное приложение от 1 000 000 ₸. Более сложные проекты (платформы с несколькими ролями, мобильные приложения со своим сервером, ИИ-интеграции) оцениваем после разбора требований, не раньше. Что входит в стартовый объём, смотрите на странице цены на MVP, а мобильный вариант на странице разработки мобильных приложений.

Пример из нашей практики. Для агентства мероприятий мы сделали ИИ-агента, который ведёт повседневную переписку с клиентами: понимает текст, голос, фото и видео, ставит задачи в Trello и зовёт менеджера, когда нужен человек. Такой проект, рабочий ИИ-агент со связкой с системой задач, хорошо ложится в короткий цикл, если объём описан плотно.

Мы также делали ERP для логистической компании (автопарк, документы, финансы и операции в одной системе) и приложение лояльности для розничной сети со связкой с кассами и 1С. Общее у всех: описанный объём, регулярные показы и передача, с которой клиент реально может работать.

Почему короткие MVP срываются

Объём, добавленный посреди итерации. Каждая новая просьба во время разработки либо сдвигает срок, либо вытесняет что-то запланированное. ТЗ делает это видимым: «да, добавим, вот что это заменит или вот сколько это стоит».

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

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

Отложенные решения по дизайну. Если навигацию и путь пользователя решать в середине работы, придётся переделывать уже сделанное. Решения по дизайну принимаются на первом шаге.

MVP как финальный продукт. MVP это проверка, а не большой запуск. Цель узнать что-то о рынке, а не построить всё, что когда-нибудь понадобится продукту. Команды, которые относятся к первой версии как к финальному релизу, раздувают объём и недодают результат.

Данные и закон: что учесть в Казахстане

Если MVP собирает персональные данные (имя, телефон, e-mail), закон о персональных данных действует с первого пользователя, а не с какого-то порога. Данные хранятся в базе на территории Казахстана (Закон РК от 21.05.2013 № 94-V «О персональных данных и их защите», ст. 12 п. 2, текст на adilet.zan.kz). Нужны согласие пользователя, которое можно подтвердить, политика обработки и порядок отзыва согласия. Подробно разобрали в гайде персональные данные на сайте.

Если часть данных уходит в зарубежные сервисы (почта, аналитика, ИИ), это трансграничная передача, и её нужно указать в согласии. Это не повод откладывать запуск, но повод заложить правильную работу с данными в ТЗ с самого начала, а не переделывать потом.

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

Как проверить студию до подписания

Несколько вопросов, которые стоит задать любому исполнителю до договора на MVP по фиксированной цене:

• Можно посмотреть ТЗ из прошлого проекта? Студия, которая не может показать, как выглядит её ТЗ, скорее всего, их не пишет.
• Кому принадлежит код в конце? Правильный ответ: вам. Код передаётся вам, а не остаётся навсегда на инфраструктуре исполнителя.
• Что если после запуска что-то сломается? Гарантийный срок с понятными условиями это норма. «Посмотрим» это не гарантия.
• Как оформляются просьбы вне объёма? Письменно, с ценой и влиянием на срок. Устные договорённости о «маленьких доработках» и есть то, как проекты выходят за бюджет.
• Есть ли примеры похожих проектов? Не кейсы с туманными результатами, а продукты, которые можно открыть и потрогать.

Итог

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

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