Organization of the Future: Simulating the AI-Native Teams Workshop

#

### Організовано Ataccama // Karlín, Прага 8

***

**Зустріч на основі агентів у Празі: створюйте як POD — імітація команди розробників на основі ШІ**

***

## Короткий опис

Ваша організаційна схема вбиває ваших агентів. Приєднуйтесь до нас, щоб провести живу симуляцію того, як команди на базі POD приймають рішення за допомогою агентів штучного інтелекту — не кажучи про це.

***

## Повний опис

***

### Це зустріч у Празі, керована агентами.

Якщо ви були тут раніше, ви знаєте, що це таке: жодної дурниці, жодних пропозицій постачальників, жодних презентацій «ШІ змінить усе». Ми будуємо речі, ми ламаємо речі, ми з’ясовуємо, що насправді працює, коли ви запускаєте агентів у виробництво в реальних організаціях.
Це видання йде на один рівень вище від коду. Не як створити агентів — як створити команди, які ними керують.
Тому що на цих зустрічах ніхто вголос не каже: **агенти в порядку. Організаційна структура навколо них порушена.**

***

### Справжня проблема, яку ми не вирішуємо

Кожна команда на всіх зустрічах, які ми проводили, використовує агентів однаково. В одного розробника відкрито вікно Клода. Інший має курсор. Хтось на Slack опублікував підказку, яка виявилася корисною. Немає спільного контексту, спільного розподілу ролей, немає способу колективної відповідальності агентів за фактичні цілі команди.
Ви використовуєте ШІ 21-го століття на організаційній діаграмі 20-го століття.
Організаційна схема була розроблена для передбачуваної, повторюваної, розкладаної роботи — припущення індустріальної епохи, вписані в кожну ієрархію, кожну команду функцій, кожну дошку спринту. Він не знає, що робити з агентами, оскільки агенти — це не завдання. Вони здатні істоти. Їм потрібні ролі. Їм потрібен контекст. Вони повинні вписуватися в структуру, яка була розроблена для їх утримання.
Дейв Грей зрозумів це в 2012 році, ще до появи агентів.

Він назвав це **Зв’язаною компанією**. Основним підрозділом є **POD** — невелика, автономна багатофункціональна команда з усім необхідним для незалежного обслуговування клієнтів, підключаючись до інших POD через чіткі інтерфейси, а не рівні керування.

***

### Що насправді відбувається на цій зустрічі

Ви входите. Вас призначають до POD.
Кожна POD — це міжфункціональна одиниця всередині **NovaTech** — вигаданої (але незручно знайомої) чеської B2B SaaS-компанії, яка переходить від традиційної ієрархії до пов’язаної структури на основі POD. Продукти POD. Доходи POD. Інфраструктура POD. Поди успіху клієнтів. Кожен із завданням, пов’язаним із його функцією.
**Перед компанією стоїть одне рішення: чи варто NovaTech запускати в Німеччині в третьому кварталі?**
Жоден POD не має повної картини. Product POD знає, скільки коштує дорожня карта. У Revenue POD є пропозиції. Інфраструктурний POD має графік постійності даних. Customer Success POD знає, що вони не можуть підтримувати. Рішення справді важке. Команди POD повинні вирішити це разом, щоб менеджер не порушив зв’язку.
**Ваш POD отримує агент ШІ.** Не інструмент. Член команди з роллю, яку ви визначаєте, ім’ям, яке ви даєте, і коротким описом, який ви пишете. Аналітик-дослідник. Технічний аналітик Due Diligence. Стратег доходів. Ви вирішуєте. Ви інформуєте про це. Ви працюєте з тим, що вам це дає.
**У вас є 45 хвилин.** Потім усі POD збираються на **Раду компанії** — відповідь Підключеної компанії на засідання правління, за винятком того, що ради немає. Просто POD зі своїми рекомендаціями, конфліктами та вимогою досягти колективної позиції, не маючи жодних повноважень скинути будь-кого іншого.
Це складна частина. Це повинно бути.
Після цього проводимо підведення підсумків. Що змінила структура POD у вашій роботі? Що ви зробили зі своїм агентом, чого не робили раніше? Де розпалася Рада товариства — і чому? Це не гіпотетичні запитання після цієї вправи. Це запитання, відповідь на які ви щойно пережили.

***

### Чому це правильна розмова для цієї спільноти

