Как управлять bottleneck командой

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

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

Несколько советов из статьи для менеджеров таких команд:

👉Проблемы такого рода часто растут из архитектуры. Попробуйте привлечь нескольких независимых людей, чтобы они со стороны оценили вашу ситуацию и подсветили бы какие-то слепые пятна.
👉Найдите способ держать ваш менеджмент в курсе ситуации в команде, того, по каким причинам вы не справляетесь со всеми запросами, и как выстраиваете приоритизацию. Вам нужно получить защиту от так называемого stakeholder bullying, когда разные менеджеры с громкими тайтлами будут пытаться продавливать вас, чтобы их фича вышла в топ бэклога.
👉Подумайте, есть ли возможность перейти из сервисной в платформенную команду – и вместо выполнения работы за других людей давать им удобную платформу, которой они смогут пользоваться целиком без вас.
👉Рассмотрите подход внутреннего open source, когда люди из других команд могут сами делать нужные им фичи, а вы только принимаете PR.
👉Установите режим дежурств, в котором все входящие запросы к команде в каждый момент времени направляются строго на одного человека.