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-каналы, работа с несколькими таймзонами.