Как концепция MVP экономит деньги клиента
Есть чудесный эксперимент, проведенный во времена, когда психологам еще разрешали бить людей током. Испытуемых обвешивали датчиками и одной группе сообщали, что они точно получат удар шокером, а второй, что вероятность удара — 50%. И что же вы думаете? Тревожность, пульс и физическое состояние обеих групп было одинаковым! И при снижении риска до 20%, 10% тоже ничего не поменялось. Прорыв случился, когда риск снизился до… 0.
Эта занимательная история говорит о том, что мы, человеки, как то слабо умеем оценивать шансы риска. Когда я прочитала* про этот эксперимент, то стало понятнее, почему так мало компаний и стартапов по-настоящему умеют в MVP.
Привет, я Ольга Кулапина, руководитель направления бизнес-анализа в Red Collar и сегодня мы будем говорить про MVP.
Итак, MVP — по определению Minimal Viable Product (минимально жизнеспособный продукт). Концепция придумана для итерационного пути бизнеса к цели. Моя статья про пользу этого подхода в мире IT разработки.
Обычно на старте проекта (особенно если это стартап) мы проговариваем, что сначала будем формировать и разрабатывать минимально жизнеспособную версию, запускать, обкатывать, а уж потом расширять продукт. Говорим (и это чистая правда), что так минимизируются риски для бизнеса. Меньше времени и денег тратится на первую версию, можно проверить гипотезы и вовремя скорректировать направление разработки. На этом этапе все соглашаются. Давайте пошагово рассмотрим дальнейший путь, увидим где жизнь вносит корректировки и как с этим можно работать.
Шаг 1. Дискавери-фаза аналитики
Начинаем мы с брифа стейкхолдеров, исследования конкурентной области, выявления и исследования ЦА. Все это дает нам базу для построения гипотез.
Гипотеза в рассматриваемом примере стартапа — это верхнеуровнево сформированная концепция будущего продукта. Например «Возможно и востребовано рынком создание специализированой [название специализации] тендерной площадки, позволяющей заказчику выставить заявку на [материал], а участникам рынка на нее откликнуться.»
Для того, чтобы эти гипотезы имели право на жизнь, а были не просто фантазиями, нужно на этапе исследования учесть несколько аспектов:
1. Какие у заказчика есть конкурентные преимущества в рамках его идеи. Как правило, стейкхолдеры разбираются в исследуемом секторе рынка и могут иметь значимую информацию, полезные партнерские связи или собранные информационные базы. Такие преимущества крайне важны. Они могут стать как определяющим фактором в формировании продукта, так и помочь в его продвижении.
2. Какие потребности пользователей (в рамках идеи) рынком уже закрыты, а где есть свободные ниши. Это выясняем на этапе конкурентного исследования. Тут мы не ограничиваемся прямыми конкурентами, а захватываем и косвенных: они могут как стать партнерами, так и просто с другого ракурса показать структуру спроса.
3. Что думает по этому поводу целевая аудитория будущего продукта. В изучении аудиторий я никогда не ограничиваюсь количественным анализом. Качественный анализ, интервью, CustDev с открытыми вопросами позволяют вынырнуть из рамок собственных представлений и реально «пощупать» настроение и потребности людей.
4. Как может монетизироваться разрабатываемый продукт. За что люди готовы платить и по каким каналам их можно будет привлечь.
После завершения этапа исследования и формирования гипотез того, как именно будет выглядеть наш продукт, нужно эти гипотезы проверить.
Это первый серьезный шаг на пути к экономии средств клиента. Тут мы должны отсечь нежизнеспособные или высокорискованные идеи и не пускать их в разработку.
Фреймворков, которые нам могут помочь, много, но я для этой цели чаще всего использую SWOT-анализ.
SWOT-анализ — метод стратегического планирования, заключающийся в выявлении факторов внутренней и внешней среды организации и разделении их на четыре категории: Strengths (сильные стороны), Weaknesses (слабые стороны), Opportunities (возможности), Threats (угрозы).
Для анализа мы располагаем в матричной форме по вертикали внутренние характеристики продукта (сильные и слабые стороны), а по горизонтали внешние факторы (возможности и угрозы). Суть фреймворка в том, чтобы оценить эффект от пересечения различных факторов. Берем мы эти факторы из всех уголков предыдущего исследования.
Факторы с наибольшим весом нужно использовать в SWOT-анализе.
Таким образом мы можем оценить все разработанные гипотезы и аргументировано выбрать самую безрисковую и потенциально выгодную из них.
Шаг 2. Выделяем из разработанной концепции состав первой, минимально жизнеспособной версии (MVP)
И вот мы в полном согласии с заказчиком остановились на лидирующей гипотезе. Описали ее функциональности, ролевую модель, и настало время волевого решения для выделения из всего этого MVP. В этот момент вера в продукт у стейкхолдеров бывает уже очень велика, а риски кажутся призрачными, и они могут предлагать пускать в разработку сразу все придуманное. Но так делать очень рискованно. Тут полезно вспомнить про HADI-циклы.
HADI-цикл — это довольно простой алгоритм действий, предполагающий движение по высокорисковому полю (а бизнес — это всегда высокий риск) маленькими шагами. HADI состоит из четырех слов: hypothesis (гипотезы), actions (действия), data (данные) и insight (выводы). То есть, мы бьем большую гипотезу на более мелкие, совершаем действие, чтобы ее проверить (в нашем случае выпускаем IT продукт), собираем данные и получаем инсайты для следующих доработок.
Тут важно в гипотезу включить некие измеряемые критерии успеха и ограничить время проверки. На мой взгляд, это одна из лучших практик маркетинга. Пошаговый путь развития не дает нам сильно разойтись с реальностью, он позволяет растить бизнес опираясь на поток внешних событий, а не перебарывая его.
Как же выделить MVP? Тут есть несколько подходов, но все их надо начинать с основных целей и ценностей проекта, которые определяются на этапе Дискавери.
- Можно пойти по пути срезания функциональностей. Если это агрегатор услуг, то, допустим, оставить возможность публиковать объявление, но без редактирования, архивирования, ответов и т. д. Самое важное — выделить ключевые идеи продукта и его УТП, после этого понять, какие функциональности жизненно важны, и остановиться только на них.
- Второй путь — сконцентрироваться на одной из целевых аудиторий и сократить роли продукта. Тут принципы те же — определение ключевой для продукта ЦА и построение функционала только для нее.
Это реально сложный процесс, ведь продукт должен быть не «сырым», а узкоспециализированным.
Именно малофункциональность и позволяет выделить и проверить самый важный набор метрик продукта. А если мы можем посчитать и проверить успешность небольшой, но важной для продукта части, значит, мы можем осознанно, экономично, управлять ростом продукта
Все оставшиеся функциональности мы распределяем по графику релизов, делаем верхнеуровневую дорожную карту. Но при этом помним, что она будет корректироваться по мере работы продукта и получения реального отклика рынка.
Корректировка планов развития — это основной профит от MVP, так же как и возможность видеть, как именно надо развивать продукт, чтобы инвестиции окупились.
Шаг 3. Проектирование и разработка
Допустим, уровень согласования MVP мы прошли. Молодцы! Начинаем подробное проектирование. В Red Collar этот этап проводят совместно аналитики, UX-дизайнеры и информационные архитекторы. Погружаемся подробно в каждый элемент, дособираем и уточняем информацию, на выходе получаем высокодетализированные кликабельные прототипы. Наконец-то абстрактные идеи принимают вещественный вид, который можно пощупать. На этом этапе тоже часто возникают пожелания «а давайте добавим еще фичу!». Очень тонкий момент, ведь с одной стороны, тут и правда может стать очевидной недостача какого-то функционала, а с другой — запросто можно раздуть проект.
Важный момент! Red Collar — IT-компания заказной разработки, а это значит, что мы разрабатываем продукты не для себя, а для заказчика. В этой модели заказчик является частью рабочей группы, но может (и имеет на это полное право) не быть знаком с концепцией MVP и тонкостями разработки. В этом случае для исполнителей важен не только профессионализм, но и экспертность, и готовность к ненавязчивому консалтингу. Важно стремиться к прозрачности и озвучивать последствия и риски спорных решений.
Но этап проектирования достаточно лоялен к корректировкам состава MVP. Да, могут вырасти сроки, но пока речь не идет о глобальных переделках.
После проектирования начинается фаза разработки. Подключаются frontend, backend-разработчики, DevOps, QA. А так как мы говорим о довольно крупном и сложном продукте, то общий пул задач разбивается на эпики, эпики на стори и так далее. Другими словами мы делаем не «все и сразу», а поэтапно. И вот мы завершили часть функционала (допустим авторизацию или карточку товара) и демонстрируем результаты заказчику.
Это третья точка риска, в которой MVP может выпрыгнуть из задуманных границ. Стейкхолдер, увидев часть продукта, замечает некоторые не закрытые этой частью потребности клиента. После чего нередко у него возникает пожелание «а давайте еще вот ЭТО добавим».
Упс! «ЭТО» может не только менять изначальную цель проекта или затягивать сроки, но и противоречить чему-то, уже сверстанному или написанному. Простое «да, сделаем» в этот момент не только раздувание бюджетов, согласие с костыльными решениями и лепка «Франкенштейна», но и риск размыть идею MVP и сделать гипотезу труднопроверяемой.
В такой ситуации главное помнить: у каждой просьбы заказчика есть причина. Универсальный способ решения — дополнительное брифование клиента, выявление источника его пожеланий и поиск альтернативных вариантов.
Всегда надо возвращаться к изначальным целям, и вспоминать что MVP — это не «урезанный, сырой» вариант, а сконцентрированный. В качестве аналогии можно привести цепь. Она гибкая, но не в рамках одного звена. Так вот MVP —это всего лишь первое звено. Если разработать его быстро, в задуманном виде, то можно будет проверить жизнеспособность идеи и уже потом гибко менять направление следующего звена.
Шаг 4. Запуск продукта и следующий цикл
Преодолев все трудности и препоны мы закончили разработку IT-продукта и выпустили его! Ура! Это все? В концепции MVP — нет. Надо вспомнить, что же изначально задумывалось и зачем, проверить, как рынок откликается на ваш продукт, сверить реальные метрики с ожидаемыми. Теперь мы уже не теоретизируем, а видим как фактически рынок откликается на нашу разработку. Понимаем, насколько были верны гипотезы и как надо сместить акценты.
Следующие шаги — переосмысление планов и корректировка дорожной карты. А затем можно заходить на следующий цикл, развивая продукт именно в том направлении, в котором он будет приносить деньги заказчику.
Выводы
Мы не знаем будущего, и как бы тщательно мы ни анализировали рынок и тенденции, никто не может предсказать успех продукта со 100% вероятностью, поэтому и придумана такая штука как MVP. Она дает гибкость идее. Если мы все таки смогли в процессе разработки придерживаться рамок минимально жизнеспособного продукта, то заказчик может идти дальше не вслепую. Может рассчитать возврат инвестиций, а не полагаться на веру в идею.