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

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

Хакатоны [14]проводятся в самых разных вариациях. В этой главе я опишу одну из своих любимых методик для быстрой выработки множества перспективных идей, решающих насущную проблему потребителя или вашего бизнеса.

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

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

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

Прототипы в различных формах и видах существуют с тех пор, как люди начали использовать технологии для решения проблем. Как говорил известный ученый в области теории вычислительных систем Фредерик Брукс: «Сразу планируйте что-то выбросить — все равно придется».

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

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

Далее я кратко расскажу об основных классах прототипов, а в последующих главах мы обсудим каждый из них подробно.

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

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

Суть прототипов на реальных данных объяснить несколько сложнее, но это чрезвычайно важный инструмент, полезный сразу в нескольких ситуациях. Главная их цель — в сборе фактических данных, чтобы мы могли что-то доказать или хотя бы подтвердить, а чаще всего выяснить, работает ли идея (относительно фичи, дизайнерского решения, рабочего процесса). Как правило, это означает, во-первых, что такой прототип требуется для доступа к своим источникам данных, а во-вторых, что мы должны иметь возможность направлять в него реальный трафик — в достаточном для сбора информативных данных количестве.

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

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

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