Atlassian Rovo в роботі бізнес-аналітика: як я шукала мідь, а знайшла золото (але лепреконське)

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

Привіт, мене звати Саша Серебрянська, я старша бізнес-аналітикиня в ЕРАМ Україна, власниця мемного каналу та лідерка ВА спільноти.

Хочеться написати «я знов принесла вам нейрослопу!», але давайте про це в коментарях, а тут поговоримо про Atlassian Rovo, корпоративний AI-асистент для команд, що живуть у Jira і Confluence. Наразі я працюю як AI SME (звучить дуже пафосно, на ділі все прозаічніше) на проєкті з кількома бізнес-юнітами на Atlassian Cloud, і я провела з Rovo кілька місяців у режимі реальної роботи. Розкажу, що вийшло, а що ні, і хто винуватий (звісно, я).

Чому Rovo — це не просто «ChatGPT для Jira»

Rovo — це AI-платформа від Atlassian, запущена у 2024 році. Вона складається з кількох компонентів: Rovo Chat (чат-асистент), Rovo Search (пошук по всьому Atlassian-простору) та Rovo Agents — кастомні агенти, яких можна збудувати в Rovo Studio без коду. Ще є Flow, така собі автоматизація, також без коду, і це Rovo Forge — інструментарій, через який можна створити більш кастомного Rovo agent через код.

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

Як виглядає агент

Під капотом Rovo використовує гібридний підхід: Atlassian динамічно маршрутизує запити між різними LLM залежно від сценарію. В офіційній документації згадуються third-party hosted models з OpenAI GPT, Anthropic Claude та Google Gemini series, а також Atlassian-hosted open-source models, зокрема Llama, Phi та Mixtral. Конкретну модель для кожного запиту користувач зазвичай не обирає — це вирішує orchestration layer Atlassian.

Що з цього випливає на практиці? По-перше, ви не можете запінити конкретну модель під свій агент — вибір залишається за Atlassian. По-друге, оновлення моделей відбуваються без попередження і можуть змінювати поведінку ваших Scenarios без будь-яких змін з вашого боку. По-третє — і це важливо для ентерпрайз — ланцюжок провайдерів довший, ніж здається.

Дані можуть проходити через Atlassian, Google, OpenAI або Anthropic залежно від задачі. Atlassian запевняє, що жоден провайдер не використовує ваші дані для навчання моделей, і що є суворі confidentiality agreements. Але для регульованих індустрій це окрема розмова з юристами.

Як це виглядає в реальній ВA-роботі

Наша команда BA/PO працює з типовим циклом: від збору вимог від бізнес-юнітів до документації, рефайнменту з девелоперами, створення тікетів і завершення демо-cесією. Ми намагалися покрити Rovo-агентами ~20 use case.

Де Rovo справді допомагає

Чернетки документації. Найкращий кейс. Агент отримує сторінку з high-level вимогами, шаблон Low-Level Analysis і контекст з пов’язаних Confluence-сторінок — і видає перший драфт. BA все одно його доопрацьовує, але час «від думки до структури» скорочується суттєво. Для Functional Analysis — аналогічна ситуація. Якщо у вас є шаблон і живі вимоги, агент зробить перший прохід.

Перевірка повноти документа. Агент отримує Confluence-сторінку і чеклист: чи є Acceptance Criteria, чи описані error scenarios, чи вказані залежності, чи є UX-коментарі. Видає список прогалин. Це вже звільняє десятки хвилин ручного ревʼю.

Рефайнмент та демо комунікація. Агент, який генерує email до команди з посиланням на рефайнмент-сторінку і коротким описом теми, це не щось надзвичайне, але це 5 хвилин замість 20, якщо ви ще й формулюєте все з нуля після напруженого дня.

Перевірка на дублювання. «Знайди схожі вимоги на цих сторінках» — і агент порівнює контент, виявляє перетини. Для великих проєктів з довгою історією, де один requirement може бути описаний у 4 місцях трохи різними словами, це реально цінно.

Accessibility by Design. Агент застосовує чеклист доступності до аналізу фічі. Не замінює експертизу, але як перший фільтр відловлює очевидні пропуски.

Автоматизований flow у Rovo

Де Rovo частково справляється

Збір high-level вимог. Агент структурує вхідні дані (email або нотатки з зустрічі) за шаблоном і формулює перелік уточнюючих питань. Але: якщо вхід надто «вільний», агент галюцинує — додає пункти, яких не було. Human-in-the-loop обов’язковий.

Синергії між проєктами. Rovo може переглянути кілька STR/EPIC-тікетів і знайти схожий scope. Але для великого масиву — більше 50 тікетів — він зрізає вибірку. Це не баг у мене в голові, це підтверджена обмеженість: Atlassian Community задокументувала ліміт у ~50 issues на запит у Automation-сценаріях. Для системного пошуку по всьому портфелю потрібен окремий пайплайн.

Рефайнмент-сторінки в Confluence. Агент може задрафтувати сторінку — але публікація завжди потребує ручного підтвердження. Навіть якщо ви прописали у інструкціях «публікуй автоматично», Rovo все одно зупиняється і запитує. Це не баг. Atlassian пояснює це як навмисне «human-in-the-loop gate». У нашому контексті абсолютно виправдано.

