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

5

Как передаются данные при 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. На нем вы должны разобраться, все ли члены команды понимают, зачем это нужно. Обсудите видение минимально жизненного продукта, сложите все воедино и постройте первый примерный план дальнейшей работы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Определение основных принципов создания MVP.
2. Поиск проблемы, которую решит MVP.
3. Поиск целевой аудитории.
4. Определение и анализ основных конкурентов.
5. Проведение SWOT-анализа.
6. Создание карты пути пользователя.
7. Составление перечня функций продукта.
8. Определение объема MVP.
9. Выбор метода управления и разработки.
10. Проведение тестирований.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое MVP, и как создать минимально жизнеспособный продукт

Чтобы добиться успеха с минимальными рисками и затратами в условиях, где закрывается 92% запущенных стартапов, каждый проект стоит начинать с запуска минимально жизнеспособного продукта. В этой статье мы разберем понятие, типы и этапы построения MVP.

MVP — подробное руководство по созданию минимально жизнеспособного продукта

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

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

Понятие MVP ввел в оборот в 2001 году Фрэнк Робинсон (Frank Robinson), соучредитель и президент консалтинговой фирмы SyncDev. Робинсон определяет MVP, как результат «синхронной разработки» — одновременного развития продукта и исследования целевой аудитории, ее реакции на продукт. MVP — такая версия будущего проекта, которая позволяет собрать максимум практических данных о том, как с ним взаимодействуют клиенты, при минимальных затратах.

Отличия MVP от PoC

MVP часто путают с PoC — Proof of Concept — доказательством правильности концепции. Эти понятия взаимосвязаны, но не равнозначны. В качестве PoC выступают: реакция потенциальных клиентов на анонс, число предзаказов, маркетинговые и социологические исследования и другие теоретические свидетельства того, что будущий продукт интересен рынку. MVP — больше, чем доказательство, это — работоспособный продукт.

Отличия MVP от прототипа

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

Задачи MVP

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

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

Пример MVP

Показательный пример MVP — мессенджер WhatsApp, который в момент публикации в 2009 году не имел функций для отправки сообщений.

Создатели WhatsApp — Ян Кум (Jan Koum) и Брайан Эктон (Brian Acton) исходили из простой идеи — создать мобильную телефонную книгу, которая бы показывала статус контакта: доступен, занят, на совещании, за рулем, в спортзале и так далее. Когда пользователи указывали статус, их контакты получали всплывающее уведомление.

Вскоре Кум и Эктон заметили, что пользователи стали использовать статусы для общения. Ухватившись за эту идею, они выпустили новую версию WhatsApp, в которой было больше функций, связанных с отправкой сообщений. В результате небольшая пользовательская база в считанные дни выросла до 250 000 человек, доказав, что разработчики на верном пути.

Преимущества MVP

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

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

Разновидности MVP

Среди многочисленных подходов к созданию Minimum Viable Product выделяют три основных подхода.

1. Продукт с единственным параметром

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

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

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

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

Так запустился сервис Groupon. На старте он представлял собой лишь примитивный сайт на основе открытого исходного кода. Все услуги Groupon оказывал по электронной почте. Социальные функции, полноценная email-рассылка, автоматизация, мобильное приложение — все это было разработано потом, когда стало ясно, что коллективные покупки востребованы.

3. Волшебник страны Оз и консьерж

Эти близкие разновидности Minimum Viable Product подразумевают отказ от длительной и дорогостоящей разработки в пользу ручного труда.

Герой сказки Фрэнка Баума (Lyman Frank Baum) изображал из себя волшебника, а MVP этого типа притворяются полнофункциональными сервисами и приложениями. На деле же, вместо алгоритмов работу Minimum Viable Product обеспечивают люди.

Волшебник страны Оз не афиширует этот факт. Так поступал основатель Zappos — крупного американского интернет-магазина. Чтобы убедиться в жизнеспособности идеи, он начал продажи задолго до того, как автоматизировал заказы и даже арендовал склады. Первых клиентов Ник Свинмурн (Nick Swinmurn) обслуживал лично, приобретая товары со скидками в рознице и перепродавая их.

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

Создание MVP: пошаговое руководство

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

1. Сформулируйте задачу

Каждый продукт создается для решения некой задачи, и речь не о получении прибыли. Здесь требуется клиентоориентированный подход. Для чего пользователю нужен продукт?

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

2. Определите аудиторию и выделите ее ядро

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

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

3. Изучите конкурентов

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

4. Проведите SWOT-анализ

