Этапы разработки MVP: от гипотезы до работающей версии

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

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

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

Этап 1. Формулируем гипотезу

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

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

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

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

Этап 2. Определяем, как будем оценивать результат

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

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

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

Важно определить эти показатели заранее. Тогда аналитика становится частью MVP, а не чем-то, о чём вспоминают уже после запуска.

Этап 3. Выделяем ключевой пользовательский сценарий

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

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

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

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

Этап 4. Определяем состав MVP

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

Если нужна — оставляем. Если нет — переносим в бэклог следующих этапов.

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

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

Этап 5. Продумываем архитектуру

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

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

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

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

Этап 6. Проектируем интерфейс

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

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

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

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

Этап 7. Разрабатываем первую версию

Только теперь начинается непосредственно разработка.

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

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

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

Этап 8. Тестируем не только код, но и сценарий

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

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

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

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

Этап 9. Запускаем MVP на реальных пользователях

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

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

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

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

Этап 10. Анализируем результаты и принимаем решение

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

Результат при этом не сводится к двум вариантам «успех» или «провал». Возможных сценариев значительно больше.

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

Все эти результаты полезны, если помогают принять решение на основании реальных данных.

Что происходит с MVP дальше

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

Причём первоначальный план развития после запуска вполне может измениться. Это нормально: теперь приоритеты определяются не только представлениями команды, но и поведением реальных пользователей.

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

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

Разработка MVP — это цикл, а не сокращённая разработка продукта

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

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

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