Сегодня речь пойдет об MVP, как методологии работы для проверки и валидации гипотез и изменений в продукте. Немного заглянем под капот процесса, выделим ценности и цели. Материал для продуктовых специалистов: Game Pruducer, Product Manager, Product owner, LiveOps, также он актуален для любого стартапа – не только game development.
Давно не писал на продуктовую тему. Пришло время немного компенсировать этот пробел. Читая курсы Game Producer, LiveOps и Game Design я не мог не обратить внимание на то, как большинство трактует MVP. На каждом из потоков гарантировано трачу порядка 5 минут на разъяснение методологии использования MVP и как его готовить. Сегодня контент этих 5 минут в заметке блога.
“THE LEAN STARTUP” – ERIC RIES / БЕРЕЖЛИВЫЙ СТАРТАП:
MVP – MINIMUM VIABLE PRODUCT
Что такое MVP?
Перед тем как читать дальше, сначала ответь себе на этот вопрос. Как конкретно ты понимаешь эти три буквы. Что для тебя значит построение минимального жизнеспособного продукта. И главное ответь на вопрос – что есть продукт в этом определении.
Ответил? Давай расскажу, как у меня с этим пониманием, а потом сравним.
Так вот, как я упомянул ранее, чаще всего под продуктом понимают именно игру, как продукт, а под MVP – раннюю версию продукта которую еще можно назвать: прототип, вертикальный срез, софт лонч, альфа… И когда говорят “давай делать MVP” – речь идет именно о ранней версии игры, где можно что-то пощупать.
И это верно, но MVP это не только ранняя версия вашей игры. MVP – это методология.
Термин MVP
Я не ошибусь, если предположу, что большинство из вас и моих коллег знакомы с термином MINIMUM VIABLE PRODUCT из книги “THE LEAN STARTUP” – ERIC RIES, которую я рекомендовал в материале “Что лежит на полке у Product Manager”.
Книга рассказывает о различных принципах “Lean Startup”, таких как построение минимального жизнеспособного продукта, измерение ключевых метрик, применение принципов “постоянного цикла сбора обратной связи – построения – изучения” и многих других. Она также включает в себя реальные примеры и истории успеха компаний, которые применили эти принципы для достижения значительного роста и успеха.
Основная идея Минимально Жизнеспособного Продукта (MVP) в книге “The Lean Startup” заключается в том, что перед тем как вкладывать большие ресурсы в разработку полноценного продукта, стоит создать минимальную версию продукта, которая имеет только необходимый минимум функциональных возможностей для того, чтобы убедиться в том, что продукт имеет спрос на рынке.
Вот основные выводы и принципы, связанные с MVP из книги “The Lean Startup”:
-
Сбор обратной связи рано и часто: MVP позволяет вам как можно скорее вывести продукт на рынок и начать собирать обратную связь с рынка. Это позволяет лучше понять потребности и ожидания игроков.
-
Интерактивный процесс разработки: MVP – это всего лишь первый шаг в разработке продукта. С использованием обратной связи и данных о взаимодействии, вы постоянно улучшаете итерации продукта.
-
Сокращение потерь: Создание MVP позволяет избежать больших инвестиций в продукт, который может оказаться не востребованным на рынке. Это помогает снизить риски и потери.
-
Понимание ценности продукта: MVP помогает определить, действительно ли ваш продукт решает проблему или удовлетворяет потребности игрока, а также насколько пользователи готовы платить за него.
-
Time to Market: MVP позволяет быстро запуститься на рынок, что может дать вам конкурентное преимущество и первичные данные о реакции клиентов.
-
Принцип “сделать, изучить, корректировать”: Эффективный процесс разработки включает в себя создание MVP, изучение данных и обратной связи, и корректировку продукта на основе этой информации.
-
Фокус на сущности: MVP фокусируется на самых важных и ценных функциях продукта, избегая излишней сложности и наворотов.
Примеры в книге дают нам понять, что продукт – это чаще всего Физические товары, Цифровые продукты, Услуги, Идеи и концепции (Иногда “продуктом” может быть новая идея, концепция или план, который вы хотите проверить на рынке).
Вот вывод, который можно сделать после чтения:
MVP - это не конечный продукт, а лишь первый этап, минимально необходимый для тестирования идеи или концепции. Это может быть упрощенной версией вашего продукта или услуги, обладающей только самыми важными функциями, чтобы проверить, будет ли он интересен и востребован на рынке. MVP создается с целью быстро получить обратную связь от пользователей и, при необходимости, внести корректировки в продукт перед тем, как затратить большие ресурсы на его полную разработку и масштабирование.
MVP – как методология
Теперь к сути. Примем во внимание все ценности и цели из книги, но расширим понимание, что есть PRODUCT. Выйдем за рамки, что продукт – это наша игра. Мне нравится называть продуктом, каждую составляющую игры. Каждая фича – это “мини продукт” внутри игры: Колесо фортуны, Сезонный пропуск, Система миссий… Все что у вас написано в AERM матрице, в GDD – все это продукты, к которым применим методология MVP.
Использование MVP для отдельных фичей имеет несколько преимуществ для более быстрой и дешевой валидации гипотез:
-
Снижение рисков
Оценка интереса пользователей к конкретной фиче или компоненту игры, прежде чем вкладывать много времени и ресурсов в разработку всего продукта. Если данная функция не пользуется популярностью, можно пересмотреть стратегию без больших потерь. -
Быстрая обратная связь
Запуск MVP для фичи позволяет быстро получить обратную связь от пользователей относительно конкретной части игры. -
Эффективное управление ресурсами
Оптимизация использования ресурсов, концентрируясь на разработке и тестировании только одной фичи, в минимальном формате. Это особенно полезно в начальной стадии разработки. -
Постепенное улучшение
После получения обратной связи и данных о том, как работает MVP фичи, вы можете поэтапно улучшать и дополнять эту фичу в соответствии с потребностями пользователей.
Можете называть это MVF – если удобно.
Как интегрировать MVP (MVF) в бизнес процесс
-
Определение цели и ценности фичи
Сначала определите, какую конкретную функцию или компонент игры вы хотите разработать и почему. Убедитесь, что она приносит измеримую ценность пользователям и соответствует вашим бизнес-целям. -
Идентификация ключевых элементов
Определите ключевые характеристики и функционал, которые являются неотъемлемой частью этой фичи. Фокус на самых важных элементах, которые необходимы для достижения цели. Важно зафиксировать минимальную планку качества для элементов, интерфейса, анимаций, состояние элементов, глубину контента фичи.
Вам важно сделать минимальную жизнеспособную версию фичи, а не кастрированную, которая потом не даст вам понять перфоманс из-за недостаточной доработки. -
Создание MVP
Разработайте минимальную версию фичи, включая только необходимые элементы и функциональность. Это должно быть как можно более простое и быстрое решение, позволяющее пользователям воспользоваться фичей.
То есть вполне нормально, после валидации идеи и грин лайта, выкинуть все что вы сделали в этом “баттл пассе” на костылях и плейсхолдерах, и запилить с нуля. Но уже будучи уверенным, что он точно полетит. -
Тестирование на аудитории
Запуск версии с MVP на ограниченную, но достаточную аудиторию пользователей, которая оценит и использовать фичу в формате АВ теста. Следим за тем, как они взаимодействуют с фичей и собираем обратную связь. Данные – итс э квин. -
Анализ результатов
Оценка результата тестирования MVP – анализ данных, обратной связи пользователей и показателей использования фичи. Успешно? Фича решает задачу из п.1? Какие улучшения требуются? -
Грин лайт
На основе полученных данных и обратной связи принимаем обоснованное решение, стоит ли продолжать развивать и улучшать данную фичу, добавлять новые функции или, возможно, отказаться от нее, если она не оправдала ожидания. -
Итерации и улучшения
Если решено продолжать разработку, начните поэтапно улучшать фичу, внедряя новые функции или исправляя недостатки, опираясь на обратную связь и данные с АВ тестов. -
Повторение – это процесс
Этот цикл тестирования, анализа и улучшения может повторяться несколько раз, постепенно дорабатывая фичу до полной реализации, и регулярной актуализации в угоду трендов рынка, ниши, динамики и прочих факторов. Но все через АВ и MVP методологию.
Методология MVP для отдельной фичи позволяет сосредоточить усилия на том, что действительно важно, и минимизировать сроки, риски и затраты на разработку. Она также способствует более быстрому внедрению новых функций или улучшений в продукт и более гибкому реагированию на потребности пользователей.
…MVP очень хорошо объясняет Закон Парето “20/80”. Нужно делать то, что занимает 20% времени и дает 80% результата. И вот это 20/80 надо применять всегда и везде. В каждом вопросе от вашей команды разработки или дизайна, когда где-то хочется пофиксить супер редкий кейс от тестировщика или дотюнить еще графику — вспоминайте 20/80 и скипайте все лишнее.
Oleg Medved – Easybrain
Про MVP очень хорошо объясняет закон парето 20/80. Нужно делать то что занимает 20% времени и дает 80% результата. И вот это 20/80 надо применять всегда и везде. В каждом вопросе от вашей команды разработки или дизайна когда где-то хочется пофиксить супер редкий кейс от тестировщика или дотюнить еще графику — вспоминайте 20/80 и скипайте все лишнее
Как начать использовать MVP на регулярной основе
Чтобы понять – нужно начать =)
Я могу посоветовать поэтапно вводить вообще любые новые методологии и фреймворки в работу. Это касается не только MVP. Не стоит сейчас наскоком идти перекраивать весь свой продакшен (или стоит?).
- Выберите фичу, которую попробуете внедрить в формате MVP. Я бы взял емкую фичу, которая дорого стоит в разработке, и сроки по ней вызывают легкую прокрастинацию.
- Дальше берем GDD этой фичи, и переписываем его в формате GDD MVP фичи. Т.е. указываем, что не берем на борт, где что-то упрощаем, а где используем заглушки, фейки, симуляции. Указываем критерии приемки, необходимые для валидных данных оценки фичи.
- Говорим команде, что костылить не просто можно, а нужно. Что потом, вероятно – мы все это выкинем, что главная цель – “Проверить, нужен ли нам вообще батл пасс”
- Не вкладываемся в визуальный контент. Все что можно купить на стоках, ассет сторах – экономит время, деньги? Потом перерисуем, когда пройдем грин лайт. Хотя практика показывает, что “НЕ ПЕРЕРИСУЕМ” =)
- Не забываем про трекеры, аналитику и тест.
Дальше шаг за шагом, от фичи к фиче вы переведете разработку на рельсы, где практика MVP станет базовой. Вы сами не заметите, как подсядите на эту методологию, и потом уже не сможете от нее отказаться.
У меня все.
Понравился пост?
Супер, я очень рад. Напиши комментарий, меня это мотивирует. Пошейри в социальных сетях – вот тут ниже я специально вставил эти кнопочки шейра.
И я буду рад видеть тебя у себя на курсах по
Там много вкусного, не только MVP.