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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот несколько тревожных сигналов, которые могут свидетельствовать о том, что на топологию следует обратить внимание:

• Вы постоянно перебрасываете разработчиков из одной команды в другую.

• Вы часто вынуждены вмешиваться, чтобы урегулировать конфликты, связанные с зависимостью команд друг от друга.

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

• Команды обладают слишком ограниченным объемом ответственности.

• Разработчики должны иметь дело со слишком большим количеством сложности во многих областях.

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

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

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

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

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