18+ Условия подписки: clck.ru/FMQND
Главные премьеры года. Уже в подписке
18+ Условия подписки: clck.ru/FMQND
Личный опыт
SimbirSoft

5 ошибок при разработке MVP, которые не приведут вас к цели

Необходимость разработки MVP может вызывать дискуссии в среде профессионалов, так как на то, стоит ли применять его в проекте, влияет много условий. Если бизнесу нужна внутренняя система (например, CRM для управления взаимоотношениями с клиентами), потребность в которой очевидна и понятна, бизнес не тратит ресурсы на проверку её жизнеспособности, а сразу приступает к созданию ИТ-системы спринт за спринтом. Но если компания хочет проверить гипотезу жизнеспособности какой-то оригинальной идеи продукта, она приступает к разработке MVP.

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

Ошибка № 1. Рассчитывать на то, что MVP можно создать и запустить за 1 месяц

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

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

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

Ошибка № 2. Не прояснить термины

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

За MVP иногда принимают прототип. Прототип – это тоже своего рода «некая пробная» версия системы. Но в отличие от MVP, его цель – показать будущий продукт, его идею. Например, прототипом может быть картонный макет жилого комплекса или кликабельные макеты приложения. Как правило, прототип так и остается прототипом.

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

Ошибка № 3. Выявить не ту идею и заложить в MVP не те фичи

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

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

Ошибка № 4. Заложить на MVP не те работы, неправильно подобрать команду

Частый вопрос: нужен ли сложный дизайн продукта или UX-дизайнер в команду на MVP? Все зависит от целевой аудитории, на которой будет исследоваться MVP, а именно: что побудит пользователя «попробовать» продукт, а что удержит его от этого.

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

Когда необходимо проверить идею публичного пользования (например, оказание той или иной услуги клиентам), приложение выкладывается в AppStore или Google Play. Чтобы его скачали и начали им пользоваться, оно должно быть внешне привлекательным, логичным и удобным, пусть и содержать всего одну фичу. Поэтому в MVP такого продукта нужно сразу заложить дизайн и UX-проработку.

Ошибка № 5. Использовать не все возможные каналы связи для сбора обратной связи

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

Для этого лучше комбинировать различные способы сбора данных:

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

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

Узнать о том, как избежать этих ошибок, можно на бесплатном вебинаре, который проведет наш эксперт, руководитель направления бизнес-решений SimbirSoft Анна Шведова.

На вебинаре мы подробно обсудим, какому бизнесу стоит начинать разработку с MVP, а кому этого делать не нужно, как выделить главные фичи при создании минимальной жизнеспособной версии продукта, а также о том, как перейти к полноценному продукту. Увидимся с вами 28 октября в 15:00

Анна Шведова
руководитель направления бизнес-решений

Обращаем внимание, что необходима предварительная регистрация.

0
2 комментария
Популярные
По порядку
SimbirSoft

Все зависит от требований к полноценному сервису: нужно понимать, что из MVP можно переиспользовать, а что придется "строить по-новому"

Ответить
2
Развернуть ветку
Юлианна Смирнова

Спасибо за информацию! интересный список ошибок) А "подружить" полноценный сервис и MVP затратно?

Ответить
0
Развернуть ветку
Читать все 2 комментария
Авито потеряла посылку и не возвращает деньги

21 декабря 2021 года решил заказать на авито куклу в качестве подарка. Товар сразу оплатил вместе с авито доставкой(boxberry), продавец в этот же день отправил посылку, дело оставалось за малым - просто подождать. Для заметки, я с продавцом нахожусь на расстоянии в 15-20 км.

Статус бота Veles
Ошибки мышления у сммщиков

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

Как пандемия изменила рынок онлайн-страхования

Выяснили и рассказываем, как изменился онлайн-спрос на услуги страхования с начала пандемии.

Вы ВТБ или календарь праздников?

Зачем в мобильном приложении ВТБ каждый день показывают клиентам, какой сегодня день в истории? Нет, я очень уважаю Эйзенштейна, Сезанна и Винни-Пуха, но вам не кажется, что клиенты заходят совсем не за этим?

В Москве появился фонд, инвестирующий в перспективные транспортные проекты

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

Саид
Токсичная маркетинг-тусовка: как у номинального директора по маркетингу Самолета подгорело от нашего кейса

Наш c Digital Bands кейс про продажу квартир на PornHub завирусился после публикации на VC. По сути мы были первопроходцами: до нас никто не продавал недвижимость на порносайтах. Получили награду, опубликовали кейс — и хапнули негатива от коллег по цеху и приближенных к маркетингу. Но одно дело — комментарии среднестатистического спеца под…

«Холакратия, любимые мемчики и прозрачность»: программист о работе в Точке, моделинге и запуске треков на Spotify

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

Как добиться перехода на электромобили? Спросите Норвегию

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

«Инновации — это поле для сражений»

Как фуд-ритейл внедряет новые технологии.

null