Как правильно запустить MVP, чтобы не «закопать» проект на старте
Когда происходит движение от идеи к реализации проекта, часто возникает соблазн сразу направить все силы на создание идеального решения, объять необъятное. Но при таком подходе даже самая превосходная идея рискует так и не дожить до релиза, несмотря на месяцы разработки и значительные вливания средств. Причина в пренебрежении этапом тестирования гипотез, который помогает решению не обрастать ненужными функциями, а самое главное – понять, отвечает ли оно запросу целевых пользователей.
Здесь на помощь приходит MVP (Minimum Viable Product). Однако его стоит рассматривать не просто как первый «сырой» вариант продукта, он должен выступить стратегическим инструментом. Ведь MVP проекта – что это? По сути, это версия решения, созданная быстро и с минимальными затратами, чтобы однозначно проверить какую-то одну главную гипотезу. Например, «Сократит ли внутреннее приложение для курьеров время доставки на 20%?» или «Будет ли пользоваться популярностью чат-бот для первичной оценки состояния организма?». И цель MVP – не впечатлить всех фичами, а получить честную обратную связь от реальных пользователей, чтобы понять, стоит ли двигаться дальше, нужно ли что-то изменить, до того, как потрачены серьезные ресурсы.
Почему MVP начинает разрастаться
Несмотря на предполагаемую минималистичность, MVP не застрахован от попыток перегрузить его. Основная угроза на данном этапе – постепенное расширение функциональности продукта как по инициативе заказчика, так и в связи с появляющимися у команды новыми предложениями и доработках. Чтобы не происходило смещение фокуса с проверки ключевой гипотезы на реализацию второстепенных возможностей, стоит фильтровать идеи, отсекая те, без которых пользователь сможет решить основную задачу, пусть и менее удобно. Всё остальное нужно отправить в бэклог для будущих итераций.
Да, бывает сложно остановиться, когда загораешься идеей, и кажется, что «еще одна важная фича», добавленная перед запуском, обязательно усилит первое впечатление от продукта. Но здесь таится первая и, пожалуй, самая коварная ловушка – стремление к идеалу до того, как была доказана сама идея. В итоге сроки раздуваются как мыльный пузырь, команда выдыхается, а главное – все начинают забывать, что затевалось всё для решения единственной проблемы. Создание MVP начинается не с красивого кода или дизайна, а с кристально четкого понимания: какую конкретную боль мы снимаем у конкретной аудитории? Основная цель создания MVP продукта – не впечатлить, а доказать, что минимальное решение действительно закрывает острую потребность.
Хорошо помогает не раздувать функциональность принцип «Jobs to be Done» (Работа, которую нужно выполнить): если постоянно спрашивать себя, для чего пользователь «нанимает» MVP, держать фокус на действительно нужных на данном этапе фичах становится проще.
Проектные треугольники: баланс между скоростью, стоимостью и функциональностью MVP
MVP, как и для любого другого проекта, работает модель треугольника ограничивающих факторов (скорость-стоимость-функциональность). Качество продукта зависит от четкого соблюдения баланса между этими «гранями», а при любых изменениях в треугольнике MVP рискует «раздуться». Основная ответственность за то, чтобы этого не произошло, ложится на project-менеджера, которому приходится постоянно жонглировать упомянутыми выше факторами.
Хочет бизнес ускорить запуск? PM тут же обсуждает, какие функции можно отложить на следующие этапы разработки MVP. Урезали бюджет? Значит, придется сужать функциональность или искать более простые технические решения. Главная задача PM – не дать проекту выйти за рамки реалистичного треугольника, иначе разработка MVP продукта превратится в долгострой с неясными целями.
Управление проектным треугольником подразумевает постоянные переговоры, а в случае с MVP это проявляется особенно ярко. Project-менеджеру довольно часто приходится доносить до бизнеса необходимость придерживаться концепции проверки одной гипотезы, чтобы не выйти за пределы оговоренных сроков или бюджета. А команду порой нужно возвращать к объективности оценок по задачам. Безжалостно отсекать все, что не проверяет ключевое предположение о ценности продукта для рынка, – единственный способ удержать создание MVP в рамках управляемых временных рамок и стоимости, не превращая его в полноценный (и дорогой) продукт на старте.
Почему итерации – воздух MVP проекта
Что еще однозначно помогает удерживаться в необходимых рамках, так это итеративный подход. Его стоит применять на всех этапах создания MVP продукта, чтобы вовремя увидеть необходимость остановиться и «пересобрать» проект. Здесь снова на первый план выходит коммуникация: каждый шаг должен достаточно тщательно обсуждаться с заказчиком, чтобы ожидания максимально совпали с результатом. На небольшом масштабе MVP любое отклонение от зафиксированных на спринтах целей, может быть очень заметным и критичным.
Еще до написания первой строчки кода итерации помогают уточнить и сузить ключевую гипотезу, создать прототипы интерфейсов и даже сразу же протестировать их на фокус-группах. И, конечно же, получать обратную связь после тестовых версий до финального релиза, не менее ценно – перед каждым новым шагом можно осмыслить слабые места гипотезы, оперативно их скорректировать и только затем двигаться дальше. Это позволяет ловить фундаментальные ошибки до того, как они сделали проект неоправданно дорогим.
Очевидно, что в рамках объемной функциональности, частые итерации и следующие за ними изменения, могут вызывать панику у команды и клиента – какая-то одна (а, возможно, и сразу несколько) граней проектного треугольника может сильно отклониться от изначального плана. В итоге проект вообще может остаться нереализованным. Но мастерство project-менеджера заключается в том, чтобы с одной стороны, во время сдерживать пыл всех участников процесса создания MVP, а с другой если расширение продукта оправдано, то приводить сильные аргументы в пользу тех или иных решений. То есть, при грамотном управлении проектом частые итерации перестают быть чем-то пугающим.
Заключение
Чтобы MVP не превратился в дорогостоящий «склад идей», которые никогда не воплотятся в жизнь, необходимо постоянно держать фокус на ключевой ценности, главной гипотезе проекта. Постоянный сбор и анализ обратной связи, а также итеративность позволят не только во время остановиться и пересмотреть дальнейший путь, но замотивируют этот самый путь продолжать.
Даже запущенный по всем правилам MVP не обещает, что продукт мгновенно завоюет рынок. Но это отличный стратегический инструмент, который поможет сэкономить компании месяцы рабочего времени, не слить крупные бюджеты клиента и сохранить его доверие. Разработка MVP проекта либо покажет тупиковость изначальной идеи, избавив тем самым от многолетних вложений в неудачный продукт, либо укажет верное направление для развития с подтвержденными данными. Так MVP выступает «страховкой» от провала полномасштабного проекта.
Есть задача? Поможем решить.
