Что такое MVP и когда он нужен бизнесу

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

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

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

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

Что такое MVP

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

Minimum означает, что мы сознательно ограничиваем объём первой версии и не пытаемся реализовать сразу все задуманные возможности.

Viable — что продукт уже должен быть жизнеспособным. Им можно пользоваться, он решает определённую задачу и даёт пользователю ценность.

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

Поэтому MVP — это не «плохая версия хорошего продукта» и не способ сделать разработку максимально дёшево. Это инструмент проверки гипотез.

MVP — это не просто сайт с половиной функций

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

Не обязательно. Главный вопрос при определении состава первой версии звучит иначе: что именно мы хотим проверить?

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

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

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

Зачем бизнесу запускать MVP

Основная причина — возможность получить реальные данные до того, как компания вложит значительные ресурсы в полноценный продукт. До запуска команда работает с предположениями. Можно провести исследования, поговорить с будущими пользователями, изучить конкурентов и подробно спроектировать сценарии. Всё это снижает неопределённость, но не устраняет её полностью.

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

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

MVP помогает проверить не только спрос

Когда говорят о минимально жизнеспособном продукте, чаще всего вспоминают стартапы и вопрос: «Будут ли люди вообще этим пользоваться?» Но проверять можно гораздо больше.

Например:

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

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

Когда MVP действительно нужен

MVP особенно полезен там, где существует высокая неопределённость.

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

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

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

Когда MVP может быть не нужен

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

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

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

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

MVP не должен быть неудобным или ненадёжным

Слово «минимальный» иногда воспринимают как разрешение экономить на всём. В результате первая версия получается настолько сырой, что выводы по итогам тестирования теряют смысл.

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

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

Иногда часть процессов можно выполнять вручную

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

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

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

Это один из важных принципов MVP: сначала проверить ценность, а уже потом инвестировать в масштабирование решения.

Как определить, что войдёт в первую версию

Хороший способ — начать не со списка функций, а с основного пользовательского сценария.

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

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

Так постепенно формируется не просто сокращённое техническое задание, а осмысленная первая версия продукта.

Что происходит после запуска MVP

Релиз MVP — не финал проекта. Наоборот, именно после него начинается самая важная часть работы.

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

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

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

MVP не всегда означает маленький проект

Минимальность — понятие относительное.

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

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

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

Как понять, нужен ли вашему проекту MVP

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

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

MVP не делает разработку современной или эффективной. Ценность MVP появляется только тогда, когда существует неопределённость, которую действительно необходимо снять.

Сначала гипотеза, потом MVP

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

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

Иногда результатом станет масштабирование продукта. Иногда — изменение первоначальной идеи. А иногда эксперимент покажет, что продолжать разработку вообще не стоит.

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