Кілька останніх зустрічей ми провели на технічному рівні: оркестровка, багатоагентна координація, керування пам’яттю та контекстом, шаблони керування. Ми створили реальні речі та навчилися реальним речам.
Але люди на цих зустрічах повертаються до команд, які все ще організовані так само, як і до появи агентів. Технічні знання не передаються, тому що їм нікуди приземлитися. Ви знаєте, як побудувати багатоагентний конвеєр. У вашої команди немає структури, у якій можна її розгорнути.
**Архітектура POD — це посадкова площадка.**
Коли ваша команда є POD — із визначеним клієнтом, визначеною метою, місцевими повноваженнями приймати рішення та явними інтерфейсами до інших POD — питання «куди підійде агент?» має реальну відповідь. У агента є роль. Роль має короткий. У брифі є результат. Результат має місце у вихідних даних POD для своїх клієнтів. Це не складно. Але спочатку потрібно, щоб існувала організаційна структура.
Ця зустріч будує цю структуру — у моделюванні — щоб ви могли відчути, як це виглядає, перш ніж спробувати переконати свою організацію в цьому.

***

### Що ви заберете

* Прямий, втілений досвід того, що відчуває автономія POD у порівнянні з командним виконанням функцій — різниця непомітна
* Робоча модель призначення агентам ШІ функціональних ролей у структурі команди, а не лише завдань у розмові
* Конкретна інтуїція щодо того, де відбувається збій координації між POD і чому цей режим збою є найскладнішою проблемою в дизайні підключеної організації
* Конкретне уявлення про те, що архітектура агента та архітектура організації — одна й та сама проблема — ви не можете вирішити одну без іншої

***

### Для кого це

Кожен, хто раніше був на Agent-Driven Meetup і хоче зрозуміти, чому знання агента не передаються їхній реальній команді.
Усі, хто раніше не був на Agent-Driven Meetup, але працює в команді розробників, яка намагається з’ясувати, як насправді інтегрувати штучний інтелект у свою роботу, а не лише в окремі робочі процеси.
Технічні лідери. Інженерні менеджери. Розробники з думками про структуру команди. Технічні директори в компаніях, які переосмислюють свою організацію. Продукти, які хочуть зрозуміти, чому їхні розробники ставляться до агентів так індивідуально, коли проблема є колективною.
Вам не потрібно читати *The Connected Company*. Ви повинні бути готові почуватися некомфортно в симуляції з незнайомими людьми протягом 45 хвилин. Ось і все.

***

### Розклад

| Час | |
| ---- | --- |
| 18:00 | Двері, напої, спілкування з людьми, яких ви ще не знаєте |
| 18:30 | Початковий кадр: архітектура POD за 20 хвилин, агенти як члени команди |
| 18:50 | Призначення POD, брифінг, призначення агента |
| 19:00 | **Робоча сесія POD** — 45 хвилин у прямому ефірі |
| 19:45 | **Рада компанії** — усі POD, одне рішення, без керівника |
| 20:15 | Структурований дебриф |
| 20:45 | Відкритий майданчик, запитання та відповіді, нетворкінг |
| 21:30 | Кінець |

***

### Розташування

**Ataccama** Sokolovská 685/136f, Карлін, Прага 8
Метро: Інвалідівна (лінія Б), 5 хв пішки. Трамвай: Urxova.
Ataccama створює платформи довіри корпоративних даних і робить це від Karlín з 2007 року. Вони знають, що означає масштабувати програмну організацію. Ми вдячні, що вони приймають.

***

### Ємність

**Максимум 40 осіб.** Це не зустріч, яку ви можете відвідувати пасивно. Симуляція потребує реальних POD з 5–7 осіб. Понад 40 років Рада товариства припиняє роботу. Зареєструйтеся раніше або не реєструйтесь.

***

### Принеси

* Ноутбук (мінімум один на POD, краще два)
* Ваші фактичні думки про те, як мають бути організовані команди — ви їх використаєте
* Необов’язково та з вдячністю: перед тим, як прийти, перегляньте *The Connected Company* Дейва Грея. Короткого змісту достатньо.

***

*Agent-Driven Meetup Prague — це провідна технічна спільнота штучного інтелекту в Центральній Європі, яка зосереджена на агентських системах виробничого рівня, організаційній інтеграції штучного інтелекту та інженерних дисциплінах, необхідних для керування ними. Ми зустрічаємося, ми будуємо, ми з’ясовуємо, що насправді працює.*
*Організатор: Якуб Бареш — [[email protected]](mailto:[email protected])*