Перш ніж брати ШІ — перевдягніть команди за потоками цінності

Перш ніж впроваджувати ШІ у компанії, є один крок, що окупиться дорожче за будь-який інструмент чи модель: перебудуйте технічні команди навколо потоків цінності. Я бачив це занадто часто — інструменти куплені, моделі розгорнуті, люди перенавчені, а доставка все одно буксує, і команда виходить з процесу втомленішою, ніж увійшла. Корінь майже ніколи не в слабкому ШІ. Він у тому, що команди нарізані за технологічними шарами — фронтенд, бекенд, алгоритми, операції, безпека. Одна наскрізна функція мулить крізь чотири-п’ять команд, і на кожній передачі щось осипається: трохи вимог, трохи контексту, трохи відчуття власності. Коли межі команд стоять правильно — ШІ є що підсилювати. Коли хибно — ШІ лише пришвидшує нагромадження боргу на зламаній структурі.

Ця стаття викладає метод організаційного дизайну, який можна взяти в руки — Team Topologies (Skelton & Pais, 2019). Три стрижні: нарізати команди за потоком цінності, тримати в полі зору когітивне навантаження кожної, вести внутрішню платформу як продукт. Розгортатиму на реальному виробничому сценарії.

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

1. Закон Конвея каже лише половину

Закон Конвея (Conway’s Law) стверджує: архітектура системи дзеркалить комунікаційну структуру команди, що її будує. Наріжете фронтенд і бекенд окремо — отримаєте систему, поділену на фронтенд і бекенд. Як команда спілкується, так і відростає система. Це підтверджено емпірикою знову і знову.

Але Конвей лише зафіксував, що так буде. Він не підказав, як спроєктувати команди, щоб гарна архітектура відростала сама. Цю прогалину закрили Skelton і Pais у «Team Topologies» (2019): чотири базові типи команд, три режими взаємодії та один наскрізний принцип — стежити за когітивним навантаженням.

2. Чотири типи команд: це опції для реоргу, а не терміни на зубріння

Подаю ці чотири типи як «опції, до яких можна звернутися під час реорганізації». Визначення не зубрити.

Потокова команда (stream-aligned) — робоча конячка організації, і її має бути переважна більшість (у книзі сказано most, без конкретної частки). «Потік» — це безперервний потік цінності. Потокова команда володіє відрізком цього потоку наскрізь: від розуміння вимоги, через розробку, до випуску й експлуатації. Ознака одна: чи може команда без зовнішніх рук доставити цінність користувачу? Повернемося до того CIO: якби функцію контролю якості тримала одна «команда потоку контролю» — з людиною на фронтенд, на інтеграцію з MES, на розгортання моделей, на операції — функція б виходила без жодної передачі. Так і має виглядати.

Найпоширеніша хвороба великих підприємств — система біжить наскрізно, а команди нарізані горизонтальними технологічними шарами. Кожна наскрізна доставка протикається крізь звітні межі кількох команд. Змініть галузь — картина та сама. У фінансах кредитний ризик-функція розпорошується між чотирма сторонами: команда мобільного додатку, команда ядра, команда моделей ризику, команда даних — і між ними тягнуться окремі ланцюжки узгоджень, бо кожна тримає лише свій шматок. E-commerce й телеком стискають ту саму біль у інші слова: промо-акція перетинає каталог, транзакції, маркетинг, склад; зміна тарифу — канали, білінг, CRM, мережу. Горизонтально нарізані команди обслуговують вертикальний потік — і неминуче на кожному кроці передають роботу далі.

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

Команда-наставник (enabling team) — допомагає потоковим піднятися, цілеспрямовано працюючи на власне безробіття. Вона не доставляє бізнес напряму. Вона піднімає здатність потокових команд: тренер із нової технології, фасилітатор DevOps-переходу, консультант із безпеки й комплаєнсу. Стосунки — наставник і учень, не замовник і підрядник. Для великого бізнесу саме цю роль має грати зовнішній консультант-супровідник: передавати здатність, а не садити на довгострокову залежність.

Команда складної підсистеми (complicated-subsystem team) — бере твердині, що вимагають вузької спеціалізації. Коли підсистема вимагає справжньої глибини — рушій ризику, рекомендаційні алгоритми, криптографія, відеокодеки — її вирізаають в окрему команду експертів, щоб не розірвати когітивне навантаження потокової. Таких команд має бути мало. Якщо організація обростає командами складних підсистем — зазвичай це означає, що те, що мало бути платформою, розсипалося на окремі димарі.

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

3. Чому не рятує ні «більше людей», ні «більше процесу»: когітивне навантаження

Це найменш оцінений внесок Team Topologies — вона ставить когітивне навантаження в центр оргдизайну.

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

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

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

