MVP постепенно становится не только способом снизить риски, но и весомым условием для согласия инвесторов. Всё меньше людей хочет вкладывать деньги в идею, теперь для подтверждения её состоятельности бизнесу необходимо представить «живой» концепт. Читайте в нашей статье о том, чем MVP отличается от PoC и что необходимо для создания первого.
MVP — минимально жизнеспособный продукт, первая версия разработки, в которой присутствуют лишь наиболее важные функции. Используется для тестирования и объяснения целевой аудитории смысла, ценностей, а также направленности разработки.
В первую очередь MVP изготовляют для того, чтобы собирать с потенциальных пользователей обратную связь. Иногда с помощью него выясняется, что такой продукт пользователям не нужен вообще, тогда концепция кардинально переосмысливается. Однако чаще в отзывах разработчики получают рекомендации по исправлению функционала, добавлению каких-то фишек и т. д.
Несмотря на то, что создание MVP стоит денег, это может значительно сэкономить средства компании (в этом и заключается одна из его главных целей). Ведь предварительное тестирование «наживую» уменьшает не только стоимость дальнейшей разработки, но и снижает риски пострелизного провала.
MVP и PoC
Иногда MVP путают с PoC, по-русски: доказательством правильности концепции. Что представляет из себя последнее сказать однозначно весьма затруднительно.
Точное значение PoC зависит от конкретной сферы. В IT, а точнее — в разработке ПО, это описание процессов, направленных на выяснение уровня жизнеспособности концепции разработки технически. Компания может использовать PoC, чтобы определить будущие сроки работы, наиболее удачные технологии для реализации идеи, выявить вероятные технические проблемы и заранее найти пути их решения.
PoC может стать хорошим предварительным этапом создания MVP. Но не наоборот. Например, в своём блоге компания может рассказать идею и, если пользователи её поддержат, «выкатить» людям MVP на проверку.
Типы MVP
Выбирать рекомендуется из следующих 4 типов.
Волшебник страны Оз
(MVP Флинстоуна)
Название прямо отражает специфику данного типа MVP: версия лишь кажется целиком (или хотя бы преимущественно) функциональной, на самом деле разработчик выполняет все действия самостоятельное, вручную. Он не использует ПО вообще. Его нет даже базового. Однако есть концепция. И её необходимо проверить.
Например, предприниматель Вальдемар (ещё не знаете, кто это? Читайте здесь)
решил продавать не только жаб, но и пауков. При этом он просто разместил на сайте фото нескольких видов, не покупая их заранее, не тратясь на аквариумы, корм, аренды нового помещения и т. д.
Как только люди начали заказывать пауков, Вальдемар купил все те виды, которые фигурировали в заказах, и самостоятельно отправил их. Так он понял, что его проект жизнеспособен и в него можно и нужно вкладывать деньги.
Консьерж MVP
Данный тип используется так же при тестировании разработки для сферы услуг. Однако в случае Консьержа пользователи понимают, что услугу им предоставляет живой человек, а не ПО.
Ещё одно ключевое отличие этого типа от первого заключается в том, что Консьерж больше направлен на формирование идей о перспективах и будущем продукта, на предоставление реальных услуг и коммуникацию с потребителем.
Разрозненный MVP
Основное предназначение данного типа — донести до потенциального потребителя разработки ценность использования уже существующих инструментов, а не создания уникального решения. Поэтому MVP представляет из себя комплексный продукт, где любые улучшения вносят только после обработки фидбека и конкретных просьб.
Продукт с одним параметром
Тот самый «классический» MVP. Представляет из себя реальное ПО с минимумом функционала, нужного для проверки гипотезы. Позволяет опросить и профильтровать целевую аудиторию, собрать с неё отзывы для анализа и протестировать разработку.
Как создать MVP
Пройти перечисленные ниже 9 этапов придётся вне зависимости от типа MVP.
Подготовительный этап. Сформируйте основные принципы и методы MVP
Помимо составления концепции MVP и контроле выполнения всех нужных действий командой в дальнейшем рекомендуется сосредоточить внимание так же на следующих пунктах:
- тратьте как можно меньше денег и других ресурсов. В обратном случае теряется вся суть создания MVP;
- определите самый простой тип MVP, который будет подходить именно вашему бизнесу для проверки именно вашей идеи. Придерживайтесь его, не пытайтесь изменить типа MVP «по ходу дела», иначе никакой экономии не выйдет;
- не забывайте концентрироваться на на отзывах:используйте все возможные каналы связи, чтобы найти и набрать первых пользователей. Для этого, кстати, можно осуществлять PoC-деятельность;
- ещё немного по поводу обратной связи: постоянно разговаривайте со своими пользователями. часто, ежедневно, всегда. Делайте это вне зависимости от того, на каком этапе работы вы находитесь и продолжайте разговор даже когда вы закончили тестирование MVP и переходе к созданию первой версии своего продукта. Расширьте свою предыдущую практику с помощью A/B-тестирования или иных, более близких вам методов. Как правильно исследовать аудиторию и что спрашивать у людей, можете посмотреть в этой статье;
- создайте лендинг с описанием продукта и его основного функционала. В идеале пользователь должен иметь возможность зарегистрироваться там, чтобы попробовать платные и (или) бесплатные решения. Это поможет вам понять и выставить наиболее разумную, подходящую вашей аудитории и ситуаци стоимость разработки;
- попробуйте провести предпродажу продукта на краудфандинговых платформах или продать его напрямую. Это хороший способ услышать независимое мнение о продукте и, если повезёт, получить денег на дальнейшее развитие;
1 этап. Найдите и сформулируйте (словесно) потребность аудитории, которую будете закрывать
Чётко сформулируйте цель вашей разработки. Вы должны ясно и коротко рассказать самому себе, для чего необходима эта разработка и в чём его уникальная ценность.
2 этап. Определите целевую аудиторию и максимально сузьте её
Чем шире будет ваша целевая аудитория, тем менее вероятен будет успех полного удовлетворения всех её нужд. Попробуйте отсечь лишнее, чтобы увеличить свои шансы на успех.
Для этого не идите дедуктивным путём: от общего к частному. Наоборот, попробуйте детально описать человека, который бы был в восторге от вашего продукта и смог бы купить его без колебаний по той цене, которую вы поставите.
Это поможет не только рассчитать нужную аудиторию (в процессе размышлений вы так или иначе попробуйте критически подойти к делу и проверить свои идеи), но и понять — поможет ли потенциальный продукт в действительности закрыть потребности представителей данной группы.
3 этап. Сделайте анализ конкурентов
А они будут. Маловероятно, что ваш продукт эксклюзивен настолько, что данный этап при всём желании придётся перешагнуть. Поэтому.. анализируйте конкурентов. Изучите их сильные и слабые стороны, чтобы не повторить ошибок при создании собственного продукта.
Классифицируйте конкурентов, хотя бы главных гигантов рынка, узнайте возраст этих компаний, какие кризисные моменты преодолевали, с чем они были связаны. Подумайте, сможет ли ваш продукт предложить пользователям что-то действительно лучшее и более удобное?
При этом исследовать нужно не только то, что компания говорит о себе, но и то, что о ней пишут и говорят другие. Смотрите отзывы, обзоры, сравнения и т. д., чтобы понять, что хотят и в чём нуждаются пользователи на самом деле.
В идеале попробуйте сами стать пользователями конкурентов. Это позволит вам убедиться в правильности или ошибочности своих предположений, проанализировать их продукт детальнее и точнее.
Используйте для своего исследования специальное ПО или сервисы.
В этой статье есть список того, что может очень помочь и сэкономить время.
4 этап. Сделайте SWOT-анализ
SWOT-анализ позволяет выявить сильные и слабые стороны (внутреняя среда), возможности и угрозы (внешняя среда). Применяется при стратегическом планировании. Для его выполнения нужно ответить на ряд вопросов, связанных с 4 упомянутыми категориями. Чётких формулировок нет, вы сами можете составлять вопросы и оформлять ответы на них в виде таблицы (так будет удобнее).
5 этап. Определите карту путей пользователя
Путь пользователя — условный «маршрут», который проходит потребитель при взаимодействии с продуктом. Если вы хотите, чтобы всё было хорошо, необходимо приложить все усилия к тому, чтобы данный путь вышел понятным, простым и логичным.
Карта этих путей представляет собой руководство с требованиями к дизайну и контенту продукта. Например, приложения.
6 этап. Составьте список функций и ранжируйте их по степени приоритетности
В этом может помочь метод составления пользовательских историй. Фактически, вы должны выбрать полезные функции с точки зрения пользователей и записать их на карточках в виде списка действий, которые должен совершить человек для их осуществления.
После того, как список будет закончен, проведите горизонтальную линию. Это путь пользователя. Слева направо должны располагаться функции, начиная с той, которой пользователь воспользуется в первую очередь, заканчивая той — что в последнюю.
Теперь важно расставить приоритеты. Определите, насколько важна каждая функция, как часто она будет использоваться, каковы риски её наличия. После приоритизации разместите под каждой функцией соответствующие ей действия пользователя: от наиболее к наименее важным.
Подобная приоритизация позволит определить объём MVP.
7 этап. Определите объём MVP
Фактически это будут первые 1–2 горизонтальных ряда получившейся карты пользовательского пути. Если вы сомневаетесь, классифицируйте функции: отделите существенные от несущественных.
Те, которые вы определили в наиболее приоритетные, включаются в MVP. Остальные стоит добавить позже, после развёртывания MVP или анализа обратной связи.
8 этап. Выберите метод управления и разработки MVP
Выбирать лучше всего в зависимости от специфики бизнеса и структуры компании.
LEAN. Один из методов разработки Agile. Основан на устранении ненужных расходов, быстрой доставки, усилении обучения и создании целостности. По факту это итеративная разработка с использованием шаблона «создание-измерение-обучение». Это хороший вариант для тех, чьи разработчики не многозадачны, т. к. LEAN позволяет установить быстрый цикл обратной связи а значит не растягивать процесс создания и тестирования продукта.
SCRUM. Базируется на эффективном распределении объёма работ, который так же значительно ускоряет процесс создания MVP и продукта. Делится на спринты (периоды по 7–21 день), работу в которых контролирует scrum-мастер. При этом MVP реализуется сразу же после первого спринта. Что позволяет команде обновлять и оптимизировать продукт в течение каждого следующего спринта, опираясь на мнение пользователей. Подходит тем, кто готов к постепенному, возможно длительному, однако предельно качественному развитию.
KANBAN. Модель незавершённого производства, которая не имеет цикличной прогрессии. Основное преимущество Канбан — возможность сосредоточиться на задачах по мере их появления. Обычно эту модель рекомендуют применять уже после выпуска первой версии MVP, при условии, что обратная связь продолжает поступать регулярно и в большом объёме.
ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ (XP). Строится на коротких циклах, которые не длятся дольше 7 дней. Позволяет улучшить код и обновить его в кратчайшие сроки. Рекомендуется к применению в случае MVP, который представляет из себя реальное ПО и опирается именно на качество кода.
9 этап. Проводите Альфа- и Бета-тестирования
Альфа-тестирование — это тестирование продукта внутри ограниченной группы: рабочего коллектива, друзей, семьи и т. д. Если мини-группа одобрила разработку, её можно передавать в бета-тестирование, или тестирование более обширным числом реальных, незнакомых разработчикам пользователей.
Повторять эти циклы можно пока обе группы не скажут, что замечаний и комментариев (кроме, конечно же, похвалы) нет. Длительность тестирования подбирается индивидуально, однако обычно она не превышает пары недель.
Если тестирования не дают положительных результатов даже спустя достаточно долгое время, лучше всего вернуться к подготовительному этапу и начать работу над MVP с так называемого «чистого листа» (или хотя бы откорректировать то, что было создано, учитывая ошибки и отзывы).
