Пересмотр руководства о книге «‎Топологии команд»

13.09.2023

3

Пересмотр руководства о книге «‎Топологии команд»

В 2019 году Мэтью Скелтон и Мануэль Паис представили книгу «‎Топологии команд: организация бизнесовых и технологических команд для оптимизации работы».

В книге рассматриваются 4 ключевых типа команд, среди которых:

Команды, ориентированные на поток: Эти команды нацелены на конкретный поток работы — это может быть определенный продукт, услуга, отдельный функциональный набор, пользовательский сценарий или даже конкретная целевая аудитория. Основная задача такой команды — быстро и надежно создавать ценность для конечного пользователя, работая автономно и минимизируя зависимости от других команд.
Команды поддержки: Эти команды состоят из экспертов в определенной технической или продуктовой области. Их задача — помогать другим командам преодолевать технические пробелы. Они работают в тесном взаимодействии с командами, ориентированными на поток, исследуя и принимая обоснованные решения относительно инструментов, практик и других ресурсов.
Команды сложных подсистем: Эти команды специализируются на разработке и поддержке отдельный частей системы, требующих углубленных знаний. По большей части, члены таких команд — эксперты в своей области, что позволяет им вносить изменения и развивать подсистему.
Команды платформы: Главная цель этих команд — обеспечивать ресурсы и инструменты, которые позволят командам, ориентированным на поток и работать максимально автономно. Хотя команды, ориентированные на поток, несут полную ответственность за свои приложения, команды платформы предоставляют услуги для упрощения и оптимизации их работы.

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

Скелтон и Паис выделяют 3 типа взаимодействия между командами:

Сотрудничество: Команды совместно работают на протяжении определенного времени, чтобы изучить новые возможности, будь то API, методы работы, технологии и так далее.
Как услуга (X-as-a-Service): Одна команда предоставляет определенные ресурсы или услуги, в то время как другая команда их использует.
Наставничество: Одна команда обучает и направляет другую, помогая в освоении новых навыков или практик.

Закон Конвея

Книга «Топологии команд» уделяет большое внимание «‎Закону Конвея».

Суть «закона Конвея» заключается в том, что системы, созданные организациями, отражают их внутренние коммуникационные структуры.

Скелтон и Паис утверждают, что нельзя рассматривать архитектуру программного обеспечения как нечто, что можно разработать отдельно и затем передать любой команде для реализации. Если организация структурирована по функциональным направлениям (где команды специализируются, например, только на безопасности или контроле качества), тогда вряд ли её программные продукты будут оптимизированы для эффективного потока работы.

Применяя принцип «‎обратного закон Конвея», мы можем организовать команды таким образом, чтобы они соответствовали желаемой архитектуре программного обеспечения. Это может включать в себя, например, интеграцию разработчиков для клиентских приложений, API и баз данных в одну команду, а не разделение их.

Скелтон и Паис предоставляют 4 инсайта для эффективного дизайна команд:

Домен для каждой команды: Если домен слишком обширен для одной команды, его лучше разделить на поддомены и назначить каждому поддомену отдельную команду.
До трех «‎простых» доменов на команду: Простые домены, как правило, более прямолинейны, что уменьшает затраты на переключение контекста.
Не комбинируйте сложные и простые домены: Команды, работающие со сложными доменами, не должны также управлять простыми доменами, чтобы избежать отвлекающих факторов и потерь в эффективности.
Избегайте комбинации двух сложных доменов: Даже большая команда, состоящая из 8-9 человек, разделится на две подкоманды, при этом каждый член команды должен будет следить за обоими доменами. Это увеличит когнитивную нагрузку. Вместо этого лучше разделить такую команду на две меньшие, каждая из которых будет сосредоточена на своем домене.

Организовывайте команды не по технической экспертизе или функциям, а по бизнес-областям

Юта Экштейн, эксперт в области Agile

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

Одной из таких ошибок является создание излишне крупных команд, что ведет к увеличению коммуникационных издержек. Еще одной распространенной проблемой является постоянная перестановка членов команды, что приводит к формированию неустойчивых командных составов для конкретных проектов.

Для того чтобы избежать этих и других ошибок и целенаправленно формировать команды, Скелтон и Пейс рекомендуют задавать себе следующие вопросы:

Какую структуру команд будет наилучшим решением для достижения наших бизнес-целей, учитывая наши навыки, ограничения и желаемую архитектуру ПО?
Как мы можем минимизировать передачи работы между командами для ускорения процесса?
Как определить границы в нашей системе, чтобы обеспечить её эффективность и быстродействие? И как соответствующим образом организовать команды?

Основные выводы

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

Разбиение на части может привести к определенным сложностям, например, к потере согласованности или дублированию данных.

Книга представляет различные примеры, вот некоторые из них:

Бизнес-домен: ПО выравнивается в соответствии с конкретными областями бизнеса. Например, сервис потоковой передачи музыки может быть разделен по функциональным особенностям: поиск музыки, воспроизведение и лицензирование.
Нормативные требования: В отраслях с жестким регулированием, например, в финансах или медицине, законодательные требования могут служить естественными границами для ПО.
Частота изменений: Разные части системы могут требовать обновления с разной периодичностью. Вместо того, чтобы ограничивать все части скоростью самой медленной из них, разделение позволяет более быстрым частям эволюционировать в своем ритме.
Географическое распределение команд: Когда команды находятся в разных местах или часовых поясах, это может служить руководством к разделению. Ведь распределенным командам необходимо особое усилие для эффективного общения и координации.

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

«‎Командные топологии«» акцентирует внимание на важности осознанного подхода к формированию команд, учитывая факторы, такие как сложность домена и когнитивная нагрузка. Книга предлагает практичные рекомендации и инструменты для противостояния «‎Закону Конвея«» в структуре организации.

Бесплатный 20-дневный курс: Создание и управление цифровым продуктом

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