Хаотичные метания от одного “критичного” требования к другому не приведут к понятному и логическому результату, недовольство и разочарование продуктом, который не может обеспечить сквозную работу бизнес-процесса от начала и до конца, будут закономерно накапливаться. Такой подход приведет к отодвиганию сроков дедлайна вплоть до полнейшей неопределенности; чрезмерным трудозатратам, переработкам и быстрому таянию бюджета; фрустрации даже со стороны убежденных сторонников проекта.
Здесь на помощь приходит такое понятие, как MVP (minimal valuable product) – минимально жизнеспособный продукт, самая ранняя версия доработки, у которой есть минимальный набор функций, достаточный для презентации и проверки на первых потребителях.
Конечно, MVP является лишь частью процесса рождения продукта, однако для полного разбора цикла разработки потребуется отдельная статья. А пока разберем понятие MVP, его выделение, внедрение и отличие от других этапов процесса разработки, например, прототипирования.
MVP vs. Прототип
В первую очередь выясним, чем понятие MVP отличается от прототипа.
"Прототип – это чаще всего неработоспособный макет, показывающий, как будет выглядеть решение. Поработать в прототипе пользователям не удастся – в нем нет многих важнейших функций. Максимум, который может дать вам прототип, это предметный разговор о том, как будет выглядеть конечный продукт, например, сайт, после разработки, а также показать ценность продукта для пользователей и инвесторов" – Екатерина Косарева, бизнес-аналитик Onellect.
Многие IT-компании, увлеченные своим продуктом, на brainstorm-встречах создают самые разнообразные прототипы, начиная от бумажных макетов и заканчивая конструкторами LEGO. Простейший пример прототипа с элементами кликабельности – дизайнерский макет сайта в Figma.
MVP же, в отличие от прототипа, не показывает продукт – он им является. Как было отмечено выше, в MVP вполне можно пустить тестовую или даже рабочую группу пользователей, чтобы собрать обратную связь и определить дальнейшее развитие доработки.
Чем точно схожи MVP и прототип, так это тем, что при разработке и того и другого команда стремится потратить минимум усилий при максимуме выгоды для проекта.
Когда необходим MVP
И прототип, и MVP на самом деле являются опциональными шагами в процессе разработки, от которых можно отказаться и разрабатывать конечное решение без ориентиров на тестовые группы и демо-период. Но есть ситуации, в которых MVP действительно необходим:
- Тестирование гипотез или проверка рынка. Например, такие проверки требуются в стартап-компаниях или в компаниях-гигантах при выводе экспериментального функционала на рынок.
- Действительно большой проект. Создание нового продукта, разбитое на этапы и включающее множество связанных логик, но объединенное единой целью.
- Масштабная разветвленная доработка, к примеру, коннектор между системами.
- Горящие сроки внедрения функционала.
Выделение MVP
Самый простой способ выделить MVP из общего процесса: вместе с командой пройтись по каждому элементу и задать вопрос «Будет ли всё работать, если это убрать?». Вычеркнуть таким образом из сценария все необязательные требования и… Пройтись снова.
При ответах необходимо помнить о следующем:
- Какова конечная цель функционала? Что он должен делать?
Например, если при внедрении доработки по интеграции 1С и CRM-системы конечной целью является возможность построить аналитику по движению денежных средств по заказам в CRM, то тщательно фильтровать данные, поступающие из выбранных регистров в 1С, на первом этапе не обязательно. Нужные данные можно будет отфильтровать в уже готовых отчетах.
- Вызовет ли удаление части логики нарушение цепочки в целом?
Например, если настраивается процесс ЭДО, то элемент согласования убирать из реализации нельзя – без успешного визирования документ не пройдет на этап подписания.
- Насколько критично требование?
Например, раскраска заказов в интерфейсе никак не влияет ни на цель, ни на логику процесса. Однако после обсуждения с руководителем отдела становится ясно, что регулировать обработку огромного количества потоковых записей без выделения просроченных сотруднику будет значительно сложнее.
Далее можно договориться о минимальной функциональности – не обязательно оставлять требование в первоначальном варианте – например, сделать временный дашборд по просроченным заказам, который можно быстро построить без применения кода, или автоматически сортировать заказы в реестре таким образом, чтобы сначала показывались записи с просроченной датой.
Посмотрим выделение MVP на реальном примере. По просьбе одного из клиентов нами была реализована доработка по присвоению категории покупателям. Требования к процессу были предварительно обговорены, и общий вид конечного решения представлял примерно такую схему:
После согласования с клиентом, схема значительно сократилась, не потеряв в основной логике – расчете категории покупателя менеджером. На рисунке ниже красным выделены удаленные элементы.
Внедрение MVP
Казалось бы, здесь всё понятно с первого взгляда. Выкладываем разработанное решение на продуктовую среду, даем доступы пользователям – и принимаем овации бизнеса. Но есть несколько моментов, о которых необходимо помнить еще на этапе разработки MVP:
- Определиться с пользователями. Перед выдачей доступов необходимо определиться, будет ли апробация решения производится на тестовой или основной рабочей группе. Например, некоторые демо-решения обкатываются на ограниченном числе людей, подходящих под определенные критерии, особенно если речь идет о выкладке решения в открытое интернет-пространство.
- Предупредить завышенные ожидания. Если MVP внедряется в реальный рабочий процесс, необходимо проинструктировать сотрудников о возможностях функционала, чтобы не столкнуться с неконструктивной реакцией.
- Подготовить формы обратной связи. Перед выкладкой необходимо подготовить формы для обратной связи от пользователей. Обратная связь чрезвычайно важна для дальнейшего роста и развития продукта.
- Не затягивать следующий релиз. Первая рабочая версия продукта – это конечно хорошо, однако надолго застревать в этой стадии не стоит. Технические возможности для масштабирования решения должны быть подготовлены еще на начальном этапе. Самый плохой сценарий здесь – когда из-за ограничений, введенных разработчиками на этапе MVP, дальнейший рост и развитие решения невозможны.
Точки роста
После успешной обкатки MVP встает вопрос его дальнейшего развития в полноценный продукт. И здесь можно выделить как минимум два подхода:- Внедрение доработок, отброшенных на этапе выделения MVP. Такой подход выбирают, как правило, если обкатка прошла по плану и не было выявлено значительного расхождения с изначальными бизнес-требованиями.
- Пересмотр изначальных требований с учетом реальных условий. Этот подход подойдет в случае, если на практике оказалось, что выстроенные в теории бизнес-процессы расходятся с реальностью. При таком подходе особенно важна обратная связь.
Коннектор BPMSoft – Webinar
- Можно дальше модернизировать стандартный процесс поиска и создания контактов, пришедших через вебинарную площадку – добавить теги, фильтрацию.
- Можно использовать несколько настроек интеграции: индивидуально для каждого мероприятия или в зависимости от разбивки мероприятий по типам.
- Можно отрегулировать фильтрацию участников вебинара в зависимости от их статуса участия в мероприятии.
Коннектор BPMSoft – Контур.Диадок
- Можно настроить двусторонний обмен данными с «Контур.Диадок», например, прием и подписание входящих документов от контрагентов.
- API «Контур.Диадок» обладает широкими возможностями расширения логики обработки документов разных типов: их отправки и приемки, а также работы с сотрудниками, занесенными в контур системы – управление их доступами и доверенностями.
Интеграция BPMSoft с личным кабинетом на сайте
- логику в данной доработке можно усложнять и дорабатывать в зависимости от потребностей заказчика, но, возможно, потребуются дополнительные данные для передачи – например, суммы продажи по лиду или иная информация.
Заключение
MVP – не обязательный, но важный шаг процесса разработки, который может сэкономить ваше время, бюджет и вовремя скорректировать движение проекта. Основным бонусом при начале проекта со стадии MVP является быстрое вовлечение пользователей в рабочий процесс и получение обратной связи.
Конечно, для того, чтобы начать работать с MVP, необходима подготовка, в том числе, верная декомпозиция задач проекта и отсечение требований, неважных на первом этапе. Однако в перспективе этот нюанс окупается положительным настроем всех участников, экономией средств и быстрым и понятным продвижением продукта по релизам.