Організація виконання

Людські команди, експертиза й спеціалізовані агенти

У студії працюють двоє людей і кілька програмних агентів. Один агент уже підготував код, п’ять агентів-рецензентів назвали його правильним, а релізний…

Глава 41Заморожене українське видання

У студії працюють двоє людей і кілька програмних агентів. Один агент уже підготував код, п’ять агентів-рецензентів назвали його правильним, а релізний агент пропонує розгорнути його. Водночас зміна зачіпає перевірку доступу до чужих облікових записів. Хто тут вирішує, чи потрібна ця можливість, хто має право оцінити загрозу, хто може схвалити реліз і які докази мають зупинити автоматичний потік?

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

Передумови. Потрібне загальне розуміння продукту й дослідницької роботи з глав 6, 12 і 20, а також делегування, стану й перевірки з глави 40. Ця глава розглядає організаційні рішення, а не налаштування конкретного програмного засобу чи реальну реорганізацію команди.

Глава складається з трьох послідовних частин: людська команда й експертиза; межі команд за Team Topologies; розподіл роботи між людьми, детермінованими перевірками та програмними агентами. Принципи, виведені з книжок про людей і організації, не є емпіричним доказом того, що агент поводиться як людина. Там, де ми застосовуємо їх до агентів, це окремо позначено як проектне рішення або обережний висновок.

41.1. Команда, професійна робота та експертиза

У цій частині читач відрізняє посаду від компетентності та права рішення, і добирає роботу під навички й обмеження команди. Вона спирається на загальні передумови глави 41: знання продукту й дослідницької роботи з глав 6, 12 і 20.

Посада не визначає конкретне рішення

Слово «роль» часто означає різні речі. Щоб не переносити владу від назви до дії, розділяймо п’ять понять:

Поняття На яке питання відповідає Приклад
Посада Яке місце людини в організації чи трудовій угоді? Інженерка платформи, консультант, керівник продукту
Роль у задачі Яку роботу людина виконує в цій конкретній ситуації? Збирає докази, змінює схему даних, перевіряє контроль доступу
Компетентність Які знання й уміння підтверджують здатність виконати роботу належно? Може пояснити модель загроз, відтворити сценарій і показати перевірку
Відповідальність За який результат людина або команда звітує та що має підтримувати? Команда володіє працездатністю сервісу й усуває його інциденти
Право рішення Хто уповноважений обрати серед варіантів, прийняти ризик або дозволити наслідок? Власник сервісу схвалює запуск після визначених перевірок

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

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

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

Професійні послуги: відповідність роботи й можливостей

Девід Майстер розглядає професійну фірму як систему, що має узгоджувати різні типи клієнтської роботи з навичками, взаємодією з клієнтом та розвитком людей. У його статті про будову консалтингової фірми «знаходити роботу, керувати роботою й аналізувати її» — це спрощені види внеску, а не універсальні посади чи обов’язкова схема кожної компанії. Він також описує різні моделі практики аналогіями до аптекаря, медсестри, нейрохірурга й психотерапевта, щоб показати, що стандартність роботи, діагностика та контакт із клієнтом різняться. Це корисна професійна перспектива, а не доведена таксономія для всіх інженерних команд (Maister, “The Anatomy of a Consulting Firm”).

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

У статті про результати й винагороди у фірмі з кількома групами Майстер застерігає від короткострокового керування лише завантаженістю та годинами. Системи, методики й навчання можуть з часом дати змогу передати типову частину роботи менш старшому виконавцеві, вивільнивши старшого для складнішої діагностики. Це погляд автора на професійні послуги; його не слід перетворювати на гарантію зростання продуктивності або на прямий рецепт автоматизації (Maister, “Results and Rewards in the Multi-Group Firm”).

Девід С. Бейкер розглядає експертність через здатність помічати повторювані закономірності у вузькій сфері, формувати відмінну позицію на ринку та цінувати правильну діагностику. Сам авторський сайт подає ідеї книжки The Business of Expertise і її погляд на відмінність між підприємництвом та вузькою консультативною експертизою; це не незалежна оцінка результативності (авторський сайт і опис книжки). Для команди це означає, що експертність — не просто довгий стаж і не кількість інструментів у профілі. Корисні ознаки — релевантність досвіду до цього класу проблем, здатність назвати ознаки й контрприклади, які відрізняють випадки, та пояснити, як перевірити висновок. Нішева спеціалізація може підвищити цінність точного діагнозу, але також створити залежність від однієї людини. Тому зберігайте приклади, критерії, рішення та навчальні можливості, не припускаючи, що весь досвід можна повністю передати текстом.

Фокус, довіра й умови роботи

Том ДеМарко й Тім Лістер у третьому виданні Peopleware обговорюють переривання, фрагментацію робочого часу, командну згуртованість, середовище для зосередженої роботи й управлінське ставлення до людей. Видавець надає зміст, передмову та окремий зразок розділу про лідерство, але не повний текст книжки у відкритому доступі. У зразку автори розрізняють лідерство як «вилучення роботи» через владу та лідерство як служіння, підтримку й інновацію (зразок розділу “Let’s Talk About Leadership”; сторінка видавця Peopleware, 3-тє видання).

Застосування до сучасної інженерної команди — це інтерпретація їхніх ідей, а не гарантія, що будь-яке переривання шкодить або що всі люди працюють однаково. Часті термінові повідомлення, зустрічі без рішення та раптові зміни пріоритетів можуть ускладнювати безперервну роботу. Доцільно об’єднати запити, визначити канал термінової ескалації, підготувати контекст у заявці й розрізнити справжню аварію від звичайної цікавості. Водночас критичне чергування чи термінова допомога можуть бути потрібною частиною роботи. Треба проєктувати систему так, щоб перерви мали причину, адресата й шлях відновлення, а не звинувачувати того, хто отримує запити.

Лідер, який прибирає перешкоди, узгоджує пріоритети та пояснює право рішення, не просто вимагає швидшого темпу. Керівник може забезпечити межі для фокусної роботи, розв’язати конфлікт залежностей, погодити навчання або зафіксувати, хто несе наслідки рішення. Довіра та психологічна безпека не означають відсутності стандартів чи складного зворотного зв’язку. Вони мають полегшувати повідомлення про невизначеність, помилку й незгоду до того, як ціна виправлення зросте. Наставництво й спільна діагностика допомагають розподілити досвід; стабільна команда може накопичити контекст, але потребує часу й здорових умов, щоб це сталося.

Дослідження 51 виробничої команди виявило зв’язок психологічної безпеки з навчальною поведінкою. Це спостереження не доводить однакового причинного ефекту в кожній команді, але підтримує практичне питання: чи можуть люди рано повідомити про невизначеність, помилку й незгоду та отримати конструктивну відповідь? Edmondson, 1999.

Тиск строків теж є організаційним вибором, а не властивістю окремого виконавця. Третє видання Peopleware має розділи з назвами «Quality—If Time Permits» і «Teamicide», а видавець окремо показує зразок, де ДеМарко й Лістер критикують лідерство як механізм витискання більшої кількості роботи. Відкритий зміст підтверджує, що автори розглядають якість, строки й дії, які шкодять згуртованості команди; оскільки повний текст відповідних розділів тут не опрацьовано, це не підстава приписувати авторам точний універсальний список причин чи виміряний ефект. Практичний висновок цієї глави: коли дата фіксована, керівник має явно узгодити обсяг, ризик, докази та те, що буде вилучене або перенесене. Не стискайте мовчки дослідження, рецензування й час на відновлення, не ставте команди в штучну конкуренцію й не карайте за раннє повідомлення про проблему. Інакше команда втрачає довіру, а якість непомітно стає необов’язковою. Це запитання до процесу, а не діагноз конкретному менеджеру (зміст і зразок Peopleware у видавця).

Фредерік Брукс у The Mythical Man-Month застерігає від простої арифметики, ніби додавання людей до вже затриманого програмного проєкту лінійно віднімає час: нових людей треба ввести в контекст, а залежна робота додає координацію. У розділі про координацію він розглядає попарні канали комунікації за певного способу взаємозалежності задач. Ця модель не є прогнозом строку для конкретної команди: залежності, інструменти, структура задач і зрілість людей різняться. У розділі про концептуальну цілісність він розглядає користь узгоджених системних рішень і чіткого архітектурного бачення. Це не аргумент, що одна людина має одноосібно вирішувати все, і не доказ, що більше виконавців завжди гірше. Для складної системи важливі узгоджені поняття, зрозумілий власник рішення та процес, де експерти можуть надати заперечення й докази (книга та видання у бібліографічному записі Google Books; текст Брукса на сайті Carnegie Mellon).