Этот метод стратегического планирования используется крупными компаниями для принятия управленческих решений и формирования бизнес-политики с 1963 года. И хотя обычно он используется в куда большем масштабе, SWOT-анализ хорошо подходит для определения сильных и слабых сторон, возможностей и угроз для минимально жизнеспособного продукта.

5. Составьте карту путей

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

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

6. Выделите основные функции для реализации и рассчитайте объем MVP

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

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

7. Выберите подходящую методологию и разработайте MVP

Определив объем, порядок и направление работ, можно приступить к разработке минимального жизнеспособного продукта.

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

8. Протестируйте продукт

Минимально жизнеспособному продукту требуется регулярное тестирование на всем протяжении разработки. Альфа-тестирование проводится внутри команды силами тестировщиков, но для бета-тестирования потребуется помощь посторонних. Хорошо, если это будут люди из числа будущих пользователей. Желающих поучаствовать в тесте можно найти на таких сайтах, как BetaList, ProductHunt, Reddit, Quora или привлечь через собственные каналы связи: социальные сети, блоги и email-рассылку.

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

Запуск минимально жизнеспособного продукта

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

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

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

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

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

Model View Presenter (MVP) — это архитектурный паттерн и его назначение — отделение пользовательского интерфейса от данных приложения и методов их обработки (бизнес-логики). Это достигается путем введения дополнительного объекта — презентора. Диаграмма взаимодействия всех трех частей показана ниже:

Об этом паттерне написано, наверно, более 9000 статей, но достаточно редко встречаются описания, подкрепленные практическими примерами. Поэтому вначале я дам определения каждой составляющей этого архитектурного паттерна, потом рассмотрим совсем простое приложение для прояснения всех деталей, а затем (в следующей статье) уже рассмотрим реализацию MVP в программе NewStage2VK. Итак:

• Модель (Model) — это набор данных и методов их обработки, т.е. это бизнес-логика нашего приложения. Модель ничего не знает о существовании презентора и, тем более, представления. Она полностью независима.
• Представление (View) отвечает за визуализацию данных, которые получены от модели. Как, правило, модель только отображает данные, но в некоторых случаях возможно включение и простых алгоритмов расчета. Например, представление самостоятельно может подсчитать общее количество записей в таблице или итоговую сумму.
• Презентор (Presenter) — связующее звено между моделью и представлением. Он ответственен за обработку событий, возникающих в представлении, которые обычно инициированы пользователем, и в зависимости от типа события изменять состояние модели путем вызова ее публичных методов, после чего обновлять представление в соответствии с состоянием модели. Один презентор отвечает за взаимодействие с одним представлением.

Это достаточно отстраненные определения, и чтобы лучше в них разобраться рассмотрим совсем простое приложение DemoMVP, которое будет производить эмуляцию перевода денежных средств с одного счета на другой. При написании я использовал технологию WPF, которая сейчас стала более популярна, чем WinForms, однако, благодаря четкому разделению обязанностей приложение очень легко портируется и под WinForms. С другой стороны, в WPF обычно рулит шаблон проектирования MVVM (Model-View-ViewModel), но, возможно, это тема одной из будущих статей. На рисунке ниже представлена диаграмма основных классов:

Рассмотрим интерфейс модели IBankModel . Я выделил специальный интерфейс для модели, чтобы не привязывать ссылающиеся на нее классы (наш презентор) к конкретной реализации. В данном примере модель — это класс SimpleBankModel , который реализует интерфейс IBankModel . Создание прослойки в виде интерфейса позволит в дальнейшем нашу простую реализацию заменить на модель, которая работает с БД и сохраняет свое состояние, без изменения использующих ее классов. Реализация SimpleBankModel выглядит следующим образом:

Т.е. реализация достаточно тривиальна. Стоит обратить внимание на объект transaction . В данном случае он ничего не делает, но призван показать, что при совершении операций система сохраняет свое состояние, чтобы в случае каких-либо порблем смогла восстановить свое исходное состояние. Методов Withdraw (снять) и Deposit (зачислить) и объекта транзакции достаточно для того, чтобы обеспечить надежную систему по переводу денежных средств.

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

Обратите внимание, что ITransferView не содержит никаких ссылок на элементы управления, характерные для WPF. Это важный момент! Поэтому класс, который будет содержать ссылку на данный интерфейс, не сможет получить доступ к элементам управления. Он сможет обращаться к представлению только через четко обозначенный нами интерфейс. Таким образом и достигается независимость представления от других частей программы. Поэтому, чтобы сменить интерефейс нам достаточно будет переписать только класс MainWindow . Внешний вид окна показан на рисунке:

