Командные топологии не универсальны

Сложность нашего мира означает, что мы не можем просто использовать чужие решения для решения наших собственных уникальных проблем. Необходимо понимать специфику контекста проблем, с которыми мы сталкиваемся. В сложной области Cynefin решения должны возникать на основе зондирования, ощущения и реагирования, а не на основе применения заранее определённых рамок. Такая перспектива побуждает нас адаптировать и настраивать наши подходы в соответствии с нашими специфическими условиями и потребностями, а не полагаться исключительно на успех чужих стратегий.

Продуктовые команды

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

Какую проблему мы пытаемся решить?

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

Когнитивная нагрузка

В Командных Топологиях одним из основных факторов является ограничение когнитивной нагрузки с помощью относительной сложности домена; важно понимать три типа когнитивной нагрузки: внутреннюю, внешнюю и зародышевую. Внутренняя когнитивная нагрузка относится к фундаментальным аспектам самой задачи, таким как понимание структуры класса Java или создание нового метода решения задач. Посторонняя когнитивная нагрузка связана с окружением, в котором выполняется задача, включая вопросы о том, как развернуть компонент или настроить сервис. Зародышевая когнитивная нагрузка связана с теми аспектами задачи, которые требуют особого внимания для обучения или достижения высокой производительности, например, определение того, как служба должна взаимодействовать с другой службой, например, службой ABC. Различая и управляя этими типами когнитивных нагрузок, команды могут оптимизировать свою производительность и эффективность обучения.

Когнитивная креативность

В данной интерпретации используется весьма нетрадиционный взгляд на теорию когнитивных нагрузок, разработанную в конце 1980-х годов Джоном Свеллером на основе изучения решения проблем. Свеллер утверждал, что учебный дизайн может снизить когнитивную нагрузку у обучающихся. В когнитивной психологии под когнитивной нагрузкой понимается объём используемых ресурсов рабочей памяти. Очень важно отличать это от фактической конструкции когнитивной нагрузки (CL) или умственной нагрузки (MWL), которые широко изучаются в различных дисциплинах. Исследования в области учебного дизайна и педагогики выделяют три типа когнитивной нагрузки: внутренняя когнитивная нагрузка, которая представляет собой усилия, связанные с конкретной темой; внешняя когнитивная нагрузка, которая относится к способу представления информации или заданий; и зародышевая когнитивная нагрузка, которая включает усилия, затраченные на создание постоянного запаса знаний (схемы). С годами аддитивность этих видов когнитивной нагрузки была поставлена под сомнение, и теперь считается, что они влияют друг на друга по кругу.

Проектирование привода домена

Наверное, все мы согласны с Командными Топологиями в том, что снижение когнитивной нагрузки необходимо для большинства команд и организаций. Однако я считаю, что проектирование с учётом домена (Domain-Driven Design, DDD) предлагает более эффективный подход к снижению когнитивной нагрузки при разработке программного обеспечения, чем использование теории когнитивной нагрузки TT, поскольку он напрямую учитывает сложность бизнес-области и согласовывает с ней процесс разработки. Сосредоточившись на создании чёткого, общего понимания домена с помощью вездесущего языка и ограниченных контекстов, DDD упрощает коммуникацию и гарантирует, что все члены команды находятся на одной волне. Это снижает необходимость постоянно переводить знания о домене в технические термины, тем самым минимизируя внутреннюю и внешнюю когнитивную нагрузку. Кроме того, DDD подчеркивает модульность и стратегическое разделение домена, что облегчает управление сложными системами и рассуждения о них, в конечном итоге способствуя лучшему обучению и более эффективному сохранению знаний (зародышевая когнитивная нагрузка) в командах.

Если вы не знаете «Почему», вы не сможете масштабировать «Что»

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

Заключение

Джордж Бокс знаменито заметил: «Все модели ошибочны, но некоторые из них полезны». Согласно этой логике, Командная Топология по своей сути несовершенна: сложные организации нельзя свести только к четырём типам команд и трём типам взаимодействий. Топологии команд служат инструментом, который побуждает организации развиваться в сторону более эффективных способов работы. Она позволяет выровненным по потоку командам максимизировать свой поток за счёт снижения когнитивной нагрузки, тем самым повышая общую эффективность и производительность. Помните об эффекте Даннига-Крюгера, когда люди с книгой в руках начинают реструктурировать организацию, не понимая фундаментальных основ.

Список полезных законов, паттернов и фреймворков:

• Закон Конвея: Структура любой системы, разработанной организацией, изоморфна структуре организации. Последовательно проектируйте архитектуру вашей системы и вашей организации рука об руку и позвольте им развиваться вместе.

• Число Данбара: 150. Когнитивный предел количества людей, с которыми человек может поддерживать стабильные социальные отношения – отношения, в которых человек знает, кто он такой и как каждый из них относится к каждому другому человеку.

• Теория «работы, которую нужно сделать»: Теория, которая помогает инноваторам понять, как и почему люди принимают решения.

• Закон Паркинсона: Работа расширяется так, чтобы заполнить время, отведённое на её выполнение. Делайте более короткие спринты, циклы, встречи, таймбоксы и т.д.

• Закон Паркинсона о тривиальности: Время, потраченное на любой пункт повестки дня, будет обратно пропорционально денежной сумме.

• Теория ограничений: «Время, потраченное на обсуждение пункта, обратно пропорционально рассматриваемой сумме». Определите ограничения системы. Используйте ограничения системы. Подчините все остальное вышеуказанному решению. Повысьте значимость системного ограничения. Промывайте и повторяйте.

• Закон Галла: Сложная система, которая работает, неизменно оказывается развившейся из простой системы, которая работала. Не стройте и не исправляйте сложную систему в целом. Найдите правильную гранулярность и внедрите простые элементы, которые будут работать и поддерживать систему в рабочем состоянии всё время.

• Закон Энгельбарта: Внутренняя скорость человеческой производительности экспоненциальна. Начинайте с малого и медленно, чтобы «становиться лучше, когда становишься лучше».

• Закон Литтла: Время обслуживания – это узкое место, которое создаёт очередь.

• Закон Брукса: «Добавление рабочей силы в поздний программный проект делает его ещё более поздним».

• Эффект Даннинга-Крюгера: Люди, не обладающие навыками в какой-либо области, ошибочно полагают, что их способности выше среднего уровня. Они не знают того, чего не знают.

• Бритва Оккама: Нельзя умножать сущности сверх необходимости. Держите свои команды как можно более простыми и маленькими.

• Принцип Парето: Для многих явлений 80% последствий вытекают из 20% причин.

• Закон Виерордта: Ретроспективно «короткие» промежутки времени имеют тенденцию к переоценке, а «длинные» – к недооценке.

• Закон Ларманса: Организации неявно оптимизированы для того, чтобы не менять статус-кво.