Сначала команды — потом AI

Прежде чем внедрять AI, есть один шаг, который окупится сильнее любого инструмента и любой модели: перестроить технические команды под потоки ценности. Я видел это слишком много раз — инструменты куплены, модели развёрнуты, люди обучены, а доставка всё равно буксует, и люди выгорают ещё сильнее, чем до старта. Причина почти никогда не в слабом AI. Она в том, что команды нарезаны по технологическим слоям: фронтенд, бэкенд, алгоритмы, эксплуатация, безопасность. Одна end-to-end-фича проходит через четыре-пять команд, и на каждой передаче что-то теряется — чуть-чуть требований, чуть-чуть контекста, чуть-чуть ответственности. Задайте правильные границы команд — и у AI появится почва, на которой его можно усилить. Оставьте границы неправильными — AI просто начнёт быстрее накапливать долг на сломанной структуре.

В этой статье — метод организационного дизайна, который можно взять и применить: Team Topologies (Skelton & Pais, 2019). В основе лежат три вещи: команды режутся по потокам ценности, когнитивная нагрузка (cognitive load) каждой команды держится под контролем, внутренняя платформа ведётся как продукт. Разбирать будем на реальном производственном сценарии.

CIO одного производственного предприятия (кейс обезличен) рассказывал мне так: технически AI-функция контроля качества не была сложной — камеры распознают дефекты, модель готовая. Сложной оказалась доставка. Фронтенд-группа делала интерфейс, MES-группа переделывала маршрут рабочих нарядов, группа алгоритмов разворачивала модель, эксплуатация держала серверы, и поверх всего этого безопасность ещё проводила свой аудит. Одна функция, 5 команд, 4 формальных передачи, 3 месяца задержки. Никто не ленился — но на каждой передаче что-то падало на пол.

1. Закон Конвея — только половина истории

Закон Конвея (Conway’s Law) говорит: архитектура системы копирует коммуникационную структуру команды, которая её строит. Режете команды на фронтенд и бэкенд — получаете систему с разделением на фронтенд и бэкенд. Как команда общается, так система и растёт. Эмпирика это подтверждает раз за разом.

Но Конвей лишь зафиксировал, что так будет. Он не ответил, как спроектировать команду, чтобы хорошая архитектура вырастала сама. Этот пробел закрыли Skelton и Pais в 2019 году книгой «Team Topologies»: четыре базовых типа команд, три режима взаимодействия и один сквозной принцип — следить за когнитивной нагрузкой.

2. Четыре типа команд: это опции для реструктуризации, а не термины для заучивания

Буду подавать эти четыре типа как «опции, до которых можно дотянуться при реструктуризации», а не как определения, которые нужно вызубрить.

Команда, выровненная под поток (stream-aligned team) — рабочая лошадка вашей организации; таких должно быть подавляющее большинство. В оригинальной книге сказано «most», без фиксированной доли. «Поток» здесь — это непрерывный поток ценности, и команда такого типа владеет участком этого потока от начала до конца: понимает требования, разрабатывает, выкатывает, эксплуатирует. Один тест говорит, поток-выровненная ли перед вами команда — может ли она самостоятельно, без внешних зависимостей, донести ценность до пользователя. Вернёмся к тому CIO: если бы функция контроля качества принадлежала одной «команде потока контроля качества», в которой сидят и фронтендер, и специалист по интеграции с MES, и инженер по развёртыванию моделей, и эксплуатационщик — функция закрывалась бы одной командой, с нулём передач. Вот такой она и должна быть.

Самая частая болезнь крупных предприятий — система работает end-to-end, а команды нарезаны горизонтально, по технологическим слоям. Каждая сквозная доставка вынуждена прошивать границы отчётности нескольких команд. Меняется отрасль — патология остаётся. В финансах фича кредитного риск-контроля разносится сразу по четырём группам: приложение, ядро, модели риск-контроля, данные. В e-commerce и телекоме боль та же, только слова другие — промо-механика проходит через каталог, транзакции, маркетинг и склад; смена тарифа через каналы, биллинг, CRM и сеть. Горизонтально нарезанные команды пытаются обслуживать вертикальные потоки ценности — и передачи плодятся повсюду.

