AI workspace для команди Бізнес-Аналітиків: мій досвід впровадження

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Навіщо я взявся за AI-адопшн BA-процесів

Моя роль — технічний delivery-менеджер у компанії EPAM. Я активно адвокатую AI-практики на проєкті, і в один прекрасний день вирішив зайнятися AI-адопшном процесів бізнес-аналізу.

Почати я вирішив із впровадження AI-friendly User Story — формату вимог, який підтримує AI-native SDLC workflow.

Розглянемо детально, що я називаю AI-native User Story, для яких цілей вона потрібна та які проблеми вирішує. Почнемо із загальних принципів AI-native workflow.

Класична User Story (текст, таблиці, зображення) трансформується в AI-native формат — зі списком acceptance criteria та out-of-scope, — який споживають агенти розробки й тестування.

Проблема класичного User Story для AI-агентів

У нас уже був певний досвід написання агентів розробки та агентів тестування, які напряму читали інформацію про вимоги (User Story) — у нашому випадку з Confluence. Типовий контент вимог — це текст, таблиці та скриншоти екранних форм із детальними UI/UX-посиланнями на Figma.

Такий вигляд представлення вимог зручний для людини, але натикається на ряд проблем при взаємодії з AI-агентами. Наприклад, мені хотілося мати чітку traceability на конкретний requirement, який імплементував або тестував агент.

Щоб якість написання вимог бізнес-аналітиком (наскільки чітко аналітик формулює acceptance criteria тощо) не ламала traceability, мені потрібен був чіткий ID для кожного AC.

Також відповідальність за вимоги має залишатися на стороні бізнес-аналітика, а не переноситися в логіку парсингу вимог агентами, написаними розробниками. Звідси й виникла задача — написати AI-агента для аналітиків, який вирішує задачу підготовки AI-native User Story за оригінальним описом із Confluence.

Ми не відмовляємося від Confluence як master-системи зберігання та управління вимогами — ми доповнюємо її новим артефактом.

Нижче фінальний результат створення AI-native User Story від нашого BA-агента.

AI-native User Story, згенерована агентом за оригінальним описом вимог на Confluence-сторінці: High-Level Overview, Why/What, таблиця Acceptance Criteria з ID для кожного AC та таблиця Out of Scope.

Організація AI workspace для аналітиків

Існує цілий зоопарк рішень для організації AI-простору для інженера чи нетехнічного співробітника — AI-скіли, плагіни, розширення в IDE тощо.

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

Весь AI-простір аналітика — це звичайна папка на диску. Агенти — Markdown-файли з system prompt, а навколо них зібраний контекст: конфіг, командні модулі, пам’ять і дані про вимоги.

Така проста організація дозволяє запускати AI BA-агентів із будь-якого harness’у — будь то Claude Code, MS Copilot чи AI-плагін в IDE.

Ось як виглядає ця структура.

Структура aiworkspace: агенти, командні модулі, конфіг, контекст «по запиту» і поведінкові правила — все звичайні файли й папки.

Що відбувається «під капотом»: флоу аналітика

Розгляньмо, як аналітик збирає AI-native User Story, працюючи в AI BA workspace. Увесь шлях — від запуску агента до готового артефакту — складається з кількох простих кроків.

1. Запуск агента й завантаження контексту

Аналітик запускає AI-асистента в корені workspace і дає йому system prompt BA-агента. На старті агент сам послідовно підвантажує контекст проєкту: глосарій акронімів, карту архітектури, FRD (Functional Requirements Document), SDD (Solution Design Document) і project-wide контекст. Аналітику не треба робити нічого — він лише спостерігає за прогресом.

2. Введення номера User Story

Завершивши завантаження, агент запитує Page ID — цифри з URL Confluence-сторінки потрібної User Story. Агент завантажує саму сторінку з усіма вкладеннями та описує зображення (скриншоти екранних форм). Поки Page ID не введено, агент далі не йде.

3. Команда ac compose

Тепер аналітик вводить команду ac compose. Агент проходить три фази поспіль, без зупинок:

• AC Composition — формує атомарні Acceptance Criteria у форматі Given / When / Then з унікальними ID, спираючись лише на текст сторінки вимог і скриншоти (текст має пріоритет над зображеннями).
• OOS Composition — складає список Out of Scope: що система свідомо не робить, із посиланням на джерело.
• Coverage Double-Check — двостороння перевірка: кожна вимога покрита хоча б одним AC, і кожен AC має простежуване джерело на сторінці. Пропущене додається автоматично.

4. Звіт від агента

На виході аналітик отримує готовий список AC та OOS, а також підсумок: скільки критеріїв перевірено, які прогалини знайдено й що було дописано. Завершує звіт Handover Verdict — однозначний вердикт про готовність передати вимоги розробникам:

• 🟢 READY — усе покрито, можна віддавати в розробку;
• 🟡 READY WITH CAVEATS — прогалини закрито автоматично, варто переглянути доповнення;
• 🔴 NOT READY — лишилися теги [NEEDS CLARIFICATION], автор має їх вирішити перед передачею.

Які use-кейси вже доступні аналітикам

Розгляньмо use-кейси, які аналітики вже зараз можуть виконувати в AI BA workspace.

Типові use cases, які закриває AI BA-агент: від першого аналізу нової User Story до підготовки рефайнменту, оцінки та внесення рішень назад у Confluence.

Як розширювати AI-функціонал новими типами аналітики

Функціонал AI BA workspace розширюється командами. Кожна команда — це звичайний Markdown-файл у папці ba/. Так уже зроблені базові команди: validate req (перевірка вимог), ac compose (формування AC та OOS), estimate (оцінка трудовитрат) і refinement (скрипт для рефайнменту).

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

Щоб додати власну команду під свою роботу, аналітику достатньо створити новий Markdown-файл у ba/ і описати в ньому звичайною мовою:

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

Висновки

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

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