1. Главная
  2. Блог Onellect
  3. Полезные статьи
  4. MVP: как создать минимально жизнеспособный продукт

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

2 августа 2023
1064
Итак, вы внедряете в систему новый функционал или даже создаете свой продукт с нуля: решение принято, исполнители назначены, бюджет утвержден, а сроки известны. И здесь встает закономерный вопрос: с чего начать? Хочется реализовать всё и сразу, чтобы бизнес начал полноценно работать в системе, ни одна часть логики не потерялась, а Иван Палыч из отдела продаж мог раскрасить свои задачки в те цвета, которые ему нравятся.

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

Здесь на помощь приходит такое понятие, как MVP (minimal valuable product) – минимально жизнеспособный продукт, самая ранняя версия доработки, у которой есть минимальный набор функций, достаточный для презентации и проверки на первых потребителях.

MicrosoftTeams-image (207).png


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

MVP vs. Прототип


В первую очередь выясним, чем понятие MVP отличается от прототипа.

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

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

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

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

Когда необходим MVP 


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

  • Тестирование гипотез или проверка рынка. Например, такие проверки требуются в стартап-компаниях или в компаниях-гигантах при выводе экспериментального функционала на рынок. 
  • Действительно большой проект. Создание нового продукта, разбитое на этапы и включающее множество связанных логик, но объединенное единой целью.  
  • Масштабная разветвленная доработка, к примеру, коннектор между системами.  
  • Горящие сроки внедрения функционала.  

Выделение MVP 


Самый простой способ выделить MVP из общего процесса: вместе с командой пройтись по каждому элементу и задать вопрос «Будет ли всё работать, если это убрать?». Вычеркнуть таким образом из сценария все необязательные требования и… Пройтись снова.  

При ответах необходимо помнить о следующем:  

  • Какова конечная цель функционала? Что он должен делать?
    Например, если при внедрении доработки по интеграции 1С и CRM-системы конечной целью является возможность построить аналитику по движению денежных средств по заказам в CRM, то тщательно фильтровать данные, поступающие из выбранных регистров в 1С, на первом этапе не обязательно. Нужные данные можно будет отфильтровать в уже готовых отчетах.  
  • Вызовет ли удаление части логики нарушение цепочки в целом?  
    Например, если настраивается процесс ЭДО, то элемент согласования убирать из реализации нельзя – без успешного визирования документ не пройдет на этап подписания. 
  • Насколько критично требование? 
    Например, раскраска заказов в интерфейсе никак не влияет ни на цель, ни на логику процесса. Однако после обсуждения с руководителем отдела становится ясно, что регулировать обработку огромного количества потоковых записей без выделения просроченных сотруднику будет значительно сложнее.  

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

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

MVP1.JPG

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

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

MVP2.JPG

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

Внедрение MVP 


Казалось бы, здесь всё понятно с первого взгляда. Выкладываем разработанное решение на продуктовую среду, даем доступы пользователям – и принимаем овации бизнеса. Но есть несколько моментов, о которых необходимо помнить еще на этапе разработки MVP: 

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

Точки роста 

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

  • Внедрение доработок, отброшенных на этапе выделения MVP. Такой подход выбирают, как правило, если обкатка прошла по плану и не было выявлено значительного расхождения с изначальными бизнес-требованиями.  
  • Пересмотр изначальных требований с учетом реальных условий. Этот подход подойдет в случае, если на практике оказалось, что выстроенные в теории бизнес-процессы расходятся с реальностью. При таком подходе особенно важна обратная связь.  
Приведем примеры теоретических точек роста для коннекторов, о которых мы писали ранее в статье "Интеграция через API: как работает, преимущества и кейсы".

Коннектор BPMSoft – Webinar

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

Коннектор BPMSoft – Контур.Диадок 

  • Можно настроить двусторонний обмен данными с «Контур.Диадок», например, прием и подписание входящих документов от контрагентов. 
  • API «Контур.Диадок» обладает широкими возможностями расширения логики обработки документов разных типов: их отправки и приемки, а также работы с сотрудниками, занесенными в контур системы – управление их доступами и доверенностями. 

Интеграция BPMSoft с личным кабинетом на сайте

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

Заключение 


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

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

8 (800) 777-31-67