Платформенная команда (platform team) — строит дорогу для потоковых команд. Она даёт инфраструктуру, CI/CD, общие сервисы так, чтобы потоковые команды получали нужные способности через самообслуживание, а не через заявку с ожиданием. Один критерий: ваша внутренняя платформа ведётся как продукт — с пользователями, с дорожной картой, с SLA — или съехала во «внутренний аутсорс», который живёт на тикетах? Большинство IT-подразделений крупных предприятий застряли во втором варианте. Построили платформу — никто не пользуется, бизнес-команды обходят и стряпают своё, платформенная команда деградирует в подрядчика. Spinnaker от Netflix (continuous delivery) и Backstage от Spotify (портал разработчика) — эталоны платформы как продукта. Их постоянно путают: Spinnaker — это Netflix, Backstage — это Spotify. Не перепутайте в отчёте для совета директоров.

Команда-наставник (enabling team) — помогает потоковым командам прокачаться, с явной целью сделать себя ненужной. Она не delivering бизнес напрямую, а поднимает capability потоковых команд: коуч по новой технологии, фасилитатор DevOps-перехода, консультант по безопасности и комплаенсу. Отношение к потоковой команде — наставник и ученик, а не заказчик и подрядчик. Во крупных компаниях именно эту роль и должен играть внешний консультант-сопровождающий: передавать компетенции, а не плодить долгосрочную зависимость.

Команда сложной подсистемы (complicated-subsystem team) — для твёрдых орешков, требующих глубокой специализации. Когда подсистема требует настоящей глубины — движок риск-контроля, рекомендательный алгоритм, криптография, видеокодек — её выделяют в отдельную команду экспертов, чтобы не перегружать потоковые команды. Их должно быть мало. Если в организации расплодилось много команд сложных подсистем, скорее всего то, что должно было стать платформой, раскроено на отдельные дымоходы.

Назвать типы команд — мало. Нужно определить, как они между собой взаимодействуют. Team Topologies даёт три режима. Совместная работа (collaboration) — две команды глубоко работают вместе; подходит для неопределённой новой территории, но энергозатратен, поэтому только короткими рывками. Как сервис (X-as-a-Service) — одна команда отдаёт способность как продукт, другая потребляет её в самообслуживании; самый эффективный режим, должен быть нормой. Фасилитация (facilitating) — только для команд-наставников. Главный вопрос орг.дизайна — как можно больше взаимодействий сдвинуть в режим «как сервис». Если команда надолго остаётся на «совместной работе», значит платформизация не произошла. На ситуации того CIO: между командой потока контроля качества и платформенной командой должен быть режим «как сервис» — платформа открывает self-service-вход в CI/CD, команда контроля качества пользуется им без перекличек. Если каждое развёртывание требует совещания с платформенной командой ради «совместной работы» — платформизация не дотянула, и проблема не в отношении людей, а в том, что платформу не вели как продукт.

3. Почему не спасает ни «добавить людей», ни «добавить процесс»: когнитивная нагрузка

Самый недооценённый вклад Team Topologies — они поставили когнитивную нагрузку в самый центр орг.дизайна.

У команды из 5–8 человек когнитивная нагрузка конечна. Заставьте её одновременно поддерживать десяток не связанных систем, стыковаться с шестью-семью источниками и ещё отбиваться от трёх новых фреймворков — она неизбежно перегрузится. Качество поползёт вниз, доставка замедлится, люди выгорят.

Это объясняет и второе недоумение того CIO: «Я добавил им троих, почему всё равно медленно?» Корень в том, что эта группа уже тащила слишком много несвязанного. Люди, по сути, были в нужном количестве. Добавление людей лишь умножало количество тел, кружащихся в одном и том же хаосе. Добавление процесса — ещё хуже: процесс съедает ещё один слой когнитивной нагрузки, и те, кто мог бы делать дело, начинают тратить больше времени на формы, совещания и согласования.

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

