Використання Claude в роботі бізнес-аналітика на корпоративному проєкті
- Gleb Bryskin
- 15 годин тому
- Читати 7 хв
На корпоративному проєкті налаштування ШІ допомагає бізнес-аналітикам збирати вимоги, декомпозувати їх на user stories, додавати критерії прийняття та багато іншого. В цій статті ми поділимося нашим досвідом та розповімо про налаштування ШІ, яке заощаджує наш час і зусилля.
АВТОРИ: ГЛІБ БРИКСІН ТА АНАСТАСІЯ ЄВСТРАТОВА
Поверхневе використання ШІ
ШІ існує вже певний час і довів свою надзвичайну корисність для ІТ-команд. Однак, як на багатьох інших проєктах, використання інструментів ШІ в нашій команді було непослідовним: розробники, QA-інженери та бізнес-аналітики використовували штучний інтелект автономно, не маючи спільної бази знань чи єдиного набору інструментів.
На перший погляд це не проблема, але насправді це зовсім не так. Не маючи уніфікованого підходу, команда використовувала ШІ значно менш ефективно. Ми, як бізнес-аналітики, продовжували стикатися зі звичними проблемами: постійне розширення обсягу робіт (scope creep), розмивання вимог, повністю ручне створення тікетів тощо, тоді як ШІ використовувався для запитів і консультування.
Тому на проєкті основним завданням було виправити це, але не шляхом створення окремого налаштування ШІ лише для бізнес-аналітиків, а за допомогою комплексного рішення, яке використовувала б уся команда.
Єдиний інструмент ШІ для всієї команди
Мета нашої команди полягала в тому, щоб налаштувати життєвий цикл розробки програмного забезпечення (SDLC) за підтримки ШІ, яким користувалася б уся команда: дизайнери, бізнес-аналітики, розробники та QA-інженери. Кожна команда використовувала б власного агента, спеціально адаптованого до її потреб, але заснованого на спільному контексті.
• Бізнес-аналітикам потрібен був набір інструментів для звернення до контексту проєкту (project context), декомпозиції фіч, підготовки вимог, створення тікетів тощо.
• Розробникам знадобився б набір інструментів, який допомагає з реалізацією та рев'ю коду.
• QA-інженери використовували б ШІ для створення тест-кейсів і запуску автоматизованих тестів.
• UI/UX-дизайнери могли б використовувати інструменти ШІ для прискорення прототипування.
Цінність полягала б у спільній базі знань (knowledge base), завдяки якій жодна user story, жоден фрагмент коду і жоден тест не суперечили б один одному.
Налаштування ШІ, яке ми створили для бізнес-аналітиків
Оскільки ця стаття присвячена бізнес-аналізу, ми опишемо лише ту частину налаштування AI SDLC, яку отримали бізнес-аналітики:
Розглянемо деталі:
workspace.py — єдине джерело істини (source of truth), яке генерує та валідує весь робочий простір.
Artisyn SDK керує спільним каталогом навичок (skills) для всієї команди.
BA-agent — інструмент на основі Claude, який викликає BA-навички, такі як ba-story-authoring, grooming, create-tasks та багато інших.
База знань є спільною для всієї команди і базується на кількох джерелах, таких як проєктна документація, Azure DevOps Wiki та база коду.
MCP-коннектори використовуються ba-agent для доступу до Azure DevOps і Figma.
Один агент, що виконує всю рутинну роботу бізнес-аналітика
Розглянемо ba-agent детальніше. Це помічник бізнес-аналітиків на нашому проєкті, побудований на основі Claude. Він приймає три типи вхідних даних:
• База знань
• Figma
• Azure DevOps
BA-agent виконує всю рутинну роботу бізнес-аналітика: обґрунтовує кожну user story на основі бази знань, аналізує інтерфейс користувача у Figma, аналізує фічі в Azure DevOps, декомпозує їх на user stories, готує вимоги у форматі INVEST-стор і безпосередньо записує їх в Azure DevOps. Розглянемо, як ми використовуємо ba-agent у щоденній роботі з бізнес-аналізу.
Клікабельні прототипи для збору вимог
Завдяки базі знань, ba-agent достатньо добре знає проєкт, щоб створювати клікабельні HTML-прототипи за кілька хвилин. Це виявилося потужним інструментом для сесій зі збору вимог зі стейкхолдерами, що допомагає зібрати фідбек, а також проводити брейнштормінг. Найкраще те, що клікабельні HTML-прототипи, створені Claude, допомагають бізнес-аналітикам і стейкхолдерам виявити те, чого не вистачає у початкових вимогах — сліпі зони та невисловлені вимоги, не згадані в жодному з документів.
Декомпозиція вимог на основі контексту
BA-agent може декомпозувати фічі на INVEST user stories за одним із паттернів: за дією користувача, за роллю, за даними, за платформою, тощо. Спочатку він створює карту user stories (user story map) для перевірки бізнес-аналітиком. На цьому етапі Claude ще не готує вимоги – він зробить це лише після того, як бізнес-аналітик підтвердить декомпозицію та за потреби внесе зміни.
Наприклад, якщо є запит на фічу, що дозволяє клієнтам з домашніми тваринами змінювати рейси, ba-agent може створити такі тікети:
Платформа | User story |
web | Change seats in booking with pet |
web | Change flights in booking with pet |
mob | Change seats in booking with pet |
mob | Change flights in booking with pet |
Фіча → карта user stories
Декомпозиція завжди потребує ретельного перегляду та підтвердження бізнес-аналітиком, перш ніж ba-agent переходить до автоматичного створення тікетів.
Гнучкий формат критеріїв прийняття (AC)
Наш ba-agent налаштований писати критерії прийняття у різних форматах — Gherkin-сценарії або критерії прийняття у форматі bullet point — залежно від уподобань команди. Перед підготовкою user stories Claude запитує, якого формату дотримуватися.
BULLET-POINT | GHERKIN |
Happy path — list updates after a new in-app booking Precondition: the logged-in user commits a new in-app booking.Trigger: they open the Trips → Upcoming tab.Expected: the booking appears with no manual refresh; ordered by departure date; cache updated. | Happy path — same behaviour Given the logged-in user has committed a new in-app bookingWhen they open Trips → UpcomingThen the booking appears, no refreshAnd it is ordered by departure date |
BA-agent можна донастроювати й надалі. У прикладі вище замість звичних маркованих пунктів використано альтернативний формат опису. Гнучкість ba-agent дозволяє бізнес-аналітикам змінювати його за потреби, перероблювати формати опису критеріїв прийняття. Іншими словами, ba-agent – це гнучкий інструмент, який легко адаптувати до роботи команди.
Після перегляду та підтвердження бізнес-аналітиком, Claude автоматично створює тікети в Azure DevOps, і до всіх таких тікетів додається тег agent-created, щоб відрізняти їх від задач, створених людьми. Перед тим як дозволити Claude додавати тікети, бізнес-аналітики донастроюють результат роботи Claude, а після цього до тікетів в ADO можна вносити ручні правки.
Швидший груммінг (refinement)
Налаштування ШІ на проєкті також дозволяє бізнес-аналітикам прискорити груммінг. Команда грає в planning poker, щоб оцінити задачі у story points. На нашому проєкті також потрібно надавати оцінку зусиль розробки та QA в годинах для підзадач (subtasks). Під час груммінгу команда оцінює зусилля в годинах, а потім, після підтвердження бізнес-аналітиками, Claude створює підзадачі.
Dev task | 24h |
QA task | 10h |
Estimated effort | 34h |
Крім того, після груммінгу Claude оновлює статус тікетів на Ready for Dev, даючи знати членам команди, які user stories можна брати в спринти.
Ще три способи оптимізації роботи бізнес-аналітиків
Робота бізнес-аналітиків не обмежується лише user stories — багато часу витрачається на управління вимогами, прототипами та узгодженнями (sign-off). Три додаткові скіли допомагають робити це швидше:
Оновлення user stories за результатами дзвінків — транскрипт дзвінка проходить через скіл meeting-notes, потім зіставляється з конкретною user story, а Claude одразу вносить правки в Azure DevOps. Оновлена версія тікета стає доступною миттєво, замість витрачання часу на ручну роботу.
Підготовка мокапів для брейнштормінгу — дуже часто стейкхолдери сприймають клікабельні HTML-прототипи за фінальну систему (to be). Тому Claude допомагає бізнес-аналітикам знизити «якість» клікабельних прототипів, щоб стейкхолдери не плутались під час воркшопів зі збору вимог та інших сесій.
Генерація документа для узгодження (sign-off) — було створено окремий скіл для генерації документів вимог для узгодження. Він отримує фічу та пов'язані user stories, аналізує вихідний запит і генерує HTML-файл, який можна вставити безпосередньо в Loop для перевірки стейкхолдерами.
Claude готує чернетку, бізнес-аналітик підтверджує
Отже, як розмежувати те, що робить Claude, і те, що робить бізнес-аналітик? На нашому проєкті все просто: Claude генерує, а бізнес-аналітик приймає рішення та підтверджує. ШІ-агент дуже швидко створює першу версію BA-артефактів, але нічого не публікується без перегляду та фінального підтвердження людиною.
Активність | Claude | Бізнес-аналітик |
Збір вимог | Створює клікабельні HTML-прототипи | Проводить сесії, привносить контекст, визначає обсяг, надає фідбек Claude |
Декомпозиція вимог | Пропонує карту user stories за обраним паттерном | Підтверджує або коригує декомпозицію, перш ніж щось публікується |
Підготовка user stories | Готує user stories з критеріями прийняття у погодженому форматі | Переглядає user stories, вносить зміни |
Створення тікетів | Записує підтверджені тікети в Azure DevOps і додає теги | Дозволяє публікацію user stories та коригує тікети в ADO |
Груммінг обсягу | Створює підзадачі Dev / QA та переводить статус на Ready for Dev | Модерує сесію та ініціює створення підзадач |
Генерація артефактів для узгодження | Генерує документ вимог для перегляду | Надсилає документи для узгодження стейкхолдерам і слідкує за прогресом |
Хто що робить в нашому AI SDLC
Хоча може здатися, що Claude робить усе самостійно, процес і рішення все ще належать бізнес-аналітику. ШІ не робить нічого без нагляду й підтвердження людиною: на кожному етапі роботи бізнес-аналітик має останнє слово та контролює дії ШІ. Лише таке поєднання зусиль людини та ШІ забезпечує ефективність AI SDLC.
Застосовність до застарілого та нового функціоналу
Одне з побоювань щодо будь-якого налаштування ШІ — чи воно адаптоване лише для роботи з існуючою (enterprise) системою, чи також здатне працювати з проєктами «з нуля» (greenfield). У контексті корпоративного проєкту деякі нові модулі чи застосунки можуть створюватися з нуля паралельно з наявними веб- або мобільними застосунками.
Для нас це не проблема, оскільки налаштування ШІ чудово підходить для створення нових продуктів. Наприклад, якщо потрібно спроєктувати новий застосунок, який частково інтегрується з наявними, для отримання чудового результату можна використати того самого ba-agent і тих самих агентів для розробки й QA. Таке завдання виникало на нашому проєкті — ba-agent виявився потужним інструментом, який допоміг проаналізувати запит, створити клікабельні HTML-прототипи, підготувати вимоги та отримати узгодження.
Чи це справді себе виправдовує?
Оскільки налаштування ШІ було запущено відносно недавно, наведемо статистику за один місяць:
44 | 135 | ~5 |
підготовлені user stories з критеріями прийняття | створені, декомпозовані та оцінені задачі Dev/QA | заощаджені людино-днів бізнес-аналітика (орієнтовно) |
Ці дані отримані з Azure DevOps на проєкті. Якщо взяти user story як приклад, середній час на її створення становить приблизно 45 хвилин, тоді як за допомогою Claude цей показник знижується до близько 12 хвилин. Те, що здається незначним для однієї user story, перетворюється на суттєву економію часу та коштів.
Наведена статистика демонструє вражаючу економію часу від використання ШІ в повсякденній роботі бізнес-аналітика. Могло би здатися, що людині майже нічого не залишилось — Claude бере все на себе. Але це не так: людина завжди залишається невідʼмною частиною процесу. Як зазначено вище, Claude готує чернетки, декомпозує та створює прототипи, але саме бізнес-аналітик ставить завдання, перевіряє їх виконання ШІ та підтверджує. Кожен результат роботи потребує ретельного перегляду бізнес-аналітиком.
Порада іншим бізнес-аналітикам
Якщо ви хочете отримати користь від ШІ на своєму проєкті, вам не потрібне таке саме налаштування, щоб досягти хороших результатів. Попросіть Claude створити скіли та адаптувати їх до ваших потреб, або просто повторно використайте BA-скіли іншої команди, а потім направте Claude до тікетів (будь то Azure DevOps чи JIRA/Confluence), щоб сформувати контекст проєкту (project context), — і ви зможете підвищити ефективність своєї роботи як бізнес-аналітика.
Впровадження ШІ перебуває на ранньому етапі, тож не бійтеся експериментувати та пробувати нові підходи, щоб отримати налаштування, адаптоване до потреб вашої команди.
Від редакції: Якщо хочете поглибити свої БА навички щодо використання AI, зверніть увагу на
Новини та статті з бізнес-аналізу:
