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

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

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

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

Для определения объема ответственности команды я использую термин «топология команд»[37]. Мне нравится этот термин, так как он отражает идею организации составляющих частей в рамках более масштабной системы.

Топология команд в продуктовой организации отвечает на следующие вопросы:

• Сколько продуктовых команд должно быть в нашей организации?

• Каков объем ответственности у каждой команды?

• Какие навыки требуются для каждой команды и в каком объеме?

• Какова степень взаимных зависимостей между командами?

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

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

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

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

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

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

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

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

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