Конкретный пример. Руководитель группы ядра банковской системы держал команду из семи человек, которая одновременно стыковалась с четырьмя источниками — риск-контролем, клиентской поддержкой, регуляторной отчётностью, маркетингом — и поддерживала три никак не связанных модуля. Ежедневно только на межкомандные согласования, выравнивания и переключения контекста уходило почти половина энергии команды. Дайте им лучший AI-инструмент на рынке — он не приживётся: у людей уже не осталось когнитивной полосы, чтобы учиться новому или менять процессы. Спасти такую команду можно только одним способом — сначала разгрузить: вынести несвязанные модули, оставить ей один поток ценности.

Правило «Two-Pizza Team» у Amazon — про стоимость коммуникации: когда людей много, число каналов между ними (n(n-1)/2) взлетает, и решения замедляются. Team Topologies идёт уровнем глубже: свыше примерно восьми человек когнитивная нагрузка тоже выходит из-под контроля. Настоящая работа орг.дизайна — делить команды по когнитивной нагрузке, удерживая её в выносимом диапазоне, а не рисовать линии подчинения по функциям.

Одно предложение для самопроверки крупного предприятия: ваши «самые занятые люди» — не тащат ли они одновременно пять и больше несвязанных дел? Если да, ни люди, ни процесс не спасут. Придётся перенарезать.

4. Как делать руками: обратный манёвр Конвея

Самый операционный приём из книги. Не рисуйте сначала архитектурную диаграмму и потом под неё переделывайте команды — сначала меняйте структуру команд и позвольте архитектуре самой вырасти в нужную форму.

Традиционный подход: архитектор рисует целевую архитектуру («переходим на микросервисы!») и требует, чтобы команды под неё перестроились. Это почти всегда проваливается. Существующая структура команд будет тянуть архитектуру обратно к своей форме — закон Конвея работает.

Обратный манёвр разворачивает порядок. Сначала перестройте команды под потоки ценности — выделите потоковые команды, поставьте платформенную команду — так, чтобы границы команд стали будущими границами сервисов. Архитектура сама начнёт дрейфовать к разумному разбиению, потому что команды естественным образом начнут общаться через API, а не через общую базу.

Вернёмся к тому CIO. Я не велел ему выбирать микросервисный фреймворк. Я дал ему действие куда проще: выделить «контроль качества» в отдельную потоковую команду — взять по одному человеку из прежних групп фронтенда, MES, алгоритмов и эксплуатации, собрать команду из шести человек, end-to-end отвечающую за функцию. За три недели произошло три вещи. На первой неделе они обнаружили, что затык в маршрутизации нарядов MES, который казалось требовал вмешательства группы алгоритмов, на деле правится внутри самой команды — и они его поправили. На второй неделе они сами решили перевести развёртывание модели из «очереди за эксплуатацией» в self-service внутри команды — потому что платформенная команда открыла им self-service-вход в CI/CD. На третьей неделе они выкатили первую небольшую end-to-end-фичу, не пересекая ни одной командной границы. Людей не добавили, инструменты не сменили — горизонтальные слои поставили вертикально, в потоки. Цикл доставки вернулся с трёх месяцев к трём неделям. И неожиданный бонус: команда начала сама предлагать улучшения, потому что впервые увидела свой поток целиком и взяла за результат полную ответственность. Раньше, когда функция размазывалась по пяти командам, никто не чувствовал, что должен отвечать за весь поток контроля качества.

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

Кто применяет

Банкинг (ключевая отрасль по TT + ориентир для сильного регулирования). На teamtopologies.com есть экспертная колонка «When DORA metrics meet governance in banking». Вывод DORA-исследования, который там приводится, очень жёсткий: внешние согласования (external approvals) отрицательно коррелируют с lead time, deployment frequency и restore time — чем больше межкомандных согласований на заднем конце, тем медленнее доставка и медленнее восстановление после сбоев. Это в точности подтверждает тезис этой статьи: встраивайте комплаенс в потоковую команду и сдвигайте согласование вперёд, а не устраивайте межкомандные проверки постфактум. ClearBank и другие британские цифровые банки неоднократно всплывают в официальной экосистеме. Банкинг — самый референсный сценарий реструктуризации потоков ценности под сильным регулированием.
Zalando (e-commerce, эталон «платформа как продукт»). Внутренняя платформа разработчиков как self-service-способность для потоковых команд — частый эталон платформизации в TT-сообществе.
AutoTrader UK (платформа автомобильных объявлений). Реальный кейс, который TT цитирует раз за разом — реструктуризация по потокам ценности плюс превращение внутренней платформы в продукт.
KPMG UK (в 2024 году стала официальным TT Solution Partner). Принесла TT крупным предприятиям и финансовым клиентам — сигнал, что TT вошёл в основной корпоративный консалтинг.
Netflix / Spotify (духовные эталоны «платформа как продукт», а не кейсы принятия TT). Обе компании вели платформу как продукт ещё до выхода книги в 2019 году, подтверждая принцип, — но к внедрению четырёхкомандной модели TT это не относится.