Теперь давайте взглянем, на код MainWindow и посмотрим, каким образом достигается реализация интерфейса ITransferView .

Здесь мы видим, каким образом реализация методов по обновлению баланса взаимодействует с существующими элементами управления WPF, а также, каким образом достигается отображение предупреждений и ошибок. Благодаря тому, что данный класс реализует интерфейс ITransferView , мы можем всего лишь в одном месте изменить реализацию методов ShowWarning и ShowError таким образом, чтобы отображать сообщения не окошками, а выводить их, например в Label где-то внизу окна. Что касается срабатывания событий, то здесь мы, по сути, просто пробрасываем события от элементов управления WPF в подходящие события ITransferView , предварительно поместив всю необходимую информацию из элементов управления формы в экземпляр соответствующего класса. В обработчиках событий txtSrcAccount_LostFocus и txtDestAccount_LostFocus мы реализовали логику проверки изменения номера счета. И события срабатывают только в том случае, если пользователь указал новый счет. Обработчик btnTransfer_Click дополнительно выполняет преобразование введенную строку в число и в случае, если обнаружена ошибка, то информирует об этом.

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

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

Мы рассмотрели все составляющие паттерна MVP. Теперь осталось нам создать экземпляры всех наших классов и запустить приложение. По умолчанию приложение WPF создает частичный класс приложения App и помещает точку входа — метод Main в автоматически генерируемый файл App.g.cs. Чтобы самому реализовать метод Main необходимо открыть свойства файла App.xaml и параметр «Действие при построении» изменить с «ApplicationDefinition» на «Page». Далее, нужно открыть содержимое файла App.xaml и удалить атрибут StartupUri=»MainWindow.xaml» . Теперь добавим в содержимое файла App.xaml.cs следующие строки:

Здесь мы создаем уже конкретный экземпляр модели и наполняем ее некоторыми объектами счетов. Затем создаем экземпляр представления и презентора, которому в конструктор и передаем нашу модель и представление. Далее идет стандартный код WPF по созданию экземпляра класса приложения и вызов метода Run , в который передается созданный ранее экземпляр окна (нашего представления).

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

Особенности реализации MVP для Windows Forms

Придумаем простую задачу — реализовать 3 экрана:
1) экран авторизации;
2) главный экран;
3) модальный экран изменения имени пользователя.
Должно получиться что-то вроде этого:

Немного теории

MVP, как и его родитель, MVC (Model-View-Controller) придуман для удобства разделения бизнес-логики от способа ее отображения.

На просторах интернета можно встретить целое множество реализаций MVP. По способу доставки данных в представление их можно разделить на 3 категории:
— Passive View: View содержит минимальную логику отображения примитивных данных (строки, числа), остальным занимается Presenter;
— Presentation Model: во View могут передаваться не только примитивные данные, но и бизнес-объекты;
— Supervising Controller: View знает о наличии модели и сам забирает из нее данные.

Далее будет рассматриваться модификация Passive View. Опишем основные черты:
— интерфейс Представления (IView), который предоставляет некий контракт для отображения данных;
— Представление — конкретная реализация IView, которая умеет отображать саму себя в конкретном интерфейсе (будь то Windows Forms, WPF или даже консоль) и ничего не знает о том, кто ей управляет. В нашем случае это формы;
— Модель — предоставляет некоторую бизнес-логику (примеры: доступ к базе данных, репозитории, сервисы). Может быть представлена в виде класса или опять же, интерфейса и реализации;
— Представитель содержит ссылку на Представление через интерфейс (IView), управляет им, подписывается на его события, производит простую валидацию (проверку) введенных данных; также содержит ссылку на модель или на ее интерфейс, передавая в нее данные из View и запрашивая обновления.

Какие плюсы нам дает малая связанность классов (использование интерфейсов, событий)?
1. Позволяет относительно свободно менять логику любого компонента, не ломая остального.
2. Большие возможности при unit-тестировании. Поклонники TDD должны быть в восторге.
Начнем!

Как организовать проекты?

Условимся, что решение будет состоять из 4х проектов:
— DomainModel — содержит сервисы и всевозможные репозитории, одним словом — модель;
— Presentation — содержит логику приложения, не зависящую от визуального представления, т.е. все Представители, интерфейсы Представлений и остальные базовые классы;
— UI — Windows Forms приложение, содержит только лишь формы (реализацию интерфейсов Представлений) и логику запуска;
— Tests — unit-тесты.

Что писать в Main()?

Стандартная реализация запуска Windows Forms приложения выглядит так:

