Марти Каган - Вдохновленные. Все, что нужно знать продакт-менеджеру

Спектр пользовательских прототипов весьма широк. На одном его конце находятся опытные образцы малой детализации. Они не похожи на реальный продукт; по сути, это просто интерактивный вайрфрейм. Многие команды используют их для всестороннего обдумывания продукта в тесном кругу коллег, но есть и другие способы применения этого метода.

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

На другом конце спектра находятся пользовательские прототипы высокой детализации. Несмотря на то что это тоже симуляция, она выглядит и воспринимается как нечто весьма реалистичное. Часто их даже не отличишь от настоящего продукта. Тем не менее это не так; данные, которые вы видите, не реальные, хоть и очень похожие.

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

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

Существенное ограничение пользовательского прототипа состоит в том, что он ничего не доказывает. Скажем, не дает гарантии, что ваш продукт будет продаваться.

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

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

Иногда для снижения серьезного риска, выявленного на этапе исследования продукта, нам нужна возможность собирать фактические данные о его использовании. Но делать это необходимо именно на этапе исследования, то есть задолго до того, как вы потратите время и силы на создание реального и масштабируемого готового продукта.

Мои любимые примеры использования этого вида прототипа связаны с применением динамики игры, релевантности результатов поиска, социальных фич и «воронки» работы над продуктом. Для этого, собственно, и предназначены прототипы на реальных данных.

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

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

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

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

1. Поскольку речь идет о коде, создавать такие прототипы должны инженеры-программисты, а не дизайнеры.

2. Поскольку это не окончательный продукт, готовый к выведению на рынок, бизнес на нем не сделаешь. Так что, если тесты на реальных данных проходят успешно и вы решаете выходить с продуктом на рынок, придется предоставить программистам достаточно времени для выполнения всей дальнейшей необходимой работы. Менеджер продукта не должен говорить инженерам, что все «уже и так, как надо»; это неправильно . Решение принимает не он. Однако он обязан гарантировать, что руководство компании и ключевые заинтересованные стороны в полной мере понимают ограничения прототипа данного вида.

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

Позже мы обсудим количественные методики для подтверждения надежности идей и продуктов, и вы увидите разные способы применения прототипа на реальных данных. А пока запомните: главное — иметь возможность направить на такой прототип некоторый ограниченный объем трафика и собирать аналитику о его использовании.