Если вы находитесь на этапе, когда рассматриваете возможность создания MVP, вы, вероятно, уже добились нескольких целей на пути разработки продукта. Ключевые достижения будут включать в себя успешное создание, тестирование и оценку Proof of Concept (PoC), обеспечение технологической осуществимости и применяемого подхода для решения проблемы. Для решений ИИ и машинного обучения это выходит за рамки стандартных соображений программного обеспечения, и вы тщательно протестируете свою модель, чтобы убедиться, что прогнозы (выходные данные) удовлетворяют определенным показателям. Все это создает основу для бизнес-кейса, основанного на технической осуществимости и коммерческой жизнеспособности.

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

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

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

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

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

1. Начните с пользователя.

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

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

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

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

Вопрос. Кто этот пользователь?

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

Вопрос. Какие действия пользователя выполняются с продуктом?

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

Вопрос. Каков итог пути пользователя?

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

В. Какую ценность или преимущества необходимо создать для пользователя на протяжении всего пути или в конце его пути?

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

2. Определить основные функции и результаты продукта и сосредоточиться на них.

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

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

Например, если вы хотите разработать «традиционную» платформу программного обеспечения как услуги (SaaS), которая предоставляет конкретную услугу — будь то CRM-система, инструмент визуализации данных или приложение — основные функции продукта будут включать веб-приложение, вход в систему , аутентификацию учетных данных и разработку рабочих процессов, отвечающих за предоставление базовой службы. Значительное время и усилия будут потрачены на разработку внешнего интерфейса, чтобы обеспечить плавные рабочие процессы и привлекательный пользовательский интерфейс и пользовательский интерфейс (UI / UX).

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

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

3. Согласуйте бюджет, команду и сроки запуска.

Как и в случае с Proof of Concept, минимально жизнеспособный продукт — это ограниченное по времени мероприятие, которое должно быть точно спланировано, определено в масштабах и внесено в бюджет. Руководитель проекта MVP будет отвечать за установление сроков, этапов, результатов и распределения бюджетов.

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

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

Минимально жизнеспособная команда должна соответствовать следующим критериям:

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

Требования к команде MVP будут зависеть от вашего видения продукта. Если результат включает в себя интерфейс, такой как веб-приложение для платформы SaaS, вам, вероятно, потребуются дизайнеры UI/UX, разработчики программного обеспечения с полным стеком, инженеры-программисты и менеджер проекта. Если вы хотите создать продукт AI / ML, вам, вероятно, также понадобятся специалист по данным и инженер по данным.

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

4. Сборка. Контрольная работа. Повторить.

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

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

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