Как передаются данные при mvp

MVP: что это такое и как работает?

Читая новости про проекты и сервисы, вы могли часто сталкиваться с понятием MVP. Но что скрывается под этой аббревиатурой и почему MVP так часто используют на начальных этапах развития продукта? Давайте прямо сейчас вместе разберемся в этом.

Что собой представляет MVP

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

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

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

Полезность разработки MVP доказывают примеры крупных на данный момент компаний. Например, Даниэль Эк и Мартин Лорентсон в 2006 году запустили небольшой сервис с одной функцией — потоковая передача музыки. Сегодня их продукт — Spotify — оценивается в $21 миллиард, сотрудничает с крупными звукозаписывающими студиями и имеет 50 миллионов человек активной аудитории.

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

MVP и PoC — одно и то же?

Proof of Concept (PoC) — доказательство правильности концепции и некоторые новички часто путают его с минимально жизнеспособным продуктом. PoC описывает процессы выяснения технической жизнеспособности концепции программного обеспечения (или любого другого продукта).

Да, эти определения взаимосвязаны, но не взаимозаменяемые. Proof of Concept — описание процессов на начальной стадии развития продуктов, которые потом реализуются фактически, из чего получается MVP.

Виды MVP

Есть много разных подходов к созданию минимально жизнеспособного продукта, но на практике чаще всего используют некоторые из них. Далее поговорим о наиболее популярных.

MVP Флинстоуна

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

Изначально у этого подхода было много критиков, мол, как можно что-то проверить, если ничего нет? Состоятельность метода доказал Ник Свинмерн — основатель интернет-магазина Zappos, стоимость которого в 2015 году «пробила» отметку в $2 миллиарда.

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

Консьерж MVP

Эта методология больше подходит для онлайн-сервисов, конечная цель которых — автоматизировать решение проблем целевой аудитории. На начальных этапах реализации продукта услуга оказывается вручную.

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

Эту модель в конце 90-х годов использовал Чак Темплтон — основатель сервиса по онлайн-бронированию ресторанов, билетов и многого другого. Он не стал сразу вкладывать сотни тысяч долларов в техническую реализацию сервиса, а бронировал для других людей столики в ресторанах вручную. Так он проверил жизнеспособность идеи, понял, кто, сколько и за что готов платить и познакомился с целевой аудиторией.

Разрозненный MVP

Метод разрозненного MVP используют, когда идею можно проверить и реализовать без разработки уникального программного обеспечения. Вместо этого собирают готовые инструменты, объединяют в одну систему и преподносят в едином интерфейсе.

Если бы все компании начинались с разработки уникальных решений, которая обходилась бы в сотни тысяч долларов, мы бы не увидели много крутых проектов. К этому, как правило, переходят после запуска, получения обратной связи и первых результатов.

Посмотрите на популярный сервис совместных покупок Groupon. Когда-то он был простеньким сайтом на WordPress, где все взаимодействие с пользователями осуществлялось по электронной почте. Только после получения первой обратной связи и финансовых результатов были разработаны социальные функции, полноценная email-рассылка, автоматизация и мобильное приложение.

Продукт с одним параметром

Эту разновидность используют чаще всего, когда есть готовый продукт с минимальным набором функций (как правило, одной). По такому принципу действовали основатели Spotify, которых упомянули в начале статьи.

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

Когда и для чего нужно делать MVP?

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

Но самое крутое в MVP — сбор ценной информации от первых пользователей. Именно конечный потребитель расскажет о правильной реализации проекта. Собранные данные используйте для планирования дальнейших обновлений и определения наиболее приоритетных целей: какие функции реализовать в первую очередь.

Как сделать MVP правильно

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

Нулевой этап: определяем основные принципы создания MVP

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

В ходе общего собрания обсудите следующие вопросы:

Как потратить минимум ресурсов? Помните, что на MVP должно быть потрачено минимум времени и сил. Вместе с командой разберитесь, как потратить мало денег, но при этом провести эффективное тестирование бизнес-идеи. Как правило, обсуждение этого вопроса помогает выбрать функции для реализации на начальном этапе развития продукта.
Как взаимодействовать с пользователями? Одна из главных целей создания MVP — тестирование гипотез, определение спроса и востребованности продукта. В этом помогает обратная связь от первых пользователей продукта. Чтобы не упустить ни капли важной информации, заранее продумайте все каналы взаимодействия с целевой аудиторией: отзывы, опросы, прямые интервью и т.п.
Как сделать первые продажи продукта? Первые продажи продукта дадут средства для начала разработки и покажут, интересна ли кому-то разработанная концепция. Хороший вариант — организовать сбор средств (предпродажи) на краудфандинговой площадке — Kickstarter (международная), Boomstarter (Россия), Planeta (Россия) и т.п.
Как будем продвигать продукт? На старте планируйте рекламную кампанию и используемые каналы. Основные инструменты — контекстная реклама Яндекс и Google. Далее осваивайте социальные сети — Facebook, ВКонтакте и Instagram. Создайте официальные страницы, запустите таргетинг. Кстати, брендированные сообщества — один из каналов сбора обратной связи. Разработайте продающий лендинг: опишите продукт, расскажите о функциях, пользе для клиента, дайте пользователям возможность выбора между платной и бесплатной версиями продукта. После обсуждения этого вопросы вы должны знать, по каким каналам будете продвигаться и сколько денег потратите.

Первый этап: поиск проблемы, которую решит MVP

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

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

Второй этап: находим целевую аудиторию

Распространенная ошибка начинающих продактов и предпринимателей — они считают, что их проект решает проблему широкой аудитории (всех людей). Такой подход в разы повышает вероятность провала. Сфокусируйтесь на определенной целевой аудитории.

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

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

Пример с сервисом по составлению финансовых планов для физических лиц:

25-34 лет;
мужчины;
40 000-80 000 рублей в месяц;
хотят погасить кредиты, накопить денежные средства, повысить качество жизни;
пользуются ПК и смартфон;
испытывают нехватка заработной платы до конца месяца.

Третий этап: определяем основных конкурентов

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

Эту гипотезу подтверждает история с разработкой радио. В России считают, что его изобрел Александр Попов, а вот в Италии лавры отдают Гульельмо Маркони. Оба начали работать над реализацией идеи в 1894 году, но Попов свою разработку презентовал в марте 1896 года (но при этом не запатентовал), а Маркони в июне 1896 года подал документ на патент. Кстати, есть еще несколько ученых в разных странах, которые также претендуют на звание «создатель Радио».

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

Соберите максимум информации об основных конкурентах. Проанализируйте трех самых крупных игроков рынка: изучите историю развития, посмотрите предлагаемые продукты, ознакомьтесь с конкурентными преимуществами и оцените способность предложить что-то лучше.
Определите рыночные доли основных конкурентов. Рассмотрите деятельность компаний со всех сторон, определите их стратегии, объемы продаж, рассчитайте рентабельность и т.п. Так вы поймете, насколько они успешны и как можно опередить их в конкурентной борьбе (а главное, сколько на это придется потратить ресурсов).
Изучите первичные источники информации. Все, что публикуют конкуренты о своей деятельности, — первичные источники данных. Поэтому посмотрите их официальные сайты, презентации, «белые книги», годовые отчеты, рекламные материалы и т.п. Это поможет разобрать деятельность конкурентов по кирпичикам и даст новые идеи для развития продукта.
Изучите вторичные источники информации. Новости, видео, обзоры, интервью, оценки и т.п. — вторичные источники информации. Их публикуют СМИ, независимые отраслевые сайты и многие другие. Сбор информации из вторичных источников поможет глубже понять выбранную отрасль и изучить «правила игры». Но при этом не забывайте, что далеко не все дают достоверную информацию.
Посетите отраслевые мероприятия. Ваши конкуренты презентуют продукцию или услуги на конференциях, выставках и любых других подходящих для этого площадках. Чтобы собрать максимум информации и задать интересующие вопросы, посещайте такие мероприятия. В большинстве случаев они бесплатны, поэтому потратить придется только свободное время.

Для удобства советуем составлять сводную таблицу со всей собранной информацией. Впоследствии будет проще ориентироваться в больших массивах данных и принимать какие-либо решения.

Четвертый этап: проводим SWOT-анализ

SWOT-анализ представляет собой таблицу, состоящую из четырех блоков:

сильные стороны;
слабые стороны;
возможности;
угрозы.

Не расписывайте пункты на целые абзацы. Они должны быть короткими и понятными для всей команды.

Обратите внимание, что таблица разделена на две части. Сильные и слабые стороны, как правило, относятся к внутренним факторам, а возможности и угрозы — к внешним.

Цель SWOT-анализа выявить сильные стороны и возможности, чтобы сосредоточить работу на них для минимизации негативных последствий от слабых сторон и угроз. Сделанные выводы помогут выбрать стратегию развития и позиционирования бизнеса на рынке.

Пятый этап: создаем карту пути пользователя

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

Чтобы избежать такого недоразумения, на пятом этапе создания минимально жизнеспособного продукта составляют карту пути пользователя — что делает пользователь при взаимодействии с продуктом. Вы должны понимать, какие у аудитории требования к контенту, дизайну, интерфейсу.

Кстати, не забывайте корректировать карту пути пользователя (user flow) после получения обратной связи от первых клиентов. Они расскажут, что хорошо, а что плохо или неудобно. На основе этого корректируйте карту, чтобы конечный потребитель получал то, что хочет.

Например, для сервиса по финансовому планированию сделали такую карту:

выбор периода планирования;
добавление активов, пассивов, доходов и расходов;
аналитика финансового плана;
постановка целей и отслеживание прогресса достижений.

Шестой этап: составляем перечень функций продукта

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

Дальше для каждого взаимодействия определяется перечень функций. Здесь помогут логика и пользовательские истории. В первом случае самостоятельно или вместе с командой подумайте, что нужно сделать для обеспечения того или иного взаимодействия.

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

Дальше расставьте все функции по приоритету. Самые востребованные (которыми пользуются чаще всего) ставим в начало списка, редко используемые — в конец. Должна получиться вот такая карта:

Седьмой этап: определяем функции MVP

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

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

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

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

Восьмой этап: выберите метод управления и разработки

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

Lean.
Scrum.
Канбан.
Экстремальное программирование (XP).

Девятый этап: проводите тестирования

Тестируйте MVP короткими итерациями: альфа- и бета-тестированием. Альфа — внутренний этап: закончили разработку, пользуйтесь продуктом внутри команды несколько дней. Если все окей, запускайте бета-тестирование — внешний этап, дайте доступ к проекту первым пользователям. Длительность: 7-14 дней.

После первой беты соберите отзывы, статистику посещений, аналитику поведений и проанализируйте весь массив данных. Так вы узнаете, что надо доработать, что можно убрать, а что, наоборот, надо добавить в срочном порядке.

Несколько итераций «разработка-альфа-бета» помогут прийти к оптимальной первой версии продукта, который можно выпускать на рынок для массового пользователя и продолжать дорабатывать.

Еще раз поговорим всю последовательность этапов:

Определение основных принципов создания MVP.
Поиск проблемы, которую решит MVP.
Поиск целевой аудитории.
Определение и анализ основных конкурентов.
Проведение SWOT-анализа.
Создание карты пути пользователя.
Составление перечня функций продукта.
Определение объема MVP.
Выбор метода управления и разработки.
Проведение тестирований.

Самые распространенные ошибки при создании MVP

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

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

Попытки достигнуть идеала

Закройте в клетке своего перфекциониста, потому что в ходе разработки MVP он сыграет с вами злую шутку! Запомните, задача минимально жизнеспособного продукта — дать пользователю базовое представление о продукте, он априори не должен и не может быть идеальным.

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

Небрежная работа

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

Минимально жизнеспособный продукт должен быть простым, но качественным. Например, если делаете сервис, то купите хотя бы домен второго уровня, не надо оставлять его на поддомене какого-то бесплатного конструктора.

Отсутствие обратной связи

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

«Пустые» обещания

Когда «глаза горят», есть ощущение способности свернуть горы! И в такие моменты руководитель начинает делать анонсы крутых и необычайных возможностей. Конечно, это все здорово с точки зрения маркетинга, но если не сдерживать обещания, пользователи начнут покидать проект.

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

Отказ от анализа и аналитики

Окрыленность собственной идеей часто дурманит разум и вся команда перестает обращать внимание на объективные факты: плохие метрики, отрицательные отзывы и т.п. Начинают думать, что просто пользователи не все понимают сейчас, а вот когда финальная версия продукта будет готова, тогда они оценят.

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

Итак, подведем краткий итог: MVP — минимально жизнеспособный продукт, который делают для тестирования идей и гипотез, сбора обратной связи от первых потребителей (и да, MVP ≠ PoC). Реализовать можно за 10 этапов и постараться избежать наиболее распространенных ошибок. Если вы планируете создание нового продукта, начинайте с MVP: это позволит избежать больших ресурсных потерь в случае плохого потенциала идеи.

Ещё больше о MVP можно узнать на нашем годовом курсе «Профессия: Продакт (с 0 до PRO)» Узнать подробности

Блог компании ProductStar
Управление продуктом

Что такое MVP в IT? Что о нем нужно знать стартаперу, начинающему продакт-менеджеру и предпринимателю?

По статистике 92% проектов не станут полноценным бизнесом, «умерев» на этапе стартапа (исследование Startup Genome Report). В большинстве из них отсутствует ядро бизнеса — MVP (Minimal Viable Product, минимально жизнеспособный продукт). Чем MVP в IT отличается от MVP в общепринятом смысле и что об этом нужно знать стартаперу, начинающему продакт-менеджеру и предпринимателю, чтобы войти в те самые 8% успешных проектов, рассказываем в статье.