Но мы условились, что Представители будут управлять Представлениями, следовательно хотелось бы, чтобы код выглядел как-то так:

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

Создать форму и реализовать в ней интерфейс ILoginView не составит труда, как и написать реализацию ILoginService. Следует только отметить одну особенность:

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

А тесты будут?

С момента написания представителя (LoginPresenter), появляется возможность сразу же его от-unit-тестировать, не реализуя ни формы, ни сервисы.
Для написания тестов я использовал библиотеки NUnit и NSubstitute (библиотека создания классов-заглушек по их интерфейсам, mock).

Тесты довольно глупые, как пока и само приложение. Но так или иначе, они успешно пройдены.

Кто и как запустит второй экран с параметром?

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

Но мы условились, что представители ничего не знают о представлениях кроме их интерфейсов. Что же делать?
На помощь приходит паттерн Application Controller (реализован упрощенно), внутри которого содержится IoC-контейнер, знающий, как по интерфейсу получить объект реализации.
Контроллер передается каждому Представителю параметром конструктора (снова DI) и реализует примерно следующие методы:

После небольшого рефакторинга запуск приложения стал выглядеть так:

Пару слов о new ApplicationController(new LightInjectAdapder()) . В качестве IoC-контейнера я использовал библиотеку LightInject, но не напрямую, а через адаптер (паттерн Adapter), чтобы в случае, если понадобится сменить контейнер на другой, я смог написать другой адаптер и не менять логику контроллера. Все используемые методы есть в большинстве IoC-библиотек, сложностей возникнуть не должно.
Реализуем дополнительный интерфейс

Нельзя просто так взять и закрыть форму.

Один из подводных камней связан со строчкой View.Close() , после которой закрывалась первая форма, а вместе с ней и приложение. Дело в том, что Application.Run(Form) запускает стандартный цикл обработки сообщений Windows и рассматривает переданную форму как главную форму приложения. Это выражается в том, что приложение вешает ExitThread на событие Form.Closed , что и вызывает закрытие приложения после закрытия формы.
Обойти данную проблему можно несколькими способами, один из них — использовать другой вариант метода: Application.Run(ApplicationContext) , затем вовремя подменяя свойство ApplicationContext.MainForm . Передача контекста формам реализована с помощью Контроллера приложения, в котором регистрируется объект (instance) ApplicationContext и затем подставляется в конструктор формы (опять DI) во время запуска Представителя. Методы отображения первых двух экранов теперь выглядят так:

Модальное окно

Реализация модального окна не вызывает затруднений. По кнопке «Сменить имя» выполняется Controller.Run<ChangeUsernamePresenter, User>(user) . Единственное отличие этой формы от остальных — она не главная, поэтому форме для показа не требуется ApplicationContext:

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

Ну и накрутили. Как теперь ЭТО использовать?

1. Пишем интерфейс Представления, интерфейс Модели (если требуется).
2. Реализуем Представителя, попутно решив, будем ли мы в него передавать какие-то данные или модель.
3. [Опционально] Пишем тесты для Представителя, убеждаемся, что все нормально.
4. [Опционально] Реализуем Модель и тесты для нее.
5. Накидываем формочки и реализуем интерфейс Представления.

Забрать демонстрационный проект можно c Github (для сборки необходимо выкачать Nuget-зависимости).

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

Бонус. Хочу еще круче, больше, сложнее!

На этом я остановлюсь, а пытливые умы могут идти дальше:
— улучшение Контроллера приложения (у меня написан немного упрощенный вариант);
— реализация агрегирования событий для обмена информацией между формами (шаблон Event Aggregator);
— дальнейшее изучение шаблона по ссылкам ниже

Как правильно реализовывать модель MVP?

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

View реализация

Presenter реализация

Модель и вызов

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

Ну соответственно при нажатии на кнопку Search я не могу обновить UI, неужели придется в Presenter пробрасывать сам TextBox в ICustomer и вызывать BeginInvoke? Или я просто чего-то недопонимаю в реализации MVP?

UPD:

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

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

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

1. Одноклеточные

Определимся с компонентами паттерна и тем, какие элементы приложения к ним относятся.

M — Model — отдельный класс инкапсулирующий работу с данными. Все операции над данными производятся только в нем. Если рассматривать модель под микроскопом, то в ней можно рассмотреть много-поточную или асинхронную обработку тяжелых вычислений, обращения к сервисам и базам данных и прочие слои свойственные моделям.

V — View — визуальное представление данных модели. Сюда можно отнести все контролы нашей, пока единственной, формы, которые собственно отображают нашу модель с выбранного ракурса.

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

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

