Cross-project status reports з Jira/Asana/Runn

Що робить автоматизація

Cross-project status reports об'єднує дані з Jira (задачі, епіки, спринти), Asana (проекти, subtasks, due dates) і Runn (ресурс-планування, утилізація команд), перетворює їх на щотижневий або щоденний звіт по портфелю. AI-агент читає raw-дані, виділяє ключові зміни, аномалії та ризики, формує narrative — зв'язний текст, а не таблицю цифр.

Що потрапляє до звіту

1. Прогрес по проектах. Відсоток готовності, burn rate, відхилення від плану.
2. Затримки та блокери. Задачі, прострочені за тиждень; задачі з позначкою blocked.
3. Ризики. AI-агент порівнює поточну швидкість із планом, виділяє проекти з тенденцією до відставання до того, як дедлайн став hard.
4. Завантаженість команд. З Runn — хто перевантажений, де простій, де overbooked.
5. Зміни scope. Нові задачі, перенесені строки, зміна estimation.
6. Executive summary. 3-5 речень для керівника: що важливо, що потребує вирішення, куди йдемо.
7. Порівняння з попереднім періодом. Прогрес тиждень-до-тижня, rolling trends за місяць.

Формати та канали доставки

Звіт надходить у Slack (thread у канал PMO), на email керівникам, у Notion або Confluence як сторінку, або в PDF для клієнтів. Один звіт — кілька отримувачів із різною деталізацією: executive summary для CEO, повна версія для PMO, client-facing версія з відфільтрованими внутрішніми метриками для замовника.

Тригери та розклад

Звіт генерується за cron-розкладом (щотижневий дайджест щопонеділка о 9:00) або за тригером — натискання кнопки в Slack, call із Notion, подія в Jira (P0-баг), перевищення budget у Runn (load команди 90%+), пропущений дедлайн у Asana. AI-агент у тригерних сценаріях формує не щотижневий overview, а alert: короткий звіт про аномалію з рекомендаціями. Комбінація розкладу та тригерів покриває більшість PMO-запитів на видимість.

Типові варіанти налаштування

#### Solo PMO / 1-5 проектів

Для фрилансерів, solo-проджектів і small teams, де одна людина веде 1-5 паралельних проектів. Автоматизація бере дані з одного джерела (Asana або Jira), генерує weekly digest у Markdown, надсилає в особистий Slack або email. Фокус на personal overview і outstanding items. Підключення — 1 робочий день, включаючи auth і шаблон промпта. AI-агент на AI-моделі запускається за cron-тригером раз на тиждень. Без додаткового хостингу, без ресурсного планування — Runn тут не потрібен. Інфраструктура — GitHub Actions або AWS Lambda у free tier.

#### SMB PMO / 6-30 проектів

Для агентств і SaaS-команд 6-30 осіб із портфелем 6-30 проектів. Підключаються всі три системи: Jira (розробка), Asana (дизайн, marketing), Runn (ресурси). AI-агент групує звіт за типами: клієнтські проекти, внутрішні ініціативи, R&D. Окрема секція — capacity-алерти від Runn. Звіт надходить у два канали: executive summary керівнику, повна версія PMO. Client-facing версії доступні з фільтрацією внутрішніх деталей. Підключення — 2-3 робочих дні, включаючи маппінг проектів між системами, prompt tuning, налаштування шаблонів.

#### Enterprise PMO / 30+ проектів

Для компаній із PMO-офісом і портфелем 30+ проектів. Ієрархія: програми → проекти → епіки. Звіт формується каскадно: програма-level для C-suite, проектний — для програм-менеджерів, тактичний — для команд. AI-агент виділяє cross-project dependencies (залежності між проектами з різних треків) і проактивно підсвічує ризики ескалації. Інтеграція з BI-системою для історичного тренду, версійність звітів у Notion або Confluence. Підключення — 2-3 тижні, включаючи рольову модель доступу, review процес і RBAC для client-facing версій.

Як це працює

Архітектура

Автоматизація — custom-code рішення (Python або TypeScript), працює в 5 кроків за розкладом (cron) або за тригером:

1. Extraction. Скрипт звертається до API Jira, Asana та Runn, забирає дані за заданий період (тиждень або день). Використовуються OAuth-токени від PMO-акаунта або service account.
2. Normalization. Дані з трьох систем приводяться до єдиної схеми: project_id, status, owner, deadline, progress, risk_signal. Маппінг проектів між системами — за кастомним ID або naming convention.
3. Analysis. AI-агент на AI-моделі читає нормалізовані дані, порівнює з даними за минулий тиждень, виділяє дельти, аномалії, ризики.
4. Generation. Той самий AI-агент пише narrative: executive summary, секції по проектах, список ризиків, рекомендації. Використовується structured output — JSON-схема для звіту, markdown для тексту.
5. Delivery. Звіт розсилається в Slack, email, Notion або PDF за правилами, заданими в конфігу.

Кроки AI-аналізу

AI-агент не просто форматує дані — робить 4 типи аналізу:

