Від ручної розробки до Dark Factory. Як змінюється роль бізнес-аналітика на шести рівнях автоматизації програмної інженерії
- Yevhen Kliukin
- 2 години тому
- Читати 20 хв
У січні 2026 року Ден Шапіро опублікував статтю “The Five Levels: from Spicy Autocomplete to the Dark Factory”, у якій описав еволюцію використання штучного інтелекту в програмній інженерії: від майже повністю ручного написання коду до автономної системи, що перетворює специфікації на готове програмне забезпечення.
Попри назву, модель охоплює шість станів — від рівня 0 до рівня 5. Шапіро пояснює це нумерацією з нуля, запозиченою з класифікації рівнів автоматизації автомобілів.
Оригінальна стаття розглядає насамперед те, як змінюється робота інженера програмного забезпечення. Але з неї випливає не менш важливе для спільноти бізнес-аналітиків (БА) питання:
Що відбувається з бізнес-аналітиком, коли інженерна функція компанії переходить на кожен наступний рівень автоматизації?
Тут важливо правильно визначити предмет аналізу.
Нас цікавить не те, наскільки активно сам бізнес-аналітик користується ChatGPT, Claude або іншими інструментами ШІ. Для цього можна побудувати окрему модель зрілості. Більшість матеріалів про ШІ та бізнес-аналіз якраз зосереджена на тому, як БА використовує ШІ, тоді як зміни самої розробки та їхній вплив на роль БА обговорюються значно рідше.
Нас цікавить інше:
як на кожному рівні використання ШІ відбувається розробка;
як видозмінюється цикл розробки програмного забезпечення;
який вхідний контекст потрібен інженерам та агентам;
хто досліджує проблему й середовище;
хто проводить передпроєктне дослідження (discovery);
хто має повноваження приймати бізнес-рішення;
хто забезпечує цілісність специфікації;
хто оцінює правильність і цінність результату;
чи залишається в такій моделі місце для окремої ролі бізнес-аналітика.
Моя головна теза полягає в тому, що трансформація бізнес-аналітика не буде лінійною.
На рівнях 0–1 роль майже не змінюється. На рівні 2 прискорена розробка може зробити аналіз і прийняття бізнес-рішень новим вузьким місцем. На рівні 3 змінюється спосіб взаємодії БА з процесом постачання (делівері, delivery). На рівні 4 інженер переходить у зону специфікації, де починають перетинатися сфери відповідальності бізнес-аналітика, продуктових ролей (Product Owner, Product Manager) та інженерної функції (engineering). На рівні 5 традиційний БА у процесі постачання може втратити значну частину функцій, хоча потреба в бізнес-аналізі не зникає.
Саме тут модель Шапіро залишає відкритою важливу для цієї статті частину: вона описує передусім автоматизацію інженерної функції, але майже не розглядає, як при цьому змінюються передпроєктне дослідження, формування бізнес-наміру, прийняття бізнес-рішень, управління контекстом і перевірка результату.
При цьому не варто сприймати рівні Шапіро як формально підтверджений галузевий стандарт або універсальну модель зрілості, яку кожна компанія зобов’язана пройти послідовно. Це корисна евристична модель, що допомагає говорити про різні стани автоматизації програмної інженерії.
Два контури: бізнес-намір і реалізація
Щоб визначити роль бізнес-аналітика в моделі Шапіро, умовно розділимо створення програмного продукту на два взаємопов’язані контури.
Контур бізнес-наміру (business intent) визначає, яку проблему потрібно вирішити, для кого, навіщо та яким має бути прийнятний результат. Він охоплює дослідження, аналіз потреб зацікавлених сторін (стейкхолдерів, stakeholders), бізнес-правил, меж рішення, обмежень, ключових рішень та критеріїв приймання.
Контур реалізації перетворює цей намір на працююче рішення через технічне проєктування, планування, розробку, інтеграцію, тестування та розгортання.
Ці контури не є послідовними фазами каскадної моделі (waterfall): бізнесові й технічні рішення формуються і перевіряються у постійній взаємодії.
Модель Шапіро описує передусім автоматизацію контуру реалізації. Але чим автономнішим і швидшим він стає, тим вищими стають вимоги до бізнес-наміру, специфікації та контексту, які запускають реалізацію.
Роль бізнес-аналізу в агентній розробці
Бізнес-аналіз забезпечує проєкту спільне розуміння проблеми, узгоджені рішення, цілісну доменну модель, керований контекст і перевірювані критерії результату.
У традиційній розробці частину прогалин можна компенсувати під час реалізації: розробник ставить уточнювальні питання, команда переглядає окрему користувацьку історію (user story), а помилку виправляють у межах невеликої частини функціональності.
В агентній розробці масштаб виконання змінюється. Агенти можуть брати на себе дедалі більші автономні пакети роботи — від окремих завдань до великих частин функціональності.
Через це помилка у вимогах, бізнес-правилах або налаштуванні контексту також масштабується. Вона може одночасно потрапити в архітектуру, код, тести, інтеграції та документацію. Подальші зміни стають складними й дорогими, а в найгірших випадках простіше повторно згенерувати значну частину рішення або переписати проєкт із нуля.
Тому зі скороченням часу на розробку значення бізнес-аналізу не слабшає, а вимоги до нього зростають.
Критичними стають:
правильне визначення проблеми й меж рішення;
узгодження вимог і бізнес-рішень до запуску великого циклу реалізації;
формалізація бізнес-правил, обмежень і винятків;
створення та налаштування контексту для агентів;
перевірка узгодженості специфікації;
визначення критеріїв, за якими можна довести правильність результату.
Чим більший обсяг агенти здатні реалізувати автономно, тим важливішою стає якість вхідного контексту, на основі якого вони працюють.
Від вимог до специфікації для агентної розробки
Чим більший обсяг реалізації передається агентам, тим важливішим стає не лише погодження окремих вимог, а й формування цілісного контексту, на основі якого агенти плануватимуть і створюватимуть рішення.
Окремих користувацьких історій або списку функціональних вимог для цього може бути недостатньо. Агентам також потрібні бізнес-намір, межі рішення, доменні поняття, правила, обмеження, сценарії, припущення та критерії правильності результату.
У межах цієї статті такий керований набір взаємопов’язаних знань і рішень я називатиму специфікацією (specification, spec).
Вона може включати:
проблему, цілі та бажані результати;
обсяг і межі рішення;
доменну модель і термінологію;
бізнес-правила, стани та сценарії;
обмеження, припущення й погоджені рішення;
критерії приймання та оцінювання.
Специфікація не обов’язково є одним документом. Вона може бути розподілена між моделями, структурованими описами, журналом рішень, сценаріями, контрактами, тестами та базою знань.
Для агентної розробки критично, щоб цей контекст був узгодженим, простежуваним і достатньо однозначним для планування, реалізації та перевірки результату.
Це не означає, що специфікація повинна бути остаточною або що ітеративне передпроєктне дослідження зникає. Вона має забезпечувати достатній рівень визначеності для конкретного циклу реалізації та чітко показувати, що підтверджено, що залишається припущенням, а що ще потребує рішення.
Рівні 0–1 — ручна розробка та окремі завдання для ШІ
Як працює розробка
На рівні 0 розробники вручну створюють програмне забезпечення. ШІ може використовуватися для пошуку або автодоповнення, але не виконує суттєвої частини реалізації.
На рівні 1 інженери передають ШІ окремі локальні завдання:
написати тест;
створити невеликий фрагмент коду;
додати технічну документацію;
запропонувати виправлення;
допомогти з типовою технічною операцією.
Основний процес розробки при цьому залишається під контролем людини. ШІ використовується для окремих локальних завдань, тоді як декомпозиція роботи, координація, інтеграція результату та загальний контроль залишаються за розробником.
Роль БА
Для бізнес-аналітика різниця між рівнем 0 і рівнем 1 майже непомітна.
БА, як і раніше:
досліджує потреби й контекст;
працює зі стейкхолдерами;
документує та погоджує вимоги;
підтримує команду під час реалізації;
долучається до приймання й оцінювання результату.
Головними споживачами результатів аналізу залишаються люди. Тому частина контексту може зберігатися в розмовах, спільному доменному знанні та неформальних домовленостях.
Розробник може помітити суперечність, поставити уточнювальне питання або попросити БА пояснити намір. Частину недосконалості вимог команда компенсує безпосередньо під час реалізації.
Рівень 1 може трохи прискорити розробку, але для БА це поки кількісна, а не якісна зміна.
Головний ризик
На цих рівнях легко ототожнити цінність БА з написанням документації, створенням та описом завдань у Jira, підтримкою беклогу (backlog) і передаванням інформації між людьми.
Поки процес постачання залишається переважно людським, така модель ще може працювати. На наступних рівнях значна частина цієї діяльності починає автоматизуватися.
Рівень 2 — розробник працює з ШІ як із постійним колегою
БА все ще працює у традиційному процесі постачання разом із командою розробки. Але вперше виникає системна проблема: швидкість реалізації може зростати швидше, ніж здатність організації формувати й підтверджувати бізнес-рішення.
ШІ прискорює не лише написання коду. Він також дозволяє значно швидше обробляти матеріали передпроєктного дослідження, створювати й оновлювати специфікацію, знаходити прогалини та підтримувати узгодженість артефактів. Водночас він не робить автоматично швидшими доступ до стейкхолдерів, погодження між підрозділами, визначення пріоритетів, юридичні та регуляторні рішення, роботу з конфліктами й розуміння складної доменної логіки.
Тому на цьому рівні БА має перейти від епізодичного використання ШІ до повторюваної операційної моделі:
від разових запитів — до перевірених промптів (prompts), скіллів (skills) і проєктних інструкцій (project instructions);
від окремих завдань з підтримкою ШІ (AI-assisted tasks) — до робочих процесів (workflows), у яких система послідовно обробляє джерела, витягує правила й рішення, оновлює артефакти, виконує перевірки та готує наступні питання;
від особистих експериментів — до стандартизованих командних практик.
Новизна не в тому, що ШІ може створити чернетку вимог. Це було можливо й раніше. Зміна полягає в тому, що весь повторюваний цикл — від обробки джерел до оновлення специфікації та перевірки її узгодженості — можна виконувати значно швидше й частково автоматично.
Насамперед це стосується:
підготовки й обробки матеріалів передпроєктного дослідження;
структурування нотаток і транскриптів;
формування та актуалізації моделей, вимог, бізнес-правил і критеріїв приймання;
пошуку прогалин і суперечностей;
підтримки простежуваності (traceability);
підготовки уточнювальних питань;
синхронізації пов’язаних артефактів.
На рівні відділу/офісу бізнес-аналізу (BA Office) наступний крок — не просто рекомендувати окремі інструменти, а розробляти, тестувати й поширювати перевірені робочі процеси, скілли, шаблони та правила перевірки результату. Використання ШІ має ставати частиною звичайного БА-процесу, а не набором персональних прийомів окремих аналітиків.
У термінах агентних систем таку сукупність інструкцій, скіллів, робочих процесів, контексту та механізмів перевірки можна розглядати як harness — керувальне середовище, що визначає, як модель отримує контекст, використовує інструменти та перевіряє результат.
Що структурно змінюється
БА стає одним із чинників, які не дозволяють прискореній розробці зупинитися через нестачу готового контексту та несвоєчасні бізнес-рішення.
Від нього дедалі більше вимагається:
раніше виявляти відкриті питання й залежності;
завчасно ескалювати необхідні бізнес-рішення;
підтримувати достатній обсяг готового контексту;
декомпозувати роботу на незалежні частини;
працювати коротшими циклами зворотного зв’язку;
автоматизувати повторювані аналітичні операції.
Основний ризик рівня 2 полягає не в тому, що БА працює недостатньо добре, а в тому, що його операційна модель може залишатися розрахованою на повільнішу розробку. Якщо аналіз і підготовка специфікації залишаються переважно ручними, вузьке місце поступово переміщується від виробництва коду до створення достатньої визначеності бізнес-наміру.
Рівень 3 — ШІ виконує значну частину розробки, людина залишається в контурі контролю
Як працює розробка
На рівні 3 ШІ перебирає значну частину роботи, яку раніше виконував досвідчений розробник.
Людина більше не є єдиним або основним виробником коду. Вона запускає агентів розробки (coding agents), контролює їхню роботу та переглядає створені зміни.
Інженер стає оркестратором агентної роботи й залишається в контурі контролю.
Агенти можуть паралельно створювати значні частини функціональності, а людина перевіряє плани, зміни, тести та кінцевий результат.
Роль БА
БА тепер працює із системою, яка швидко перетворює отриманий контекст на код, тести, API, інтеграції та документацію. Тому неточність або непогоджене припущення також можуть масштабуватися одночасно на кілька частин рішення.
Зростає відповідальність БА не лише за загальну бізнесову логіку, а й за критичні деталі поведінки системи, які раніше часто уточнювалися безпосередньо під час реалізації:
бізнес-правила та винятки;
стани й переходи;
права доступу;
помилки та сценарії відмов;
часткове виконання, повторні операції й тайм-аути;
поведінка системи в неоднозначних ситуаціях;
деталі, що визначають очікуваний користувацький досвід;
критерії правильності результату.
БА не повинен самостійно визначати кожну технічну деталь. Але він має забезпечити, щоб критична бізнесова поведінка не залишалася на випадкову інтерпретацію агентів.
Що структурно змінюється
Менше супроводу реалізації, більше підготовки контексту
Агенти розробки не потребують постійних усних пояснень під час написання коду. Тому БА менше супроводжує кожен окремий крок реалізації й більше працює до запуску агентів: узгоджує критичні рішення, формалізує правила, виявляє прогалини та визначає межі допустимої поведінки.
Співпраця з інженерною командою не зникає. Навпаки, складні питання, обмеження й ризики потрібно опрацьовувати раніше, щоб не виявити після генерації значного обсягу функціональності, що агенти працювали з різними трактуваннями однієї вимоги.
Вища ціна неоднозначності
Людина-розробник може помітити дивну вимогу, поставити питання або використати доменну інтуїцію. Агентна система здатна послідовно реалізувати неправильне припущення в коді, тестах, документації, API та кількох компонентах одночасно.
Саме через це мій попередній скептицизм щодо мультиагентних систем поступово змінився. Проблема не лише в тому, що неточності на окремих кроках можуть множитися. Вона ставить перед командою практичний вибір: або підвищувати точність і узгодженість вхідного контексту, або свідомо приймати ризик, створений його прогалинами й неоднозначністю.
Це не означає, що всі питання мають бути закриті до реалізації. Але невідомі факти, припущення, відкриті рішення та пов’язані з ними ризики повинні бути позначені явно.
Паралельність потребує спільної семантики
Кілька агентів можуть створити локально правильні частини рішення, які глобально суперечать одна одній.
Тому бізнес-аналітик або керівник продукту разом з інженерною командою мають підтримувати спільне трактування доменних понять, сутностей, статусів, правил, обмежень і погоджених припущень. Важливо не лише надати кожному агенту достатній контекст для його завдання, а й забезпечити узгодженість контексту між паралельними потоками роботи.
Користувацький досвід також стає частиною контексту
Функціонально правильна реалізація ще не гарантує правильного користувацького досвіду. Агентам потрібно передавати не лише сценарій, а й очікувану поведінку інтерфейсу: що бачить користувач, який зворотний зв’язок отримує, які дії доступні, що відбувається під час помилки, очікування або часткового виконання.
Якщо в команді зберігається окрема роль продуктового або UX (UX — користувацький досвід) дизайнера, БА допомагає підтримувати двосторонній зв’язок між дизайном і агентною реалізацією. Рішення щодо UX, брендингу, стилістики та моделей взаємодії мають потрапляти в контекст для агентів, а згенеровані варіанти й реалізована поведінка — повертатися дизайнеру для перевірки.
Перевірка правильності стає важливішою
Коли виробництво коду прискорюється, ключове питання зміщується від «чи можемо ми це реалізувати?» до «як довести, що система реалізувала саме те, що було погоджено?»
БА робить внесок у:
визначення бізнесових сценаріїв;
межі прийнятного результату;
негативні й альтернативні випадки;
очікувані наслідки;
зв’язок між погодженими рішеннями, вимогами та реалізованою поведінкою;
бізнесову перевірку рішення.
Контекст, готовий для агентів
На рівні 3 опису окремого елемента списку завдань (backlog item) з вимогами щодо нього часто вже недостатньо. Агентам потрібен цілісний контекст: бізнесова мета, обсяг і межі рішення, доменні поняття, правила, стани, критичні сценарії, обмеження, підтверджені рішення, явно позначені припущення та критерії правильності.
Такий контекст має проходити контрольні точки: ключові терміни визначені, критичні правила підтверджені, суперечності виявлені, результат можна перевірити, а припущення не замасковані під факти.
Це ще не повна специфікація як вхідний інтерфейс автономного циклу розробки програмного забезпечення (Software Development Life Cycle, SDLC) — до цього переходимо на рівні 4. Але вже на рівні 3 БА має навчитися працювати з контекстом як із системою, а не як із набором окремих користувацьких історій і документів.
Головний ризик
Якщо БА продовжить оцінювати свою продуктивність кількістю написаних користувацьких історій, він програє швидкості агентної системи.
Його цінність тепер не в тому, щоб виробляти більше тексту. Вона полягає в тому, щоб зменшувати ймовірність швидкого створення неправильного, суперечливого або неприйнятного для користувача рішення.
Рівень 4 — інженер більше не є розробником
Рівень 4 — ключова точка моделі.
Шапіро описує інженера, який уже не є розробником у традиційному сенсі. Він працює зі специфікацією, обговорює її з ШІ, формує або перевіряє план реалізації, налаштовує повторно використовувані скілли, запускає агентну систему й пізніше оцінює результат.
Безпосереднє написання коду перестає бути основною діяльністю людини. Значна частина циклу — планування, декомпозиція, реалізація та тестування — може виконуватися агентами автономно.
Людина дедалі більше визначає, що система повинна створити, у яких межах вона може діяти та як перевірити отриманий результат.
Шапіро жартівливо називає цю людину PM, залишаючи відкритим, чи йдеться про Product Manager, Project Manager або Program Manager.
Чому рівень 4 є критичним для БА
До рівня 3 ШІ передусім змінював спосіб виробництва коду. На рівні 4 інженер виходить із шару написання коду й починає працювати зі специфікацією, постановкою завдання, планами, критеріями успіху та оркестрацією автономної реалізації.
Ця діяльність безпосередньо перетинається із зонами відповідальності бізнес-аналітика, продуктових ролей, архітектора рішень (Solution Architect) та управління проєктами (Project Management).
Тому головне питання звучить уже не так:
Чи потрібні вимоги, якщо код пишуть агенти?
А так:
Хто має повноваження приймати бізнес-рішення і хто забезпечує цілісність специфікації, яка запускає автономну реалізацію?
Ці відповідальності можуть належати різним ролям.
Бізнес-рішення та цілісність специфікації
Формальний мандат щодо напряму продукту, пріоритетів, цінності, допустимих компромісів і прийняття ризику зазвичай належить продуктовій ролі або відповідальному представнику бізнесу (business owner).
БА при цьому може досліджувати проблему, готувати й оцінювати варіанти рішень, фасилітувати вибір, формувати рекомендації та приймати окремі рішення в межах делегованого мандата.
Критично, щоб було зрозуміло, хто готує рішення, хто має право його затвердити і хто відповідає за пов’язані ризики.
Окремою зоною відповідальності БА може стати цілісність бізнесового контексту та специфікації:
повнота й внутрішня узгодженість;
спільна доменна семантика;
простежуваність погоджених рішень;
явне розмежування фактів, припущень і відкритих питань;
зафіксовані обмеження та винятки;
придатність до реалізації й перевірки.
Тобто БА не обов’язково має мандат на всі бізнес-рішення, але може забезпечувати, щоб вони були достатньо обґрунтовані, правильно представлені у специфікації та не втрачалися під час автономної реалізації.
Від вимог до специфікації, готової до агентної розробки
На рівні 4 недостатньо написати користувацькі історії й передати їх команді.
Специфікація стає вхідним інтерфейсом автономного циклу розробки. Вона має бути організована так, щоб агентна система могла перейти від бізнес-наміру до планування й реалізації без постійної компенсації прогалин усними поясненнями.
Одним із практичних форматів для такого підходу може бути структурований Markdown-файл (.md), версіонований разом із проєктом. Наприклад:
requirements.md — бізнес-намір, обсяг і межі рішення, правила, сценарії, обмеження та критерії правильності;
plan.md — технічний план реалізації;
tasks.md — декомпозиція роботи;
файл контексту проєктного рівня на кшталт AGENTS.md або CLAUDE.md — постійні правила та інструкції для агентів.
Назви файлів не є принциповими. Важливіше, щоб різні шари контексту мали зрозуміле призначення, власників і правила оновлення.
БА та продуктова роль передусім працюють із бізнесовим і користувацьким контекстом. Інженерна команда формує технічний план, архітектурні рішення, правила роботи з кодовою базою та технічні механізми перевірки.
Там, де це потрібно, специфікацію доповнюють машинно перевірюваними артефактами — OpenAPI-контрактами, схемами даних, моделями станів, тестовими даними або автоматизованими приймальними тестами, — які роблять окремі частини специфікації формально перевірюваними, але не замінюють опис бізнес-наміру, правил і контексту.
Для автономного циклу специфікація має явно розрізняти підтверджені рішення, припущення, відкриті питання, обмеження та ситуації, у яких потрібна ескалація до людей. Також мають бути визначені критичні основні, альтернативні й негативні сценарії та критерії правильності результату.
Важлива не абсолютна завершеність специфікації, а її достатність для конкретного автономного циклу без прихованих прогалин, які агенти будуть змушені заповнювати власними припущеннями.
Інженерія контексту (context engineering) на цьому рівні переходить в інженерію специфікації (specification engineering): бізнесовий і технічний контекст потрібно організувати як узгоджений вхід для планування, декомпозиції, реалізації та перевірки агентною системою.
Інженерія контексту стає спільною дисципліною
Межа між БА та інженерною функцією тут може здаватися розмитою, оскільки обидві працюють із контекстом для агентів.
БА і продуктова роль формують бізнесовий та користувацький контекст: проблему, цілі, доменну семантику, правила, рішення й критерії правильності.
Інженерна команда формує технічний контекст: архітектуру, межі компонентів, кодову базу, API, стандарти, інструменти й технічні обмеження.
Агенти працюють на перетині цих двох шарів.
Роль БА у планах, сформованих агентами
БА не повинен оцінювати технічну оптимальність плану замість відповідального за технічну частину (інженера чи архітектора).
Його експертиза стосується бізнесового покриття:
чи покрито погоджений обсяг і межі рішення;
чи не пропущено критичні сценарії;
чи не змінено доменну семантику;
чи враховано бізнесові залежності;
чи не з’явилися непогоджені припущення;
чи збережено критерії правильності.
Інженерна функція продовжує відповідати за архітектуру, технічну здійсненність, продуктивність, безпеку, підтримуваність та інші технічні характеристики рішення.
Три організаційні сценарії
Сценарій 1. БА забезпечує бізнесову частину специфікації
У складному домені інженер може ефективно управляти автономною реалізацією, але не мати достатньої доменної компетенції або мандата для визначення бізнесових правил і компромісів.
Тоді БА проводить передпроєктне дослідження, структурує бізнесовий контекст і забезпечує цілісність специфікації; продуктова роль або відповідальний представник бізнесу визначає пріоритети й затверджує критичні рішення; інженерна команда формує технічний підхід і план реалізації; агенти виконують значну частину реалізації та технічної перевірки.
Сценарій 2. БА та інженерна команда спільно формують специфікацію
Межа між бізнесовою потребою та способом її реалізації не завжди чітка. Бізнесові рішення можуть залежати від архітектурних обмежень, доступності даних, API, безпеки, продуктивності або вартості реалізації.
Тому БА та інженерна команда стають співавторами різних шарів однієї специфікації: БА фокусується на проблемі, домені, правилах і критеріях правильності, а інженерна команда — на здійсненності, архітектурі, технічних обмеженнях і плані реалізації.
Для БА це означає роботу, менше зосереджену на документуванні, більш системну, ближчу до архітектури та значно залежнішу від технічної грамотності.
Сценарій 3. Обов’язки БА поглинаються іншою роллю
Окрема БА-позиція може бути непотрібною, якщо керівник продукту, засновник бізнесу або інша роль здатна самостійно проводити передпроєктне дослідження, працювати з доменом і стейкхолдерами, формалізувати правила та обмеження, підтримувати цілісність специфікації й оцінювати результат.
Це особливо ймовірно в невеликих продуктових командах і простіших доменах.
У такій ситуації зникає не бізнес-аналіз. Його функцію просто виконує інша роль.
Головний ризик
Рівень 4 уже не гарантує збереження окремої БА-ролі. Якщо її основна цінність полягає в оформленні користувацьких історій, перенесенні інформації до Jira, документуванні вже прийнятих рішень і підтримці беклогу, значна частина такої роботи може бути автоматизована або поглинута іншими ролями.
Сильніша позиція БА на рівні 4 — не контроль над документами, а відповідальність за цілісність бізнесового контексту та готовність специфікації до агентної реалізації.
Чим автономнішою стає реалізація, тим важливішим стає не те, хто написав вимоги, а хто забезпечив правильний бізнес-намір, достатній контекст і перевірювані межі для дії агентної системи.
Рівень 5 — Dark Factory
Як працює розробка
На рівні 5 процес створення програмного забезпечення стає чорною скринькою (black box), яка перетворює специфікацію на готове програмне забезпечення без необхідності постійної участі людини у внутрішньому виробничому циклі.
Назва Dark Factory не обов’язково означає непрозорість процесу міркування (reasoning). Це аналогія з повністю автоматизованим виробництвом, у якому світло більше не потрібне, оскільки всередині фабрики не працюють люди.
Усередині фабрики можуть бути автоматизовані:
декомпозиція;
планування;
вибір агентів та інструментів;
реалізація;
інтеграція;
тестування;
виправлення;
відновлення після помилок;
повторні запуски;
розгортання;
моніторинг.
Точна внутрішня архітектура рівня 5 у Шапіро не деталізована. Тому подальше
розмежування рівня 4 і рівня 5 частково є інтерпретацією формули «specifications into software».
Різниця між рівнем 4 і рівнем 5
На рівні 4 людина все ще керує окремим автономним циклом: формує специфікацію, обговорює її з ШІ, переглядає план, запускає агентів і повертається до тестів та результату.
На рівні 5 людина більше не керує виконанням кожного такого циклу. Специфікація передається фабриці, а система самостійно визначає, як організувати роботу й отримати готове рішення.
Отже, різниця полягає не лише в обсязі коду, який створює ШІ:
на рівні 4 людина управляє автономною реалізацією;
на рівні 5 автономна система управляє реалізацією сама.
Людина при цьому може залишатися:
перед фабрикою — визначаючи проблему, бізнес-намір і специфікацію;
після фабрики — оцінюючи правильність, цінність і наслідки результату;
над фабрикою — визначаючи правила управління та контролю (governance), політики, допустимі ризики та межі автономності.
Що відбувається з БА
Традиційний БА у процесі постачання на цьому рівні може втратити значну частину своїх функцій.
У Dark Factory немає звичайної команди розробки, для якої потрібно готувати беклог і користувацькі історії в Jira, проводити уточнення беклогу, пояснювати вимоги розробникам, відповідати на дрібні питання реалізації та вручну синхронізувати вимоги, код і тести.
Якщо зникає традиційний процес постачання, разом із ним зникає і частина БА-ролі, побудована навколо його обслуговування.
Але бізнес-аналіз не зникає автоматично. До запуску фабрики все одно потрібно визначити проблему, контекст, бажаний результат, допустимі компроміси, обмеження та критерії успіху. Після отримання результату — перевірити, чи задоволена реальна потреба, чи створена очікувана цінність і чи не виникли неприйнятні наслідки.
Тому на рівні 5 особливо важливо розділяти бізнес-аналітика як окрему роль у процесі постачання і бізнес-аналіз як діяльність. Перша справді може суттєво скоротитися. Друга залишається необхідною до фабрики, після неї та на рівні управління й контролю.
Рівні 5A і 5B далі — моя авторська екстраполяція моделі Шапіро: вони розділяють різні можливі межі автономності між бізнес-намірами, специфікацією та реалізацією.
Рівень 5A — Specification-to-Software Factory
Це варіант, найближчий до буквального визначення Шапіро.
Люди залишаються відповідальними за передпроєктне дослідження, роботу зі стейкхолдерами, бізнесові рішення та формування підтвердженої специфікації. Після цього специфікація передається в Dark Factory, яка самостійно виконує технічне планування, реалізацію, інтеграцію, тестування та інші інженерні операції, необхідні для отримання працюючого рішення.
У такій моделі межа автономності проходить між специфікацією та реалізацією:
до цієї межі люди визначають, що потрібно створити, навіщо, у яких межах і як оцінити результат;
після неї фабрика самостійно визначає, як технічно створити рішення.
Для БА це принципова зміна. Бізнес-аналіз більше не знаходиться всередині фабрики як частина традиційного процесу постачання. Основна робота відбувається до її запуску — у передпроєктному дослідженні, роботі з бізнесовим контекстом, підготовці рішень і формуванні специфікації — та після отримання результату, коли потрібно перевірити його відповідність початковому бізнес-наміру.
Але автономність внутрішнього виробництва ще не означає, що взаємодія бізнесу з фабрикою також стає безшовною. Взаємодія з такими підходами та агентними середовищами все ще може вимагати від користувача суттєвої технічної грамотності. Спонсору проєкту, доменному експерту або менеджеру високого рівня може бути складно безпосередньо керувати специфікацією, агентними робочими процесами, контекстними файлами, ескалаціями та результатами окремих циклів.
Тому між бізнесом і Dark Factory може залишитися окрема функція оркестрації:
організовувати взаємодію бізнесу з агентною системою;
перетворювати бізнесові формулювання на структурований вхід для фабрики;
спрямовувати запитання й ескалації до людей із відповідним мандатом;
забезпечувати своєчасне підтвердження рішень;
повертати плани, ризики та результати у формі, зрозумілій нетехнічним стейкхолдерам;
підтримувати зв’язок між початковим наміром, специфікацією та створеним рішенням.
Цю функцію може виконувати БА, продуктова роль, інша роль, що безпосередньо взаємодіє з бізнесом, або спеціалізований агент під людським контролем. Для бізнес-аналітика це один із можливих шляхів трансформації: не залишатися постійним посередником між бізнесом і командою розробки, а оркеструвати взаємодію бізнесу з автономною фабрикою.
Рівень 5B — Intent-to-Software Factory
Логічним продовженням рівня 5A є розширення автономності від реалізації в бік передпроєктного дослідження та бізнес-аналізу.
На рівні 5A люди формують і підтверджують специфікацію, після чого Dark Factory перетворює її на працююче рішення. На рівні 5B початковим входом може стати вже не готова специфікація, а бізнесова проблема, потреба або бажаний результат.
Наприклад, бізнес може сформулювати запит так:
Скоротити час обробки страхового звернення з кількох днів до кількох годин, не збільшуючи операційний ризик і не порушуючи регуляторних вимог.
Щоб перетворити такий намір на програмне забезпечення, агентній системі недостатньо просто згенерувати інтерфейс або автоматизувати поточний робочий процес. Вона повинна:
дослідити наявний процес;
визначити учасників і джерела даних;
виявити бізнес-правила, регуляторні обмеження та винятки;
знайти причини затримок;
сформувати варіанти майбутнього процесу;
погодити допустимі компроміси;
визначити критерії успіху;
сформувати специфікацію;
реалізувати й перевірити рішення.
Частину цієї роботи, яку сьогодні виконує бізнес-аналітик, можуть перебрати агенти бізнес-аналізу (Business Analyst agents). Вони можуть аналізувати документи й дані, працювати зі стейкхолдерами, ставити уточнювальні питання, будувати доменну модель, знаходити суперечності та прогалини, відокремлювати факти від припущень і поступово формувати специфікацію для агентної розробки.
На практиці таке передпроєктне дослідження можна організувати як структурований агентний процес — із визначеними етапами, ролями агентів, очікуваними артефактами та контрольними точками, у яких система за визначеними правилами продовжує роботу автономно або ескалює питання людині.
Представником бізнесу в такій взаємодії не обов’язково є Product Manager або спонсор проєкту. Ним може бути внутрішній бізнес-аналітик (in-house Business Analyst) на стороні бізнесу, доменний експерт, власник процесу (process owner) або інша людина, яка має достатній контекст і мандат залучати потрібних зацікавлених сторін.
Така людина може:
сформулювати проблему й бажаний результат;
надавати доменний контекст;
відповідати на запитання агентів;
підтверджувати факти й припущення;
залучати власників критичних рішень;
погоджувати специфікацію та оцінювати результат.
Важливо, що агентна система може готувати рішення, але не повинна самостійно привласнювати собі бізнесовий мандат. Вибір пріоритетів, прийняття ризиків, затвердження критичних компромісів і легітимізація змін залишаються відповідальністю уповноважених людей.
Хто перевіряє результат Dark Factory
Навіть на рівні 5, де спонсору теоретично вже не потрібна традиційна команда розробки, хтось усе одно повинен перевірити створене рішення.
Іронія полягає в тому, що автоматизація виробництва програмного забезпечення не обов’язково спрощує його бізнесову валідацію. Фабрика може за короткий час створити великий продукт із багатьма процесами, ролями, правилами, інтеграціями та сценаріями. Одна людина навряд чи завжди матиме достатню експертизу й пропускну здатність, щоб самостійно перевірити весь результат.
Тому спонсору або відповідальному представнику бізнесу можуть знадобитися:
доменні експерти;
представники користувачів;
власники окремих процесів;
фахівці з юридичних питань, відповідності регуляторним вимогам, безпеки або операційної діяльності;
бізнес-аналітик, який координує бізнесову перевірку;
спеціалізовані агенти перевірки, які перевіряють результат за різними моделями, правилами та критеріями.
Це вже не традиційна команда реалізації. Її функція полягає не у виробництві програмного забезпечення, а в незалежній перевірці того, що автономна фабрика створила прийнятне рішення.
Дві незалежні перевірки якості
Будь-яка агентна система, що рухається від бізнес-наміру до готового програмного забезпечення, повинна пройти дві різні перевірки.
Правильність наміру
Чи правильно система:
зрозуміла проблему;
визначила потреби й бажаний результат;
відтворила бізнес-правила та обмеження;
залучила потрібних стейкхолдерів;
відобразила погоджені рішення;
не перетворила припущення на факти?
Правильність реалізації
Чи правильно система:
реалізувала підтверджену специфікацію;
покрила потрібні сценарії;
дотрималася обмежень та інваріантів;
забезпечила необхідні технічні характеристики;
пройшла визначені перевірки й тести?
Можна бездоганно реалізувати неправильний задум. І навпаки — правильно зрозуміти потребу, але невдало її реалізувати.
Тому автоматизація інженерної функції не усуває бізнес-аналіз. Вона робить критичнішими формування правильного наміру, людське підтвердження ключових рішень і незалежну перевірку того, що створене рішення справді відповідає бізнесовій потребі.
Що розвивати бізнес-аналітику на кожному рівні
Наступні рівні не скасовують попередніх компетенцій. БА на рівні 4 або 5 усе ще має вміти проводити дослідження, працювати із зацікавленими сторонами, розуміти домен, формалізувати правила та перевіряти результат.
Але зростання автономності інженерної функції поступово підвищує вимоги до того, як саме ці компетенції застосовуються:
спочатку БА має прискорити власну роботу за допомогою ШІ;
далі — перетворити окремі прийоми на повторювані робочі процеси;
потім — навчитися управляти контекстом для агентів;
створювати специфікацію як вхід для автономного SDLC;
зрештою — оркеструвати бізнес-аналіз і перевіряти результат автономної системи.
Рівні 0–1 — традиційний БА з ШІ-грамотністю
На цих рівнях БА варто навчитися:
чітко формулювати завдання для ШІ та надавати достатній контекст;
використовувати ШІ для структурування матеріалів, підготовки підсумків, чернеток, пошуку прогалин і трансформації інформації;
критично перевіряти відповіді;
відрізняти підтверджені факти від згенерованих припущень;
розуміти, які завдання можна делегувати ШІ, а де потрібне професійне судження.
Практичний орієнтир: обрати три повторювані БА-завдання, налаштувати для них перевірені способи роботи з ШІ та на кількох реальних кейсах порівняти час виконання і якість результату з повністю ручним підходом. Рівень 2 — бізнес-аналіз із підтримкою ШІ
На цьому рівні бізнес-аналітику потрібно розвивати:
створення повторно використовуваних промптів, скіллів і проєктних інструкцій;
проєктування послідовних робочих процесів із підтримкою ШІ (AI-powered workflows);
автоматизацію обробки матеріалів передпроєктного дослідження та оновлення артефактів;
налаштування перевірок повноти, узгодженості й суперечностей;
стандартизацію практик використання ШІ для команди або відділу бізнес-аналізу.
Практичний орієнтир: автоматизувати один повторюваний БА-процес повністю — від отримання джерел до оновлення артефактів і підготовки наступних питань.
Рівень 3 — інженерія контексту
До попередніх навичок додається вміння управляти контекстом як системою.
БА варто навчитися:
створювати спільний словник, доменну модель і моделі станів;
розділяти факти, рішення, припущення та відкриті питання;
визначати, який контекст потрібен конкретному агенту для конкретного завдання;
підтримувати журнал рішень і джерела ключових правил;
знаходити суперечності між результатами паралельних агентів;
проєктувати перевірки узгодженості контексту.
Практичний орієнтир: підготувати пакет контексту, готовий для агентів (agent-ready context pack), для однієї функції та перевірити, чи два незалежні агенти однаково трактують її правила, стани й обмеження.
Рівень 4 — інженерія специфікації
На цьому рівні БА має навчитися перетворювати бізнес-намір на специфікацію, придатну для передачі мультиагентній системі розробки.
Нові навички:
робота з підходами до розробки на основі специфікацій та адаптація їхнього рівня вимог;
створення структурованих і версіонованих специфікацій, зокрема у форматі Markdown;
формалізація інваріантів, сценаріїв відмов, граничних випадків (edge cases) і умов людської ескалації;
доповнення вимог машинно перевірюваними контрактами, схемами й приймальними тестами;
перевірка планів, сформованих агентами, з погляду бізнесового покриття;
оркестрація генерації, перевірки та синхронізації різних частин специфікації;
достатнє розуміння агентного циклу розробки (agentic SDLC), API, даних та інтеграцій, щоб бачити втрату бізнесового наміру в технічному плані.
На практиці це означає перехід від звичайного ШІ-помічника (AI assistant) до середовищ, побудованих навколо ШІ (AI-native environments), у яких БА може налаштовувати скілли, проєктні інструкції і власний процес роботи зі специфікацією.
Практичний орієнтир: для однієї функції підготувати цілісну специфікацію, передати її агентній системі без додаткових усних пояснень і перевірити, чи сформований план реалізації покриває всі погоджені сценарії, бізнес-правила, обмеження та критерії правильності без появи непогоджених припущень.
Рівень 5 — за межами традиційного процесу постачання
На рівні 5 БА розвиває вже не стільки навички створення вимог, скільки здатність проєктувати й контролювати систему, яка виконує бізнес-аналіз і створює рішення.
Нові компетенції:
проєктування агентного передпроєктного дослідження (agentic discovery) та робочого процесу БА;
визначення ролей агентів, етапів, передавань між агентами (handoffs) і контрольних точок;
розмежування рішень, які може підготувати система, і рішень, що потребують людського мандата;
організація комунікації між нетехнічним бізнесом і Dark Factory;
встановлення правил управління й контролю, меж автономності та допустимого ризику;
координація незалежної бізнесової валідації;
залучення доменних експертів, фахівців із юридичних питань, регуляторної відповідності, безпеки та представників користувачів до перевірки;
оцінювання не лише відповідності специфікації, а й того, чи вирішує результат початкову проблему.
БА тут може створювати скілли й методологію для агентів бізнес-аналізу, адаптувати агентні робочі процеси (agentic workflows) до процесів компанії та контролювати, як система переходить від проблеми до специфікації й готового рішення.
Практичний орієнтир: спроєктувати невеликий робочий процес від бізнес-наміру до специфікації (intent-to-specification workflow) із визначеними агентними ролями, щонайменше однією точкою, у якій рішення приймає людина, та незалежною перевіркою кінцевої специфікації.
Висновок
Зі зростанням автономності інженерної функції людина поступово виходить із безпосереднього виробництва програмного забезпечення. Для бізнес-аналітика це означає не просто ширше використання ШІ або менше ручної роботи, а зміну точки, у якій бізнес-аналіз створює цінність.
Дедалі менше цінності залишається в ручному створенні артефактів вимог, перенесенні інформації між інструментами та супроводі кожного кроку процесу реалізації. Дедалі більше — у здатності:
зрозуміти складну бізнесову реальність;
забезпечити цілісність контексту та специфікації;
визначити межі автономності;
організувати рішення, що потребують участі людини, та ескалації;
перевірити, що система створила правильне рішення для правильної проблеми.
ШІ не обов’язково знищить бізнес-аналіз. Але він може виключити бізнес-аналітика як окрему роль у процесі реалізації, якщо ця роль не має власної відповідальності за межами підготовки й передавання вимог.
Майбутнє бізнес-аналізу — у переході від документування того, що люди мають створити, до забезпечення бізнесової визначеності, на основі якої люди або машини можуть створити й перевірити правильне рішення.
А на якому рівні сьогодні перебуває ваша ІТ-команда — і чи готовий ваш бізнес-аналіз до наступного?
Від редакції: Якщо хочете поглибити свої БА навички щодо використання AI, зверніть увагу на
Новини та статті з бізнес-аналізу:
