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

• Название: Карьера менеджера IT-проекта. Как устроиться на работу в ведущую технологическую компанию
• Автор: Джеки Баваро
• Жанр: Прочая околокомпьтерная литература
• Год: 2014
• ISBN: 978-5-496-01132-7, 978-0984782819

Новая книга от автора мирового бестселлера «Карьера программиста» поможет вам наилучшим образом подготовиться к собеседованию при приеме на работу менеджером проекта в крупную IT-организацию или перспективный стартап. Основную часть книги составляют ответы на технические вопросы и задания, которые обычно получают соискатели на собеседовании в таких компаниях, как Google, Microsoft, Apple, Amazon и других. Рассмотрены типичные ошибки, которые допускают кандидаты, а также эффективные методики подготовки к собеседованию.

---

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

Задачи продукт-менеджера

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

Хотя жизненный цикл продукта зависит от компании (а иногда и от команды), он, как правило, имеет четыре основных этапа: «Исследования и планирование – Разработка дизайна – Реализация и тестирование – Выпуск». Разумеется, эти этапы часто пересекаются друг с другом.

В некоторых компаниях/командах обязанности продукт-менеджера распределяются между двумя людьми, один из которых в большей степени сконцентрирован на бизнесе, другой – на технических вопросах. В этом случае технического сотрудника называют техническим руководителем программ, или техническим продукт-менеджером (Technical Product Manager, TPM), а сотрудника, ориентированного на бизнес, – просто продукт-менеджером (Product Manager, PM).

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

Исследования и планирование

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

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

После того как продукт-менеджер подготовил предварительный план, ему необходимо привлечь к работе других людей. В таких компаниях, как Microsoft, Apple и Amazon, одобрение происходит «сверху вниз» и высшее руководство задействуется на самых ранних этапах разработки проектов. В компаниях Google и Facebook, а также во многих стартапах преобладает подход «снизу вверх», в котором основная задача продукт-менеджера – выстроить отношения с инженерами.

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

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

Дизайн

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

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

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

• цели;

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

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

• прототипы;

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

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

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

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

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

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

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

Реализация и тестирование

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

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

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

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

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

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