Розібраний випадок: двоє людей у студії та агенти

Уявімо невелику продуктову студію. Марта відповідає за продукт і клієнтські вимоги, Данило — за реалізацію та супровід. Агент досліджує документацію, другий створює патч у тестовій гілці, третій шукає помилки в авторизації, четвертий готує опис випуску. Клієнт просить додати вхід через запрошення колеги. Агент-програміст зробив зміни, а п’ять агентів-рецензентів погодилися, що «логіка виглядає правильно».

Спершу Марта як власниця продуктового рішення уточнює очікувану поведінку: хто може запросити колегу, на яку адресу, з якими строком дії та правами, як скасувати запрошення. Вона може доручити агенту дослідити варіанти, але агент не визначає сам, які ролі потрібні клієнту. Данило перевіряє вплив на код і підтримку: термін дії токена, повторне використання посилання, журналювання, відмови пошти й можливість відкликання. Продуктове рішення залишається за Мартою. У цьому прикладі кваліфікований зовнішній фахівець оцінює загрозу, а уповноважений власник даних клієнта окремо приймає або відхиляє залишковий ризик. Марта як визначена власниця релізу схвалює його лише після зафіксованого прийняття ризику й отримання технічних доказів; Данило виконує розгортання в погоджених межах. Якщо клієнт не назвав власника ризику чи повноваження Марти на випуск не встановлені, зміна зупиняється до такого рішення. Назва агента «безпековий рецензент» не дає йому права прийняти ризик чи дозволити випуск.

Кожному агенту видають вузьке завдання з вхідними даними, дозволеними діями й вимаганим доказом. Дослідник повертає посилання на чинну документацію та перелік невирішених питань. Агент-реалізатор пропонує зміни й описує, що не змінив. Агент-рецензент має порівняти вимогу з фактичною логікою та навести конкретний сценарій ризику. Автоматичні перевірки виконують перевірку формату, типів і відомих тестових випадків. Данило інтегрує результати й переглядає зміну у спільному стані. Після прийняття залишкового ризику клієнтом і проходження потрібних технічних перевірок Марта є єдиною визначеною власницею схвалення релізу; Данило надає технічні докази та виконує розгортання, але не обходить невиконані перевірки. Це домовленість у наведеному прикладі, а не загальне правило для всіх студій.

Якщо продукт не має визначеного власника безпеки, роботу не можна «погодити» голосами агентів. Марта й Данило фіксують прогалину та передають її клієнту; вони можуть залучити компетентного фахівця для оцінки загрози, але не приймають ризик замість уповноваженого власника. Випуск залишається зупиненим, доки клієнт не назве такого власника й той не прийме або не відхилить ризик. Для двох людей це може бути повільніше за повну автоматизацію одного релізу, зате відповідає реальним повноваженням і наслідкам. Якщо перевірка показує, що запрошувальне посилання дозволяє отримати доступ після відкликання, випуск зупиняють, доки не буде виправлено логіку й перевірено відновлений стан.

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

Один учасник Reddit-обговорення описує малу програмну компанію, де власник поєднує розробку, підтримку, фінанси, продажі й виправлення помилок та не має часу на розвиток бізнесу; відповіді пропонують різні шляхи, але не підтверджують їхні результати. Це один особистий опис і не доказ того, що мала студія обов’язково має наймати людину, звужувати нішу чи автоматизувати роботу. Він корисний лише як нагадування поставити конкретні питання про робоче навантаження, невидимі обов’язки та обмеження власника (обговорення у r/smallbusinessuk).

41.2. Межі команд і потік цінності: Team Topologies

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

Мисліть межами взаємної роботи

Team Topologies — підхід Метью Скелтона й Мануеля Пейса до організації людських команд навколо потоку роботи й керування когнітивним навантаженням. Друге видання вийшло 2025 року; ця частина використовує поняття його авторів, але не перетворює їх на єдину обов’язкову структуру. Автори описують чотири типи команд і три режими їхньої взаємодії на офіційній сторінці ключових понять (друге видання та опис книжки; ключові поняття Team Topologies). Типологія стосується людської організації; перенесення її назв на агентів не доводить, що програмні виконавці мають людську командну динаміку.

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

Чотири типи команд є лінзами для дизайну, а не оцінками важливості людей:

Тип команди Основна орієнтація Коли може бути доречною Межа, за якою вона заважає
Потоково-узгоджена (stream-aligned) Безперервний потік цінності для визначеного сегмента, продукту чи користувача Коли команда може володіти пов’язаною частиною продукту від зміни до підтримки Якщо для звичайної зміни щоразу потрібні кілька зовнішніх погоджень і передач
Спроможнісна (enabling) Тимчасове наставництво, усунення перешкод і передавання відсутньої спроможності іншій команді Коли команда виявила конкретну прогалину й має навчитися діяти самостійно Якщо тимчасова допомога перетворилася на постійну чергу або приховане володіння продуктом іншої команди
Складної підсистеми (complicated-subsystem) Спеціалізована частина системи, що потребує глибокої технічної чи математичної експертизи Коли повторно створювати цю спеціалізовану спроможність у кожній продуктовій команді нераціонально Якщо межа стала надто широкою і команди чекають на зміну кожної деталі
Платформна (platform) Внутрішній продукт, що зменшує інфраструктурне навантаження на потоково-узгоджені команди Коли багато команд повторюють схожу інфраструктурну роботу й можна дати їм самообслуговування Якщо платформа перетворилася на обов’язкове погодження або приховує складність за нестабільним інтерфейсом

Назва типу не замінює перевірки фактичної поведінки. Команда «платформи» може діяти як квиткова черга, а потокова команда — бути настільки перевантаженою, що нічого не завершує. Перевіряйте, чи скоротилися зайві передачі та чи має команда ясне володіння результатом.

Три режими взаємодії

Взаємодії мають різні цілі, терміни та межі відповідальності:

Режим Для чого він потрібний Типовий завершений результат Приклад межі
Співпраця (collaboration) Спільно дослідити нову чи неоднозначну проблему, коли обом сторонам потрібен контекст Відповідь на визначене питання, спільне рішення або перевірений прототип Обмежте час і ціль; перегляньте режим, коли невизначеність зменшилася
Послуга X-as-a-Service Одна команда надає чітко описану можливість, інша самостійно нею користується Документований інтерфейс, стабільний результат, зрозуміла підтримка й шлях самообслуговування Вкажіть власника, умови якості й канал помилок; споживач не повинен домовлятися вручну для кожного звичайного запиту
Фасилітація (facilitation) Тимчасово допомогти іншій команді навчитися, розібрати перешкоду чи змінити спосіб роботи Передана спроможність, усунена перешкода або план виходу Експерт допомагає, але не перебирає безстрокове володіння чужою роботою

Не тримайте співпрацю безстроково: коли обидві команди вже знають вимогу й контракт, перейдіть до послуги або заверште її. Не маскуйте тимчасову фасилітацію під постійну залежність. Режим слід обрати за характером роботи й переглядати, коли характер роботи змінюється. Офіційний виклад Team Topologies визначає ці три режими як collaboration, X-as-a-Service і facilitation; конкретний строк та умови у таблиці — робоча інтерпретація для планування (офіційні ключові поняття).

Платформа — внутрішній продукт

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

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

Розібраний випадок: інфраструктурна черга росте

У продуктової компанії є шість команд. Кожна окремо просить одну людину-експерта налаштувати журналювання, резервні копії та права середовища. Нові зміни зупиняються, коли ця людина у відпустці. Назвати експерта «платформною командою» замало; спершу розділіть різні потреби.

  1. Знайдіть повторювану роботу й межу ризику. З’ясуйте, які конфігурації однакові, де потрібна доменна експертиза й які дії справді вимагають окремого затвердження. Зафіксуйте вік, обсяг і вплив черги. Не можна автоматизувати винятки, для яких ще не визначено політику.
  2. Якщо бракує знання, почніть із фасилітації. Експерт працює з продуктовою командою над одним репрезентативним випадком, пояснює модель ризику, допомагає створити інструкцію чи шаблон і погоджує критерії самоперевірки. Умова завершення — команда може виконати стандартний випадок і знає, як розпізнати та підняти виняток.
  3. Якщо повторювана потреба стала спільною, створіть внутрішню послугу. Невелика платформна група може надати документовані стандартні шаблони й автоматичне створення середовища. Продуктові команди самі запускають безпечний типовий сценарій, бачать його стан і можуть відкотити зміну за визначеним порядком.
  4. Якщо проблема стосується одного складного компонента, збережіть спеціалізоване володіння. Власник складної підсистеми може приймати зміни, але описаний контракт і перевірки дають іншим командам можливість виконувати суміжні безпечні задачі самостійно.
  5. Визначте, коли залишати ручне погодження. Якщо запит надає широкий доступ, змінює політику зберігання або стосується регульованої інформації, його передають уповноваженому власникові з потрібними доказами. Самообслуговування не скасовує управління доступами.

