Міжпроектні статус-звіти з Jira/Asana/Runn

Міжпроектні статус-звіти об'єднують дані з Jira (задачі, епіки, спринти), Asana (проекти, підзадачі, дедлайни) і Runn (ресурс-планування, утилізація команд), перетворює їх на щотижневий або щоденний звіт по портфелю.

AI-агент читає сирі дані, виділяє ключові зміни, аномалії та ризики, формує виклад — зв'язний текст, а не таблицю цифр.

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

1. Прогрес по проектах. Відсоток готовності, темп витрачання, відхилення від плану.
2. Затримки та блокери. Задачі, прострочені за тиждень; задачі з позначкою «заблоковано».
3. Ризики. AI-агент порівнює поточну швидкість із планом, виділяє проекти з тенденцією до відставання до того, як дедлайн став критичним.
4. Завантаженість команд. З Runn — хто перевантажений, де простій, де надмірно завантажений.
5. Зміни обсягу. Нові задачі, перенесені строки, перегляд оцінки.
6. Зведення для керівництва. 3-5 речень для керівника: що важливо, що потребує вирішення, куди йдемо.
7. Порівняння з попереднім періодом. Прогрес тиждень-до-тижня, ковзні тренди за місяць.

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

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

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

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

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

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

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

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

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

Корпоративний PMO / 30+ проектів

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

Як це працює

Архітектура

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

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

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

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

1. Delta-аналіз. Порівняння прогресу тиждень-до-тижня: що прискорилось, що сповільнилось, які проекти показують стабільний темп.
2. Виявлення аномалій. Проекти з незвично повільним темпом витрат, несподівано багато заблокованих задач, різкі стрибки обсягу, команди з перевантаженням 120%+.
3. Прогнозування ризиків. Екстраполяція поточного темпу: якщо проект іде цим темпом, чи встигне до дедлайну. Проактивний сигнал до того, як дедлайн став червоним.
4. Узагальнення. Стиснення десятків проектів і сотень завдань у 3-5 пріоритетів, які потребують уваги PMO наступного тижня.

Якість виводу

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

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

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

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

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

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

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

Безпека та відповідність вимогам

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

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

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

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

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

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

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

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