Чтение онлайн

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

Близость к клиентам

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

Близость к бизнес-партнерам

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

Близость к менеджерам

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

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

Близость к другим продуктовым командам

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

Близость к топ-менеджменту

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

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

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

Вот две частые ситуации, когда компромиссы оказываются полезными.

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

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

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

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

У стартапов необходимость в топологии обычно появляется, когда число инженеров превышает 15 человек или около того.

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

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

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

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

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

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

• Новая стратегия включает сворачивание продукта, выпуск которого поддерживается в настоящее время несколькими продуктовыми командами.

• Новая стратегия предоставляет доступ к некоторым ключевым возможностям одной продуктовой команды другим командам посредством внутренней платформы.

• Новая цель бизнеса — разработать предложение для расширения рынка.

• Масштабный рефакторинг архитектуры ПО.