Після початкового переходу команди дивляться, чи стандартні запити справді виконуються без ручної черги, чи зрозумілий механізм ескалації та чи стабільні шаблони. Якщо всі реальні випадки виявилися унікальними, широку платформу створювати не слід; часом достатньо фасилітації й документації. Якщо ж платформу не використовують, досліджують причину разом із користувачами, а не нав’язують adoption кампанією.

Першоджерельний випадок: Backstage у Spotify

Spotify описує, як його група платформи створила Backstage для пошуку служб, інструментів і документації. У власній інженерній публікації компанія згадує труднощі нових працівників із пошуком контексту та часті перемикання між завданнями, а також дублювання подібних внутрішніх сервісів. Компанія подає свій вибір як внутрішній продукт для розробників і пояснює, чому обрала шлях, що враховував її автономну культуру, замість простого централізованого наказу (Spotify Engineering, “A Product Story: The Lessons of Backstage and Spotify’s Autonomous Culture”).

Це корисний приклад того, як велика організація описує внутрішню платформу, проблему виявлення контексту й спосіб залучення команд. Це першоджерельна розповідь самої Spotify: її цифри та позитивну оцінку не слід подавати як незалежний аудит, доказ причинності або прогноз для малої студії. Переносимий урок скромніший: назвіть конкретну внутрішню потребу, зробіть продукт корисним його користувачам і перевірте фактичне використання; не вважайте високий рівень автономії доказом того, що внутрішні дублікати зникнуть самі.

Закон Конвея як зворотний зв’язок, а не вирок

Закон Конвея пов’язує структуру системи комунікації організації зі структурою систем, які вона створює. Його корисно читати як застереження: стійкі межі відповідальності й канали співпраці впливають на те, які інтерфейси та залежності команда схильна будувати. Це не означає, що оргструктура механічно визначає архітектуру, або що потрібна реорганізація щоразу, коли схему коду складно змінити. На архітектуру впливають і спадщина систем, технології, обмеження домену, відповідність стандартам і вимоги сумісності.

Використовуйте спостереження циклічно: потік роботи показує, де межі створюють затримки; команда змінює спосіб взаємодії; потім вона перевіряє, чи змінився потік і чи не виникли нові витрати. Топології за Team Topologies теж слід адаптувати разом із сервісами й потребами, а не фіксувати один раз назавжди. Не робіть кадрових змін із самого лише висновку, що команда «не відповідає» діаграмі.

41.3. Спеціалізовані агенти в команді людей

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

Спеціалізація — це контракт роботи

Спеціалізований агент — програмний виконавець, налаштований на обмежений тип роботи й доступні засоби. Його спеціалізація може бути задана контекстом, інструкціями, джерелами, дозволеними діями, форматом відповіді та критеріями перевірки. Це не обов’язково означає іншу базову модель; і навпаки, інша модель сама по собі не утворює корисної спеціалізації. Агент не є членом людської команди в правовому, трудовому, професійному чи моральному сенсі. Людина або організація відповідає за систему, дозволи, рішення та наслідки.

У документації виробника OpenAI показані два конкретні патерни їхнього набору засобів: передавання керування спеціалісту, який володіє наступною відповіддю, та виклик агента як обмеженого інструмента, коли головний агент залишається відповідальним за фінальну відповідь. Документація радить давати спеціалістам вузькі задачі та розділяти їх тоді, коли потрібні інші інструкції, інструменти чи політика. Це продуктова настанова для описаної реалізації, а не організаційний закон (OpenAI, “Orchestration and handoffs”). Anthropic описує ланцюжки, маршрутизацію, паралельні виклики, оркестратор із виконавцями та цикли оцінювання як шаблони, які варто комбінувати відповідно до виміряної потреби; власний матеріал також попереджає про витрати та накопичення помилок в автономному виконанні (Anthropic, “Building Effective AI Agents”).

