На волне нынешнего хайпа про инфраструктурные платформы, наверное каждый слышал о книге 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-процессах)?

  • Что будет меняться для команды при движении по этому пути?

  • Зачем командам вообще двигаться по этому пути?

  • Кто и каким образом будет их по этому пути двигать?

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

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

Комментарии (4)


  1. gleb_l
    00.00.0000 00:00
    +1

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

    Но вот модифицирующая команда - эдакий белок-трансформер (или катализатор), с помощью (или через который) происходит трансформация команды X в команду Y - это очень крутая идея.


    1. erthad Автор
      00.00.0000 00:00
      +1

      Спасибо за комментарий! Да, идея о "модифицирующих командах" была введена в книге Team Topologies. Здесь я пытаюсь разобрать вариант как такие команды могли бы работать, потому что к этому у меня лично много вопросов.

      Касательно вашего комментария о динамическом профиле команды — имеются в виду долгоживущие "проекты" длиной в несколько лет? Я не уверен, что команду можно сильно поменять на горизонте планирования меньше чем полгода-год, команде же не только учиться и меняться, но еще и работать нужно.

      Или вы что-то другое имели в виду?


      1. gleb_l
        00.00.0000 00:00
        +1

        У проекта есть динамический профиль потребных ресурсов. Как у многоступенчатой ракеты. Команду хорошо строить так, чтобы ее профиль превышал везде профиль потребностей проекта. Но специалисты - не пороховые ускорители - ввод/вывод/замена - это тоже время/деньги/провал_производительности. В итоге короткие проекты проще делать статичными командами (кирпичами) - скажем 6 чел {спец 1..спец 6} * 12 месяцев. Хотя экономия на высвобождении экспертов на выбеге проекта может быть косвенная - за счёт участия его в бусте следующего и поддержке энтузиазма (читай - производительности).

        Динамическую пересборку, помимо всего, можно саутсорсить такому вот белку - и это очень круто, если результат более-менее повторяем.


        1. erthad Автор
          00.00.0000 00:00

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

          Спасибо за идею!