1. Delta-аналіз. Порівняння прогресу тиждень-до-тижня: що прискорилось, що сповільнилось, які проекти показують стабільний rate.
2. Anomaly detection. Проекти з незвично повільним burn rate, несподівано багато blocked tasks, різкі стрибки scope, команди з перевантаженням 120%+.
3. Risk forecasting. Екстраполяція поточного темпу: якщо проект іде цим темпом, чи встигне до deadline. Проактивний сигнал до того, як дедлайн став червоним.
4. Summarization. Стиснення десятків проектів і сотень завдань у 3-5 пріоритетів, які потребують уваги PMO наступного тижня.

Якість output

JSON-схема жорстко фіксує структуру звіту — AI-агент не може "забути" секцію або додати вигадане поле. Текстові поля проходять пост-процесинг: перевірка на галюцинації (AI-агент посилається на проект, якого немає в даних), перевірка tone, перевірка довжини. Для critical-звітів (client-facing) налаштовується human-in-the-loop — PMO бачить draft у Slack, робить 1-2 правки, approves в відправку клієнту.

Альтернативні підходи

Status reports можна робити трьома способами — у кожного свій компроміс між контролем, швидкістю та вартістю.

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

No-code підхід (Zapier, Make.com) підтягує дані за розкладом, але не вміє аналізувати — видає таблицю або bullet-list. Narrative та risk-висновки все одно пишуться вручну. Економить 30-40% часу, не вирішує задачу якості аналізу. Підходить для dashboards, не для narrative-звітів.

AI-автоматизація робить narrative, risk forecasting та summarization за секунди. Потребує custom-коду, хостингу та налаштування промптів. Контроль — через JSON-схему звіту (структура фіксована) та regression-тести на минулих даних. Вартість підтримки вища, ніж у no-code, але нижча ручного часу PMO.

Автоматизація не замінює PMO-судження — фінальні рішення щодо пріоритизації, ресурсів та комунікації з клієнтом залишаються за людиною. AI-агент готує матеріал для рішення, а не приймає його.

Безпека та compliance

Дані з Jira, Asana та Runn містять бізнес-чутливу інформацію: клієнтів, дедлайни, ставки, імена співробітників. Custom-code рішення розгортається в інфраструктурі замовника (on-premise, Docker, private cloud) — дані не потрапляють на сторонні сервіси понад те, що потрібно для AI-запиту. OAuth-токени зберігаються в secret-менеджері (Vault, AWS Secrets Manager). Для компаній з вимогами GDPR або SOC2 — звіти зберігаються в контрольованому середовищі (Notion workspace з SSO, Confluence з RBAC); промпт налаштовується на редагування PII та чутливих полів перед відправкою в AI. Для compliance-вимогливих індустрій (fintech, healthcare) використовується self-hosted AI-модель замість публічного API — дані не покидають периметр. Автоматизація логує кожне звернення: хто запитав, які дані прочитав AI-агент, який звіт вийшов. Log retention налаштовується окремо.

Що потрібно до запуску

Базові вимоги

1. Доступ до API. Робочий PMO-акаунт або service account у Jira, Asana та Runn з правами на читання проектів і завдань.
2. OAuth або API-токени. Для кожної системи — personal access token або OAuth app, зареєстроване в адміністративній панелі.
3. Канал доставки. Slack workspace, робочий email або Notion/Confluence воркспейс з правами на запис.
4. Єдина схема проектів. Узгоджені project ID між системами або мапінг-таблиця (ручна або через naming convention).
5. AI-модель. API-ключ AI-моделі (або аналог) з квотою, достатньою для 1-4 запусків на тиждень.
6. Місце для запуску скрипта. Cron-сервер, AWS Lambda, GitHub Actions або локальний workflow-рушій — будь-який headless runtime з доступом до API.

Що налаштовується окремо

• Шаблон звіту (markdown + JSON-схема) — PMO визначає структуру розділів, формати полів.
• Правила доставки: хто отримує executive summary, хто повну версію, хто client-facing.
• Пороги ризиків: з якого відсотка відставання підсвічувати як risk.
• Список проектів, що ігноруються (internal chores, archived).
• Мова звіту (EN/RU/UK/ES) і тон (executive, технічний, дружній).

Можливі підводні камені

1. Різний статус-флоу в системах. У Jira статуси одні, в Asana інші, в Runn треті. Без явного маппінгу ("Done" у Jira == "Complete" в Asana == "Delivered" в Runn) AI-агент отримає confusing картинку. Рішення — mapping-таблиця статусів до запуску.
2. Дублі проектів. Один і той самий проект заведено у Jira та в Asana під різними ID. AI-агент бачить два проекти, звіт двоїться. Рішення — унікальний project-tag у кожній системі або мапінг-файл.
3. Очікування ідеального narrative з першого прогону. Перша версія промпта видає або надто загальний текст, або перевантажує деталями. Потрібно 3-5 ітерацій на prompt tuning з реальними даними PMO. Закладайте 1 тиждень на калібрування до production.
4. Rate limits. Jira та Asana мають обмеження на кількість запитів за хвилину; при 30+ проектах можна впертися. Рішення — кеш, пакетні запити, exponential backoff.
5. Зміна даних після збору. Звіт формується на снапшот у момент запуску. Якщо PMO редагує завдання під час генерації, можливий розсинхрон. Рішення — атомарний pull за період із фіксацією timestamp у звіті.