Что такое MVP: как ограничить объем первой версии продукта
MVP это самый маленький работающий продукт, который проверяет идею на реальных пользователях. Как ограничить первую версию и что в неё не включать.
Команда rabbitclipПубликация: 5 мин чтения
Коротко
MVP, или минимально жизнеспособный продукт, это самый маленький работающий продукт, который способен показать, будут ли реальные люди пользоваться вашей идеей. Его цель не в том, чтобы выпустить что-то с меньшим числом функций. Его цель в том, чтобы проверить самую рискованную из всех гипотез как можно быстрее и при этом как можно дешевле. Хороший MVP состоит из одного цельного сценария, который решает главную проблему пользователя от начала до конца, а всё остальное добавляется лишь после того, как этот сценарий доказал свою состоятельность.
Это понятие часто понимают неверно. MVP не небрежный и не наполовину сделанный продукт. Его объем узок, но при этом он надежен, действительно работает и пригоден к использованию. Представьте приложение для записи в сети спа-салонов. Если первая версия предлагает только запись на приём и напоминания, и эти две вещи работают без сбоев, это MVP. Если в ней есть ещё и абонементы, система баллов и экран акций, а экран записи работает с ошибками, это не MVP. Это разрозненный продукт.
Для чего нужен MVP, а для чего не нужен?
MVP это прежде всего инструмент обучения. Внутри большинства продуктовых идей скрыты три-четыре гипотезы: пользователи действительно сталкиваются с этой проблемой, им нужно именно такое решение, и они готовы платить за него или тратить на него время. MVP показывает, какая из этих гипотез неверна, ещё до того, как вы построили полный продукт, а именно тогда узнать об этом дешевле всего.
Чего MVP сделать не может, так это выиграть гонку функций у устоявшегося конкурента. Попытка повторить в первой версии функции, накопленные за годы, съедает и сроки, и бюджет. Первая версия существует вовсе не для того, чтобы обогнать соперника. Она существует для того, чтобы дать пользователю одну веское причину вернуться.
Как ограничить объем первой версии?
Начните с того, чтобы записать одно предложение, которое описывает проблему, решаемую вашим продуктом. Если вы не можете его написать, значит, объем работ ещё не готов. Затем перечислите шаги, которые пользователь делает на пути к этому решению, и отметьте только те экраны, которые эти шаги строго требуют.
Задайте каждой отдельной функции один и тот же вопрос: сможет ли первый пользователь решить свою проблему без неё? Если ответ да, функция относится ко второй версии. Если держать решение таким же простым и прямым, список сократится сам собой.
- Определите единственный основной сценарий, который решает главную проблему пользователя.
- Разделите каждую функцию на три группы: обязательная, полезная и откладываемая.
- Возьмите в первую версию только обязательную группу.
- Не автоматизируйте то, что можно сделать вручную: для первых пользователей ведите процесс сами.
- Заранее и как можно раньше зафиксируйте дату запуска и подгоняйте объем под дату, а не наоборот.
Что следует оставить за пределами первой версии?
Обычные кандидаты это подробные панели администрирования, многоязычный интерфейс, расширенная отчетность, несколько способов оплаты, слои ролей и прав доступа и сложные настройки уведомлений. Ничто из перечисленного не лишено ценности. Оно просто никак не меняет ответ на самый первый вопрос, который вы перед собой ставите.
Другой способ оставить что-то за бортом это выполнять работу вручную. Если портал строится для производителя напольных покрытий, сотрудник может обновлять остатки на складе вручную первые несколько недель. Интеграцию пишут, когда продукт прижился, и вы не платите за автоматизацию, которой пока никто не пользуется.
Когда MVP не нужен или является неверным выбором?
Там, где процесс хорошо изучен, пользователи известны, а проблема уже доказана на практике, подход MVP может оказаться совершенно лишним. Если вы просто переносите в интернет уже существующий внутренний процесс, потребности уже ясны, и настоящая задача состоит в том, чтобы точно описать объем работ.
В областях, где ошибка влечет тяжелые последствия, таких как безопасность, здоровье или платежи, узкий MVP не должен означать снижение качества. Объем работ сокращается, но безопасность и достоверность данных должны быть полными с первого дня. В этих сферах MVP означает меньше функций, но никогда не меньше внимания.
Какие ошибки часто встречаются с MVP?
Первая ошибка это принимать MVP за сокращенный список функций. Настоящая мера это то, решена ли проблема пользователя, а не то, сколько существует функций. Вторая ошибка: месяцами разрабатывать продукт, никому его при этом не показывая и не слушая ничьих отзывов. MVP, который не получает никакой обратной связи, так и остается просто маленьким продуктом.
Третья ошибка: написать первую версию как черновик на выброс, а потом пытаться строить поверх него. Код и структура данных первой версии должны быть достаточно аккуратными, чтобы допускать рост. Скорость, купленная ценой качества, всё равно возвращается во второй версии, причем с процентами.
- Запуск без меры успеха: заранее решите, что будет считаться успехом.
- Отсутствие разговоров с пользователями: беседа с первыми десятью пользователями ценнее большинства аналитики.
- Добавление каждого запроса: внутренние пожелания путают с реальными потребностями пользователей.
- Пропуск дизайна: простой продукт не то же самое, что беспорядочный.
Что измерять после запуска MVP и что делать дальше?
Когда первая версия вышла, нужно спросить, проходят ли пользователи основной сценарий до конца. Сколько человек начали, сколько дошли до самого конца и где именно остановились остальные. Именно эти три ответа определяют, что будет создаваться в следующем спринте.
После измерения выбирается один из трех путей: продукт работает и его расширяют, продукт работает частично и сценарий исправляют, либо продукт не работает и идею оставляют или меняют. Третий исход тоже является успехом, потому что вы узнали это, не потратив бюджет полного продукта.
MVP это не искусство выпускать что-то маленькое. Это дисциплина, которая позволяет задать правильный вопрос самым дешевым из доступных способов. Одного основного сценария, ясной меры успеха и твердой даты запуска хватает для большинства проектов. Если вы хотите вместе с командой, которая в этом разбирается, ограничить первую версию собственной идеи, вы можете договориться о ознакомительной встрече с rabbitclip.
Частые вопросы
MVP и прототип это одно и то же?
Нет, это разные вещи. Прототип это макет, который показывает, как идея будет выглядеть и вести себя, и его не открывают для реальных пользователей. MVP это первый работающий в сети продукт, который проверяют на реальных пользователях.
Сколько времени занимает разработка MVP?
Это зависит от объема работ, размера команды и числа интеграций, которые нужно подключить. Когда объем сокращен до одного основного сценария, срок заметно уменьшается, а самый здоровый подход состоит в том, чтобы зафиксировать дату запуска и подогнать под нее объем.
Нужно ли потом переписывать MVP?
Нет, если первая версия построена с аккуратной структурой, потому что тогда на ней можно спокойно надстраивать дальше. Необходимость переписывать обычно возникает, когда в первой версии пренебрегли качеством и структурой данных.
Какие функции обязательны в MVP?
Только те, которые требует основной сценарий, решающий главную проблему пользователя. Входа, основного действия и экрана результата часто достаточно, а панели администрирования и отчеты, как правило, могут подождать.
Стоит ли действующему бизнесу начинать с MVP?
Если вы переносите в интернет хорошо известный процесс, потребности вам уже ясны, и MVP может вовсе не понадобиться. Если же вы обслуживаете новую группу клиентов или запускаете новую услугу, безопаснее и разумнее начать с узкой первой версии.