Естімації. Задача, де я найбільше боялась підключати AI (спойлер: страх виявився виправданим). Ми підключили Rovo до етапу попередньої оцінки задачі. На вході були опис нової ініціативи, Jira із закритими задачами як прикладами з минулого та сторінка в Confluence з правилами оцінювання.

Агент видав структурований драфт оцінки з числами, поясненнями та посиланнями на конкретні тікети. Під час перевірки ми знайшли кілька конкретних проблем.

По-перше, Rovo бачив не всю історію в Jira, а приблизно 50 тікетів. Тобто він працював не з повною базою попередніх оцінок, а лише з обмеженим фрагментом. По-друге, приклади він брав не обов’язково з найрелевантніших задач, а з тих, які потрапили у доступний контекст. Через це частина порівнянь виглядала логічно на перший погляд, але насправді не була достатньо точною.

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

У результаті розбіжність із коректною оцінкою могла сягати 30–40%. Для внутрішнього драфту в команді це ще прийнятно як відправна точка. Для фінальної оцінки, яку показують стейкхолдерам і закладають у плани, — категорично ні.

Обмеження, про які не пишуть у релізах

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

1. Довгі промпти — це ігнорування частини інструкцій

Atlassian прямо попереджає: чим довший системний промпт агента, тим більша ймовірність, що він забуде частину інструкцій у середині розмови. На практиці це означає: якщо ваш Scenario-промпт більше ~300 слів, агент починає вибирати, що виконувати.

2. Write-дії потребують explicit Yes/No gate, але і це не завжди спрацьовує

Rovo зроблений так, щоб не робити деструктивних дій без підтвердження. Але оркестраційний шар часто «проскакує» вперед, особливо у багатокрокових сценаріях. Ми бачили кейси, коли агент після першого повідомлення вже намагався щось зробити — замість того, щоб показати прев’ю. Workaround: вбудовувати явний «After drafting, ask: Proceed? (Yes/No). Only execute on Yes» у кожен Scenario, де є write-action.

3. Кастомні поля в Jira — нестабільна зона

Офіційно підтримку custom fields при створенні тікетів анонсували у лютому 2026. На практиці — Story Points, Team Assignment, специфічні поля зі схемою Forms — не завжди заповнюються коректно. Ми зупинили тестування цього блоку: агент або повертає помилку 400 (bad request), або заповнює поля частково, або — найгірший варіант — «успішно» звітує, але поле насправді залишилось порожнім.

Офіційне підтвердження з Atlassian Jira: ROVO-229 — «Rovo currently faces limitations when creating Jira issues, as it can only fill default fields like summary, description, and project». Патч є, але стабільність залежить від типу поля. Тестуйте кожне поле окремо, не вірте на слово.

4. Ліміт у 50 issues при bulk-операціях

При спробі обробити великий JQL-результат через Rovo Agent у Automation агент обрізає вибірку. Офіційна відповідь Atlassian Support: «50-issue limit is a constraint of the Rovo Agent, though not officially documented». Це пов’язано з розміром контекстного вікна агента, не з лімітами Automation. Workaround: пагінація через батчі, фільтрація по компоненту/команді/даті.

5. Miro немає в екосистемі Rovo

Якщо ваша команда живе в Miro (process flow charts, impact maps, user journey), Rovo вас підведе. Нативної Miro-інтеграції в Rovo агентах немає. Miro є тільки як read-only Knowledge Source. Для створення або оновлення діаграм — або Miro AI напряму, або Remix with Rovo в Confluence (якщо достатньо вбудованого діаграмного інструменту).

6. Агент діє від service identity, а не від вашого імені

Це технічна деталь із серйозними наслідками. Rovo агенти працюють через Atlassian-managed service identity. Це означає: навіть якщо ви адмін проєкту, агент може не мати доступу до певних полів або дій, якщо вони не виставлені для service accounts. І — головне — ніякий API-токен, OAuth або service account не «підняти» дозволи для Rovo-агента. Якщо skill не виставляє поле ніякі конфігурації його не розблокують.

7. Агент не тримає фокус між повідомленнями

У довгих розмовах Rovo часто «перезапускає» аналіз з початку. Ви пишете «тепер додай розділ X», а агент знову аналізує оригінальну сторінку замість того, щоб продовжити розмову. Причина — архітектурна: кожен turn може перезаповнювати контекст. Дизайн Scenarios повинен враховувати це: кожен сценарій — self-contained, мінімум залежності від попередніх повідомлень у тому ж треді.

8. «Ghost Credits» і невидимі витрати

Якщо ваш агент робить запити до зовнішніх систем (наприклад, через MCP-підключення до Google Drive, Amplitude або іншого сервісу), і ці запити завершуються помилкою — токени все одно витрачаються. Atlassian Community назвала це «Ghost Credits»: невидимі невдалі ретраї, що спалюють ліміт. Особливо критично для команд на Standard-плані з обмеженим пулом Rovo credits.