Источники: teamtopologies.com/examples (официальная библиотека кейсов) · teamtopologies.com/news-blogs-newsletters/when-dora-metrics-meet-governance-in-banking (экспертная колонка по DORA в банкинге)

5. Когда не работает

Team Topologies — не серебряная пуля. Четыре типичных провала, каждый из которых ложится на реальную болезнь крупного предприятия.

Сменили имя, не сменили структуру. «Фронтенд-группу» переименовали в «потоковую команду», а отчётность осталась по технологическим слоям. Закон Конвея не платит за номенклатуру. Так заканчивается большинство косметических реформ в крупных компаниях — новые вывески, старая структура.

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

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

KPI не поменяли вслед. Орг.схему перестроили, а измерение осталось по функциям — объём фронтенд-кода, число багов — и поведение команд быстро откатывается к старому.

Все четыре сводятся к одному суждению: среди орг.структуры, системы стимулов и технической архитектуры поменяете любое одно без двух других — трансформация провалится.

Вариант для сильнорегулируемых отраслей. Финансы и телеком обязательно спросят: безопасность, комплаенс, технологические риски — это функции, которые регулятор требует держать независимыми (segregation of duties), и их нельзя просто «вытащить» в потоковую команду. Это жёсткое юридическое ограничение, а не инерция — не ломайте грубо. Но и возвращаться к горизонтальным очередям согласований не обязательно. Два пути. Первый — встроить представителя комплаенса/безопасности в потоковую команду: он сидит в команде и одновременно точечно отчитывается по пунктирной линии перед комплаенс-вертикалью — и у потока, и независимо. Второй — сделать комплаанс командой-наставником, которая помогает потоковым командам встроить регуляторные требования в процесс: проверки комплаенса в CI, согласование внутри команды, а не межкомандная подпись на заднем конце. Регуляторное требование становится встроенным качеством потоковой команды, а не внешним шлюзом. Вот ключ к тому, чтобы в сильнорегулируемой отрасли поток «потёк».

6. Возможно, вы хотели спросить

«Мы десять лет нарезали по техслоям — не разрушит ли реструктуризация всё до основания?» Разрушит, но куда меньше, чем вам кажется. Сносить всю компанию не нужно. Выберите самый затычный поток ценности — обычно тот, на который громче всех жалуются — и поставьте его как пилотную потоковую команду. Как тот CIO: 4–8 недель, одна небольшая команда — и вы увидите заметный сдвиг в скорости доставки. Результат продаёт следующий раунд куда эффективнее, чем презентация.

«Как это связано с идущей у нас AI-трансформацией?» Связь прямая. AI не чинит неправильно собранную организацию — он усиливает то, что уже есть: высокоэффективная команда с AI ускорится, а неправильно собранная с AI только быстрее накопит долг. Поэтому орг.диагностика идёт раньше закупки инструментов. Именно поэтому в моей фирменной методологии «AI-трансформация: 7-шаговый коучинг-фреймворк» оценка capability стоит очень рано: сначала люди и организация, потом инструменты.

«У нас не набираются все четыре типа команд — что делать?» В большинстве организаций все четыре типа и не собираются — это нормально. Первое, что должно появиться, — потоковые команды (гарантируют end-to-end-доставку) и платформенная команда (гарантирует, что колесо не изобретается заново). Команда-наставник и команда сложной подсистемы добавляются по необходимости; если в начале их нет — это нормально. Не лепите команды только ради полного набора четырёх типов — это ставит телегу впереди лошади.

7. Выводы для принимающих решения