Звідси випливає корисний запит до власника процесу: «Який конкретний вид роботи має стати легшим, що цей виконавець може бачити й змінювати, і як незалежно перевірити його результат?» Якщо відповідь лише «агент буде архітектором» або «зробимо команду агентів», назви поки що не визначають роботу. Натомість можна сказати: «Перевірить заявлені зміни контракту авторизації проти двох офіційних джерел і актуальної схеми; поверне розбіжності з точними посиланнями, не змінюючи код і не вирішуючи, чи приймати виняток».

Розклад ролей роботи

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

Вид роботи Вхід і корисні питання Хто або що може виконати Очікуваний доказ Межа рішення
Продуктове рішення Запит користувача, обмеження продукту; хто має проблему, як зміна допомагає, що неприйнятно? Уповноважений власник продукту; агент може синтезувати відгуки чи підготувати альтернативи Ясна поведінка, припущення, відкладені питання та вибраний варіант Агент не визначає цінність, цільову політику чи обіцянку клієнту без визначених повноважень
Дослідження Вузьке питання, допустимі джерела, дата й критерій достатності; чи джерело авторитетне та актуальне? Людина або агент з вебпошуком, сховищем чи документацією Посилання, уривки мінімального обсягу, дата, контекст і невідоме Синтез не перетворює неперевірене твердження на факт; рішення щодо суперечності належить власнику змісту
Архітектура Вимоги, поточний стан системи, обмеження; які альтернативи й наслідки? Архітектор, команда, агент для аналізу залежностей та варіантів Порівняння варіантів, міграційний шлях, ризики, тестовані інваріанти Остаточний вибір уповноважує визначений технічний власник із потрібним залученням команди
Реалізація Прийнята вимога, область змін, спосіб перевірки; який найменший сумісний патч? Інженер чи агент у межах ізольованого середовища Diff, опис, відтворювані кроки та результати перевірки Написати зміну не означає прийняти її, випустити чи підтвердити безпеку
Тестування Очікувана поведінка, інваріанти й приклади збоїв; що може спростувати гіпотезу? Детермінована перевірка, тестувальник, агент для пропозиції граничних випадків Результати конкретних тестів, покриті випадки, пропуски й обмеження Зелений набір підтверджує лише перевірені умови; агент не вигадує відсутні гарантії
Безпека Межа довіри, дані, загрози, контроль; хто може отримати доступ і що може піти не так? Компетентна людина або команда; агент може шукати визначені патерни й перевіряти конфігурацію Сценарій загрози, вразлива поверхня, доказ, запропоновані засоби пом’якшення Рішення про прийняття ризику, виняток або нормативний висновок лишається за уповноваженою людиною
Рецензування Зміни, критерії приймання й незалежні джерела; що є контрприкладом до твердження автора? Колега, спеціаліст або агент для окремого аспекту Знахідки з місцем у зміні, причиною, серйозністю та доказом Голосування, кількість рецензентів і впевненість формулювання не замінюють перевірку
Випуск і підтримка Схвалена зміна, план відновлення, стан системи; чи готові моніторинг, користувацьке повідомлення й відкат? Власник сервісу, чергова людина, автоматизований деплой у погоджених межах Версія, зміна стану, результати перевірок, спостережуваність і підтвердження відновлення Автоматичний крок не надає права на небезпечний випуск; відповідальний за наслідки визначений заздалегідь

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

Три різні виконавці: людина, агент, детермінована перевірка

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

Агент може шукати, синтезувати, пропонувати варіанти, готувати зміни й інструментально виконувати роботу в наданому середовищі. Його повідомлення про виконання є твердженням, яке треба звірити з файлами, журналами, результатами інструментів або системою-джерелом. Відомості з контексту попереднього запуску можуть застаріти; агенту може бракувати знань, прихованих припущень або потрібного доступу. Тому новий запуск не має успадковувати право рішення через те, що схожа задача раніше пройшла успішно.

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

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

Розібраний випадок: п’ять схвалень, одна неправильна умова

Уявімо, що п’ять агентів отримали однакове завдання: «Перевірити, що запрошений користувач не може прочитати запис до прийняття запрошення». У вимозі команди було записано: «Чинне запрошення дає доступ до профілю». Кожен агент прочитав ту саму вимогу й ту саму функцію перевірки, побачивши однакову умову invitation_status == accepted. Усі п’ятеро погодилися. Але продуктова політика в іншому джерелі каже, що статус pending має дозволяти доступ лише до сторінки прийняття, а не до профілю. Помилка міститься в невірному трактуванні «доступу», яке повторили і вимога, і агенти.

