Team Topologies, 2nd edition by Matthew Skelton, Manuel Pais
Строить подразделения, которые не тормозят, — задача со звёздочкой (в чём я успел убедиться на собственном опыте, собирая отдел буквально «на ходу» на одной из работ). Поэтому любые ментальные модели, которые помогут грамотно подойти к этому вопросу, очень полезны руководителю любого уровня.
Про Team Topologies я ранее слышал неоднократно и даже читал краткое описание концепции (из которой понял, что интуитивно применял этот подход к построению команд и раньше). Но скоро передо мной снова встанет задача проектирования и развития крупного юнита в управлении, поэтому я решил погрузиться в идею глубже.
⭐️ О чём книга
Название книги довольно говорящее — она посвящена топологиям инженерных команд, которые работают на поток поставки ценности и не тормозят разработку.
В книге раскрываются следующие темы: ➡️ В чём проблема с традиционными структурами команд ➡️ Почему так важен закон Конвея и что такое обратный манёвр Конвея ➡️ 4 фундаментальные топологии команд ➡️ Модели взаимодействия команд между собой ➡️ Эволюция оргструктуры под потребности бизнеса
⭐️ 3 идеи из книги 🟡Думать, что архитектуру можно долго поддерживать в отрыве от структуры команд, — фундаментальная ошибка. Разрыв между архитектурой и структурой команд будет виден на всех уровнях разработки. Я думаю, на этом месте скупую слезу пустят те, кто работает с «отделом корпоративной архитектуры».
🟡Один из ключевых факторов эффективности команд — неблокирующие зависимости. Например, очень сложно эффективно поставлять фичи, если их тестирует отдел QA, который находится чёрт его знает где и имеет свои процессы/приоритеты/взгляд на вещи. Или другая, более частая проблема — неправильно разделённые зоны ответственности, где одна команда вынуждена ждать другую (иногда месяцами). Проблема не в самом наличии зависимостей, а в зависимостях, которые регулярно блокируют поток работы одной команды решениями другой.
🟡Платформенные команды нужны для того, чтобы расчистить путь продуктовым командам и снять с них лишнюю когнитивную нагрузку. Хорошая платформа убирает много трения в процессе разработки и релиза. К сожалению, не все платформы это понимают и навязывают свою «философию», что приводит к аккуратному избеганию их возможностей разработчиками.
⭐️ Мои впечатления
Впечатления у меня остались немного смешанные. С одной стороны, идеи из книги мне понравились, и в них много здравого смысла. Разделение на типы команд, определение типов коммуникаций, применение обратного манёвра Конвея — ценные и полезные штуки, которые я успел проверить на практике.
С другой стороны, книга показалась мне удивительно водянистой. Сложилось ощущение, что её ключевые идеи можно было уложить в страниц 20–30, но для издательства нужно было нарастить объём. Поэтому треть книги занимают бесполезные case studies, а сами главы изобилуют историями, восхваляющими Team Topologies.
Главная ценность Team Topologies для меня не в четырёх типах команд, а в самом способе смотреть на организацию: архитектуру систем, границы ответственности и взаимодействия между командами нужно проектировать как одно целое.
Руководителю, который проектирует отдел из нескольких команд, идеи из этой книги стоит знать обязательно. Но для ознакомления с ними вполне достаточно будет прочитать несколько статей или саммари книги. Саму книгу целиком стоит читать, только если хочется разобраться в аргументации и деталях взаимодействий.
Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.
➡ А для тех, кто хочет читать с большей пользой, у меня есть практикум «ИнфоСушка», в котором мы полностью меняем подход к чтению и делаем его эффективным.
➖➖➖➖➖➖➖➖➖➖➖ 📝 @ulshinblog
В этом посте были ссылки, но мы их удалили по правилам Сетки
