Неоднозначность минимальных жизнеспособных версий

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

Рассуждения и споры не происходят на ровном месте: никто так рьяно не рассуждает о том, нужно ли увеличивать продолжительность жизни людей. Противоречивость MVP сосредоточена вокруг мысли о неготовности продукта, о формировании у клиентов неправильного первого впечатления. Apple не показывает iPhone в деревянном корпусе со словами, что это MVP и он еще допиливается (и в буквальном смысле слова тоже). Сторонники отвечают: ну, это неправильное понимание минимального продукта. Он должен быть целостный и формировать правильное впечатление, просто функций не должно быть периферийных. Противники на это: ну ничего себе MVP, если брать пример с Эппла! Да с такими первыми версиями и вторых не нужно…

Кто-то подходит с третьей стороны: нам нужен не MVP, а MAP – minimum awesome product!

В общем, тут не все так однозначно, так что лучше разобраться по порядку.

Популярность MVP

Если минимальный жизнеспособный продукт – такая прекрасная вещь, то как люди делали что-то все предыдущие тысячи лет, пока этот чудесный рецепт не был изобретен? Довольно просто: это понятие является лишь акцентом на одну из многих сторон логичного и прагматического подхода к решению задачи.

В любом непростом деле (а создание IT продуктов – именно оно, непростое дело) случается множество неудач. Неудачи порождают постоянный спрос на информацию о способах достижения успеха, который удовлетворяется в виде синтеза бесконечного ряда “рецептов“. Каждый такой рецепт обращает взгляд на конкретный аспект всего процесса и убеждает в его важности. Одной из таких важностей обладает и логика постепенных, последовательных шагов для достижения ориентира.

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

Скажем, мы хотим запустить в России копию австралийского сервиса для пар. Так и называется – Paired. Суть его в том, что пара регистрируется и связывается через мобильное приложение, после чего оба получают небольшие задания каждый день, занимающие 5-10 минут, направленные на сохранение, углубление и обогащение отношений. Например, “скажите своему партнеру как прекрасно он выглядит в сегодняшней одежде (если это действительно так)”.

Продумать основное – продумали, чего там сложного, но тут же возникают следующие мысли:

• Надо определенно добавить и другие языки, в первую очередь СНГ, вдруг пойдет по соседним странам если на взлетит в РФ
• Хорошо бы добавить советы от какого-то авторитета или знаменитости, чтобы и уровень доверительности повышался, и был дополнительный канал рекламы
• Можно продавать книги в области психологии отношений, аудио и обычные, прямо через приложение через партнерскую сеть. И дополнительная ценность для клиентов (они по скидке будут и вообще делаем на них акцент), и дополнительная монетизация. Возможно, продаж будет достаточно чтобы вообще приложение сделать бесплатным и тем самым привлечь как можно большую часть аудитории
• Надо добавить рекламу: через подписки много не заработать (1-2% будут платить), а реклама позволяет монетизировать всех оставшихся пользователей.
• Можно добавить и аккаунты для детей (виртуальные или реальные): общение родителей с детьми – тоже большая проблема, у всех мало свободного времени, а так сервис будет напоминать о самом главном и подсказывать, что лучше делать в какой день

Если есть стойкая вера в дополнительный эффект от одной из этих дополнительных опций, отказаться от ее реализации крайне непросто. И это совершенно ясно и с эмоциональной, и с вероятностной точек зрения.

Однако из-за того, что избыток функций приводит к расфокусировке внимания и к потере последовательности, случается так, что под этим грузом проект рушится, отсюда и столь пристальное уделение внимания MVP.

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

В результате мы имеем достаточно серьезную проблему и ее видимое интуитивное решение – обязательно сначала делать MVP и не забывать про это. Так эта мысль появилась и прочно закрепилась в IT сообществе где-то лет 20 назад.

Почему все-таки нет?

Важных контраргументов у противником MVP три:

Во-первых, нельзя сформировать первое впечатление дважды. Мы даем людям, событиям, предметам и явлениям первую эмоциональную оценку в течение нескольких секунд (в случае с людьми достаточно семи). Настолько быстро сконструированное мнение на удивление является самым стойким. Безусловно, есть множество факторов, способных изменить этот первый привкус, тем не менее это определенно исключение из правил.

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

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

Что-то неполное, незавершенное, психологически воспринимается как неполноценное, ненастоящее, не предназначенное для реального использования. Если клиент видит где-то заглушки, coming soon’ы, недоработки, у него создается именно это впечатление, несмотря на всю создаваемую продуктом пользу. Наши эмоции – чрезвычайно важный фактор и в нашей жизни, и в нашем выборе покупок. Подавляющее большинство товаров и услуг мы приобретаем через эмоциональные, а не рациональные решения. MVP, как правило, имеет все шансы попасть в чертоги негативного восприятия, откуда уже не возвращаются.

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

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

В-третьих, скорость и роста, и копирования IT продуктов, достаточно высока. Это означает, что, запустив MVP, он может начать стремительно начать набирать аудиторию и тут же упрется ростом в то, что это MVP. Слабые сервера, недостаточно функций, непродуманные второстепенные узлы. При этом конкурентам ничего не стоит скопировать ваш продукт за короткий промежуток времени. Наличие больших ресурсов (а в случае подтвержденного только что успеха конкурента имеет смысл их тратить, и именно в это окно) позволяет сделать дубликат продукта за 1-2 недели. Пока вы будете радоваться успеху, разговаривать с инвесторами показывать цифры, кто-то запустит более полнофункциональную версию, причем так, что с юридической стороны вы будете долго пытаться что-то доказать.

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

Прагматичность и итог

Создание продуктов, как и достижение любой другой цели, должно основываться на максимально прагматичной стратегии. Эта стратегия может иметь совершенно разную степень сложности (чем более точно она моделирует реальность в необходимом для достижения задач объеме, тем лучше), однако она всегда должна иметь достаточное количество степеней свободы.

Если вы делаете разные продукты с помощью одних и тех же технологий (вот принципиально) – вряд ли это оптимально для всех этих продуктов. Если все время идете путем MVP – это настолько же односторонне. MVP делает акцент только на одной из сторон логики, а нужно руководствоваться ей всей. Фокусироваться нужно не на методах, а на цели, и каждый раз использовать оптимальные по соотношению скорость/качество/затраты.

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