Строить подразделения, которые не тормозят, — задача со звёздочкой (в чём я успел убедиться на собственном опыте, собирая отдел буквально «на ходу» на одной из работ). Поэтому любые ментальные модели, которые помогут грамотно подойти к этому вопросу, очень полезны руководителю любого уровня.
Про Team Topologies я ранее слышал неоднократно и даже читал краткое описание концепции (из которой понял, что интуитивно применял этот подход к построению команд и раньше). Но скоро передо мной снова встанет задача проектирования и развития крупного юнита в управлении, поэтому я решил погрузиться в идею глубже.
О чём книга
Название книги довольно говорящее — она посвящена топологиям инженерных команд, которые работают на поток поставки ценности и не тормозят разработку.
В книге раскрываются следующие темы:
- в чём проблема с традиционными структурами команд;
- почему так важен закон Конвея и что такое обратный манёвр Конвея;
- 4 фундаментальные топологии команд;
- модели взаимодействия команд между собой;
- эволюция оргструктуры под потребности бизнеса.
Три идеи из книги
-
Думать, что архитектуру можно долго поддерживать в отрыве от структуры команд, — фундаментальная ошибка. Разрыв между архитектурой и структурой команд будет виден на всех уровнях разработки. Я думаю, на этом месте скупую слезу пустят те, кто работает с «отделом корпоративной архитектуры».
-
Один из ключевых факторов эффективности команд — неблокирующие зависимости. Например, очень сложно эффективно поставлять фичи, если их тестирует отдел QA, который находится чёрт его знает где и имеет свои процессы/приоритеты/взгляд на вещи. Или другая, более частая проблема — неправильно разделённые зоны ответственности, где одна команда вынуждена ждать другую (иногда месяцами). Проблема не в самом наличии зависимостей, а в зависимостях, которые регулярно блокируют поток работы одной команды решениями другой.
-
Платформенные команды нужны для того, чтобы расчистить путь продуктовым командам и снять с них лишнюю когнитивную нагрузку. Хорошая платформа убирает много трения в процессе разработки и релиза. К сожалению, не все платформы это понимают и навязывают свою «философию», что приводит к аккуратному избеганию их возможностей разработчиками.
Мои впечатления
Впечатления у меня остались немного смешанные. С одной стороны, идеи из книги мне понравились, и в них много здравого смысла. Разделение на типы команд, определение типов коммуникаций, применение обратного манёвра Конвея — ценные и полезные штуки, которые я успел проверить на практике.
С другой стороны, книга показалась мне удивительно водянистой. Сложилось ощущение, что её ключевые идеи можно было уложить в страниц 20–30, но для издательства нужно было нарастить объём. Поэтому треть книги занимают бесполезные case studies, а сами главы изобилуют историями, восхваляющими Team Topologies.
Главная ценность Team Topologies для меня не в четырёх типах команд, а в самом способе смотреть на организацию: архитектуру систем, границы ответственности и взаимодействия между командами нужно проектировать как одно целое.
Руководителю, который проектирует отдел из нескольких команд, идеи из этой книги стоит знать обязательно. Но для ознакомления с ними вполне достаточно будет прочитать несколько статей или саммари книги. Саму книгу целиком стоит читать, только если хочется разобраться в аргументации и деталях взаимодействий.