Ось конкретно. Керівник групи банківського ядра мав 7 людей, які одночасно стикувалися з чотирма джерелами — ризик, підтримка клієнтів, регуляторна звітність, маркетинг — і підтримували три непов’язані модулі. Лише на міжкомандні візування, вирівнювання й перемикання контексту щодня йшла майже половина енергії команди. Дайте їй найкращий ШІ-інструмент на ринку — не приживеться, бо в людей немає вільної смуги, щоб учитися новому й міняти процес. Рятувати — спершу розвантажити: вирізати непов’язані модулі й залишити команду володіти одним потоком цінності.

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

Однорядковий чекап для великих компаній. Чи не тягне ваш «найзавантаженіший» одночасно п’ять і більше непов’язаних справ? Якщо так — ні додані люди, ні доданий процес не врятують. Треба перенарізати.

4. Як діяти: зворотній маневр Конвея

Це найбільш практичний крок у книзі. Не малюйте спершу архітектурну діаграму, а потім під неї переробляйте команду. Спершу змініть структуру команд — і архітектура сама відросте туди, куди вам треба.

Традиційно архітектор малює цільову архітектуру («йдемо в мікросервіси!») і вимагає, щоб команди під неї перебудувалися. Це майже завжди мимо. Наявна структура команд так і тягтиме архітектуру назад до своєї форми. Закон Конвея у дії.

Зворотній маневр Конвея перевертає порядок. Спершу реорганізуйте команди за потоками цінності — виріжіть потокові, поставте платформну — так, щоб межі команд стали майбутніми межами сервісів. Далі архітектура сама схиляється до розумного розрізу: команди природно спілкуватимуться через API, а не лізти в спільну базу.

Повернемося до того CIO. Я не сказав йому вибирати фреймворк мікросервісів. Я дав йому набагато буденніший крок: поставити «контроль якості» як окрему потокову команду — витягнути по одній людині з фронтенду, MES, алгоритмів та операцій, зібрати команду з 6 осіб, що наскрізь володіє функцією. За три тижні сталося три речі. Перший тиждень: вони виявили, що крок, що застрягав у роботі з MES-замовленнями, взагалі не потребував алгоритмістів — і полагодили його всередині команди. Другий тиждень: вони самі перевели розгортання моделі з «черги до операційників» на внутрішньокомандне самообслуговування, бо платформна команда відкрила їм самообслуговний вхід CI/CD. Третій тиждень: вони випустили першу наскрізну дрібну функцію, не перетнувши жодної командної межі. Людей не додалося, інструментів не міняли — горизонтальні шари поставили як вертикальні потоки. Цикл доставки повернувся з 3 місяців до 3 тижнів. І несподіваний бонус: команда почала сама пропонувати покращення, бо вперше побачила свій потік цілісно й узяла на себе повну відповідальність за результат. Раніше, розпорошена на 5 команд, ніхто не відчував, що має відповідати за весь потік контролю якості.

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

Хто це використовує

Банківський сектор (офіційно пріоритетна галузь TT + еталон жорсткого регулювання). На teamtopologies.com ведеться експертна колонка «When DORA metrics meet governance in banking». Дослідження DORA, на яку вона спирається, дає жорсткий висновок: зовнішні погодження (external approvals) негативно корелюють із lead time, deployment frequency і restore time — чим більше міжкомандних погоджень постфактум, тим повільніше доставка й повільніше відновлення після інцидентів. Це точно підтверджує тезу цієї статті: комплаєнс треба вбудовувати в потокову команду, погодження виносити вперед, а не тримати як міжкомандну постфактум-процедуру. ClearBank та інші британські цифрові банки постійно фігурують в офіційній екосистемі. Банківництво — найбільш показовий сценарій реоргу за потоками під жорстким регулюванням.
Zalando (e-commerce, еталон «платформа як продукт»). Внутрішня платформа розробника як самообслуговна здатність для потокових команд — орієнтир платформізації, що його TT-спільнота цитує часто.
AutoTrader UK (платформа автокласифайдів). Реальний кейс прийняття, який TT цитує постійно, — реорг за потоками цінності плюс продуктізація внутрішньої платформи.
KPMG UK (у 2024 стала офіційним рішенням-партнером TT). Принесла TT великим бізнес- і фінансовим клієнтам — сигнал, що TT увійшла в мейнстримний корпоративний консалтинг.
Netflix / Spotify («духовні еталони» «платформа як продукт», а не кейси прийняття TT). Обидві вели платформу як продукт ще до виходу книги 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 тижнів, одна невелика команда — і ви побачите помітний зсув у швидкості доставки. Дати результату продати наступний раунд набагато ефективніше, ніж продати його слайдами.

«Який це має стосунок до моєї ШІ-трансформації?» Прямий. ШІ не полагодить невідповідну організацію — він підсилює наявне: сильна команда з ШІ стане швидшою, невідповідна з ШІ лише швидше нагромадить борг. Організаційний діагноз має передувати закупівлі інструментів. Саме тому у моїй фірмовій методології «7-крокова рамка ШІ-трансформації» я ставлю «оцінку здатності» дуже рано: спершу люди й організація, потім інструменти.

