Что такое MVP и как разработать первую версию IT-продукта

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

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

Что такое MVP: разбираем простыми словами

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

В разработке IT-проектов MVP обычно представляет собой первую рабочую версию. Она включает функции, необходимые для решения одной конкретной задачи.

Примеры MVP проектов для разных отраслей

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

Зачем бизнесу разрабатывать MVP

Разработка MVP помогает проверить, оправдает ли продукт дальнейшие вложения. 

Разбираем задачи.

• Окупятся ли вложения? Пилот даёт первые данные для расчёта ROI — рентабельности инвестиций. Например, клиника проверяет, позволяет ли онлайн-запись обслуживать больше пациентов без расширения регистратуры.
• Сколько стоит привлечь клиента? Если ремонтная компания потратила на рекламу 60 000 рублей и получила 20 новых заказчиков, CAC — стоимость привлечения клиента — составит 3 000 рублей. Эту сумму сравнивают с доходом от заказа после вычета затрат на его выполнение.

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

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

Чем MVP отличается от прототипа и PoC

Чтобы проверить идею, не всегда нужно сразу разрабатывать MVP. Иногда достаточно использовать прототип и PoC. 

• Прототип показывает, как будет работать продукт. Часто его собирают из связанных макетов экранов. Пользователь проходит по спроектированному интерфейсу, а команда фиксирует ошибки. При этом система ещё не выполняет реальные операции. 
• PoC — Proof of Concept — проверяет, можно ли реализовать техническое решение. Допустим, разработчики выясняют, получится ли получать данные от оборудования через доступный интерфейс. Удобный пользовательский экран для такой проверки может вообще не понадобиться.
• MVP позволяет наблюдать за использованием решения в реальной работе. Пример: покупатель резервирует товар, магазин обрабатывает заказ. Тогда можно оценить, выполняет ли сервис свою задачу.

Главное отличие: MVP уже даёт пользователю реальный результат и позволяет проверить спрос или пользу продукта; прототип помогает проверить сценарий взаимодействия, а PoC — техническую возможность реализации.

Виды MVP: как выбрать подход

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

Консьерж-MVP

Вы вручную оказываете услугу, которую в будущем должен выполнять продукт. Так можно проверить, нужна ли она клиентам, до разработки.

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

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

«Волшебник страны Оз»

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

Например, покупатель оформляет резерв на сайте магазина. Сотрудник проверяет наличие товара и подтверждает запрос вручную.

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

MVP из готовых сервисов

Минимальную версию продукта можно собрать на базе сервисов, которыми компания уже пользуется.

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

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

MVP с ограниченной функциональностью

Этот вариант подходит, когда проверить идею без собственной разработки трудно.

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

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

Можно ли ограничиться лендингом

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

Как создать MVP: этапы разработки

1. Изучите текущий процесс

• Выясните, какую проблему должен решить продукт и как люди справляются с ней сейчас.
• Проведите интервью в рамках Customer Development. Попросите потенциальных пользователей разобрать недавний опыт: что они хотели сделать и где возникли сложности.
• Используйте Jobs to Be Done, чтобы понять ожидаемый результат. Например, пациенту нужно записаться на удобное время без звонка в клинику. Это поможет определить, что должен обеспечивать сервис.
• При необходимости дополните исследование SWOT-анализом. Он поможет оценить возможности проекта с учётом его ограничений и ситуации на рынке.

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

2. Сформулируйте гипотезу MVP

Определите, что хотите проверить с помощью MVP и какого результата ожидаете.

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

До запуска выберите показатель (в этом случае долю записей без помощи сотрудника). Заранее договоритесь, какой результат оправдает дальнейшую разработку и сколько времени потребуется для проверки.

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

3. Ограничьте первую версию

Составьте основной сценарий и проверьте каждую функцию: что произойдёт, если её убрать?

Чтобы разделить функции по важности, используйте MoSCoW.

Договорённости относятся к конкретной версии: отложенную функцию можно пересмотреть позже.

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

RICE = (охват × влияние × уверенность) / трудозатраты.

