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