My First Data Project 2: Создаем прототип продукта

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

Давай разберемся, что такое MVP и чем оно отличается от  PoC. 

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

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

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

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

Повторим еще раз.

Доказательство концепции - POC - это метод проверки предположений с помощью целевых пользователей и проверки технической осуществимости вашей идеи.

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

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

Есть несколько основных видов MVP:

Флинстоун MVP. 
  Это про имитирование наличия функционала, хотя на самом деле технически он никак не реализован. MVP нацелен на проверку гипотезы, доказательство жизнеспособности выбранной модели развития бизнеса.
  Можно сказать, что хорошо этот метод продемонстрировал Ник Свинмерн — основатель интернет-магазина Zappos. Он сделал сайт и опубликовал фото разных моделей обуви. Получил заказ, пошел в магазин, приобрел нужную пару и отправил покупателю. У него не было ни склада, ни всей логистики продаж, только их имитация.

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

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

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

 Зачем нужен MVP.

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

Какие можно выделить этапы создания MVP?

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

Распространенные ошибки MVP – это 

• Не нужно бояться сделать pivot*, если понимаете уже во время реализации MVP, что что-то не так
• И главное, нужно помнить, что MVP – это инструмент, а не цел

*Pivot – резкое изменение направления стартапа (продукта) с целью его дальнейшего развития и сохранения жизнеспособности

Еще у MVP есть альтернативы:  Minimum Viable Experiment MVE и Minimum Awesome Product MAP. Но на практике MVP самая простая и полезная концепция

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

• Мок, Фигма, Тильда (быстрый фронтэнд)
• Notion для доков (документация)
• Инструменты для генерации данных, Заглушки (датасеты)
• Скринкасты (демка)
• FastAPI (REST API)

Мы ожидаем, что по окончании модуля ты создашь план MVP.  И помни, что не бывает единственно верного решения.  Мы всегда готовы ответить на любые вопросы в нашем чате. Удачи!

Ждем от тебя: 

1. итоговую проработанную концепцию сервиса и как она работает 
2. продумывание технической части, видение (ТГ-бот, сайт, приложение)