Пара слов про Team Topologies.

Год назад я готовил доклад про организационный дизайн и был просто обязан прочитать Team Topologies — хоть и не очень люблю читать на английском.

Основную мысль книги все и так знают: 4 типа команд и 4 типа взаимодействий. Если читать целиком не хочется, у Александра Поломодова есть разбор в трех частях

Но самое интересное для меня нашлось не там, а в начале книги — там, где авторы объясняют, почему это вообще может быть важно, своего рода problem discovery. Ниже — вольный пересказ тезисов, которые осели у меня в хайлайтах.

• Организация — это не механизм, а организм. Сложный и адаптивный, а не линейный и предсказуемый

• Организационная диаграмма всегда врет. Не потому что её плохо нарисовали, а потому что она в принципе не показывает реальные паттерны коммуникации. Ровно как архитектурный док устаревает в момент старта разработки — орг диаграмма не совпадает с реальностью с первого дня. Смотреть нужно на фактическую структуру связей, а не на квадратики

• Структур на самом деле три, и они не совпадают. Формальная (орг диаграмма) — про соблюдение правил. Неформальная — "сфера влияния" между людьми. И value creation структура — как работа делается на самом деле, на меж-личностной и меж-командной репутации и коммуникации. Управляешь обычно первой, а результат дает третья

• Матрица не спасает. Подход "матричного управления" родился в 90-х и пытался справиться со сложной и неопределенной работой через двойное подчинение — бизнесу и функции одновременно. Фокус на бизнес-ценности там и правда выше, чем в чисто функциональной структуре. Но это все равно статичный снимок мира, который устаревает так же стремительно как стремительно эволюционируют бизнес и технологии (обратите внимание, когда была написана книга, лично я слова LLM еще не знал)

• Монолит — это не только когда одно огромное приложение. Бывают Application Monolith, Joined-at-the-Database Monolith, Monolithic Builds, Monolithic Releases, Monolithic Thinking и даже Monolithic Workplace. Связность бывает не только в коде, но и в процессах, в головах и в рассадке

• Как резать команды. Авторы дают каталог "плоскостей разлома" (fracture planes) — линий, по которым систему можно разделить так, чтобы шов был максимально естественным: Business Domain Bounded Context, Regulatory Compliance, Change Cadence, Team Location, Risk, Performance Isolation, Technology, User Personas

• Turtles all the way down. Каждая платформа сама стоит на другой платформе — даже если низлежащую не видно или не очевидно

• Анти-паттерны: тасовать людей между командами, проектная ориентация команд, экономия за счет аутсорса и джуновых команд без достаточного опыта

И главное — про когнитивную нагрузку. Её три типа:

• intrinsic — про саму суть задачи. "Как устроен класс в Java", "как написать метод". Неизбежная сложность предметной области
• extraneous — про окружение, в котором задача делается. "Как это задеплоить", "как поднять тестовое окружение". Та сложность, которую в идеале хочется убрать в ноль
• germane — про то, что требует отдельного внимания: бизнес-домен, ради которого всё затевалось. "Как именно считается инвойс"

Вся идея в том, что у команды нет под это бесконечного сосуда. Нагрузка складывается, и если extraneous съедает половину — на germane, ради которого команда и существует, просто не остается места. Соответственно, идея в том, чтобы минимизировать extraneous там, где это возможно.

Отсюда главный тезис: команды и их контекст нужно проектировать. Не "нарежем сервисы, посчитаем капасити, а команды как-нибудь разберутся", а берем когнитивную нагрузку как ограничение и оптимизируем её через проектирование правильных границ систем и зон ответственности.

То есть те самые 4 типа команд и 4 взаимодействия — совсем не единственное зачем стоит прочитать книжку. Сначала ты признаешь, что команда — живой организм с конечной емкостью, а уже из этого ограничения выводится вся остальная конструкция.

Так что если соберетесь читать — не проматывайте первые главы к красивым схемам. Самое интересное как раз до них.