Асинхронний стендап із Slack + Jira

Автоматизація замінює синхронний щоденний стендап на асинхронний цифровий формат.

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

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

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

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

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

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

Технічна схема роботи

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

Компоненти

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

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

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

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

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

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

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

Дані

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

Терміни

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