Что такое MVP (минимальный продукт)?

Категория: Что такое?

– Автор: Игорь (Администратор)

Когда понимаешь, что программа, сервис или иной какой-то продукт будут пользоваться популярностью, то создавать их как-то проще. Как минимум появляется больше уверенности, а сомнения откладываются на второй план. Соответственно, возникает вопрос: "А как этого добиться на более ранних этапах?". И тут, вероятно, читателю в голову приходит самый банальный подход - опрос людей и поиск конкурентов.

Но этим методы не ограничиваются! Речь идет о так называемом минимальном жизнеспособном продукте или MVP.

Но обо всем по порядку.

MVP это

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

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

Кстати, отмечу, что MVP не является каким-то открытием или чем-то подобным. Данный подход и раньше существовал (даже до появления интернета). Просто в текущий момент скорость обмена данными настолько высока, что принцип "кто первый встал, того и тапки" стал более существенным.

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

Нужен ли будет Колин сервис в такой ситуации? Вопрос сложный. Так как даже если у Коли более мощный сервис, многие пользователи уже привыкли к другой системе (у них там куча данных, многие моменты уже понятны, сформировано некое комьюнити, многие ошибки решены и т.п.). Т.е. разница должна быть более существенна, чем в ситуации конкуренции двух одинаковых сервисов без пользователей, иначе смысла использовать Колин сервис ради одной функции, которую скоро прикрутят к другому сервису, нет.

Так же вам может быть интересен обзор Ранний доступ: плюсы и минусы для геймера, так как часть моментов легко применима к любым другим сферам жизни, хоть и речь о компьютерных видеоиграх.

Цели MVP или для чего он нужен?

Рассмотрим основные цели MVP:

1. Быстрая обратная связь с пользователем (Фидбэк). Можно рисовать сколько угодно красивые картинки (видео и т.п.), но ничего не заменит того, о чем говорит старая поговорка "лучше один раз увидеть, чем сто раз услышать". Кроме того, обратная связь с пользователями позволяет создавать более качественные товары. Абстрактный пример, некая программа отчетности. Вообще, отчеты можно сделать какими угодно (разные поля, разные фильтры, размеры, компоновка и т.п.). Но только вот полезность этих отчетов определяют пользователи. В частности, вполне нормальное явление, когда что-то вроде бы ненужное (какое-нибудь столбец или фильтр) оказывается крайне нужным для пользователей. Просто потому что они решают свои задачи каждый день. И узнать об этом лучше как можно раньше.

2. Появление уверенности в товаре (программе, сервисе и т.п.). Например, если популярность MVP набирает обороты с каждым днем, то какой вывод может сделать автор программы (товара, сервиса и т.п.)? Правильно, что спрос существует и что это то, что нужно развивать.

3. Привлечение интереса к проекту на более ранних этапах. Например, если вы делаете что-то интересное и это набрало популярность, то вам будут предлагать помощь в развитии проекта. В частности, именно так и появились большие CMS (в том виде, в котором они сейчас выглядят). Вначале их делали единицы, а потом вокруг начали появляться авторы, которые либо помогали в развитии самой CMS, либо делали модули, которые повышали и повышают привлекательность этих CMS. Абстрактно, уберите у WordPress, Joomla и OpenCart их модули, а затем добавьте в другие CMS, как тут же пользователи перестанут пользоваться первыми тремя.

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

Типы MVP

Теперь рассмотрим типы MVP:

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

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

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

Кстати, стоит отметить, что, в принципе, имитация MVP может подразумевать, что пользователь знает, что часть вещей делается вручную.

MVP: Советы и нюансы

Теперь рассмотрим разные советы и нюансы, связанные с созданием MVP.

1. Выделите конкретные цели, которые должен решать MVP. Это очень важно выделить конкретные цели, в противном случае MVP может разрастаться до полноценной большой системы (программы, сервиса и т.п.). Для этого можно использовать разные инструменты. Например, SWOT-анализ, ну или банальный листок с ручкой в стиле "список идей".

2. Определите источники обратной связи MVP. Важно всегда помнить, что MVP создается в том числе и для быстрой обратной связи с пользователем. Это значит, что нужно предусмотреть каким образом пользователи смогут оставить свой фидбэк. Это может быть электронная почта, это могут быть социальные сети и т.п. Но главное, чтобы такие каналы связи были.

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

4. MVP это не обязательно "поделка на коленке". Вполне нормальное явление, когда программа (сервис и т.п.) предоставляют всего одну функцию (может и с ограничениями и т.п.), но делает это нормальным образом. Иными словами, не стоит считать, что MVP это возможность для того, чтобы делать спустя рукава. Более того, MVP может быть даже относительно полноценной системой. Такой порой бывает, когда существует некий минимум, без которого программа бесполезна.

5. MVP должен как-то акцентировать внимание на том, что программа (сервис, товар и т.п.) будет развиваться. Иными словами, пользователь должен каким-либо образом понимать, что это не конечный результат (естественно, при наличии интереса пользователей). При чем это может быть даже банальная фраза "Хочу добавить в Сервис/Программу то-то и то-то" ("Вот это вот в текущей версии не поддерживается" и т.п.) или акцент на версии программы. Главное чтобы пользователь это понимал, так как отношение к таким товарам иное.

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

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

Так же вам может быть интересен обзор Уникальность или Универсальность, что лучше?

Понравилась заметка? Тогда время подписываться в социальных сетях и делать репосты!