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 человек с portfolio 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 в отчёте.