Міжпроектні статус-звіти з 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) підтягує дані за розкладом, але не вміє аналізувати — видає таблицю або маркований список. Виклад та висновки щодо ризиків все одно пишуться вручну. Економить частину часу, але не вирішує задачу якості аналізу. Підходить для дашбордів, не для аналітичних звітів.

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 у звіті.