На волне нынешнего хайпа про инфраструктурные платформы, наверное каждый слышал о книге 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-процессах)?
Что будет меняться для команды при движении по этому пути?
Зачем командам вообще двигаться по этому пути?
Кто и каким образом будет их по этому пути двигать?
Останется ли при таком видении роль для самой Модифицирующей Команды или же эта команда превратится в несколько команд поменьше? Мне кажется, это не столь важно если будут выполняться цели, которые ставит перед собой организация.
А как считаете вы?
gleb_l
Управление динамическими командами - это Dolby NR проектного менеджмента. Аналогии прямые - у проектного лайфтайма есть очень характерный динамический профиль требуемой специализации и квалификации - практически спектр сигнала, как функция от времени.
Но вот модифицирующая команда - эдакий белок-трансформер (или катализатор), с помощью (или через который) происходит трансформация команды X в команду Y - это очень крутая идея.
erthad Автор
Спасибо за комментарий! Да, идея о "модифицирующих командах" была введена в книге Team Topologies. Здесь я пытаюсь разобрать вариант как такие команды могли бы работать, потому что к этому у меня лично много вопросов.
Касательно вашего комментария о динамическом профиле команды — имеются в виду долгоживущие "проекты" длиной в несколько лет? Я не уверен, что команду можно сильно поменять на горизонте планирования меньше чем полгода-год, команде же не только учиться и меняться, но еще и работать нужно.
Или вы что-то другое имели в виду?
gleb_l
У проекта есть динамический профиль потребных ресурсов. Как у многоступенчатой ракеты. Команду хорошо строить так, чтобы ее профиль превышал везде профиль потребностей проекта. Но специалисты - не пороховые ускорители - ввод/вывод/замена - это тоже время/деньги/провал_производительности. В итоге короткие проекты проще делать статичными командами (кирпичами) - скажем 6 чел {спец 1..спец 6} * 12 месяцев. Хотя экономия на высвобождении экспертов на выбеге проекта может быть косвенная - за счёт участия его в бусте следующего и поддержке энтузиазма (читай - производительности).
Динамическую пересборку, помимо всего, можно саутсорсить такому вот белку - и это очень круто, если результат более-менее повторяем.
erthad Автор
Про динамическую пересборку я не задумывался, но кажется она уложится в эту же схему. И ключевые вопросы озвученные в конце статьи останутся теми же.
Спасибо за идею!