На волне нынешнего хайпа про инфраструктурные платформы, наверное каждый слышал о книге Team Topologies.
Я ее сейчас пересказывать не буду, поэтому если какие-то термины или рассуждения ниже вам окажутся непонятными я рекомендую прочитать сперва ее, а затем вернуться к моему посту.
Из всех тем, рассматриваемых в 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-процессах)?
Что будет меняться для команды при движении по этому пути?
Зачем командам вообще двигаться по этому пути?
Кто и каким образом будет их по этому пути двигать?
Останется ли при таком видении роль для самой Модифицирующей Команды или же эта команда превратится в несколько команд поменьше? Мне кажется, это не столь важно если будут выполняться цели, которые ставит перед собой организация.
А как считаете вы?
