Из всех тем, рассматриваемых в Team Topologies наиболее непонятная тема — это Enabling team, “модифицирующая” или “преобразующая” команда. Я буду использовать слово Модифицирующая Команда, потому что такой же перевод используется в Platen.

В самой книге про нее говорится многих общих слов типа:

Enabling teams have a strongly collaborative nature; they thrive to understand the problems and shortcomings of stream-aligned teams in order to provide effective guidance

или

The mission of enabling teams is to help stream-aligned teams acquire missing capabilities, usually around a specific technical or product management area

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

Давайте попробуем разобраться.

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

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

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

Здесь команда может переходить на следующий уровень как сама, так и с помощью Модифицирующей Команды.

Кому как, а мне это больше всего напоминает путь артефакта по CI/CD пайплайну.

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

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

В данном случае на вход поступают “необученные” команды, а на выходе получаем “обученные”.

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

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

• Какой будет путь развития команд? Почему именно такой?
• Одинаковым ли он будет для всех команд, или же будет разным? Почему?
• Из каких промежуточных состояний он будет состоять?
• Нужна ли для перехода на следующую стадию отдельная команда, или же будет достаточно видеоролика на wiki и примера шаблона новой практики (что-то типа “Thin Enabling Platform”)?
• Обязательно ли командам проходить все эти состояния, или же можно пройти их выборочно?
• Для каждой команды будет только один путь развития, или будет несколько параллельных путей в различных компетенциях (например, пути развития в devops, в тестировании, в agile-процессах)?
• Что будет меняться для команды при движении по этому пути?
• Зачем командам вообще двигаться по этому пути?
• Кто и каким образом будет их по этому пути двигать?

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

А как считаете вы?