Большинство компаний или стартапов не сразу реализуют крупные проекты. При подписании контракта на разработку программного обеспечения обычно указываются требования и название «MVP-версия продукта».
MVP — это минимально жизнеспособный продукт: минимально жизнеспособный продукт. Но почему часто бывает так, что вместо наименьшего ЖИЗНЕННОГО мы получаем наименьшее ЦЕННОЕ - наименьшее полезное?
Меня зовут Юлия Максименко, я аналитик компании.серфингДля 0,90% проектов я хочу получить версию MVP, но столкнулся с трудностями. Я объясню, что такое MVP, почему не всегда возможно создать продукт с минимальной жизнеспособностью и на что обращать внимание, когда вы видите, что проекты движутся к минимальной ценности.
Зачем нужна версия MVP
Версия MVP позволяет разработчику продукта и инвестирующим в него предпринимателям собирать отзывы конечных пользователей и проверять предположения и концепции, лежащие в основе бизнес-идеи продукта. Основная цель состоит в том, чтобы проверить предположения о возможности реализации идей и выявить потребности потребителей.
Почему MVP больше не «ходят»: 3 причины
Я буду описывать проблему и ее решение сверху вниз: от самого простого к самому сложному.
Причина № 1. Непонятно, что в версии MVP
Часто бывает так, что стартапы могут сформулировать видение своего продукта, но с трудом разбираются и обсуждают основные функции. Сложно отделить критичные функции от тех, которые можно записать в бэклог.
Решение 1. Проведите комплексное исследование
В начале проекта может быть непонятно, почему не может начаться разработка, и чувствуется «на стороне», что нужно реализовать в первую очередь, а что в последнюю очередь. Теоретически это вполне возможно, но оно того не стоит.
Существует риск реализации функций, которые не нужны конечным пользователям. как показывают исследованияИнформация о коммерческих банках(Анализ года выпуска компанииСообщениеПричины неудач в бизнесе) отсутствие рыночного спроса является наиболее частой причиной неудач:42 %Из-за этого стартапы закрывались (Ссылки открываются только через VPN).
Как показывает практика, компании, экономящие таким образом в начале пути, на этапе разработки, несут более высокие затраты, чем те, которые проводят предварительный анализ. Отсюда и результаты исследованияМакКинзипоказывает, что в среднем 45% ИТ-проектов стоят больше, чем планировалось, 7% срывают сроки и 56% приносят меньше прибыли, чем планировалось.
Все эти проблемы возникают из-за отсутствия планирования. Поэтому компания-разработчик должна помочь заказчику ознакомиться с процессом предпроектного исследования, чтобы продемонстрировать преимущества данного метода.
Подробнее о предпроектных исследованиях мы писали в статье о венчурных капиталистах».Зачем мобильным приложениям нужна комплексная проверка?»。
Предпроектное исследование: кто и что
Предпроектное исследование проводит команда аналитиков и дизайнеров.
Изучите бизнес и биографию клиента, чтобы определить его бизнес-цели.. Например, когда Surf выполняет CJM (Customer Journey Map — создание пути пользователя).Создать сеть магазинов "Петрович"Бизнес-целью в то время было увеличение продаж строительной продукции через электронную коммерцию.Петрович.ру.
Определить целевую группу(Калифорния). Проведите опрос потенциальных пользователей приложения, посмотрите, есть ли потребность, какие уязвимости необходимо решить продукту, и создайте карту развития продукта.
Поэтому, проанализировав целевую аудиторию компании «Петрович», мы обнаружили, что не всегда сметы составлялись и заполнялись прорабом. Некоторые эксперты делегируют это помощнику: эта информация обеспечивает дополнительный контекст, который может помочь нам в разработке нашего приложения.
Анализ конкурентов(для сравнения). Освещены ключевые отраслевые тенденции и примеры хорошей и плохой практики. Конкурентный анализ помогает сформулировать видение продукта, выделить наиболее важные варианты использования и сформировать бэклог.
Например, когда мы анализировали конкурентов Петровича — Smetter, 101 и т. д. — мы обнаружили, что большинство из них слишком перегружены для неопытных пользователей.
Решение 2. Привлеките владельца продукта (PO) к определению стратегии разработки продукта.
Вы можете делегировать ответственность за разработку продукта PO — владельцу продукта: пригласите на эту роль эксперта из аутсорсинговой компании или кого-то из команды разработчиков, будь то сотрудник или подрядчик. По нашему опыту, лучше выбрать сотрудника заказчика: он лучше знает предметную область компании, чем внешний специалист.
Чаще всего вы видите примеры, когда один человек играет несколько ролей: например, менеджер проекта и владелец продукта или аналитик и владелец продукта. Также проще работать с одним лицом, принимающим решения, чем с менеджерами проектов от компаний-клиентов и собственными продуктами от аутсорсинговых компаний и т. д. Таким образом, вам не нужно согласовывать решения одновременно с несколькими людьми, чьи взгляды могут противоречить друг другу.
Причина 2. Ограниченный бюджет
Если вы не найдете выход из этой ситуации и не предложите другие варианты, вы рискуете ненужными «продуктами-обрубками» и, в лучшем случае, негативными (но хоть какими-то) отзывами. Однако выход из ситуации с малобюджетным проектом еще предстоит найти. Итак, что мы можем предложить здесь:
Проведите анализ конкурентов, упомянутые в предыдущей причине, чтобы выделить функции, уникальные для продукта, и инвестировать в их реализацию только в первой итерации. Остальное осталось для более поздней версии.
Пример.Мы реализовали проект в сфере здравоохранения для рынка США: внедрили платформу PEaaS (Patient Engagement as a Service). Он должен выполнять следующие задачи:
Предоставляйте образовательный контент для информирования пациентов о наиболее распространенных заболеваниях: это помогает в профилактике и раннем лечении.
За состоянием пациента в режиме 24/7 следит «бригада ухода»: группа врачей-специалистов, профиль которых соответствует состоянию пациента.
Создавайте отчеты о деятельности медицинского персонала и отправляйте их в государственные органы, чтобы врачи могли получить налоговые льготы от государства.
Мы посмотрели список фич, которые должны быть включены в MVP, и поняли, что реализовать их все в заданные сроки и бюджет не получится. Поэтому мы проанализировали потенциальных конкурентов и пришли к выводу, что необходимо сосредоточиться на реализации второго и третьего пунктов.
Второй пункт — функция «Заботливая команда» — должна быть реализована, как и у всех участников. Третий пункт — отчетность врачей перед госорганами — необходимо реализовать, так как у конкурентов этой функции нет.
Получается, что врачи в США могут получить дополнительные деньги от государства, если они сдадут отчет, подготовленный и заполненный по определенному формату. Но главная проблема в том, что заполнение таких документов регламентировано и занимает много времени.
Большинство врачей знают, что есть способы заработать дополнительные деньги, но не имеют на это времени или навыков. Это уникальная особенность нашего приложения.
Однако добавление образовательного контента и обучающих игр к первой миссии можно отложить до MVP.
Сосредоточьтесь на функциях, которые могут генерировать мгновенные выигрышинашим клиентам. Например, через функции в приложениях, которые имеют функции монетизации.
Пример.Добавьте покупки в приложении, чтобы купить внутреннюю валюту приложения. Взамен он может обмениваться вещами внутри: например, улучшать аватарки или покупать стикеры, как и мессенджер.
Найдите готовое решениеДля функций, которые необходимо создавать с нуля: это снижает затраты.
Пример.Вернемся к варианту использования в здравоохранении. Нам нужно внедрить функцию «пищевого дневника», чтобы пациенты могли записывать свои ежедневные приемы пищи, а приложение рассчитывало калории и макроэлементы. У нас нет времени реализовывать такие фичи с нуля, даже в MVP. Поэтому мы изучили рынок и решили использовать API стороннего сервиса —наводящий на размышления.
создавать основные функцииВместо того, чтобы вешать «рюши и бантики», как фильтры, просмотрите раздел избранного по приложению. Это удобно, но не обязательно. Лучше всего сосредоточить внимание на современном дизайне, чтобы приложение клиента отличалось от приложения конкурентов.
Причина 3 - "Мода": Они хотят все
Уверен, что этот вопрос знаком многим из вас. Я хочу всего, моментально и быстро: превзойти конкурентов, завоевать мир и сердца пользователей. Но, к сожалению, на практике это не работает. Для нас расстановка приоритетов — это все. Технологии MoSCoW и Kano помогут расставить приоритеты в списке функций MVP.
Москва
Подходит для приоритизации требований, пользовательских историй, вариантов использования. Аббревиатура, заглавные буквы которой соответствуют наименованию категории, к которой должна принадлежать характеристика: Должен иметь, Должен иметь, Мог бы иметь, Не будет иметь.
Должен иметь- должен. В эту категорию попадает киллер-фича, без которой нет смысла запускать продукт.
Пример.Описанный ранее функционал по созданию отчетов для врачей — это лишь пример того, что должно присутствовать.
Мы также добавляем функции, которые нельзя исключить из-за нормативных требований (которые также называются «Спецификациями») или требований безопасности.
Пример.Поскольку медицинское приложение работает в США, оно должно соответствовать HIPAA (Закон о переносимости и подотчетности медицинского страхования) — опять же, это пример обязательности, только с точки зрения требований безопасности нефункциональных данных.
должен иметь- должен иметь. Мы выбираем эту категорию, когда функция важна и утомительно ее выбрасывать. Впрочем, по сравнению с предыдущим пунктом это не имеет большого значения.
Пример.Это ранее упомянутая функция Caring Team. Мы не можем его выбросить, потому что он есть у всех наших конкурентов, а если его нет у нас, мы отдаем свое конкурентное преимущество нашим конкурентам.
мог бы иметь- возможный. В этой категории мы определяем функции, которые можно относительно легко исключить из первой версии продукта. Ими можно и нужно пожертвовать, когда сроки проекта не могут быть соблюдены.
Пример.Предыдущий контент для образовательных учреждений: обучение пациентов методам профилактики заболеваний — беспроигрышный вариант. Существуют отдельные приложения, предназначенные для расширения знаний пациентов о болезни. Учитывая наше ограниченное время и бюджет, мы не могли предложить лучшего решения, чем ваше. Из-за этого мы решили перенести эту функцию в следующую версию.
не будет иметь- нет. Название категории говорит само за себя: она объединяет все, что не входит в версию MVP. Функции в этой категории составляют бэклог пост-MVP.
Кано
Метод предлагает разделить характеристики на три группы.
базовый или ожидаемый.Это включает в себя функции, которые пользователи хотят видеть: основные функции, которые есть у конкурентов. Вот почему мы не отвергаем его. Благодаря этим функциям у нас меньше шансов удивить пользователей и получить хорошие отзывы. Примером может служить возможность редактирования или удаления отправленных сообщений в чате (Hello WhatsApp Messenger).
удовлетворен.Мы определяем ряд функций, которые могут повысить удовлетворенность пользователей продуктом. Это дополнительные функции, которые делают использование продукта более приятным и удобным, например, возможность просмотра текстов песен в музыкальных плеерах (Яндекс.Музыка, Мой звук и Spotify).
распознавать.Функции, которые пользователи не ожидают увидеть или даже не подозревают о существовании - Вознаграждения. Их разработка обычно самая дорогая. Если нет, пользователям не будет стыдно, и мы не получим плохих отзывов. Пример — система вознаграждений: я захожу в приложение или выполняю действие и получаю вознаграждение.
В рамках MVP не всегда удается вовремя реализовать все пожелания клиента. Поэтому при группировке функций нужно знать порядок их реализации.
Есть одно правило:
Для начала займемся базовыми функциями: без них выпуск продукта не имеет смысла. Если нет, пользователи оставляют негативные отзывы.
Мы «удовлетворяем» фичи из группы.
Наконец, мы реализуем «замечательные» функции: конечно, только если они существуют и есть ресурсы для их создания. Как уже говорилось, их может быть много: с MVP достаточно одного.
Лучшие практики создания MVP: краткое введение
Подведем итог. Чтобы MVP был максимально жизнеспособным, а не минимально полезным, важно сделать следующее:
Провести предпроектное исследование.Исследуйте бизнес клиента, определите целевую группу, проанализируйте конкуренцию. Он подходит для проектов, где заказчики не могут разработать собственное видение продукта и сложно определить объем MVP.
Добавить владельца продукта в команду. Для проектов, где нет видения продукта или за стратегию развития никто не отвечает.
приоритетное менюИспользуйте методы расстановки приоритетов, такие как MoSCoW и Kano.
диалог с клиентами: Объясните, что должно быть включено в MVP с ограниченным бюджетом или требуемой слишком большой функциональностью.
Кейсы и лучшие практики, новости серфинга, предложения работы и стажировки в мире систем и бизнес-аналитики — все это доступно на Telegram-канале команды Surf BA.ПРИСОЕДИНЯЙСЯ СЕЙЧАС!