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

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

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

Глава 46. Прототипы для тестирования реализуемости

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

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

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

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

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

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

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

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

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

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

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

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