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

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

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

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

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

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

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

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

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

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

Автономия — концепция, обладающая большим значением, однако часто ее недооценивают как руководство компании, так и продуктовые команды.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы рассмотрим тему согласования подробнее в следующих главах.

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

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

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

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

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

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

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

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

• Платформенная команда, отвечающая за совместные сервисы, такие как аутентификация или авторизация.

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

• Платформенная команда, отвечающая за предоставление разработчикам инструментов для автоматизации тестирования и выпуска продукта.