включена в функционал кандидата в MVP. Вы можете этого не делать лишь в том случае, если ваше превосходство производительности является неоспоримым. На данном этапе главная цель состоит в том, чтобы убедиться, что кандидат в MVP включает в себя именно тот функционал, который потребители сочтут существенно и выгодно отличающимся от других представленных на рынке продуктов, а в идеале – уникальным.
Фрагменты функций, которые, как вы считаете, должны входить в состав кандидата в MVP, далее следует внести в крайний левый ряд блоков, который можно озаглавить «v1» (версия 1), как показано на Рисунке 6.4. При этом оставшиеся блоки будут отодвинуты вправо. В продолжение этого процесса вы можете создать предварительную дорожную карту продукта, добавив столбцы для каждой последующей версии продукта. В эти столбцы вы будете вносить те фрагменты функций, которые планируете добавить при выпуске соответствующих версий.
Поскольку вы собираетесь стать лучшим на рынке по показателю «Преимущество производительности 3», функционал вашего кандидата в MVP должен включать в себя соответствующий блок функций с наивысшим приоритетом – P3A. Поскольку вы также планируете убедить пользователей в уникальности своего продукта при помощи «Фишки 2», соответствующий функциональный блок – F2A – также должен присутствовать в составе функционала вашего кандидата в MVP. И, конечно, он должен включать в себя все обязательные функции («Мастхэв»).
Рисунок 6.4. Определение функциональных блоков, входящих в разные версии кандидата в MVP
Следующую версию своего продукта – v1.1 – вы планируете дополнить функциональными блоками P3B и F2B для усиления «Преимущества производительности 3» и «Фишки 2», соответственно. В версии v1.2 вы планируете решить проблему «Преимущества производительности 1» с помощью добавления приоритетного блока функций P1A.
Я не рекомендую с самого начала планировать функционал более чем одной или двух последующих версий – слишком многое может измениться, когда вы впервые представите пользователям своего кандидата в MVP. Вы узнаете, что некоторые из ключевых гипотез были не совсем точными и выдвинете новые. В конце концов, вы вообще можете изменить свое мнение о том, какое из преимуществ является наиболее важным, или же у вас могут возникнуть идеи новых функций, направленных на достижение существующих преимуществ. Поэтому, даже если вы все же составили предварительные планы, простирающиеся далее создаваемой версии MVP, вам следует быть готовыми к тому, что их придется выбросить в корзину после получения обратной связи от потребителей и засесть за разработку новых.
На Рисунке 6.4 для каждого из преимуществ кандидата в MVP в версии v1 я представил только по одному функциональному блоку. Однако на практике может оказаться, что для обеспечения соответствующего преимущества вам понадобится разработать не один, а два или три фрагмента функций. Это будет зависеть от конкретной ситуации, а также от того, насколько малы ваши фрагменты функций. Тем не менее, принцип их выбора остается прежним: приоритет должен быть отдан фрагментам функций, которые – для каждого из преимуществ – располагаются левее в составленном вами листе функциональных блоков (см. Рисунок 6.3).
Теперь давайте сделаем шаг назад и немного поразмыслим. Вы уже проделали большую работу на пути создания бережливого продукта. В вашем распоряжении имеются:
1. Сформированные гипотезы о целевых потребителях.
2. Сформированные гипотезы об их недостаточно удовлетворенных потребностях.
3. Сформулированное ценностное предложение, которое вы планируете реализовать, чтобы ваш продукт отличался от аналогов и превосходил их.
4. Сформированный перечень идей функций, которые, по вашему мнению, смогут удовлетворить потребности пользователей. Кроме того, эти идеи разбиты на достаточно мелкие фрагменты для удобства их разработки.
5. Оценка приоритетов всех фрагментов функций, полученная на основе показателя рентабельности инвестиций.
6. Перечень отобранных функций для кандидата в MVP, которые, как вы считаете, представляют для пользователей наибольшую ценность.
Вы приложили немало умственных усилий, однако то, что вам удалось создать, все еще остается лишь кандидатом в MVP, набором взаимосвязанных гипотез. Теперь нужно получить обратную связь от пользователей о вашем кандидате в MVP, чтобы проверить правильность этих гипотезы. Но прежде чем приступить к тестированию, необходимо создать в пространстве решений рабочий прототип вашего кандидата в MVP, который можно будет вынести на суд пользователей. Это и будет нашим следующим шагом в процессе создания бережливого продукта.
Глава 7
Создание прототипа MVP (шаг 5)
После того как вы определили набор функций для своего кандидата в MVP, вам захочется протестировать его на пользователях. Чтобы это сделать, необходимо будет создать пользовательский опыт (UX), который вы сможете показать клиентам. Напомню, что это является верхним уровнем пирамиды соответствия продукта рынку.
На этом этапе цель состоит в том, чтобы создать такой прототип, который позволит вам проверить свои гипотезы. Как обсуждалось в главе 1, я намеренно использую пространный термин MVP-«прототип», чтобы охватить наиболее широкий спектр продуктов, которые вы можете протестировать на пользователях для получения обратной связи. Хотя первый же тестируемый «прототип» может стать в дальнейшем реальным MVP, его использование предоставляет возможность получить обратную связь быстрее и с меньшими затратами ресурсов, проверив выдвинутые гипотезы еще до создания настоящего MVP. Кроме того, как обсуждалось в главе 1, несмотря на то что я использую здесь термин MVP, процесс бережливого производства применим даже тогда, когда вы не создаете продукт с нуля, а, например, добавляете новую функцию или улучшаете уже существующее решение. Вид прототипа, который вы должны создать, зависит от того, какого рода тестирование вы собираетесь проводить.
Чем является (и чем не является) MVP?
Ведутся оживленные дебаты по поводу того, что следует понимать под термином MVP. Некоторые яростно доказывают, что лендинговая страница сама по себе уже является MVP. Другие утверждают, что это далеко не так, настаивая, что MVP должен быть реальным работающим продуктом или, по крайней мере, интерактивным прототипом. Способ, которым я разрешаю эту дихотомию, заключается в осознании того, что и то и другое является методом тестирования гипотез, лежащих в основе MVP. Использование термина «MVP-тест» позволяет прекратить эти дискуссии. Данный термин более точно описывает суть и оставляет возможность закрепить термин «MVP» за реальными продуктами.
Многие неверно истолковывают термин «минимально жизнеспособный продукт», делая слишком значительный акцент на слове «минимально». Они используют это как предлог для создания неполноценного MVP, который обладает слишком малой функциональностью, чтобы считать его жизнеспособным. Другие ссылаются на слово «минимально», чтобы оправдать некачественный пользовательский интерфейс или ошибки в коде. Несмотря на то что MVP по определению является ограниченным по представленному в нем функционалу относительно всего объема ценностного предложения, то, что вы предоставляете на суд пользователей, должно быть выше определенной
