MVP — что это такое, зачем он нужен и как его создать
Что такое MVP
Если разобрать дословно, то:
M (minimum) – использование наименьшего количества возможностей, функций и пакетов при разработке продукта;
V (viable) – предоставляющий основную ценность для пользователя;
P (product) – то, чем можно будет активно пользоваться сразу после релиза.
Таким образом, MVP – это не бета-версия вашего продукта, предназначенная для исправления ошибок или тонкой настройки функций и элементов интерфейса. Это также не идея, существующая в презентации, и не сырая демонстрация проверки концепции, а готовый для эксплуатации продукт, который впоследствии можно будет улучшать.
Примеры MVP среди стартапов и не только
В новом инновационном деле всегда существуют риски прогореть или «не угадать» то, чего хочет аудитория. Поэтому MVP так хорош для стартапов. С его помощью можно проверить концепцию с минимальными затратами. Wildberries начинался с интернет-магазина на платформе женского журнала Passion.ru, а Snapchat был маленькой утилитой, позволяющей обмениваться удаляющимися через 10 секунд после прочтения сообщениями.
Самые известные примеры компаний, которые начинали с MVP: Uber, Airbnb ,eBay, Spotify, Yahoo. Разработка минимально жизнеспособного продукта позволила им проанализировать спрос, выявить основные потребности целевой аудитории и добиться большого успеха.
Также MVP применим и для бизнеса, который существует много лет. Ситуация на рынке и тренды постоянно меняются. Нужный софт сегодня через 2 года может стать неактуальным. Постоянно меняется поведение пользователей и их предпочтения. Поэтому компании с многолетним опытом также создают новые продукты и сервисы с использованием MVP в разработке.
К примеру, наш клиент Docke создавали b2b портал по принципу MVP. Мы присоединились к разработке уже после его запуска, улучшая и анализируя обратную связь. Сейчас мы вместе с ними разрабатываем MVP интернет-магазина.
MVP наглядно
Для того, чтобы объяснить, что такое MVP, используются различные изображения. С их помощью проще объяснить и запомнить эту концепцию.
Мы нашли самые распространенные варианты.
Изначально минимально жизнеспособный продукт иллюстрировали на примере с колесом и машиной, где MVP - колесо, а готовый продукт - автомобиль.
Сейчас же эта иллюстрация общепризнанно является антипримером MVP. Одно колесо не может нести основной функционал продукта – передвижение. Выпускать такое «колесо» в пользование нельзя, а значит – это не MVP.
Второй распространенный тип визуальных примеров: скейт и автомобиль, плот и корабль, и другие. Смысл в том, что в начале делается что-то одно, и потом переделывается, часто с нуля, получая всё более совершенный продукт.
Эти иллюстрации показывают допустимый подход к MVP, но не оптимальный.
В таком варианте разработки минимально жизнеспособный продукт сильно упрощен, и для того, чтобы сделать «автомобиль» нужно каждый раз начинать с начала. Ну или заново переписывать код вместо того, чтобы наслаивать функционал у существующего. Отдельный вопрос и к целевой аудитории, которая у самоката и автомобиля сильно отличается.
Третий тип распространенных изображений по замыслу исключает недостатки второго варианта.
MVP здесь является основательной базой, которую нужно немного доработать. Данный подход считается эталонным. Однако если бюджет ограничен, то что-то точно пойдет не по плану. Может оказаться, что вы потратите основные деньги на каркас, а автомобиль так и не доедет до этапа получения финансирования дальнейшей разработки.
Для того, чтобы продукт не пришлось переделывать с нуля, и если MVP окажется успешным, лучше создать его основу с возможностью доработки и иметь в голове четкий план (который всё-равно изменится после получения обратной связи и тестирования). Также ваш MVP будет точнее проверять гипотезу, и вы не откажетесь от хорошей идеи из-за слабого MVP. Также, нам нравится такой, простой и лаконичный вариант изображения MVP.
Минимально жизнеспособный продукт создан без излишков, но у него проработан как дизайн, так и основной функционал. Изначально, вы можете оценить гамбургер, дать обратную связь: мало мяса, овощей, хочется заменить соус. После его доработки создаются и вспомогательные продукты – как кола и картошка на изображении. На этой картинке мы видим, что на создание MVP потрачено значительно меньше денег, чем на полноценный продукт, но основной функционал и визуал выглядят достаточно приемлемо чтобы не «прогореть» на старте.
Что такое PROTOTYPE и POC и как их отличить от MVP
Три самых популярных подхода к доказательству жизнеспособности концепции – это POC, Prototype и MVP, и их часто путают. У всех них есть свои цели создания. Чтобы отличить MVP от остальных, мы решили кратко рассказать о 2-х оставшихся терминах.
Разберем на примере: Допустим, вы решили создать приложение для поиска грибов.
Первый шаг: разработка POC. У нас есть концепция того, что можно создать программу которая будет определять грибные места. Мы вычисляем то, как понять где находятся лисички. Пишем код который с использованием алгоритмов и закономерностей будет выполнять эту функцию и проверяем её. Возможность реализации главной функции с помощью POC мы проверили.
Далее – Prototype. Разрабатываем интерфейс, добавляем возможность менять тему с тёмной на светлую и настраиваем работу без интернета, так как в лесу плохая связь и это принципиально. Пока, мы всё ещё можем найти только лисички. Тестируем, исправляем ошибки, презентуем инвесторам, получаем деньги и переходим к созданию MVP.
Первое приложение будет подходить ЦА – жители Московской, Владимирской, Ярославской и Рязанской областей с определенным перечнем грибов, которые там растут. Когда MVP готов – релизим его, рекламируем ЦА, проверяем востребованность, анализируем обратную связь. Далее мы узнаем о том, что люди хотели бы рассказать другим о «своих» грибных местах (звучит сказочно) и отмечать их на карте. Дорабатываем MVP до полноценного продукта который работает по всей России, подстраивается под местоположение и содержит те функции, о которых нам сообщили пользователи.
Как мы поняли из примера, использовать на проекте можно все подходы, но каждый из них предназначен для решения разных задач.
Создание MVP
Философия Agile в создании MVP
Создание MVP тесно связано с Agile философией, поэтому, если вы рассматриваете разработку минимально жизнеспособного продукта, вам стоит ближе познакомиться с этой методологией. Она базируется на четырех главных ценностях:
- люди и их взаимодействие важнее процессов и инструментов;
- работающий продукт важнее документации и отчётности;
- сотрудничество с заказчиком важнее соблюдения формальных условий;
- готовность к изменениям важнее, чем следование плану.
Чтобы быстро создать минимально жизнеспособный продукт и избежать критических ошибок разработка проходит спринтами небольшой длительности. В конце каждого периода достигается какой-то результат – создается новая версия продукта или новые функции. Его представляют для получения обратной связи, принятия решения о доработке или улучшении продукта.
Определение целей и задач продукта
Прежде чем начинать разработку, нужно тщательно продумать основные функции и определиться с одной или несколькими основными целями MVP. Для того, чтобы помочь вам в определении этих целей мы написали небольшой список вопросов:
- Для чего мне нужен этот продукт?
- Какую проблему решает мой продукт?
- Для чего пользователям нужен мой продукт?
Его можно изменять и дополнять под разные задачи, как только вы сможете объяснить ценность продукта и его функционал в нескольких предложениях, начните ставить задачи. На этом этапе все делается крупно, но не обобщенно.
Также может показаться, что основная ценность MVP – его функционал, однако это не совсем так. Без понятного и приятного интерфейса использовать продукт даже на первых этапах может быть сложно и не комфортно. Чтобы избежать потерь целесообразно использовать модель распределения ценностей Юсси Пасасена.
На пирамиде видно, что вместо последовательного создания “слоёв”, начиная с функционала, предлагается уделять внимание всем этапам параллельно. В бОльшей степени, конечно, функционалу.
Исследование рынка
Для разработки MVP важно понимать свою целевую аудиторию, если она уже существует (на внутреннем проекте) или выбрать определенный “портрет покупателя” для которого будете создавать MVP. Изучение потребителя поможет как при дизайне, так и при разработке MVP.
Если стоит цель создать конкурентоспособный продукт, нужно изучить рынок, сильные и слабые стороны аналогов и их “успех”. На этом этапе вам нужно проанализировать понять, что вы сможете сделать лучше.
Определение User flow
User flow - это визуальное представление того, как пользователь будет взаимодействовать с вашим продуктом или его частью. Он создается UX-дизайнером, которому нужно объяснить, каким вы видите путь пользователя, основываясь на цели MVP.
После определения пути пользователя, нужно добавить функции, которые помогут ориентироваться в вашем продукте и те, что будут отличать вас от конкурентов.
Инструменты и принципы для разработки MVP
Как мы уже писали ранее, создание MVP соответствует Agile философии и в его создании правильным будет использовать некоторые её методологии и их инструменты.
Scrum – популярная методология, которая основана на эффективном разделении объема работ, благодаря чему увеличивается скорость работы. Этот метод больше подходит для долгосрочной поэтапной разработки, так как работа проходит спринтами. После выпуска MVP команда в том же темпе может продолжить дорабатывать продукт, уже в соответствии с отзывами о продукте. Работая в этой методологии тестирование продукта происходит после каждого спринта. Это нужно, чтобы быстро переработать стратегию, добавить или отказаться от каких-то фич, пересмотреть бэклог. Также каждый участник автономен. Он несет ответственность как за свою часть работы, так и за общий результат.
Kanban – это система постановки задач в которой все этапы проекта визуализируются на специальной доске, а текущее состояние задачи можно посмотреть в любой момент.
Экстремальное программирование или eXtreme Programming, XP — это набор из лучших практик гибкой разработки и усиление их до максимума. Циклы разработки для XP не превышают одной недели, поэтому можно будет оперативно совершенствовать продукт после получения обратной связи. XP подойдет для создания MVP, которые сильно зависят от качества кода и имеют простой дизайн.В XP разработке принимаются самые простые решения, которые удовлетворят потребность в функционале существующую в данный момент времени. Команда постоянно получает фидбеки от системы и заказчика, а также сама может высказывать свои предположения и корректировки.
Lean – бережливое производство. Основная идея заключается в избавлении от всего ненужного, и разработке только того, в чем вы абсолютно уверены в настоящий момент. Это касается бесполезных собраний, документации, и задач, которые нужно будет сделать в будущем. В принципы бережливого производства входит и отсутствие многозадачности, так как делая что либо наперед, часто мы будем вынуждены потратить время на их переделку. Заставляя людей кодировать то, что не нужно или не полностью определено только, чтобы чем то занять их, вы можете получить ещё больше работы в будущем, когда это придется переделывать. Один из принципов Lean заключается в постоянном обучении, поэтому построить работу нужно так чтобы добиться этого.
«Назначайте необратимые решения на последний ответственный момент, то есть на последний шанс принять решение, пока не стало слишком поздно».
Этот метод подходит для разработки MVP с первого этапа, а для стартапов даже существует отдельная концепция предпринимательства – Lean Startup. Концепция разработки продукта или компании основывается на выраженных рыночных желаниях. Она подробно изложена в книге Эрика Риса «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели».
Преимущества метода MVP
Сокращение стоимости разработки продукта
Благодаря приоритезации функций и свойств разработка MVP обойдётся вам дешевле, и на него будет потрачено значительно меньше времени. Также благодаря поэтапному тестированию вы сможете выявить ошибки на старте и исправить их с наименьшими потерями.
Оперативный анализ планов продаж
После релиза упрощенного продукта или сервиса, компания видит интересы аудитории и может провести корректировку планов продаж, спроса и предложения на конкретный товар или услугу.
Оперативное определение сильных и слабых сторон сервиса или продукта
Это позволит вам правильно распределить бюджет расставив обоснованные приоритеты среди технических и финансовых ресурсов. Также у вас получится обнаружить неочевидные достоинства и недостатки самого продукта.
Простота доработки минимально жизнеспособного продукта
Проще добавить ключевые моменты на ранней стадии – чем менять проект полностью после полного запуска.
Ускоренный запуск
И как следствие раннее получение прибыли, окупаемость инвестиций, возможность заявить о продукте раньше конкурентов или автоматизация основных бизнес процессов и увеличение производительности.
Преимущества метода MVP для стартапов:
Минимизация финансовых рисков и потерь в результате запуска неудачного продукта
Да, расходы будут, не такие критичные как при разработке полноценного продукта.
Привлечение инвесторов
Наличие MVP помогает привлечь инвесторов для развития проекта и убедить их в его жизнеспособности.
Подтверждение или опровержение жизнеспособности идеи
Проверка гипотезы – позволяет протестировать новое решение с минимальными рисками, а также генерировать идеи для дальнейшего развития бизнеса.
Недостатки MVP
Репутационные риски минимально жинеспособного продукта
Если проект по итогу оказывается нежизнеспособным, то у потребителя может возникнуть негативное восприятие компании в целом. Это является особо значимым для крупных компаний. Однако при разработке b2b портала или внутреннего портала риск уменьшается из-за лояльности “потребителя”.
Сложность в определении состава MVP
В больших проектах могут возникнуть споры по тому, какой же должна быть минимальная жизнеспособная версия продукта. Иногда просто невозможно урезать те функции, которые лежат в основе концепции будущего продукта, и они одинаково сложны в разработке даже с примитивным интерфейсом.
Плохой UX работающей программы
Пользователю может не понравиться интерфейс, или он не поймет его до конца, из-за чего его могут закрыть и посчитать убыточным. А для положительного результата стоило бы изменить только часть или исправить какую-то ошибку.
Долгий анализ обратной связи
Чтобы собрать и обработать отзывы пользователей и выяснить, что нужно добавить в продукт может потребоваться значительное количество времени и иногда несколько попыток.
Потеря фокуса
При гибкой разработке легко свернуть «не туда», начать фокусироваться на второстепенных вещах, тем самым повышая стоимость разработки.
Также мы могли бы назвать недостатком метода MVP – неопределенный бюджет, однако и в случае с “чётким” ТЗ бюджет нельзя рассчитать точно и заранее. Рано или поздно появится то, что вы не учли или разработчики наоборот могут предложить более экономичный вариант создания продукта.
***
Наш опыт в создании MVP от модулей до интернет-магазина показывает, что в разработке web-проектов и других программных продуктов преимущества перевешивают недостатки. Если осмысленно подходить к разработке, а не пытаться слепить MVP из говна и палок, то это позволит вам сэкономить бюджет и время на разработку и вовремя сливать провальные идеи.
Успехов в разработке!
- Преимущества метода MVP
- Сокращение стоимости разработки продукта
- Оперативный анализ планов продаж
- Оперативное определение сильных и слабых сторон сервиса или продукта
- Простота доработки минимально жизнеспособного продукта
- Ускоренный запуск
- Преимущества метода MVP для стартапов:
- Минимизация финансовых рисков и потерь в результате запуска неудачного продукта
- Привлечение инвесторов
- Подтверждение или опровержение жизнеспособности идеи