9. Фантомні скілли

Одна з найбільш дратівливих особливостей Rovo — те, що він може перестати робити те, що робив учора, просто тому що Atlassian щось оновив. Atlassian випускає апдейти до Rovo приблизно раз на два місяці, при цьому release notes описують нові фічі, але не завжди пояснюють, що поламалось або змінило поведінку. Ви будуєте Scenario, він стабільно працює тиждень, потім після чергового релізу агент починає ігнорувати частину інструкцій або раптово «забуває», який tool викликати. Без жодного повідомлення.

Конкретний приклад з Atlassian Community (квітень 2026): користувачі помітили, що після одного з апдейтів агент перестав коректно розрізняти типи полів у Jira — плутав project category і issue type, а на write-дії звітував «успішно», хоча поле залишалось порожнім. Atlassian підтвердив: «tends to hallucinate success on write actions rather than flagging that it couldn’t complete them properly».

Ще один патерн нестабільності — tools per agent. Офіційної жорсткої межі немає, але практика показує: якщо агент має більше 5 активних tools, він починає губитись" у виборі — викликає не той tool, пропускає кроки або взагалі відмовляється виконувати дію без чіткої помилки.

Що з цим робити:

Закладіть в процес регулярний smoke-test агентів після кожного великого Atlassian-релізу — 3-5 тестових промптів з відомими очікуваними результатами. Займає 15 хвилин, рятує від тижня «чому він раптом так поводиться».

Для write-дій завжди додавайте крок верифікації: «After creating the work item, retrieve it and confirm the field values». Не вірте на слово звіту агента — попросіть його перевірити себе.

Тримайте кількість tools на агента мінімальною. Краще два агенти з трьома tools кожен, ніж один з шістьма. І головне — не будуйте критичні процеси так, щоб Rovo був єдиним шаром. Агент може впасти, змінити поведінку після релізу, поламатися.

Коли Rovo недостатньо

Що точно не підходить для Rovo:

Обов’язкові кастомні поля, що не пишуться через Rovo: Atlassian Automation rule після того, як Rovo створив базовий тікет.

Publish до зовнішніх систем: External API + Atlassian Automation або custom MCP. Rovo тут не працює.

Великомасштабний пошук по сотням сторінок і проєктів: Rovo обрізає вибірку і не підходить для систематичного cross-project пошуку.

Оцінка естімацій: Jira pipeline. Rovo видає «draft estimate», але для цифр, за які хтось підписується, потрібна точніша система.

Miro-діаграми: Miro AI напряму або Remix with Rovo в Confluence як альтернатива.

Rovo Chat і Deep Research іноді працюють краще, ніж сам агент

Ось парадокс, до якого ми прийшли через кілька місяців роботи: для частини задач Rovo Chat без жодного кастомного агента дає кращий результат, ніж ретельно налаштований Scenario.

Причина проста. Агент — це набір фіксованих інструкцій, knowledge sources і tools, зав’язаних у Scenario. Він оптимізований під повторювану задачу. Але якщо задача неоднорідна, контекст щоразу різний, або вам треба «поміркувати разом» — фіксована структура агента стає обмеженням, а не перевагою.

У Rovo Chat ви розмовляєте напряму, без оркестраційного шару, у нього все одно є доступ до Jira і Confluence, і він не намагається втиснути відповідь у заздалегідь прописаний формат. Для аналізу нетипової ситуації, брейнштормінгу вимог або розбору суперечливих stakeholder-коментарів — це перевага, але навіть і для задачі щось швидко знайти або зробити простий аналіз працює здорово.

Окремо варто сказати про Deep Research. Це не той самий Chat — це окремий режим з іншою моделлю під капотом (Claude 4, за даними Atlassian). Deep Research будує повноцінний research plan, йде по ньому крок за кроком і видає структурований довгий звіт з посиланнями. Ми використовували його для аналізу конкурентних підходів, збору прецедентів з проєктної документації і навіть для підготовки pitch до стейкхолдерів, коли треба було зібрати аргументи з десятків Confluence-сторінок.

Порівняння з агентом тут не на користь агента: агент з Scenario-інструкцією «зроби аналіз» зазвичай видає плоский summary з поверхневими спостереженнями. Deep Research — повноцінний структурований документ, де видно логіку і джерела.

Але і тут є нюанс: Deep Research повільний. Залежно від обсягу — від 2 до 10 хвилин. Для повторюваних швидких задач агент із Scenario виграє по швидкості. Для разових аналітичних задач з високою складністю — Deep Research виграє по якості.

Отже

То чому ж я назвала Rovo лепреконським золотом — тобто тим, що є, скоріше, обіцянкою надзвичайних результатів? Бо це дійсно корисний інструмент для команд, що вже живуть в Atlassian Cloud. Він реально заощаджує час на документаційній рутині, першому прогоні чеклистів і комунікаційних шаблонах, але він не заміна BA, навіть початківцю. До того ж, як ви пам’ятаєте, деякі скіли у нього пропадають в найнеочікуваніший момент, як те саме чарівне золото.