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

Для бизнеса важно сразу делать правильно, чтобы не тратить время и деньги на разработку впустую. В таких случаях он стремится проверить гипотезы и понять, обладает ли продукт достаточным набором полезных и уникальных функций, с помощью MVP. Напомним, саму концепцию и термин ввел в оборот соучредитель и президент консалтинговой компании SyncDev Фрэнк Робинсон. В его понимании MVP – продукт с минимальным риском и максимальным профитом, результат одновременной разработки и исследования (целевой аудитории, ее реакции на продукт). Именно с этой точки зрения мы и будем его рассматривать. Поделимся проверенным советами из практики SimbirSoft и расскажем, как создать MVP, чтобы в итоге получить качественный результат.

Начинаем с определения целей MVP и создания команды

Как показывает практика, начинать работу над проектом стоит с определения целей и критериев их достижения. Здесь важно понять, что вы ждете от MVP, какую гипотезу хотите проверить и как потом будете интерпретировать результаты. Далее можно приступать к формированию команды. Её базовый состав обычно состоит из следующих ролей: product owner, product manager, аналитик, UX/UI-дизайнер, разработчик и QA, потенциальные клиенты. Причем это не обязательно должны быть разные люди, перечисленные роли можно совмещать.

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

• Исследовать рынок и конкурентов: были ли у них подобные идеи, что получилось, а что нет.
• Провести мозговой штурм и формализовать идею продукта, его ключевые особенности, киллер-фичи, которые помогут выделиться на фоне конкурентов или «взорвут» рынок.

Рассмотрим на примере. К нам обратился клиент из сферы логистики. В качестве новой для его бизнеса киллер-фичи он решил внедрить RFID-метки для учета и контроля ресурсов (перемещения продукции, сырья, иных движимых и движущихся активов) и процессов работы сотрудников на складе. В рамках реализации MVP мы выделили объем задач. Автоматизации основных процессов одной линии производства было достаточно для подтверждения наших гипотез:

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

в) ускорение процессов учета продукции и сырья,

г) минимизация ошибок сборки и отгрузки заказов,

д) контроль доступа в зоны предприятия.

        Рис. 1. Пример работы системы мониторинга при помощи RFID-меток.

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

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

Например, если разрабатывается решение для управления внутренними процессами бизнеса (как выше в примере с RFID-метками), то в данном случае можно обойтись без дизайна и UX. Для проверки гипотезы применения RFID-технологии на складе главное сделать его работоспособным.

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

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

Понять, какие фичи нужно включить в MVP, поможет анализ рынка. Начать  лучше с изучения того, чем пользуются клиенты, проанализировать их отзывы о существующих аналогах. Согласно исследованиям The Standish Group, примерно 60% пользователей обходятся базовыми функциями приложений и программ, не используя дополнительные фишки. Далее минимальный набор необходимых характеристик включаем в MVP и дополняем уникальными фичами, из-за которых и возникла идея создания продукта.

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

• Изучить способы быстрой реализации MVP, чтобы выбрать подходящий именно для вашего минимально жизнеспособного продукта и целей его реализации. Разрабатывать его можно своими силами или передать на аутсорсинг. Сегодня многие компании наращивают собственные ИТ-отделы. Но если у вас его нет, специально создавать подразделение для разработки MVP — не лучшее решение. Это потребует времени на поиск специалистов, их обучение и погружение в проект. А в итоге может оказаться, что гипотеза не подтвердится и отдел вам будет не нужен. В случае с MVP иногда бывает эффективнее нанять готовую команду. И как показывает практика, для ускорения и усиления процесса разработки, бизнес обращается к экспертизе аутсорсеров с релевантным опытом и портфолио проектов в интересующей области.

• Затем взять паузу на пару дней и проанализировать идею еще раз.

Разрабатываем концепцию MVP для оценки предполагаемых затрат

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

• Роли пользователей и User stories

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

• Бизнес-процессы.

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

• Нефункциональные требования и ограничения.

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

Например, если компания продает обувь, нужно будет учесть требования национальной системы цифровой маркировки и прослеживаемости товаров Честный ЗНАК.

• Логическая модель данных.

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

Имея на руках такое мини-ТЗ в виде концепции, уже можно иметь представление о затратах, необходимых для создания MVP (как по стоимости, так и по срокам).

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

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

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

Например, один из клиентов пришел с идеей продукта, который помог бы ему осуществлять дополнительные продажи в рамках действующего бизнеса. Свою идею он хотел презентовать инвесторам на конференции через 4 недели. Для ускорения работ мы подключили команду экспертов, которые имели опыт работы с проектами подобной сферы бизнеса. Концепция формировалась «на лету», список фич и требований для будущего интерактивного приложения составлялись командой в тесном сотрудничестве с клиентом. В итоге за 3 недели мы прошли путь от аналитики и дизайна до разработки и тестирования. При этом несколько раз пересмотрели реализацию продукта и заложили бэклог (список рабочих задач) на дальнейшее развитие, предусмотрев архитектуру с точки зрения возможности масштабирования продукта.

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

Думаем о том, что будет после MVP

Обычно уже на этапе создания MVP стоит подумать о том, что вы будете делать с MVP дальше, если проект «выстрелит». Наш опыт показывает, что, как правило, есть два варианта:

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

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

При этом доработка MVP может быть так же масштабна, как и первый вариант.

Собираем обратную связь пользователей и делаем выводы

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

Комбинирование различных способов сбора фидбека позволяют перепроверить информацию. Это могут быть:

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

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

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

________________________

Для справки:

SimbirSoft — глобальная ИТ-компания с опытом в разработке и тестировании ПО с 2001 года, которая объединяет 1400+ сотрудников из 50+ городов России. Разрабатывает системы для автоматизации работы бизнеса, высоконагруженные системы, мобильные приложения, встроенное ПО и блокчейн-проекты, Machine Learning и Data Science для заказчиков из России, Европы и США. Темпы роста и качество услуг подтверждены сертификатом ISO 9001:2015, международными наградами и рейтингами (Global Outsourcing 100, RAEX, RUSSOFT AWARD, CNews, Tadviser и Tagline).

Автор — руководитель направления бизнес-решений глобальной ИТ-компании SimbirSoft Анна Шведова.

*материал опубликован на правах рекламы.

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