Джеки Баваро - Карьера менеджера IT-проекта. Как устроиться на работу в ведущую технологическую компанию

На этом этапе продукт-менеджер начинает определять критерии успеха. Он представляет себе, как выглядит мир, если команда работает успешно. Чтобы объяснить команде основные цели работ, во многих компаниях используется модель целей и ключевых результатов (Objectives and Key Results, OKR). В этой модели продукт-менеджер вместе с командой определяет измеримые результаты, к которым они будут стремиться.

Когда продукт-менеджер сформировал консенсус относительно целей работы команды, наступает этап разработки дизайна продукта и его функциональных возможностей.

Дизайн продукта – это описание не только его пользовательского интерфейса и внешнего вида, но и функциональных возможностей. Роль продукт-менеджера в разработке дизайна продукта в значительной степени зависит от компании и команды.

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

• цели;

• варианты использования;

• требования;

• прототипы;

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

• интернационализация;

• безопасность.

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

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

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

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

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

Одна из важнейших задач на этапе реализации – обеспечение эффективной работы инженеров. Продукт-менеджер регулярно контактирует со своей командой и изучает текущее состояние дел.

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

Иногда реализовать требуемую функциональную возможность оказывается сложнее, чем предполагалось, и продукт-менеджер ищет способы скорректировать ее так, чтобы упростить реализацию. Если инженер работает медленнее, чем запланировано, то продукт-менеджер может пересмотреть план работ и отменить менее приоритетные работы.

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

Иногда командам приходится творчески подходить к поиску вариантов применения собственных продуктов. Например, Google выделяет сотрудникам бюджет на использование AdWords и стимулирует их проводить рекламные кампании, чтобы внутреннее тестирование было достаточно интенсивным.

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

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

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

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