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

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

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

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

3. Прототип служит действенным инструментом для совместной работы команды. Члены продуктовой команды и бизнес-партнеры могут вместе испытать его и выработать общий взгляд на проблему.

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

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

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

• с алгоритмом;

• производительностью;

• масштабируемостью;

• отказоустойчивостью;

• проблемами применения технологий, которые команда не использовала ранее;

• проблемами при использовании компонентов или сервисов других производителей, которые команда не использовала ранее;

• проблемами использования унаследованной системы, которую команда не использовала ранее;

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

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

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

Хотя созданием прототипа для тестирования этого вида риска обычно занимаются инженеры-программисты, эту работу относят к этапу исследования продукта, а не его поставки на рынок. Она выполняется в рамках принятия решения, следует ли вообще развивать этот подход или идею.

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

Пользовательский прототип, или симуляция — один из самых эффективных инструментов на этапе исследования продукта. Это дым и зеркала. Фасад, за которым ничего нет. Занавес, за которым пустота. Простыми словами, если речь идет о пользовательском прототипе интернет-магазина, то человек может вводить данные своей кредитной карты хоть сто раз, ничего не покупая.