Кількість погоджень тут не створює п’ять незалежних доказів. Рецензенти поділяють ті самі вхідні дані, залежності та сліпу зону. Вони могли знизити ймовірність пропущеної синтаксичної помилки, але не перевірили авторитетність вимоги. Відповідальна команда зупиняє інтеграцію й формулює точний спір: «Який ресурс має бути доступним для станів pending, accepted і revoked?» Власник продукту встановлює поведінку, власник безпеки підтверджує межу приватних даних, а реалізатор змінює логіку. Тестова матриця охоплює три стани та різні ресурси. Потім хтось, хто не писав зміну, перевіряє її проти канонічного рішення, а не перепитує ту саму вимогу.

Якщо контекст або джерело вимоги не можна встановити, рішення не переходить у «схвалено». Власник продукту уточнює контракт; за потреби залучається відповідальний за дані чи доступ. Такий крок може відкласти випуск, але робить невідоме видимим. П’ять однакових відповідей свідчать про спільний сигнал, а не автоматичну незалежність. Для справді незалежної перевірки треба розділити джерела, критерії або методи, а потім усе одно визначити, хто розгляне розбіжність.

Розібраний випадок: рецензент постійно переривається

Ірина — єдина досвідчена інженерка, яка має переглянути кілька змін критичної бібліотеки. Автори надсилають окремими повідомленнями лінк без контексту, нову версію патча, запит «глянь швидко» й уточнення до вже відхиленого підходу. Ірина перериває одну перевірку, щоб відкрити іншу, і мусить заново визначати, що змінилося, який критерій чинний і чи йдеться про той самий commit. Затримка не є свідченням браку старанності рецензента; процес змушує її щоразу відновлювати втрачений стан.

Команда змінює саму передачу. Автор відкриває один запит із посиланням на точний стан зміни, короткою метою, критеріями приймання, переліком змінених файлів, результатами вже пройдених перевірок, відомими ризиками й конкретним питанням до рецензента. Кожна нова версія оновлює той самий запис і чітко позначає нові зміни. Не термінові запити проходять через одну чергу; термінове звернення має видиму причину та потрібний час відповіді. Для повторюваної помилки команда додає автоматичний контроль або ясний шаблон, а не просто інструктує Ірину бути уважнішою.

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

Відповідальність і зупинка

Перед запуском агентного кроку визначте:

  • що є очікуваним артефактом і як відрізнити його від припущення;
  • які джерела мають пріоритет та на який момент треба перевірити їхню актуальність;
  • які інструменти дозволені й чи може агент лише читати, запропонувати зміни або застосувати їх;
  • які побічні дії заборонені чи потребують окремого людського рішення;
  • які критерії вимагають зупинитися, передати неоднозначність або відмовитися від висновку;
  • хто інтегрує результат і відповідає за наступний стан;
  • хто має право на прийняття ризику й на зовнішній наслідок.

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

Короткий підсумок

Працюйте від характеру задачі, потрібної компетентності й повноважень, а не від назви посади чи агента. Організація команд впливає на навантаження, черги й доступ до контексту; типи Team Topologies допомагають описати цей зв’язок, але не є кадровим шаблоном. Фокус, стабільність і наставництво потребують процесу, який не приховує перешкод і не перекладає провину на окремого працівника. Спеціалізуйте агентів лише для конкретної роботи з визначеним доказом, межами інструментів і власником рішення. Рецензії та автоматизовані перевірки підтримують людську відповідальність, але не створюють її замість людини.

Подальше читання за темами

Книжка Які теми глави допоможе поглибити
Team Topologies, 2-ге видання Когнітивне навантаження, типи команд, режими взаємодії, внутрішня платформа та межі між командами
Peopleware, 3-тє видання Фокус і переривання, стабільність команди, підтримувальне лідерство, згуртованість та умови роботи
David Maister, Managing the Professional Service Firm та пов’язані авторські матеріали Відповідність типу роботи й навичок, навчання та рівновага між короткостроковим завантаженням і розвитком спроможності
David C. Baker, The Business of Expertise Повторювані закономірності, фокус і діагностична цінність експертності
Frederick P. Brooks Jr., The Mythical Man-Month Витрати координації та входження в роботу, концептуальна цілісність і межі аргументів про командний розмір

Основні джерела