Чтение книги Team Topologies и усвоение ее материала является обязательной частью стажировки по руководству “Системная инженерия” в МИМ (Мастерская инженеров-менеджеров, бывшая ШСМ). Рецензия на книгу написана в рамках этой стажировки
В работе с людьми крайне важно отслеживать, что границы команд и интерфейсов взаимодействия остаются именно теми, которые были спроектированы, иначе все сломается. Люди имеют обыкновение работать как получится, поэтому надо внимательно все отслеживать и иногда поправлять людей в командах, а иногда интерфейсы. Это напрямую применимо и к моей работе, если что-то придумал как сделать, то обязательно надо с одной стороны обучить людей, а потом обеспечить надзор.
Это применимо к самым разным ситуациям
- к себе - сначала обращаешь внимание на то, что обучаешься чему-то, потом отдельно обеспечиваешь надзор за этим, причем надзор может быть и внешний, при необходимости
- к семье, например в семейных делах: показал ребенку, как что-то делать, а потом следишь за тем, как он это выполняет и поправляешь
- ну и непосредственно к работе. Например, сделал общий список задач, чтобы все им пользовались. Надо показать как им пользоваться (момент обучения), и устроить надзор, что это работает, что задачи попадают в список, что берутся из списка. Если получается так, что списком не пользуются, то что-то надо поменять: или поправить людей или поправить то, как устроен это список задач, например перенести его в более удобное место.
В Team Topologies команда это объект первого класса, основной минимальный объект с которым идет взаимодействие. Команда должна быть небольшой 5-9 человек, если она разрастается до 15, то значит наступает время делить ее. Тут также вводится важное, хоть и не формализованное понятие когнитивная нагрузка (cognitive load), надо держать когнитивную нагрузку оптимальной. Когнитивную нагрузку могут увеличить неожиданные вещи - слишком много коммуникаций, сложность самой системы или ее подсистем, соответственно нарезать людей надо на команды с учетом возможной когнитивной нагрузки.
Вводятся 4 типа команд: stream aligned, complicated sub-system, platform, enabling команд и 3 типа взаимодействия: collaboration, service, facilitating.
Если смотреть с точки зрения системного подхода, то stream-aligned team соответствуют роли разработчика, complicated sub-system - не имеет отдельной выделенной роли, это тоже разработчик, platform - в зависимости от ситуации выполняет роль тоже разработчика но на другом системном уровне, но также это может быть инженер платформы разработки, enabling team - это создатель мастерства разработчика. Интересно, что архитекторы в Team Topologies упоминаются только в плане функциональной архитектуры, но не модульной. Т.к. модульные архитекторы это совершенно другие команды. Например команды SRE, про которые в Team Topologies упоминается и которые рассматриваются как stream-aligned team, это на самом деле скорее архитектурные команды, которые отвечают не за функциональность, а за модульное разбиение
Таким образом видно, что Team Topologies вводит немного другое разделение по командам, нежели принятое в руководствах МИМ, но введенная в руководствах понятийная сетка позволяет без труда разобраться с этим разделением
Team Topologies говорит про программную инженерию и разработку софта, хотя специфики именно программной инженерии в ней почти нет (в отличии от например книги Building Evolutionary Architectures, где много очень специфики программной инженерии), кажется можно напрямую использовать материал книги для любой разработки, особенно если есть понимание системного подхода
К чему есть привязка, так это к размерам команд, перекладывать эти идеи на другие масштабы надо с осторожностью, впрочем основные принципы остаются верными:
- учитывать закон Конвея и обратный маневр Конвея, не бороться с ним
- выстраивать взаимодействие согласно целям команд, а не на основе расположения (в книге критикуется идея опен-спейсов и общего онлайн-пространства для общения). Продумывать интерфейсы взаимодействия команд
- Использовать естественное разделение команд, по типу создаваемой системы, по DDD. Но не делить команду по используемым технологиям, оказывается это скорее ошибка, которая приводит к монолиту. Естественные причины могут быть например регуляторные, географические, по типу клиенту, по требуемому перфомансу, ну и собственно по домену.
Книга кажется довольно сложной, если не знаком с системным подходом и не понимаешь куда ложится все это. А ложится все это специфически в то, как устроена инженерная команда создателей, итого типы “фундаментальных” команд выделены довольно произвольно и многих других команд не указано, даже в инженерной команде: нет указания на роли визионерские, архитектурные, а инженер платформы разработки (DevOps) хоть и указан, но не выделен явно, а лишь как часть platform team. Также нет указания на менеджерские роли. Team Topologies получается в первую очередь рассказывает как устроена команды в роли разработчика. Кажется, если ее читать без знакомства с системным подходом, она бы показалась сложной, интересной и очень специфической для менеджеров, у которых в управлении много команд. А так, довольно полезно для всех.
Интересно, что роль разработчика расписана прям детально, например выделена отдельная роль complicated sub-system team. Очень подробно расписано про две роли Dev (разработка) и Ops (эксплуатация). Бизнес естественным образом смотрит на Ops, как на выход разработки, но есть другой взгляд, смотреть на эксплуатацию как на вход, на источник знаний. Если это брать всерьез, то сразу идет довольно много неожиданных выводов. например, что в эксплуатирующую команду лучше ставить наиболее опытных инженеров, хотя в индустрии, наоборот, туда принято ставить наиболее неопытных, а операторы поддержки могут быть вообще не связаны с разработкой. Вообще современный метод предполагает, что кто фичу проектирует, тот ее и обслуживает, но если речь идет об изменении уже работающей систему, то сразу соединять может быть больно, на первом этапе есть смысл налаживать коммуникацию между Dev’ами и Ops’ами, с перспективой дальнейшего объединения.
В книге указаны разные антипаттерны, мне как человеку, который немного работал в крупной организации было прям интересно узнать некоторые из них. В той организации создаваемая система была распределенным монолитом и над ней работало более 100 человек, распределенных на разные команды. Антипаттерны были замечены как минимум следующие
- выделение отдельных команд под разработку, тестирование и эксплуатацию, жесткое отделение эксплуатации от разработки
- периодическое тасование членов команд волею начальства с целью, чтобы все члены команды познакомились со всем системой
Очень многое зависит от уровня зрелости команды - изменение паттернов работы команды и выделение в отдельную боевую функциональную единицу команды, которая способна сделать полноценную фичу от задумки до эксплуатации возможно лишь если есть соответствующая культура, инфраструктура и остальные команды поддерживают подобный стиль работы работы. Вообще, т.к. это работа с людьми важно обращать внимание на мастерство членов команды и способны ли они сформировать команду с нужными свойствами. И всегда надо понимать, что люди остаются людьми, а команды состоят из людей. Изменения в организации с необходимостью занимают много времени - это месяцы, иногда годы, торопиться не получится, это тоже своего рода эволюция. Причем изменения в организации происходят постоянно и в хорошей организации взаимодействие между командами развивается и эволюционирует вместе с продуктом, постепенно приходя к более decoupled версии и, способ взаимодействия может прийти от полноценной коллаборации к сервису, когда одна команда будет разрабатывать продукт независимо
Отдельно лайфках для программной инженерии - использовать людей с опытом разработки API для разработки API взаимодействия между командами.
Также интересно посмотреть на инженерные команды с точки зрения системной инженерии. Очень много уделено коммуникациям между командами, а что такое коммуникации с точки зрения системного подхода? В киберфизических системах функциональное рассмотрение - это потоки энергии, данных, вещества.. Если мы смотрим на инженерные команды, то на коммуникации можно смотреть как на метод и как на работы. Если мы говорим про метод - это про то как коммуникации устроены, какие команды по каким интерфейсам коммуницируют, а работы - это то, что выполняется в какой-то момент времени. Функциональное рассмотрение организации - это про методы, которыми работают разные роли в организации и коммуникация - один из важнейших методов, который задает способ взаимодействия разных ролей, а поток который течет в организации - это разные рабочие продукты.
Есть отсылка на книгу 2015 года Promise Theory Mark Burgess. Идея в том, что можно выстраивать взаимодействие не на директивных запросах одной команды к другой, а на обещаниях. Типичный пример обещания - это API, сервис обещает выдать нужное взаимодействие если ты с ним взаимодействуешь определенным образом. Кажется интересная книга, как-нибудь прочитаю.
Есть такая очевидная мысль, что чем больше система, тем больше требуется времени для ее изменения, соответственно в малой организации изменения могут идти месяцы, в большой могут занять годы, а изменения в обществе может занять десятки лет. Но на самом деле практика же показывает совершенно другую ситуацию. Нередки ситуации, когда организация перестает существовать одним днем, также бывают ситуации когда стартапы вырастают за год с нуля до организации в тысячи человек. Ситуации типа ковид, революция, начало войны, взрыв ядерной бомбы - меняют устой общества максимум за недели, но никак не годы. Если игнорировать подобные ситуации, то можно пропустить важные возможности. Также это согласуется с идеями, что лучше всего работать одновременно на разных системных уровнях. Как это можно использовать, не скатившись в хаос? Как-то видимо возможно, комбинируя крупномасштабные изменения уровня организации с малыми изменениями на уровне отдельных команд и совсем малые на уровне отдельных личностей. В целом это теоретическое размышление, т.к. на данный момент у меня нет рабочих проектов, требующих подобного рода крупных изменений.
Если говорить о применении идей книги, для меня ее идеи с большим запасом, т.к. на данный момент нет необходимости работы с множеством команд, а в книге команда вообще минимальная единица работы, тем не менее как минимум одну безмасштабную мысль, применимую на любом уровне беру на вооружение - это то, что надо проектировать общение между разными командами / членами команд более внимательно, т.к. раньше у меня было довольно наивное представление, что информация должна беспрепятственно ходить везде. Нет, это не так, надо выстраивать стенки и интерфейсы.