MVP в разработке: что это и как запустить первую версию продукта без лишних трат

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

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

MVP (от английского minimum viable product, «минимально жизнеспособный продукт») — это первая рабочая версия продукта, в которой есть только то, без чего он не решает главную задачу клиента. Её быстро запускают на реальных людях и смотрят, нужен ли продукт вообще и в каком виде.

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

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

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

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

В названии MVP два важных слова:

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

Термин появился в начале 2000-х, а популярным его сделал Эрик Рис в книге «Бизнес с нуля». С тех пор так называют любую первую версию, которую выпускают ради проверки, а не ради полного набора функций.

Эти слова часто путают. Разница в том, кто пользуется продуктом и что он проверяет.

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

И ещё одно важное отличие. MVP не равно «сырая версия, сделанная на коленке». Если в первой версии ломается оплата или теряются заявки, тест покажет не «продукт не нужен», а «продукт плохо сделан». Это разные выводы, и путать их дорого.

MVP нужен там, где вы не знаете ответа на главный вопрос: будут ли этим пользоваться. Обычно это:

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

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

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

Первая версия не обязана быть программой. Иногда её вообще почти нет.

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

Dropbox до запуска показал короткое видео о том, как будет работать синхронизация файлов. Число желающих попробовать выросло за ночь с 5 до 75 тысяч. Продукта ещё не было, а спрос уже был виден.

В обычном бизнесе логика та же. Допустим, магазин запчастей хочет сделать сервис подбора деталей по VIN-номеру автомобиля. Первая версия: форма, куда человек вводит номер и телефон, а подбор делает менеджер по своей базе. Если заявок много и люди возвращаются, автоматизация окупится. Если нет, вы потеряли пару недель, а не год.

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

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

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

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

Про документы стоит сказать отдельно. По закону 152-ФЗ с 1 сентября 2025 года согласие на обработку персональных данных оформляют отдельным документом, а не строчкой внутри оферты или политики. Первая версия собирает те же телефоны и имена, что и полная, поэтому требования те же. Что должно быть на сайте, мы разбирали в статье про политику конфиденциальности.

Отдельный вопрос — код. Тут есть два честных подхода. Первый: делать первую версию на нормальном фундаменте, чтобы потом достраивать, а не переписывать. Второй: сознательно сделать «одноразовую» версию для быстрой проверки и потом написать продукт заново.

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

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

Сильнее всего на сроки и стоимость влияют:

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

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

Как выглядит продукт, который уже вырос, видно по IT-платформе центра йоги «Прана». Расписание там подтягивается из 1С каждые 10 минут, мероприятия оплачиваются через ЮKassa, есть личные кабинеты и роли, 71 направление и 172 преподавателя. Каждая из этих частей — отдельный кусок работы.

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

Запуск MVP — начало проверки, а не финиш. Дальше нужно собрать цифры и поговорить с людьми.

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

Поговорите с пятью-десятью первыми пользователями. Спросите не «нравится ли вам», а «что вы делали до нас» и «что бы вас расстроило, если бы сервис закрылся». Ответы на такие вопросы часто ценнее любой статистики.

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

Чаще всего на этом этапе ошибаются так:

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

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

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

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