Сравнивайте функции по одинаковым правилам: например, оценивайте охват за месяц. В формуле 80% уверенности записывайте как 0,8. Чем выше балл RICE, тем приоритетнее функция.

Обсудите также исключения. Клиент может не знать модель продукта или не суметь приложить документ в сервисе. Решите, как он завершит обращение в таком случае.

4. Проверьте прототип

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

5. Разработайте версию для проверки

Создание MVP выполняется своими силами или с внешней командой. Выбор зависит от сложности продукта и доступных ресурсов.

• Самостоятельно. Если в компании есть разработчики, они могут собрать первую версию. Для простых сценариев подойдут no-code и low-code — платформы, которые позволяют создавать сервисы без кода или с небольшим объёмом программирования. Заранее проверьте, поддерживают ли они нужные интеграции.
• Заказать разработку. Этот вариант подойдёт, если собственной команды нет или ей не хватает опыта для вашей задачи. Мы в Aiston поможем определить техническое решение и реализовать MVP. Особенно это актуально для продуктов со сложной бизнес-логикой и обменом данными с внутренними системами.

6. Настройте аналитику и протестируйте MVP

До запуска определите, какие данные покажут, решает ли продукт задачу бизнеса. Разработчики настроят сбор событий внутри системы: например, успешное бронирование или завершение рабочей операции.

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

7. Запустите пилот в выбранных границах

• Предложите MVP ограниченной группе целевых пользователей. Для сети компаний можно начать с одного филиала.
• Дайте участникам выполнить задачу самостоятельно. Если пришлось помогать, зафиксируйте, на каком шаге возникла сложность.
• Собирайте показатели и короткие отзывы. По окончании пилота сравните результат с критерием, который задали при формулировании гипотезы. Если данных мало, продлите проверку.

Как это происходит на практике: кейс Aiston 

К нам обратились за разработкой Nasvet — мобильного приложения с фокусом на психологию и обучающими материалами по самопознанию. 

Заказчица накопила много контента, но ещё не определила, как организовать его в приложении. Мы помогли определить, как превратить их в сервис, которым человек сможет пользоваться самостоятельно.

1. Применили персоны и JTBD, чтобы связать содержание приложения с задачами аудитории. Сфокусировались на доступе к материалам без дорогой индивидуальной консультации.
2. Собрали прототип и протестировали сценарий входа. В первоначальном варианте пользователь должен был заполнить анкету, прежде чем познакомиться с приложением.
3. Пересмотрели регистрацию: открыли обучение без анкеты, а часть данных перенесли в профиль. Пользователь получил возможность сначала увидеть, что предлагает сервис.
4. Подготовили основу для разработки. Заказчица смогла пройти по экранам будущего приложения и согласовать решения до вложений в код.

На примере Nasvet видно, зачем проверять сценарии до разработки MVP. Сначала мы планировали обязательную анкету на входе. При тестировании MVP пересмотрели решение: для знакомства с обучением персональные данные не требовались. Поэтому открыли материалы сразу, а заполнение профиля отложили.

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

Как оценить результат MVP: пример с цифрами

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

Ниже — условные примеры расчётов.

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

Сколько стоит разработка MVP

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

Условный пример: команда оценила создание MVP в 600 часов. При средней ставке 3 000 рублей в час разработка обойдётся в 1,8 млн рублей.

Отдельно уточняйте расходы на инфраструктуру и поддержку после запуска.

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

Какие ошибки мешают проверить идею

• Перегруз первой версии. Каждая дополнительная функция увеличивает бюджет и отдаляет запуск. 
• Экономить на работоспособности. Если продукт теряет данные или не позволяет завершить действие, результаты проверки будут недостоверными. Проверяйте основной сценарий до запуска.
• Запускать без плана привлечения пользователей. Готовый продукт сам по себе не собирает аудиторию. 
• Не определять критерии успеха. Без заранее выбранных показателей сложно решить, продолжать ли вложения. 
• Добавлять функции вместо разбора проблем. Если MVP не даёт ожидаемого результата, расширение возможностей может только увеличить расходы. 

Что делать после запуска MVP

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

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