MVP как основа любого бизнеса

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

Иными словами, с MVP начинается любой бизнес. Он помогает еще на этапе стартапа понять, насколько продукт соответствует потребностям и ожиданиям клиента. Впервые о нем рассказал миру соучредитель и президент консалтинговой компании SyncDev Фрэнк Робинсон в 2001 году. С тех пор понятие MVP используется во многих областях для тестирования спроса при минимальных вложениях.

Если уже на этапе MVP вы видите, что потребители не заинтересованы в вашей идее, то в 99% случаев ваш гениальный бизнес обречен на провал. Как бы, наверняка, сказали в американском акселераторе стартапов «Y Combinator»: 100 продаж на этом вы точно не сделаете 🙁

Чем MVP в IT-сфере отличается от общепринятого понятия MVP

Большинство стартаперов и предпринимателей воспринимают MVP как возможность протестировать идею с минимумом затрат. При таком подходе значение MVP сильно упрощается и воспринимается не совсем верно.

Понятие минимального жизнеспособного продукта в IT-сфере нужно не только для тестирования спроса и гипотез с минимальными вложениями.

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

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

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

Какие задачи выполняет MVP

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

Тестирование MVP на клиентах также позволяет:

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

Как видите, MVP – понятие более объемное, чем тестирование спроса и гипотез с минимальным вложением средств.

Почему лендинг на Tilda – это еще не MVP

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

Стандартный лендинг сам по себе является посадочной страницей и решает только одну задачу – предоставляет потребителю информацию о продукте. У него нет и не может быть задачи закрыть всю технологическую составляющую полноценного сайта или сервиса.

Например, лендинг не может быть MVP онлайн-магазина, так как базовый сценарий в интернет-магазине – это покупка товара. Если на лендинге есть только витрина, но нет возможности оплатить товар, то он не обладает минимальной ценностью для клиента и по определению не может быть MVP.

Другой пример – сайты-агрегаторы. Главная ценность таких платформ – это экономия времени потребителя. Здесь уже собрана и структурирована информация с разных сайтов по определенной тематике. Все в одном месте и разбито по понятным категориям. В данном случае MVP – это наполненный сервис, в котором можно найти все необходимые данные.

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

Лендинг в таком случае тоже не может быть MVP, так как на одностраничном сайте технически невозможно разместить такое количество информации.

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

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

Подводя итоги

MVP или Minimal Viable Product (минимально жизнеспособный продукт) — продукт с минимальным

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

Он помогает еще на этапе стартапа понять, насколько продукт соответствует потребностям и ожиданиям клиента. При тестировании MVP уже можно оценить примерную окупаемость бизнеса.

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

MVP нужно IT-сфере, когда стоит задача ускорить, усовершенствовать взаимодействие с клиентом.

MVP в IT – не то же самое, что MVP в инфобизнесе. Лендинг из-за недостатка технических возможностей не может быть MVP.

MVP в IT – это дорого и долго, но этот «неидеальный» продукт обладает минимально необходимым функционалом для решения проблемы клиента.

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

MVP — это паттерн, который используют многие разработчики, даже если не догадываются об этом. Может, вы один из них?

Евгений Кучерявый

Пишет о программировании, в свободное время создаёт игры. Мечтает открыть свою студию и выпускать ламповые RPG.

MVP — это паттерн программирования графических интерфейсов. В нём приложение делится на три компонента:

Model (Модель) работает с данными, проводит вычисления и руководит всеми бизнес-процессами.
View (Вид или представление) показывает пользователю интерфейс и данные из модели.
Presenter (Представитель) служит прослойкой между моделью и видом.

Как и другие подобные паттерны (MVC, MVVM), MVP позволяет ускорить разработку и разделить ответственность разных специалистов; приложение удобнее тестировать и поддерживать.

Чаще всего его используют разработчики мобильных приложений, однако он гораздо популярнее, чем может показаться. Дело в том, что этот паттерн активно применяется в вебе, хотя там его и называют MVC:

Как работает MVP

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

Вид строит интерфейс и добавляет в него данные из модели.
Пользователь видит информацию и взаимодействует с интерфейсом.
Вид перехватывает события и передаёт (делегирует) их представителю.
Представитель обрабатывает данные (не всегда) и передаёт их модели.
Модель выполняет какие-то операции и обновляется (меняет те или иные свойства).
Представитель получает обновлённую модель и передаёт её виду.
Вид строит интерфейс с новыми данными.

