Что такое мвп в играх
Мобильный гейм-дизайн: итерация vs. планирование и опасности MVP
Всем гейм-дизайнерам, которые не занимаются планированием, я хотел бы сказать:
«Остановитесь! Вы опасны. Вы изматываете разработчиков. Вы напрасно тратите драгоценное время и ресурсы, которые можно было бы легко сэкономить, уделяя достаточно внимания планированию. Проектирование на скорую руку оборачивается задержками в общей разработке. Спешка втиснуть новые полусырые фичи аукнется вам в виде незапланированных расходов. Работайте нормально!»
Как же делается качественное планирование?
Как правило, мобильный гейм-дизайн делится на две базовые школы принципов разработки:
1. Итерация – заложить базовые механики, а затем итерировать до тех пор, пока не получится что-то стоящее; набросок проекта до его последующей разработки.
2. Планирование – тщательно продумать каждую фичу, каждое окно, все зависимости и взаимодействия между основными фичами еще до начала разработки.
Обычно адепты школы итерации – это выходцы из мира ПК, где народ привык продавать максимально интересные для пользователя игры в базовой комплектации за фиксированную одноразовую плату. У таких игр часто высокий показатель удержания игроков и низкая монетизация.
На мой взгляд, стало слишком много людей, которые чересчур увлеклись методом итерации. Эти люди возвели MVP (англ. minimum viable product — минимально жизнеспособный продукт) в статус культа и сделали метод MVP универсальным костылем и дешевой отговоркой для того, чтобы не особо тщательно продумывать все фичи. Сторонники MVP-подхода часто приводят аргументы вроде:
• “Мы просто можем проитерировать это потом.”
• “О монетизации подумаем позже, а пока нужно сделать интересно.”
К сожалению, нетехнические разработчики не понимают, что игровой код не резиновый. Это вам не пластмассовые блоки LEGO собирать. Игра – не пластилин, ее нельзя сильно перекроить без существенных последствий. Всё потому, что код (особенно игровой код с изрядным количество хардкода) относительно негибкий.
На этот счёт у меня довольно радикальная точка зрения: я считаю, что многие гейм-дизайнеры, которые используют метод итерации в мобильных free-to-play играх, просто опасны тем, что могут загубить своей ленью целые команды разработки.
В новой мантре для разработки мобильных игр речь должна идти не о MVP с акцентом на “минимум” для разработки жизнеспособного товара, а о чём-то бóльшем.
Разрабатывай Минимально Жизнеспособный Продукт с Максимально Жизнеспособным Планированием
Индустрия мобильных игр не по зубам людям, которые не желают вкладывать время и усилия в планирование своих проектов.
Сплошь и рядом я вижу следующие типы развития событий:
• В разработку отдают полусырые, недостаточно продуманные идеи.
• Многие разработчики в погоне за трендовыми и наиболее прибыльными гейм-дизайнами запихивают в уже существующие игры фичи, которые смотрятся там крайне нелепо.
• Недостаточно хорошо продумывается взаимодействие фич и их влияние друг на друга в игре.
Всем гейм-дизайнерам, которые попадают в эту категорию, я хотел бы сказать:
«Остановитесь! Вы опасны. Вы изматываете разработчиков. Вы напрасно тратите драгоценное время и ресурсы, которые можно было бы легко сэкономить, уделяя достаточно внимания планированию. Проектирование на скорую руку оборачивается задержками в общей разработке. Спешка втиснуть новые полусырые фичи аукнется вам в виде незапланированных расходов. Работайте нормально!»
Как же делается качественное планирование?
На самом деле, всё сводится к таким основным задачам:
1. UI. Убедитесь, что интерфейс поддерживает вашу фичу. Заранее делайте макеты основных окон.
2. Пользовательский поток. Прежде чем отдавать новую фичу в разработку, убедитесь, что в ней учтены и продуманы все окна и их сочетания в пользовательском потоке. Что за поток? Читайте здесь: Mobile UI and Game Design: Screens vs. Flows.
3. Пограничные случаи. Продумайте все основные пограничные случаи. Что это такое? Пограничные случаи – это игровые ситуации, которые находятся за рамками нормального потока геймплея, но их тоже нужно прорабатывать. Проверьте, что в пограничных случаях нет подводных камней.
4. Влияние на систему. Подумайте, как новая фича повлияет на баланс и экономику вашей игры. Как она отразится на других системах в вашей игре. А в разных частях интерфейса? Убедитесь, что нигде не будет противоречий.
5. Влияние на проект. Как новая фича повлияет на геймплей, проектные параметры и монетизацию? Если вы сходу добавите новую PvE-фичу в PvP-игру, это может привести к КАТАСТРОФЕ. Как это отразится на ожидаемой и фактической монетизации? (Подробнее здесь: Monetization-based Game Design: ARPDAU Contribution) Подумайте над этим!
Но всё же, бывают случаи, когда лучше использовать итеративный подход вместо планирования. Например, в экспериментах с новыми типами геймплея, если именно это является основной задачей и главным риском. Кроме того, смысл не в СВЕРХпланировании. Рассматривать перечисленные выше вопросы проектирования стоит настолько, насколько это необходимо для каждой конкретной фичи, типа игры, ваших целей и т.д. Именно ваш отдельно взятый случай будет определять ваше Максимально Жизнеспособное Планирование. Стандартного решения всех проблем не существует.
В зависимости от ситуации, более тщательного планирования, как правило, требуют такие типы игр:
• Более сложные – комплексные, многосистемные, с большим количеством взаимосвязей; здесь необходимо понимать, как новая фича повлияет на всё остальное в игре.
• Больше UI – тоже более сложные, но в плане большого количества окон;
• Мультисистемные — чем хардкорнее ваша игра, тем больше в ней систем.
• Надеюсь, эта публикация поможет кому-то из вас увеличить шансы на успех вашего продукта за счет планирования.
• Нужно понимать, когда ситуативно использовать планирование, а когда — итерацию.
• Используйте вышеупомянутые приемы для уменьшения итераций на продакшене; основная часть планирования должна выполняться на первых этапах разработки игры, когда стоимость изменений еще сравнительно небольшая.
Расшифровка MVP. Что означает эта аббревиатура и в каких видах спорта она используется
Под аббревиатурой подразумевается слово, образованное путем сокращения двух слов или более до заглавных букв. «Аббревиатура» с латинского языка переводится как «краткий» (brevis). Таким образом, аббревиатура полностью оправдывает свою цель: используя ее, многие сводят к минимуму потерю времени в разговоре или письме. Итак, что же подразумевается под выражением MVP?
Расшифровка MVP
Эта аббревиатура применяется в различных сферах, к примеру, в проектировании и химиотерапии. Но в этой статье пойдет речь о том, какова расшифровка MVP в спорте. Сегодня MVP используется как в профессиональных спортивных соревнованиях, так и в любительских.
В футболе
MVP в баскетболе
В США этот приз выдают четыре раза в год. Первый MVP присуждается по итогу сезона, состоящего из 82 матчей. Игроки команд, победивших в 50 играх и попавших в плей-офф, выбирают наиболее ценного участника чемпионата. К примеру, в 2018 году трофей MVP достался игроку «Хьюстона» Джеймсу Хардену. В среднем за матч Джеймс набирал более 30 очков, сделав 8 передач и 5 подборов. Безусловно, он очень помог своей команде стать первой в том сезоне.
В разное время обладателями этой награды были такие известные спортсмены, как Коби Брайант, Шакил О’Нил, Майкл Джордан, Уилт Чемберлен, Леброн Джеймс и другие. Но более всего побед (шесть!) у Карима Абдул-Джаббара, игравшего в НБА практически 20 лет.
Поскольку в национальной баскетбольной ассоциации проводится чемпионат и среди женщин, приз MVP получает баскетболистка, набравшая максимальное количество баллов среди остальных.
Итак, нет ничего сложного в расшифровке MVP в баскетболе. Просто запомните: наиболее ценный игрок (по результатам голосования) получает приз в соревновании.
В хоккее
Безусловно, получить личный приз очень приятно. Миллионы спортсменов мечтают об этой награде, но лишь немногие получают ее.
Разбор системы MVP в Лост Арк
Спасибо за предоставленный разбор игроку aguardente.
Попробуем разобраться как работает система MVP* в Lost Ark.
*MVP – Most Valuable Player – Самый ценный игрок
Игра выбирает MVP суммируя показатели игрока по 7 пунктам:
Нанесённый урон | Контроль | Исцеление | Защита группы | Личная защита | Уничтоженные враги | Использование предметов
Так же в соответствии с полученным результатом, игрокам присуждаются соответствующие титулы:
Способ выбора MVP
Система складывает все показатели игроков. Игрок с наибольшей суммой по всем показателям получает титул MVP.
Игрок А по сумме набранных очков вклада получает титул MVP. В окне статистики после боя будут показаны его 3 наибольших показателя в % значении.
Оставшиеся, помимо MVP, игроки получают лишь титул за свой лучший показатель из семи, без цифровых показателей:
Титулы и соответствующие им процентные показатели за Нанесённый урон и Контроль были подтверждены разработчиками.
Однако, стоит принимать во внимание, что указанная информация по % урона и контроля актуальна лишь для группы из 4 человек. В рейдах действуют свои процентные показатели.
Теперь, когда мы знаем как работает система в целом, давайте разберёмся с некоторыми интересными моментами. Вернёмся к нашей таблице вклада:
Цифры в этой таблице – это присуждённые баллы(не проценты). Однако, в случае с показателями нанесённого урона, контроля и исцеления количество баллов равно количеству процентов.
Таким образом Игрок А, получивший 40 баллов нанёс 40% урона, а игрок D нанёс 10% урона, за что получил 10 баллов.
В случае с остальными показателями (личная и групповая защита, уничтоженные враги, использованные предметы) количество баллов не равно проценту уничтоженных врагов, но напрямую зависит от этого процента.
Такая сложная на первый взгляд схема сделана как некий понижающий коэффициент, так как разработчики решили, что урон, контроль и исцеление являются неизмеримо более весомыми критериями, нежели использование предметов или личная защита.
Так же в отдельных активностях некоторые критерии не учитываются вовсе: например, количество уничтоженных врагов в Рейдах на хранителя.
При использовании предметов учитываются только предметы подходящие для данного вида активности: например, поисковые ракеты в Хаосе учитываться не будут.
Так же у каждого из критериев есть минимальные показатели, необходимые для того, чтобы просто попасть в таблицу MVP. Если игрок не достиг ни одного минимального показателя (стоял АФК, например), в таблице он указан не будет.
Рассмотрим интересный пример, касательно показателей Нанесённого урона (пожалуй, самого «любимого и ценного» для игроков):
Игрок А получил наибольшую сумму баллов и забрал себе титул MVP. Так же он нанёс 40% урона и получает титул «Яростный воин». Игроки В и С нанесли по 30% урона и должны оба получить титулы «Благородный воин». Однако, в случае если титул за наибольший нанесённый урон получает MVP, то лишь один из оставшихся игроков получит свой титул за нанесённый урон. В нашем случае это будет либо Игрок В, либо Игрок С. Предположим, что Игрок В получил титул за нанесённый урон, тогда Игрок С получает свой титул за второй высочайший показатель из всех остальных: Исцеление 26%.
Таким образом окно статистики будет выглядеть следующим образом:
И вот казалось бы: Игрок В получил титул «Благородный воин», а Игрок С титул всего лишь за Исцеление, значит Игрок В нанёс больше урона. Но мы с вами знаем, что урона оба игрока нанесли одинаковое количество. Вот так таблица MVP может с лёгкостью вводить в заблуждение.
Рассмотрим ещё один пример:
Игрок А по сумме баллов получает титул MVP, однако, урона он нанёс меньше всех. В таком случае все игроки могут получить свой титул за Нанесённый урон, в случае если этот показатель является наивысшим среди всех их показателей:
Комментарии
Все здорово спасибо. Один момент, думаю мало кто понимает, что такое контроль в игре (если пояснить то будет в + к информативности статьи).
Вместо открытой понятной системы вроде дпс метра, такая ерунда во всем в игре, включая шансы точки, фетранита и дропа, мне кажется тут вообще скрытое кд на успех.
Ты не прав. Если пати хорошее, то есть ты как дибил не попадаешь под атаки, а если попал кто-то один то ради него расчехлять хилку бред, то во впервых за место того чтобы давать хил бард будет давать баф на урон, а во вторых у ДДшников вливается очень много контроля помимо урона, то есть раскол брони где он есть и изнурение. Нормальный и полезный бард то как раз не будет попадать в пати, сам факт того что тебе постоянно нужна хилка говорит о том что ты бесполезный ДД и первенство Барда будет оправдано. Играем сейчас в топ активностях и в приоритете именно баф на урон, да и некогда в луже хила стоять, легче банку съесть если провтыкал урон по себе.
Благодарим за комментарий, он отправлен на модерацию
MVP: что это такое и как работает?
Читая новости про проекты и сервисы, вы могли часто сталкиваться с понятием MVP. Но что скрывается под этой аббревиатурой и почему MVP так часто используют на начальных этапах развития продукта? Давайте прямо сейчас вместе разберемся в этом.
Что собой представляет MVP
Minimal Viable Product (минимально жизнеспособный продукт) — тестовая версия товара, услуги или сервиса с минимальным набором функций (иногда даже одной), которая несет ценность для конечного потребителя.
MVP создают для тестирования гипотез и проверки жизнеспособности задуманного продукта, насколько он будет ценным и востребованным на рынке.
Результаты тестирования минимально жизнеспособного продукта и обратная связь от целевой аудитории помогают понять, стоит ли развивать проект дальше, какие изменения следует внести в стратегию, а что оставить в первоначальном виде.
В 2008 году, когда аренда отеля или жилья во время путешествия была большой проблемой, два энтузиаста решили подойти к вопросу нестандартно и сдали свою квартиру по простому факсу. По сути, это тоже MVP, в котором тестировалась основная функция. Эксперимент показал, что продукт получит спрос, а сегодня Airbnb — одна из крупнейших площадок по поиску краткосрочной аренды жилья.
MVP и PoC — одно и то же?
Proof of Concept (PoC) — доказательство правильности концепции и некоторые новички часто путают его с минимально жизнеспособным продуктом. PoC описывает процессы выяснения технической жизнеспособности концепции программного обеспечения (или любого другого продукта).
Да, эти определения взаимосвязаны, но не взаимозаменяемые. Proof of Concept — описание процессов на начальной стадии развития продуктов, которые потом реализуются фактически, из чего получается MVP.
Виды MVP
Есть много разных подходов к созданию минимально жизнеспособного продукта, но на практике чаще всего используют некоторые из них. Далее поговорим о наиболее популярных.
MVP Флинстоуна
Помните, как в популярном мультике «Флинстоуны» глава семейства создавал иллюзию передвижения на автомобиле? Так вот, этот подход предусматривает имитирование наличия функционала, хотя на самом деле технически он никак не реализован. MVP нацелен на проверку гипотезы, доказательство жизнеспособности выбранной модели развития бизнеса.
Он сделал сайт и опубликовал фото разных моделей обуви. Получил заказ, пошел в магазин, приобрел нужную пару и отправил покупателю. Так он проверил жизнеспособность идеи продаж обуви через интернет, при этом изначально он не тратил деньги на аренду склада и закупку продукции, а лишь имитировал их наличие.
Консьерж MVP
Эта методология больше подходит для онлайн-сервисов, конечная цель которых — автоматизировать решение проблем целевой аудитории. На начальных этапах реализации продукта услуга оказывается вручную.
Например, мы хотим сделать сервис по финансовому учету и планированию для физических лиц. Но чтобы проверить, будет ли пользоваться спросом эта идея, сначала сделаем несколько финансовых планов для клиентов вручную через Excel. Так мы сможем понять, кто и сколько готов платить, какие функции нужно реализовать в первую очередь и т.п. Часто консьерж MVP помогает в генерации новых идей, которые впоследствии делают конечный продукт лучше.
Эту модель в конце 90-х годов использовал Чак Темплтон — основатель сервиса по онлайн-бронированию ресторанов, билетов и многого другого. Он не стал сразу вкладывать сотни тысяч долларов в техническую реализацию сервиса, а бронировал для других людей столики в ресторанах вручную. Так он проверил жизнеспособность идеи, понял, кто, сколько и за что готов платить и познакомился с целевой аудиторией.
Разрозненный MVP
Метод разрозненного MVP используют, когда идею можно проверить и реализовать без разработки уникального программного обеспечения. Вместо этого собирают готовые инструменты, объединяют в одну систему и преподносят в едином интерфейсе.
Если бы все компании начинались с разработки уникальных решений, которая обходилась бы в сотни тысяч долларов, мы бы не увидели много крутых проектов. К этому, как правило, переходят после запуска, получения обратной связи и первых результатов.
Посмотрите на популярный сервис совместных покупок Groupon. Когда-то он был простеньким сайтом на WordPress, где все взаимодействие с пользователями осуществлялось по электронной почте. Только после получения первой обратной связи и финансовых результатов были разработаны социальные функции, полноценная email-рассылка, автоматизация и мобильное приложение.
Продукт с одним параметром
Эту разновидность используют чаще всего, когда есть готовый продукт с минимальным набором функций (как правило, одной). По такому принципу действовали основатели Spotify, которых упомянули в начале статьи.
Выпуск продукта с одной функцией (параметром) позволяет сузить целевую аудиторию, получить обратную связь и проанализировать ее, после чего приступить к тестированию.
Когда и для чего нужно делать MVP?
Приступайте к разработке MVP на начальных стадиях развития продукта. Идея может быть крутой только у вас в голове (да, такова уж суровая реальность), так зачем сразу вкладывать большие деньги в разработку, когда есть вариант с маленькими затратами и точной проверкой? После выпуска минимально жизнеспособного продукта вы определите спрос и поймете, в правильном направлении развиваете проект или нет.
Но самое крутое в MVP — сбор ценной информации от первых пользователей. Именно конечный потребитель расскажет о правильной реализации проекта. Собранные данные используйте для планирования дальнейших обновлений и определения наиболее приоритетных целей: какие функции реализовать в первую очередь.
Как сделать MVP правильно
В теории вы узнали, что такое минимально жизнеспособный продукт, теперь поговорим о практической части — создании MVP. Для получения хорошего результата разложите работу на мелкие итерации (шаги/этапы), обозначьте цели для команды в целом и задачи для каждого члена. Но в первую очередь донесите до коллектива общие принципы работы и создания продукта.
Нулевой этап: определяем основные принципы создания MVP
Проведите общее собрание коллектива, который примет участие в разработке MVP. На нем вы должны разобраться, все ли члены команды понимают, зачем это нужно. Обсудите видение минимально жизненного продукта, сложите все воедино и постройте первый примерный план дальнейшей работы.
В ходе общего собрания обсудите следующие вопросы:
Первый этап: поиск проблемы, которую решит MVP
После определения основных принципов MVP, ответьте на вопрос: «Какую проблему решает продукт?». Опишите его ценность в нескольких предложениях. Во-первых, это полезно для себя и команды, во-вторых, в дальнейшем поможет в создании уникального торгового предложения, лендинга и рекламной кампании.
Например, создаем сервис по финансовому планированию для физических лиц. Он решает проблему «бесконтрольного расходования денежных средств, помогает организовать бюджет и ставить долгосрочные цели».
Второй этап: находим целевую аудиторию
Распространенная ошибка начинающих продактов и предпринимателей — они считают, что их проект решает проблему широкой аудитории (всех людей). Такой подход в разы повышает вероятность провала. Сфокусируйтесь на определенной целевой аудитории.
Составьте портрет клиента, который обязательно купит продукт. Опишите его пол, возраст, социальное положение, уровень дохода, потребности, привычки, используемую им технику, распространенные проблемы, предпочтения в отдыхе и т.п.
Не торопитесь на этом этапе! Лучше потратить несколько часов для формирования портрета ЦА, чем потом «слить» весь рекламный бюджет и получить минимальную конверсию. И не забывайте про то, какую проблему решает MVP (это определяется на первом этапе).
Пример с сервисом по составлению финансовых планов для физических лиц:
Третий этап: определяем основных конкурентов
Не думайте, что ваш продукт (идея) уникален и такого больше нигде нет. Если вы с ним не сталкивались лицом к лицу, это не гарантирует уникальность. И вообще есть гипотеза «множественного открытия»: все исследования и изобретения делаются сразу несколькими учеными независимо друг от друга.
Эту гипотезу подтверждает история с разработкой радио. В России считают, что его изобрел Александр Попов, а вот в Италии лавры отдают Гульельмо Маркони. Оба начали работать над реализацией идеи в 1894 году, но Попов свою разработку презентовал в марте 1896 года (но при этом не запатентовал), а Маркони в июне 1896 года подал документ на патент. Кстати, есть еще несколько ученых в разных странах, которые также претендуют на звание «создатель Радио».
История с MVP аналогичная: вы должны потратить немало времени, но постараться найти конкурентов. Вам повезет, если идея все-таки окажется уникальной, а если нет, тогда решите следующие задачи:
Для удобства советуем составлять сводную таблицу со всей собранной информацией. Впоследствии будет проще ориентироваться в больших массивах данных и принимать какие-либо решения.
Четвертый этап: проводим SWOT-анализ
SWOT-анализ представляет собой таблицу, состоящую из четырех блоков:
Не расписывайте пункты на целые абзацы. Они должны быть короткими и понятными для всей команды.
Обратите внимание, что таблица разделена на две части. Сильные и слабые стороны, как правило, относятся к внутренним факторам, а возможности и угрозы — к внешним.
Цель SWOT-анализа выявить сильные стороны и возможности, чтобы сосредоточить работу на них для минимизации негативных последствий от слабых сторон и угроз. Сделанные выводы помогут выбрать стратегию развития и позиционирования бизнеса на рынке.
Пятый этап: создаем карту пути пользователя
Простой блиц для определения удобства продукта: если вы сами не понимаете, что надо делать с вашим сервисом (продуктом, услугой и т.п.), то потребитель разобраться точно не сможет!
Чтобы избежать такого недоразумения, на пятом этапе создания минимально жизнеспособного продукта составляют карту пути пользователя — что делает пользователь при взаимодействии с продуктом. Вы должны понимать, какие у аудитории требования к контенту, дизайну, интерфейсу.
Кстати, не забывайте корректировать карту пути пользователя (user flow) после получения обратной связи от первых клиентов. Они расскажут, что хорошо, а что плохо или неудобно. На основе этого корректируйте карту, чтобы конечный потребитель получал то, что хочет.
Например, для сервиса по финансовому планированию сделали такую карту:
Шестой этап: составляем перечень функций продукта
На прошлом этапе вы определили основные взаимодействия пользователя с продуктом, теперь для каждого опишите конкретные функции. Для удобства составьте специальную карту: взаимодействия и функции для каждого. Сначала она выглядит так:
Дальше для каждого взаимодействия определяется перечень функций. Здесь помогут логика и пользовательские истории. В первом случае самостоятельно или вместе с командой подумайте, что нужно сделать для обеспечения того или иного взаимодействия.
Но как вы помните, наше видение часто искажено, а вот реальные пользователи дают объективную информацию на основе опыта. Пользовательские истории описывают те или иные действия людей, на основе которых определяются необходимые функции.
Дальше расставьте все функции по приоритету. Самые востребованные (которыми пользуются чаще всего) ставим в начало списка, редко используемые — в конец. Должна получиться вот такая карта:
Седьмой этап: определяем функции MVP
На этом этапе вы должны определить функционал MVP или иными словами — запланировать объем минимально жизнеспособного продукта. Для начала определите несколько основных функций, без которых проект вообще не сможет существовать, от него не будет никакого толку. Это — каркас или наименьшая полезная версия продукта.
Каркас как дом без отделки — вроде бы, жить можно, но как-то не очень. Поэтому в большинстве случаев MVP дополняют разными «полезностями». Для этого необходимо определить существенные и несущественные функции: какие нужны сейчас, а какие можно доработать потом в процессе развития проекта.
Опять же, классифицировать функции лучше коллективом. Обсуждения, споры, аргументация — это приведет к определению оптимального объема минимально жизнеспособного продукта. На карте выделите каркас и дополнительные функции в рамках MVP для удобства дальнейшего планирования. Должно получиться что-то наподобие этого:
Такую карту с объемом минимально жизнеспособного продукта можно сделать на компьютере или на магнитной доске, стоящей в переговорной или аналогичном помещении. В ходе разработки допускается внесение корректировок.
Восьмой этап: выберите метод управления и разработки
Вы готовы к началу работы: определена идея, задачи, цели объем MVP. Осталось выбрать модель управления для достижения максимальной эффективности и соблюдения установленных сроков разработки. Возможно несколько вариантов:
Девятый этап: проводите тестирования
Тестируйте MVP короткими итерациями: альфа- и бета-тестированием. Альфа — внутренний этап: закончили разработку, пользуйтесь продуктом внутри команды несколько дней. Если все окей, запускайте бета-тестирование — внешний этап, дайте доступ к проекту первым пользователям. Длительность: 7-14 дней.
После первой беты соберите отзывы, статистику посещений, аналитику поведений и проанализируйте весь массив данных. Так вы узнаете, что надо доработать, что можно убрать, а что, наоборот, надо добавить в срочном порядке.
Несколько итераций «разработка-альфа-бета» помогут прийти к оптимальной первой версии продукта, который можно выпускать на рынок для массового пользователя и продолжать дорабатывать.
Еще раз поговорим всю последовательность этапов:
Самые распространенные ошибки при создании MVP
Теперь вы знаете, как создать свой MVP. Но есть еще один момент: новички (им это простительно, кстати) часто допускают ошибки при планировании первых минимально жизнеспособных продуктов. На второй-третий раз, набравшись опыта, они работают быстрее и эффективнее.
Но зачем учиться на собственном опыте, когда есть чужой? Почему бы не использовать его и постараться избежать неточностей на своем пути? Поэтому далее поговорим о самых распространенных ошибках начинающих продакт-менеджеров и предпринимателей.
Попытки достигнуть идеала
Закройте в клетке своего перфекциониста, потому что в ходе разработки MVP он сыграет с вами злую шутку! Запомните, задача минимально жизнеспособного продукта — дать пользователю базовое представление о продукте, он априори не должен и не может быть идеальным.
Вы тестируете гипотезу! Поверьте, маленького MVP хватит для определения потенциала идеи. Если она крутая, то спрос на продукт не испортит даже плохой дизайн, интерфейс и минимальная скорость работы. И только при подтверждении этой гипотезы начинайте тратить ресурсы на юзабилити и красивый фантик.
Небрежная работа
Если MVP не должен быть идеальным, это не значит, что его можно делать, как попало. Некоторые продакты бросаются из крайности в крайность, в результате получает вообще что-то непонятное.
Минимально жизнеспособный продукт должен быть простым, но качественным. Например, если делаете сервис, то купите хотя бы домен второго уровня, не надо оставлять его на поддомене какого-то бесплатного конструктора.
Отсутствие обратной связи
Некоторые новички так увлекаются разработкой, что забывают о приоритетной цели — сборе обратной связи. Еще на стадии планирования следует определить ключевые метрики, которые покажут успешность проекта. Это может быть количество скачиваний или покупок, число новых пользователей, коэффициент удержания клиентов и т.п.
«Пустые» обещания
Когда «глаза горят», есть ощущение способности свернуть горы! И в такие моменты руководитель начинает делать анонсы крутых и необычайных возможностей. Конечно, это все здорово с точки зрения маркетинга, но если не сдерживать обещания, пользователи начнут покидать проект.
Поэтому всегда принимайте решения о новых анонсах на «холодную» голову. Объективно оценивайте, что сможете сделать, а что нет.
Отказ от анализа и аналитики
Окрыленность собственной идеей часто дурманит разум и вся команда перестает обращать внимание на объективные факты: плохие метрики, отрицательные отзывы и т.п. Начинают думать, что просто пользователи не все понимают сейчас, а вот когда финальная версия продукта будет готова, тогда они оценят.
Нет, не оценят. В этом деле всегда важен объективизм. Есть обратная связь от реальных пользователей, слушайте ее, корректируйте работу проекта в соответствии с желаниями конечных потребителей, иначе во всей этой суете нет никакого смысла.
Итак, подведем краткий итог: MVP — минимально жизнеспособный продукт, который делают для тестирования идей и гипотез, сбора обратной связи от первых потребителей (и да, MVP ≠ PoC). Реализовать можно за 10 этапов и постараться избежать наиболее распространенных ошибок. Если вы планируете создание нового продукта, начинайте с MVP: это позволит избежать больших ресурсных потерь в случае плохого потенциала идеи.