Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе за рубежом.   Современный мир бизнеса и разработки программного обеспечения характеризуется высокой динамикой и необходимостью быстрого реагирования на изменения в рыночных условиях. В этом контексте эффективная организация команд становится ключевым фактором успеха.  Team Topologies - это концепция, которая предлагает рациональный и гибкий подход к организации команд внутри организации. Классические подходы к организации Agile команд, как правило, рекомендуют создавать универсальные и кроссфункциональные команды, где любая команда может сделать любую фичу из беклога. Это, безусловно, имеет свои преимущества, но не всегда можно сразу применить такой подход на практике, так как требуется большое количество изменений. Team Topologies предлагают альтернативный путь того, как мы можем организовать команды, чтобы они эффективно друг с другом взаимодействовали. Team Topologies - это фреймворк организации команд, предназначенный для улучшения производительности и достижения более высокой гибкости в разработке и внедрении продуктов и услуг. Этот подход разработан Мэтью Скелтоном и Мэтью Элиасом в их книге "Team Topologies: Organizing Business and Technology Teams for Fast Flow". Главной идеей Team Topologies является адаптивность и гибкость в организации команд для более быстрого достижения целей. Team Topologies основаны на нескольких ключевых принципах: Определение Целей (Purpose-Based Teams): Команды должны иметь четко определенную цель, которая фокусируется на достижении конкретных бизнес-задач. Простота Топологии (Simplify Topologies): Организация команд должна быть максимально простой и понятной для всех участников. Эволюция (Evolutionary): Структура команд должна быть гибкой и способной к эволюции в ответ на изменения в бизнес-процессах и требованиях клиентов. Team Topologies определяют несколько основных типов команд, которые могут быть использованы в организации: Потоковые Команды (Stream-Aligned Teams): Эти команды специализируются на конкретных потоках работы, например, разработке новых функций продукта или обеспечении его непрерывной поставки. Такие команды ориентированы на оперативное выполнение задач в рамках своего функционала, что способствует улучшению скорости и предсказуемости разработки. Команды Сложных Подсистем (Complicated-Subsystem Teams): Команды сложных подсистем занимаются разработкой и поддержкой сложных компонентов или подсистем в продукте или системе. Эти команды обладают экспертизой в определенных областях и специализируются на работе с технически сложными аспектами продукта. Их задачей является обеспечение надежности и эффективности подсистем, что в свою очередь повышает качество продукта в целом. Платформенные Команды (Platform Teams): Платформенные команды ответственны за создание и поддержание общей платформы, которая используется другими командами в организации. Эти команды разрабатывают инфраструктуру, инструменты и сервисы, которые упрощают и ускоряют процесс разработки для всех остальных команд. Платформа, созданная такими командами, способствует повышению продуктивности и гибкости всей организации. Команды Поддержки (Enabling Teams): Команды поддержки играют ключевую роль в обеспечении эффективной работы других команд. Они предоставляют инструменты, обучение, консультации и другие ресурсы, необходимые для успеха других команд в организации. Эти команды поддерживают и стимулируют инновации, обеспечивая командам необходимые знания и ресурсы. Повышение Гибкости: Team Topologies позволяют организации легко адаптироваться к изменяющимся условиям рынка и требованиям клиентов. Повышение Эффективности: Команды с четко определенными целями и задачами работают более эффективно и результативно. Упрощение коммуникации: Простота структуры команд упрощает понимание и сотрудничество между участниками. Последние 1.5 года я работал над трансформацией одной компании, переходя от функциональной структуры к продуктовой и строя команды с учетом топологий. В нашей практике это выглядело следующим образом: Мы создали 2 продуктовых стрима (Stream-Aligned Teams), каждый из которых состоял из двух команд, применяя Scale Scrum. Также была создана 1 платформенная команда, которая тесно взаимодействовала с продуктовыми стримами.  Одну из команд назначили на разработку уникального крипто-сервиса (как команда сложной подсистемы), который нельзя было интегрировать в продуктовые команды из-за его сложности и специфики. Команда поддержки занималась автоматизацией процессов поставки и улучшением инфраструктуры для Stream-Aligned Teams. Ключевая суть заключается в том, что все строится вокруг 2 продуктовых стримов, ориентированных на клиентов. Остальные команды работают на них, обеспечивая сервис. Такое построение команд способствует тому, что все идут в одном направлении, сосредотачиваясь на достижении общих целей и создании ценности для клиентов. Не менее важная составляющая - это то, как организовать работу команд. Для этого мы построили каденции или ключевые встречи по планированию, синхронизации и обзору результатов вокруг каждого стрима. Планирование - квартальное, на котором определяли ключевые ОКР по каждому стриму, а далее прикидывали беклоги команд для достижения ОКР. Так как все представители команд участвовали в планировании то происходила общая синхронизация.  По ходу квартала - общий Delivery синк каждые 2 недели, в ходе которого обсуждали зависимости и планы команд Общее Демо - на нем команды демонстрировали что они сделали за последние 2 недели и также синхронизировали планы. На этом событии участвовали все стейкхолдеры. Они давали обратную связь и также обсуждали изменения  которые произошли, что позволяло скорректировать планы. Общее Service Delivery Review - на котором проводили ретроспективный анализ всех сделанных поставок за период. Это событие запустило процесс непрерывных улучшений. Эта концепция позволила нам оптимально построить команды, упростить взаимодействие, и снизить время реализации ключевых бизнес инициатив. При переходе с функциональной структуры нам удалось снизить Time to market по ключевым бизнес инициативам с 6 месяцев до 2. Конечно помимо организации команд мы еще много вложились в перестроение процессов. Несмотря на то, что в командах остались зависимости друг от друга и требовались дополнительные координации и совместные планирования, топологии стали хорошей отправной точкой для трансформации компании. Больше о подходах в управлении, цифровой трансформации и менеджменте в целом вы можете узнать на курсах OTUS. На страницах курсов вы также можете зарегистрироваться на бесплатные вебинары, которые проходят каждую неделю. Подробнее о курсах в каталоге.   Если понравилась статья, подписывайтесь на мой телеграм канал.