Я не рекомендую с самого начала планировать функционал более чем одной или двух последующих версий – слишком многое может измениться, когда вы впервые представите пользователям своего кандидата в 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» за реальными продуктами.