Мои любимые примеры использования этого вида прототипа связаны с применением динамики игры, релевантности результатов поиска, социальных фич и «воронки» работы над продуктом. Для этого, собственно, и предназначены прототипы на реальных данных.
Имплементация прототипа на реальных данных очень ограниченна. Обычно она не включает в себя ничего, что требуется для коммерческого внедрения продукта: ни полного набора сценариев использования, ни автоматизированных тестов, ни аналитического инструментария, ни возможностей интернационализации и локализации продукта, ни его производительности и масштабируемости. Ничего этого не требуется.
Прототип данного вида существенно меньше того, что будет создан со временем на его основе, поэтому планка качества, производительности и функциональности устанавливается значительно ниже. Он должен в достаточной мере эффективно собирать данные для некоторых очень специфических сценариев использования — вот и все его предназначение.
При создании прототипа на реальных данных инженеры не нацеливаются на все возможные сценарии использования. Они не решают вопросы поддержки интернационализации и локализации продукта, не занимаются вопросами производительности или масштабируемости, не разрабатывают автоматизированные тесты и включают в прототип только инструментарий для специфических вариантов использования, которые мы тестируем.
Прототип на реальных данных — это лишь малая толика работы, которая проделывается для полноценного вывода продукта на рынок (по моему опыту, на него уходит 5–10 процентов всей работы над готовым продуктом), но получаемую от него пользу переоценить невозможно. Однако следует помнить о двух существенных ограничениях:
1. Поскольку речь идет о коде, создавать такие прототипы должны инженеры-программисты, а не дизайнеры.
2. Поскольку это не окончательный продукт, готовый к выведению на рынок, бизнес на нем не сделаешь. Так что, если тесты на реальных данных проходят успешно и вы решаете выходить с продуктом на рынок, придется предоставить программистам достаточно времени для выполнения всей дальнейшей необходимой работы. Менеджер продукта не должен говорить инженерам, что все «уже и так, как надо»; это неправильно. Решение принимает не он. Однако он обязан гарантировать, что руководство компании и ключевые заинтересованные стороны в полной мере понимают ограничения прототипа данного вида.
Сегодня технология создания прототипов на реальных данных настолько эффективна, что мы часто можем получить нужное за два дня, максимум за неделю, после чего придется очень быстро выполнить требуемое количество итераций.
Позже мы обсудим количественные методики для подтверждения надежности идей и продуктов, и вы увидите разные способы применения прототипа на реальных данных. А пока запомните: главное — иметь возможность направить на такой прототип некоторый ограниченный объем трафика и собирать аналитику о его использовании.
Реальные пользователи будут применять ваш прототип в настоящей работе и генерировать подлинные данные (пригодные для аналитики), которые мы можем сравнить с данными о текущем продукте или со своими ожиданиями и увидеть, дает ли новый подход лучшие результаты. Вот что важно!
Глава 49. Смешанные прототипы
Итак, мы поговорили о пользовательских прототипах, или симуляциях, прототипах для проверки и устранения рисков, связанных с технической выполнимостью, и прототипах на реальных данных, предназначенных для подтверждения или даже получения статистически значимых доказательств эффективности нового продукта или идеи. Эти три вида прототипов отлично справляются с большинством ситуаций, однако существует огромное разнообразие смешанных прототипов, в которых по-разному сочетаются различные аспекты названной троицы.
Один из моих любимых смешанных прототипов и исключительно эффективный инструмент для быстрого обучения людей на этапе исследования продукта часто называют «волшебником страны Оз». Он состоит из проработанного интерфейса пользовательского прототипа с высокой степенью детализации и реального человека, который, стоя «за ширмой», как великий и ужасный Гудвин, вручную выполняет то, что в итоге будет делаться автоматически.
Прототип этого вида не подлежит масштабированию, и никто не стал бы направлять на него сколько-нибудь значительный объем трафика. Его главное преимущество, с нашей точки зрения, заключается в том, что он создается быстро и легко, а в глазах пользователя выглядит и ведет себя как реальный продукт.
Представьте, что вы предлагаете потребителям некий вид онлайн-консультаций (живой чат), но они доступны только в часы, когда ваш персонал по обслуживанию клиентов находится в офисе. Но вы знаете, что клиенты используют этот продукт во всех уголках мира, в любое время суток, поэтому хотели бы разработать автоматизированную систему на основе чата, которая давала бы полезные консультации круглосуточно.
Конечно, вы можете (и должны) расспрашивать сотрудников службы поддержки клиентов о типичных запросах и о том, как они на них обычно отвечают (для чего, кстати, отлично подходит консьерж-тест, позволяющий быстро собрать нужные сведения). Однако довольно скоро вам придется решить непростую задачу автоматизации этого процесса. Чтобы очень быстро протестировать несколько возможных подходов к ее решению, нужно создать прототип «волшебник из страны Оз», который обеспечит вас простым интерфейсом на основе чата. За «ширмой» будете сидеть вы, продакт-менеджер, или другой член команды, который будет получать запросы и составлять на них ответы. Скоро вы начнете экспериментировать с ответами системы и, возможно, даже используете прототип на реальных данных для своего алгоритма.
Смешанные прототипы — наглядный пример главной философской идеи в исследовании продукта: создавай то, что не поддается масштабированию. Подойдя к делу разумнее, мы научимся быстро и легко создавать инструменты, которые позволяют нам очень быстро учиться и приобретать новые ценные сведения. Конечно, это преимущественно качественное обучение, но именно оттуда мы нередко черпаем самые важные познания и проницательные идеи.
Методики для тестирования на этапе исследования продукта
ОБЗОР
При исследовании продукта мы пытаемся рассортировать хорошие и плохие идеи и одновременно решить поставленные перед нами бизнес-проблемы. Что в действительности это означает?
На этом этапе мы обдумываем четыре вопроса:
1. Будет ли пользователь или клиент использовать продукт, захочет ли он его купить? (Ценность.)
2. Сможет ли пользователь понять, как он работает? (Юзабилити.)
3. Сможем ли мы создать продукт с технической точки зрения? (Выполнимость.)
4. Способствует ли это решение жизнеспособности нашего бизнеса? (Бизнес-жизнеспособность.)
Во многих случаях на большинство или даже на все эти вопросы ответить очень просто, и они не сопряжены со сколь-нибудь значимым риском. Ваша команда уверена в своих силах; она много раз делала это раньше, и мы смело переходим на этап поставки продукта на рынок. Большая работа на этапе исследования нужна в случае, когда ответы на эти вопросы неоднозначны.