Основное отличие MVP и MVC в том, что в MVC обновлённая модель сама говорит виду, что нужно показать другие данные. Если же этого не происходит и приложению нужен посредник в виде представителя, то паттерн стоит называть MVP.

Всё это можно сравнить с работой издательства:

Автор готовит текст (модель).
Текст получает издатель (представитель).
Если с текстом всё в порядке, издатель передаёт его в отдел вёрстки (вид).
Верстальщики готовят книгу, которую начинают продавать читателям (пользователи).
Если пользователи как-то реагируют на книгу, например, пишут письма в издательство, то работа может начаться заново. Допустим, кто-то может заметить в книге неточность, тогда издатель передаст информацию автору, автор её обновит и так далее.

Конечно, это не точный алгоритм работы издательства, но для иллюстрации принципов MVP его достаточно.

Пример MVP-приложения

Так как MVP служит для упрощения разработки графических интерфейсов, рассмотреть его можно на примере WPF-приложения. В качестве вида будут выступать файлы MainWindow.xaml (разметка интерфейса) и MainWindow.xaml.cs (обработчик событий).

Начать можно с создания интерфейса авторизации:

Теперь можно приступить к файлу MainWindow.xaml.cs:

Минимально жизнеспособный продукт: типы, методы, этапы построения

Там мы делимся «квинтэссенцией» своей экспертизы — постим выжимки статей, анализируем UX-решения, делаем разборы продуктов, делимся образовательными курсами и чек-листами.

Концепция минимально жизнеспособного продукта (или MVP) получила популярность после выхода в свет книги «Экономичный стартап». Её автор Эрик Рис понимал под этим понятием продукт, который имеет только основные и необходимые для работы функции. Но почему Рис называл стратегию критически важной для каждого стартапа?

В этой статье вы узнаете:

Что такое MVP?

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

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

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

Когда предприниматель запускает стартап, он может только гадать, оценят ли потребители его замысел, будут ли они использовать продукцию по назначению. Он предполагает, что у клиентов есть потребность, а продукт, над которым работает команда, удовлетворяет её. Чтобы узнать наверняка, необходимо представить клиентам MVP и собрать максимальный объем подтвержденной информации об их впечатлении от использования продукта.

Однако получение обратной связи от ЦА — не единственная польза от реализации MVP в бизнес-стратегии. Тестирование бета-версии на клиентах обеспечивает прямые и косвенные финансовые преимущества:

Тестирование бета-версии как возможность убедить инвесторов в выделении большого бюджета на завершение разработки;

Скорейший выпуск продукта на рынок — возможность получать прибыль до завершения процесса разработки;
Экономия средств на анализе рынка и ЦА.

Почему MVP важен для успешного развития бизнеса?

Стартапы предлагает товар или услугу, чтобы удовлетворить определённые потребности ЦА. Чем выше значимость проблемы для потребителя, тем ценнее предложенное решение. Реализация MVP позволяет на начальных этапах развития бизнеса установить, насколько продукт соответствует ожиданиям и нуждам клиента. Соответственно, руководство компании и инвесторы получают данные, необходимые для принятия решения о дальнейшей судьбе стартапа.

По статистике, провальными оказываются около 70% стартапов. Отчасти неудачи связаны с выпуском бесполезных или несвоевременных товаров. Вспомнить, например, легендарную историю появления пакетиков-стикеров для сахара. Их изобретатель хотел упростить пользователям жизнь. Он предполагал, что посетители кафе смогут разламывать пакетики посредине и высыпать содержимое, не проронив ни крошки. Однако клиенты кафе продолжали по привычке отрывать уголок пакетика. Гениальная, на первый взгляд, идея оказалась совершенно бесполезной на практике. И хоть позднее стикеры получили популярность благодаря удобству транспортировки, они не принесли прибыли своему изобретателю.

MVP помогает установить необходимую функциональность продукта и эффективно расходовать ресурсы производства исходя из целей, заданных на старте разработки.

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

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

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

Типы MVP

Существует множество подходов к созданию MVP. Давайте рассмотрим основные типы.

Волшебник страны Оз (иногда называют MVP Флинстоуна)

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

Nick Swinmurn, основатель Zappos, доказал, что данная стратегия работает. В самом начале он ни доллара не потратил на покупку обуви и аренду склада. Он опубликовал фотографии обуви на сайте. Как только покупатели начали заказывать обувь, он пошел в магазин, купил нужную пару и отправил ее. Осознав, что проект жизнеспособен, он обновил функциональность сайта.