2. Многоклеточные

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

Добавим класс-презентер, для которого в качестве представления будут выступать наши одноклеточные описанные выше. Его главная задача — передать частным перезентерам нужный кусочек модели для работы, агрегировать события от них и передавать эти события в нужном порядке и количестве в модель, а также маршрутизировать события модели к частным презентерам. Для частных презентеров — общий будет выступать в роли модели. Также в нем можно реализовать много-поточное/асинхронное обращение к модели, т.к. он связан только с моделью и подчиненными презентерами, а не элементами UI, за которые отвечают частные презентеры.

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

3. Меняем паттерн

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

Тут самое время вспомнить, что WinForms поддерживает DataBinding. А в связи с этим можно немного поменять шаблон. В сети он часто упоминается как MVPVM.

Тут появляется новый компонент — VM — view-model, и роль презентера немного меняется. VM — по сути, срез модели для отображения. В задачи презентера теперь не будет входить передача данных в подчиненные вьюхи, а только создание биндингов к нужным VM, привязка биндингов к вьюхам и обработка событий. И мы в принципе можем отказаться от общего презентера, т.к. при создании очередного контрола можно просто передавать в него нужную VM, а остальное он сделает сам. Правда в сложных случаях нам все еще будет нужен агрегатор для событий, особенно если события от разных контролов взаимосвязаны или конфиликтуют между собой.

Эта модель позволяет наиболее гибкое расширение функционала и массштабирование приложения.

4. Заключение

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

Ну соответственно при нажатии на кнопку Search я не могу обновить UI, неужели придется в Presenter пробрасывать сам TextBox в ICustomer и вызывать BeginInvoke? Или я просто чего-то недопонимаю в реализации MVP?

По предложенным мной вариантам, вы используете второй вариант, и единственно чего в нем не хватает — это события в CustomerPresenter о том что поиск завершен и можно забирать данные для отображения, на которое сможет подписаться форма. Или определить в ICustomer и реализовать в форме Customer метод DataUpdate (или переопределить метод Control.Update формы) и вызывать его из CustomerPresenter когда поиск завершен и к результатам можно получить доступ из основного потока.

• кнопкой (или другим действием) на форме Customer передаем запрос на поиск в CustomerPresenter .
• CustomerPresenter передает запрос в модель
• модель активирует поиск отдельным потоком. Компоненты основного потока с этого момента свободны для другой полезной работы.
• посик завершен, результаты загружены в модель. Модель активирует событие о том, что поиск завершен.
• CustomerPresenter получает событие о завершении поиска, получает результаты поиска из модели и:
  1. вызывает метод UpdateData (примерное название) у формы и передает результаты поиска в параметрах.
  2. активирует событие завершения длительной операции
• Customer , получает результаты поиска у CustomerPresenter , как именно зависит от предыдущего пункта, и отображает их.

Простоя в работе интерфейса во время поиска нет.

Можно и по имеющемуся сценарию:

• кнопкой (или другим действием) на форме Customer передаем запрос на поиск в CustomerPresenter .
• CustomerPresenter в отдельном потоке вызывает метод поиска в модели. Компоненты основного потока с этого момента свободны для другой полезной работы.
• После завершения в потоке поиска с помощью Invoke:
  1. вызываем метод UpdateData (примерное название) у формы и передает результаты поиска в параметрах.
  2. активируем событие завершения длительной операции
• Customer , получает результаты поиска у CustomerPresenter , как именно зависит от предыдущего пункта, и отображает их.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В сборе информации помогут специальные аналитические инструменты: Similar Web, Ahrefs, Quantcast, App Annie, AppFollow и другие. Соберите данные о популярности конкурентов, ежемесячном трафике, основных интересах целевой аудитории, географическом расположении клиентов и т.п.

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

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

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

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

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

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

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

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

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

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

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

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

Провели первые тестирования, за два месяца в поддержку написали несколько человек: «у нас были финансовые планы в Excel, пришлось потратить часа два, чтобы все данные перенести в ваш сервис». Что делаем? Правильно! Добавляем функцию экспорта существующих в Excel финансовых планов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Определение основных принципов создания MVP.
2. Поиск проблемы, которую решит MVP.
3. Поиск целевой аудитории.
4. Определение и анализ основных конкурентов.
5. Проведение SWOT-анализа.
6. Создание карты пути пользователя.
7. Составление перечня функций продукта.
8. Определение объема MVP.
9. Выбор метода управления и разработки.
10. Проведение тестирований.

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

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

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

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

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

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

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

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

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

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

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

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

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