Async standup із Slack + Jira

Автоматизація замінює синхронний daily standup на асинхронний цифровий формат. AI-агент аналізує активність учасників команди в Jira за останні 24 години, формує персональну чернетку оновлення для кожного і публікує зведений пост у Slack-канал команди.

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

1. Збирає сигнали з Jira. Забирає по API всі тікети учасника зі змінами за минулу добу: переходи статусів, коментарі, логи часу, створені та закриті задачі.
2. Формує персональний draft. Для кожного учасника бот збирає три блоки: «вчора» (що закрито), «сьогодні» (що в роботі або взято в спринт), «блокери» (тікети з лейблом blocked або застряглі на статусі review). LLM переформульовує сирий changelog у читабельний текст.
3. Надсилає нагадування в Slack DM. У заданий ранковий час за таймзоною учасника бот надсилає draft із кнопками «Підтвердити» і «Відредагувати».
4. Збирає підтвердження. Учасник або підтверджує draft одним кліком, або редагує текст прямо в Slack. Валідація займає 2-3 хвилини.
5. Публікує зведений пост. За розкладом бот публікує в канал команди тред: заголовок дня, блоки учасників і окремий список блокерів із тегами відповідальних.
6. Тригерить follow-up по блокерах. Всі пункти з блоку «блокери» автоматично створюють підзадачу в Jira з assignee = PM команди і тегом standup-blocker, щоб ескалація не загубилась.

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

• Не приймає рішень по блокерах. Бот фіксує і тегає PM — розбір ескалацій залишається за людиною.
• Не замінює планування спринтів, архітектурні обговорення і ретроспективи. Це формат daily, а не weekly або planning.
• Не оцінює якість коду і продуктивність команди. Автоматизація відображає лише активність в Jira і не генерує метрики performance review.

Автоматизація побудована на low-code платформі (workflow-движок або Zapier) і працює через офіційні REST API Jira та Slack. Обробка даних і формування текстів виконуються через LLM AI-модель. Потік обробляє активність команди 10-20 осіб за кілька хвилин машинного часу на добу.

Технічний flow

1. Cron-тригер. Workflow запускається за розкладом у ранній слот команди (наприклад, 8:45 локального часу PM).
2. Збір даних із Jira. Запит до Jira REST API (/search з JQL: assignee = X AND updated > -24h) повертає список змінених тікетів для кожного учасника.
3. Парсинг changelog. Для кожного тікета workflow витягує історію: переходи статусів, додані коментарі, зміни scope, оновлення оцінок.
4. Генерація draft. Зібрані сигнали передаються до LLM з промптом у три блоки: «вчора», «сьогодні», «блокери». Промпт фіксує ліміт рядків на блок і тон команди.
5. Надсилання draft у Slack DM. Через Slack Web API (chat.postMessage) бот надсилає чернетку учаснику з інтерактивними кнопками.
6. Отримання підтвердження. Slack Interactivity Endpoint приймає webhook з результатом кліку. Workflow зберігає фінальний текст блоку у сховище (Airtable, Google Sheets або PostgreSQL).
7. Публікація зведеного поста. За cron збираються всі підтверджені блоки та публікуються в канал команди #standup-{team}.
8. Створення задач для блокерів. Блокери тригерять Jira-issue типу Task з тегом standup-blocker та призначенням на PM.

Компоненти

Етапи впровадження

1. Тиждень 1 — дизайн і доступи. Grow2.ai збирає з команди шаблон оновлення (які поля, тон, мова), отримує Jira API token і Slack bot token, налаштовує тестове середовище.
2. Тиждень 2 — збирання workflow.Інженер збирає workflow у workflow-движку, пише промпт для LLM, налаштовує Slack-кнопки, тестує на 2-3 учасниках.
3. Тиждень 3 — пілот і калібрування. Async standup запускається на одній команді. Grow2.ai збирає feedback і править промпт — часто перші драфти надто сухі або, навпаки, багатослівні.
4. Фінальна фаза — handover. Додаються правила follow-up щодо блокерів, формується документація, PM команди отримує dashboard підтверджень і статистику пропусків.

Для запуску потрібні доступи до Jira і Slack, згода команди на новий формат та 1-3 тижні роботи інженера.

Технічні вимоги

• Jira Cloud або Jira Data Center з REST API-доступом і правами на створення API token.
• Slack workspace з правом встановлення ботів. Мінімальні scopes: chat:write, im:write, commands, users:read.
• Акаунт workflow-рушія (self-hosted або cloud) або Zapier з планом, що підтримує webhooks і custom-вузли.
• Доступ до LLM API (Anthropic Claude або еквівалент).

Організаційна готовність

• Згода команди та керівника відділу на відмову від синхронного daily. Async формат вимагає дисципліни: якщо половина команди ігнорує нагадування, автоматизація втрачає сенс.
• Домовленість щодо формату блоку — що вважати «блокером», що «в роботі», що «вчора».
• PM або Team Lead, готовий приймати ескалації щодо блокерів у Jira протягом робочого дня.

Дані

• Історія тікетів Jira за 2-3 тижні для калібрування промпту LLM (які поля важливі, в якому тоні писати).
• 5-10 прикладів «хороших» standup-оновлень від команди для few-shot у промпті.

Терміни

Від 1 до 3 тижнів від старту до production-запуску на одній команді. Масштабування на 2-3 команди додає ще 1-2 тижні — кастомізація промптів, окремі Slack-канали, робота з кількома таймзонами.