Вывод 1: перед внедрением AI сначала нарисуйте карту тим-топологии. Перед последним внедрением AI-инструмента вы рисовали тим-топологию? Если команды нарезаны по техслоям, то каким бы сильным ни был AI — он лишь ускоряет накопление долга на сломанной структуре. Одно это правило способно отсечь как минимум половину пустых IT-инвестиций крупного предприятия. Конкретное действие: выпишите все команды и пометьте, какой поток ценности каждая закрывает end-to-end. Те, что не размечаются, нарезаны по техслоям — их и перестраивать первыми.

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

Вывод 3: ведите внутреннюю платформу как продукт — иначе неизбежно станете аутсорсом. У платформы должны быть пользователи, дорожная карта, SLA и человек, отвечающий за уровень внедрения. В эпоху AI эта платформа должна ещё включать модельный шлюз, библиотеку промптов и среду исполнения агентов — это фундамент, который будет раскрыт в следующей статье про «фреймворк принятия».

Вывод 4: не позволяйте AI цементировать неправильные границы. Это специально для организаций, внедряющих AI-агентов. Когда вы добавляете AI-агента в команду, ошибочная нарезка усиливается: агент будет автоматизировать по существующим — неправильным — границам и цементировать сломанную структуру ещё крепче. Перед внедрением AI-агентов сначала убедитесь, что границы команд заданы правильно. Это фокус 11-го выпуска серии.

Обратная самопроверка (отвечая, не приукрашивайте): ваши команды нарезаны по потокам ценности или по фронтенд/бэкенд/эксплуатация/безопасность? Самый занятый ваш человек — не тащит ли он одновременно три и больше несвязанных дел? Если внутренней платформой никто не пользуется — это красный сигнал провала платформизации. Если хоть на один из этих вопросов вы ответили неуверенно — перед внедрением AI сначала реструктурируйте команды. Это действие с самой высокой отдачей, которое нужно сделать первым.

Дальше

Это вторая статья серии «Трансформация программной инженерии в эпоху AI» (выпуск 172 рубрики «учись AI постепенно»). Мы прошли от Конвея (организация определяет архитектуру) к Team Topologies (как проектировать организацию). Следующая, третья, берёт вопрос ещё более базовый: когда AI делает производство кода почти бесплатным, куда смещается узкое место программной инженерии?

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

Об этой серии

«Трансформация программной инженерии в эпоху AI» — серия глубоких исследований для CIO, CDO, CTO и руководителей цифровой трансформации в телекоме, финансах, производстве и e-commerce, всего 15 статей. Опирается на 200+ научных работ и отраслевых отчётов, с указанием уровня доказательности.

Я — бывший инженер IBM, ICF-сертифицированный коуч, работал над AI- и цифровыми проектами у операторов связи и крупных предприятий. Здесь написано — это практические суждения, вынесенные из сопровождения компаний через ямы.

Если дочитав, вы поймали себя на мысли «а не так ли устроена и наша компания» — я подготовил «Тим-топология: чек-лист из 20 вопросов» и предлагаю 30-минутный диагностический разговор 1-на-1, чтобы помочь вам определить, какой поток ценности реорганизовать первым. Если нужно: оставьте сообщение в публичном аккаунте «AI-инсайты для принимающих решения» или напишите на coach@iaiuse.com.

Источники

Skelton, M. & Pais, M. (2019). Team Topologies. IT Revolution Press. (первоисточник про четыре типа команд / три режима взаимодействия / когнитивную нагрузку — источник первого уровня)
Conway, M. (1968). How Do Committees Invent? Datamation.
Forsgren, Humble & Kim (2018). Accelerate. IT Revolution Press.
IT Revolution (2024). Team Topologies: Five Years of Transforming Organizations. (разбор принятия в нескольких организациях, уровень 2) https://itrevolution.com/articles/team-topologies-five-years-of-transforming-organizations/
Netflix Spinnaker / Spotify Backstage — эталоны превращения внутренней платформы в продукт
AutoTrader UK — официально цитируемый TT кейс принятия (детали ссылки на teamtopologies.com уточняются)
Официальная библиотека кейсов: https://teamtopologies.com/examples