«У нас не виходить зібрати всі чотири типи — що робити?» Більшість організацій не збирає — і не мусить. Перші два, що варто мати, — потокові команди (гарантувати наскрізну доставку) й платформна команда (не винаходити колесо щоразу). Команди-наставники й команди складних підсистем ставлять за потребою; цілком нормально, якщо на старті їх немає. Не штампуйте команди заради «зібрати всі чотири» — це поставити віз попереду коня.

7. Висновки для тих, хто приймає рішення

Висновок 1: перед ШІ спершу намалюйте карту командної топології. Чи малювали ви її перед тим, як востаннє впроваджували ШІ-інструмент? Якщо команди нарізані за техшарами, то як би не був потужний ШІ, він лише прискорює нагромадження боргу на хибній структурі. Цей один крок може відсікти щонайменше половину невиправданих IT-інвестицій у великій компанії. Конкретно: випишіть усі команди й позначте, за який потік цінності кожна відповідає наскрізно. Там, де позначити не виходить — команда нарізана за техшарами, реорганізовуйте її першою.

Висновок 2: зробіть чекап когітивного навантаження. Перестаньте питати «чи вистачає людей». Подивіться, які команди одночасно підтримують понад 5 непов’язаних систем, і хто стикується з понад 3 джерелами даних. Виявити це — набагато корисніше, ніж додавати людей чи процес. ШІ забере частину навантаження (писати код, шукати матеріали, первинний відбір) — за умови, що ви свідомо перерозподілите навантаження, а не накинете перевантаженій команді ще одне «завдання впровадження ШІ».

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

Висновок 4: не дайте ШІ закріпити хибні межі. Це спеціально для організацій, що впроваджують ШІ-агентів. Коли ви додаєте ШІ-агента в команду, хибна нарізка підсилюється: агент автоматизує за наявними — хибними — межами й цементує зламану структуру. Перш ніж пускати ШІ-агента, переконайтеся, що межі команд правильні. Це фокус 11-ї статті серії.

Самоперевірка (відповідаючи, не прикрашайте): ваші команди нарізані за потоком цінності чи за фронтенд/бекенд/операції/безпека? Найзавантаженіша людина — чи не тягне одночасно 3 і більше непов’язаних справ? Якщо внутрішньою платформою ніхто не користується, це червоне світло провалу платформізації. Якщо хоча б на одному пункті відповідати совісно — перед ШІ спершу реорганізуйте команди. Це превентивний крок із найвищою віддачею.

Далі

Це 2-га стаття серії «Трансформація програмної інженерії в епоху ШІ» (172-й випуск рубрики «Повільно вчимо ШІ»). Ми пройшли від Конвея (організація визначає архітектуру) до Team Topologies (як спроєктувати організацію). Наступна стаття (3-тя) бере базовіше питання: коли ШІ робить виробництво коду майже безкоштовним, куди зміщується вузьке місце програмної інженерії?

Про серію: ця серія відстежує останні зміни в ШІ-інструментах програмування, організаційній архітектурі та парадигмах програмної інженерії — зокрема, як Закон Конвея міняється в епоху ШІ-агентів 2026 року, зрілість новітньої інструментальної екосистеми тощо. Підписуйтесь на серію, щоб отримувати оновлювані інсайти.

Про цю серію

«Трансформація програмної інженерії в епоху ШІ» — серія глибоких досліджень для CIO, CDO, CTO та керівників цифровізації у телекомі, фінансах, промисловості, e-commerce; всього 15 статей. На основі 200+ академічних праць та галузевих звітів — довідник для прийняття рішень з маркуванням рівня доказовості.

Я колишній інженер IBM, ICF-сертифікований коуч; робив ШІ- та цифрові проєкти в телеком-операторах і великих компаніях. Тут написане — це бойові судження, вироблені, поки проводив компанії крізь ями.

Якщо після прочитання ви думаєте «чи не виглядає так і наша компанія» — я зібрав «Опитувальник із 20 запитань для самодіагностики командної топології», а також пропоную 30-хвилинну 1-на-1 діагностичну розмову, щоб допомогти знайти, який потік цінності реорганізувати першим. Звертайтеся: залиште повідомлення в акаунті «AI Insights for Decision Makers» або напишіть на 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. (Огляд прийняття в багатьох організаціях, вторинне) https://itrevolution.com/articles/team-topologies-five-years-of-transforming-organizations/
Netflix Spinnaker / Spotify Backstage — еталони продуктізації внутрішньої платформи
AutoTrader UK — кейс прийняття, що його цитує TT (деталі та посилання teamtopologies.com будуть додані)
Офіційна бібліотека кейсів: https://teamtopologies.com/examples