4 задачи проектирования MVP для бизнес-аналитика

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

БОЛЬШЕ ИНФОРМАЦИИ О БИЗНЕС АНАЛИЗЕ В НАШЕМ ТЕЛЕГРАМ КАНАЛЕ: Бизнес Аналитик|IT

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

Что означает MVP?

Минимально жизнеспособный продукт (minimum viable product, MVP) – это версия продукта, обладающая минимальными, но достаточными функциями для удовлетворения потребностей первых потребителей. Она позволяет команде разработки получить как можно больше информации о пользователях, а также быстро провести количественный и качественный анализ реакции рынка на тот или иной продукт или функцию.

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

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

4 задачи проектирования MVP для бизнес-аналитика

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

Какова роль бизнес-аналитика в разработке MVP?

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

Задача 1. Изучение бизнес-области

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

Для более глубокого изучения бизнес-сферы в целом следует:

  • Определить субъекты, их характеристики и взаимосвязи
  • Изучить терминологию, характерную для бизнес-области
  • Определить объекты с их характеристиками и взаимосвязями с субъектами
  • Детализировать бизнес-процессы и их взаимосвязь с объектами и субъектами
Задача 1. Изучение бизнес-области

Задача 2. Определение дорожной карты MVP

Второй задачей является участие в определении дорожной карты MVP и расстановке приоритетов функций. Для ее выполнения следует выполнить три следующих шага:

  • Определить видение продукта (Product Vision), которое может описывать, что представляет собой продукт, почему он необходим клиентам, какие проблемы он решает или какие амбиции преследует. Для этого можно использовать Product Vision Board, популярный визуальный инструмент, который позволяет представить видение в простой наглядной форме.
  • Определить персоны пользователей (User Personas). Персоны пользователей – это вымышленные образы пользователей продукта или услуги. Они помогают команде разработки понять их поведение, боли и потребности.
  • Составить карту пользовательских историй (User Story Mapping). Эта методика, разработанная Джеффом Паттоном, направлена на определение необходимых функциональностей продукта.

Приоритетность функций можно определить с помощью метода MoSCoW. Его суть заключается в разбиении всех функций или задач на четыре группы: обязательные (Must), необходимые (Should), возможные (Could) и желательные (Would). Приоритет реализации идет по нисходящей от обязательных к желательным функциям.

Задача 3. Написание пользовательских историй

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

  • Определить границы системы, нарисовав контекстную диаграмму. Это поможет лучше понять поток информации между системой и внешними источниками.
  • Определить унаследованные системы (Legacy Systems), которые необходимо использовать, и причины их необходимости.
  • Уточнить требования и проанализировать их зависимости и влияние.
  • Участвовать в совещаниях, организованных командой UX/UI-дизайнеров, чтобы оптимизировать юзкейсы.
  • Составить карту сервисов, которые будут использоваться для различных функций.
  • Запросить техническую документацию (ACL, WSDL, примеры ответов, коды ошибок).

Задача 4. Работа с проверкой концепции

Наконец, последней задачей, с которой может столкнутся БА, является поддержка процесса проверки концепции (Proof of Concept, PoC).

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

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

PoC нужна для того, чтобы выбрать лучшее стороннее решение для интеграции. Для этого важно понять, как работают API сторонних разработчиков, как отправлять запросы и интерпретировать полученные ответы. На этом этапе можно использовать такие инструменты, как Postman и SOAP UI.

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

Подводя итог, можно сказать, что преимуществами MVP являются:

  • Оптимизация затрат и времени
  • Более быстрое получение обратной связи от пользователей
  • Возможность появления первых пользователей после выпуска MVP
  • Привлечение внимания инвесторов.

Преимущества PoC включают:

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

Перевод статьи «4 MVP design challenges a business analyst needs to solve».

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *