Большинство компаний или стартапов не реализовывают сразу большой проект. Заключая договор на разработку ПО, они чаще всего делают док с требованиями и заголовком «MVP-версия продукта». 

MVP –  это minimum VIABLE product: минимально жизнеспособный продукт. Но почему зачастую происходит так, что вместо minimum VIABLE получается minimum VALUABLE — минимально полезный? 

Меня зовут Юлия Максименко, я – аналитик в компании Surf. 90% проектов, на которых я работала, хотели получить именно MVP-версию, однако сталкивались со сложностями. Расскажу, что такое MVP, почему не всегда удается сделать именно минимально жизнеспособный продукт и на что стоит обратить внимание если вы видите, что проект едет в сторону minimum VALUABLE.

Зачем нужна MVP-версия

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

Почему MVP перестает быть «жизнеспособным»: 3 причины

О проблемах и способах их решения расскажу в top-down подходе: от наименее к наиболее сложным.

Причина №1. Непонятно, что включить в MVP-версию

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

Решение 1: Провести предпроектное исследование

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

Есть риск реализовать функциональность, которая не будет востребована у конечного пользователя. А как показывают исследования CB Insights (аналитическая компания, публикующая ежегодные отчёты о причинах провалов стартапов), невостребованность на рынке — самая распространенная причина неудач: 42% стартапов закрываются по этой причине (ссылка открывается только под VPN).

Кроме того, как показывает практика, сэкономившие таким образом в начале пути компании, на этапе разработки несут бо́льшие расходы, чем те, которые провели предварительный анализ. Так, результаты исследования McKinsey показывают, что в среднем 45% IT-проектов превышают запланированные расходы, 7% не попадают в сроки и 56% приносят меньше прибыли чем планировалось. 

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

Подробнее о предпроектных исследованиях мы писали в статье на VC «Зачем мобильному приложению нужно предпроектное исследование».

Предпроектное исследование: кто и чем занимается

Предпроектное исследование проводит команда, в которую входят аналитики и дизайнеры. 

Изучают бизнес и бэкграунд заказчика, определяют его бизнес-цели. Например, когда Surf проводил CJM (Customer Journey Map — построение пути пользователя) для сети сторительных магазинов «Петрович», то бизнес-цель заключалась в увеличении продаж строительных товаров через e-com Petrovich.ru.

Определяют целевую аудиторию (ЦА). Проводится опрос потенциальных пользователей приложения, чтобы проверить, есть ли спрос, какие боли нужно закрыть продуктом, и сформировать карту развития продукта. 

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

Анализируют конкурентов (проводят бенчмаркинг). Выделяются основные тренды отрасли, примеры хороших и плохих практик. Анализ конкурентов помогает сформировать видение продукта, выделить основные сценарии использования (use cases) и сформировать бэклог.

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

Решение 2: привлечь продакт-оунера (PO) для определения стратегии развития продукта

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

Чаще всего можно увидеть примеры, когда один человек играет несколько ролей: например, проджект-менеджер плюс продакт оунер или аналитик плюс продакт оунер. Также работать с одним ЛПР проще, чем иметь, например, проджект-менеджера из компании заказчика, а продакт оунера — из аутсорса. Так не придётся согласовывать решения сразу с несколькими людьми, видения которых могут конфликтовать.

Причина №2. Ограниченный бюджет 

Если не найти выход из такой ситуации и не предложить альтернативные варианты, то рискуем получить никому ненужный «продукт-обрубок» и в лучшем случае негативные (но хоть какие-то) отзывы. Однако находить выход из ситуации малобюджетного проекта все равно необходимо. Итак, что здесь можно предложить:

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

Пример. Мы делали healthcare-проект для рынка США: реализовывали PEaaS-платформу (patient engagement as a service). Она должна была выполнять следующие задачи:

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

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

3. Формировать и отправлять в государственные органы отчёты об активностях медицинского персонала, чтобы врач мог получить налоговый вычет от государства.

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

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

Как оказалось, в США врачи могут получать дополнительные деньги от государства, если предоставят отчёт, сформированный и заполненный по определенному формату. Но основная проблема заключается в том, что процесс заполнения такого документа регламентирован и занимает много времени. 

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

А добавление edu-контента и обучающих игр, покрывающих первую задачу, можно отложить в post-MVP.

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

Пример. Добавить in-app purchases для покупки внутренней валюты приложения. Её, в свою очередь, можно обменять на что-то внутри: например, прокачку аватара или покупку стикеров, как это делают мессенджеры.

Найти готовое решение для фич, требующих разработки с нуля: это сократит расходы.

Пример. Возвращаюсь к примеру с healthcare-приложением. Нам необходимо было реализовать фичу «Дневник еды», чтобы пациент записывал дневной рацион, а приложение бы рассчитывало калорийность и макроэлементы. На реализацию такой фичи с нуля, да ещё и в MVP, у нас не было времени. Поэтому мы изучили рынок и решили использовать API стороннего сервиса – Suggestic.

Сделать core-функциональность без навешивания «рюшечек и бантиков» вроде фильтров, поиска по приложению, раздела «Избранное». Это удобно для пользователя, но не жизненно необходимо. Лучше предложить сконцентрироваться на передовом дизайне, чтобы приложение заказчика отличалось от приложений конкурентов.

Причина №3 — «популярная»: хочется всё и сразу

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

MoSCoW

Подходит для приоритизации требований, user stories, use cases. Аббревиатура, заглавные буквы которой соответствуют названиями категорий, по которым необходимо распределить фичи: must have, should have, could have, won’t have.

Must have — должно быть. В эту категорию попадают киллер-фичи, без которых нет смысла выпускать продукт. 

Пример. Описанная ранее функциональность по формированию отчетов для врачей – это как раз пример must have. 

Также добавляем фичи, которые нельзя исключить из-за юридически-правовых требований (они же — «нормативка») или требований по безопасности.

Пример. Поскольку медицинское приложение будет работать в США, оно должно соответствовать требования HIPAA (Health Insurance Portability and Accountability Act) – это тоже пример must have, только уже с точки зрения нефункциональных требований по безопасности данных.

Should have — следует иметь. Выбираем эту категорию, когда фича важна, и выкидывать ее болезненно. При этом она не жизненно необходима, в отличие от предыдущего пункта.

Пример. Это фича «команда заботы», упомянутая ранее. Выкинуть её мы не можем, потому что у всех наших конкурентов она есть, и, если мы её не сделаем, то отдадим конкурентное преимущество нашим соперниками.

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

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

Won’t have — не будет. Название категории говорит само за себя: она объединяет в себе все то, что не вошло в MVP-версию. Фичи из этой категории как раз и сформируют бэклог для post-MVP.

Kano 

Метод предлагает разбить функциональность на три группы.

Базовые, или ожидаемые. Сюда попадают фичи, которые пользователи ожидают увидеть: базовая функциональность, которая есть у конкурентов. Поэтому от неё мы не отказываемся. Этими фичами мы вряд ли удивим пользователя и получим хорошие отзывы за них. Пример — возможность отредактировать или удалить отправленное сообщение в чате (привет мессенджеру WhatsApp).

Удовлетворяющие. Определяем в группу функциональности, которые могут повысить уровень удовлетворенности продуктом у пользователей. Это те дополнительные вещи, благодаря которым использовать продукт приятнее и удобнее, например, возможность увидеть текст песни в музыкальном плеере (Яндекс.Музыка, Мой Звук и Spotify).

Восхищающие. Фичи-бонусы, которые пользователи не ожидают увидеть или даже не знают об их существовании. Они обычно наиболее дорогие в разработке. Пользователя не смутит, если их не будет, и мы не получим плохих отзывов. Пример — система поощрения: зашёл в приложение или выполнил действие, получил бонус.

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

Есть правило: 

1. В первую очередь берёмся за фичи из группы базовых: без них нет смысла выпускать продукты. Если их не будет, пользователи будут оставлять негативные отзывы.

2. Делаем фичи из группы «удовлетворяющие». 

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

Рекомендации при создании MVP: кратко

Подведём итог. Чтобы MVP был минимально жизнеспособным, а не минимально полезным, важно сделать следующее: 

Провести предпроектное исследование. Изучить бизнес заказчика, определить ЦА, проанализировать конкурентов. Подходит для тех проектов, где заказчику самому не удается сформировать видение продукта и сложно определить скоуп для MVP.

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

Приоритезировать таблицу функциональности с помощью техник приоритезации: например, MoSCoW и Kano. 

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

Кейсы и лучшие практики в области системной и бизнес-аналитики, новости, вакансии и стажировки Surf — в телеграм-канале Surf BA Team. Присоединяйтесь!