iTechArt logo

Что такое MVP и как его использовать

Development & QA Students Lab

MVP, или, Minimum Viable Product - понятие, о котором так или иначе слышал каждый, кто связан с разработкой. Впервые этот термин прозвучал 20 лет назад, а чуть позже он стал частью методологии «customer development», предложенной Стивом Бланком и Эриком Райсом.

Виталий Копытич, Lead Software Engineer iTechArt, последние 4 года регулярно работает на проектах, которые находятся в MVP стадии. С его помощью мы попытались разобраться в основных функциях, предназначении и алгоритме создания «минимально жизнеспособного продукта».

Наш собеседник
Копытич Виталий.jpg

Виталий Копытич

Lead Software Engineer iTechArt

Регулярно задействован на проектах MVP стадий - преимущественно в тех, которые стартуют с нуля.

Сегодня на повестке очень интересная и щекотливая, сложная и в то же время простая тема :) Думаю, что достаточно часто вы видели где-нибудь в новостях, рассказах про успешные (а, возможно, и не очень) стартапы, да или просто в рамках работы на своих ИТ-проектах такую аббревиатуру, как MVP. И это я не про most valuable player :)

Что такое MVP?

MVP (Minimum Viable Product), или по-русски просто «минимально жизнеспособный продукт» - это такая «болванка»/тестовая версия продукта с минимальным набором фичей, достаточных для того, чтобы каким-то образом уже пытаться решать «боли» клиентов. Она позволит собрать какой-то фидбек от потенциальных кастомеров для дальнейшего развития (а, возможно, и прекращения работы) проекта.

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

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

Чем MVP отличается от прототипа? От MMP (minimal marketable product)? MVP и PoC (Proof of the concept) — одно и то же?

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

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

PoC - описание технических возможностей продукта, «фичей» на этапе вынесения гипотез, которые в будущем будут реализованы и тем самым образуют MVP.

Когда и зачем нужно делать MVP? Какие задачи решает MVP?

Безусловно, наилучшее время использования MVP - запуск продукта. Я думаю, вам доводилось ощущать не самое приятное чувство непризнанности своих идей и предложений. Потому как идея продукта может быть крутой и прибыльной только у вас в голове, а по факту получается так, что вы потратили кучу ресурсов (времени, нервов, денег) своих и других людей (партнеров, сотрудников, инвесторов). Здесь-то и приходит на помощь оптимальный способ сделать проверку на ценнейший «отклик» потенциальных кастомеров на ваш продукт с минимальными затратами, отсеяв все лишнее и сконцентрировавшись на решении основной боли кастомера.

Всем ли компаниям/продуктам нужен MVP? В каких случаях можно обойтись без него?

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

Из каких этапов состоит работа над MVP, с чего начинается работа над MVP?

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

Первое: определите «боль» кастомера, которую будет решать ваш продукт

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

Второе: определите целевую аудиторию потребителей вашего продукта

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

Третье: определите основных конкурентов

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

Четвертое: разработка аналитических, маркетинговых и административных документов

SWOT-анализ, customer journey, user cases, документация внутренних процессов проекта и другое поможет вам определить сильные и слабые стороны вашего продукта, выбрать метод управления и разработки проекта, примерно понять флоу использования вашего продукта кастомером и многое другое.

Пятое: проведение тестирования вашего MVP

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

Шестое, заключительное: аналитика полученных данных в процессе тестирования продукта и последующее применение этой аналитики

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

Особенности организации рабочего процесса разработчика при MVP – есть ли какие-то нюансы? Что необходимо учитывать при разработке MVP?

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

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

Основные ошибки при разработке MVP

Самая распространенная из тех что я наблюдал в своей практике - желание впихнуть в MVP все больше и больше функционала (скорее всего, ненужного), что влечет за собой постоянное увеличение сроков, и, соответственно, увеличиваются косты проекта. Всегда помните об основной задаче MVP - дать хоть какую-то минимальную возможность кастомеру «пощупать» базовый функционал продукта для определения первичного фидбека и последующего совершенствования продукта.

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

Что нужно для успешного MVP? И как оценить, насколько успешно он реализован?

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

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

Рекомендации тем, кто впервые работает над MVP

Могу сказать, что это супер интересно и полезно! Поэтому не бойтесь всех трудностей на пути к построению успешного продукта, но и не забывайте анализировать всю информацию, полученную от потенциальных кастомеров, и правильно ее применять для совершенствования продукта :)