Обзор книги “Топологии команд” (“Team Topologies”) — Часть III

В этой статье я закончу рассказывать про книгу Team Topologies, которая мне понравилась и про которую я рассказывал в предыдущих статьях: 1 и 2. В этой статье мы рассмотрим последнюю часть, а именно “Evolving team interactions”. Эта часть посвящена тому, как четко определенные паттерны взаимодействия команд и эвристики для эволюции топологии команд могут приносить стратегическую пользу организациям.

Виды взаимодействия команд

Всего авторы выделяют 3 вида взаимодействий команд, которые изображены на рисунке ниже.

И вот что они значат

  • Collaboration (сотрудничество) — тесная совместная работа нескольких команд
  • X-as-a-Service — предоставление или потребление сервиса с минимальной потребностью в совместной работе
  • Facilitating — предоставление или принятие помощи для устранения препятствий в работе

Ключевой частью подхода Team Topologies являются критерии выбора для двух команд между сотрудничеством (Collaboration) и потреблением сервиса (X-as-a-Service) другой команды. Вот плюсы, минусы и ограничения каждого из подходов, включая Facilitating.

А вообще можно пойти дальше и составить табличку с вариантами взаимодействия и их типичностью для каждого из четырех видов команд. Эта таблица представлена ниже.

И если взять только типичные варианты взаимодействия, то они будут выглядеть так

Теперь мы знаем какие бывают взаимодействия и настало время перейти к главе

Evolve Team Structures with Organizational Sensing

Современные организации сталкиваются вынуждены активно подстраиваться под изменения на рынках и в законах. Поэтому важна не структура самой организации, а ее правила принятия решений и эвристики, которые она использует для подстройки под происходящие изменения. В этой главе рассматриваются такие правила дизайна для современных организаций, важной частью которых является разработка софта. Эти подходы учитывают Закон Конвея, топологии команд и team-first подход к принятию решений.

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

Также вам нужно помогать с обучением и принятием новых практик в организации. Для этого можно использовать преднамеренное сотрудничество (collaboration) или подход с фасилитацией (facilitating).

Взаимодействие команд может меняться со временем. Например

Initial close collaboration evolves into more limited collaboration on a smaller number of things as the technology and product is better understood through discovery, and it further evolves into X-as-a-Service once the product or service boundary is more established.

Вот так это может выглядеть.

Для того, чтобы понять когда надо менять топологию команд можно ориентироваться на триггеры и симптомы, которые приведены ниже. Триггеры выделены красным и симптомы выделены желтым.

Интересно решение последней ситуации, когда “Multiple Business Services Rely On a Large Set of Underlying Services”. В этом случае стоит

1. “Platformize” the lower-level services and APIs with a thin “platform wrapper” that provides a consistent developer experience (DevEx) for stream-aligned teams with things like request-tracking correlation IDs, health-check endpoints, test harnesses, service-level objectives, and diagnostic APIs. This “outer platform” is built on a still lower-level platform, but that remains hidden from stream-aligned teams.

2. Use stream-aligned teams for each high-level business service responsible for operational telemetry and fault diagnosis: building and evolving “just enough” telemetry integration and diagnostic capabilities to be able to detect where problems occur. Being in control of telemetry and diagnostics enables the stream-aligned teams to trace and improve the flow of change in their stream

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

Данные об эксплуатации существующих систем тоже могут быть крайне важным фактором для stream-aligned teams, которые развивают новые системы и поддерживают старые. Для этого просто нужно замкнуть контур обратной связи и учитывать эту информацию в планах разработки.

Глава заканчивается таким выводом

The combination of well-defined teams and well-defined interaction modes provides a powerful and flexible organizational capability for structural adaptation to changing external and internal conditions, enabling the organization to “sense” its environment, modify its activities, and focus to fit.

Заключение

Основные идеи книги представлены на рисунке ниже

Для успеха компаний помимо использования подходов, указанных выше важны

  • Здоровая организационная культура — окружение должно поддерживать профессиональный рост команд и отдельных сотрудников
  • Хорошие инженерные практики — test-first дизайн и разработка систем, фокус на CI/CD и хорошие практики эксплуатации, код ревью, ведение постмортемов, и т.д.
  • Здоровые финансовые практики — избежание пагубной практики деления на CapEx/OpEx разных частей организации, проектных дедлайнов и бюджетирования большими порциями
  • Ясность бизнес видения (business vision) — топ-менеджмент и лидеры организации обеспечивают ясное и непротиворечивое видение направления развития организации с разным масштабом времени (квартал, год, три года) и ясными рассуждениями относительно приоритетов.

И напоследок автор дает инструкцию как начать действовать в соответствии с рекомендациями подхода Team Topologies.

Книга вышла огненной — очень много полезных мыслей, примеров и даже алгоритмов действий. Определенно она заслуживает внимательного прочтения.

Предисторию можно прочитать в двух статьях:

P.S.

Неплохо дополняет книгу отчет 2021 State of DevOps Report от Puppet.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.