Ваш трекер знает о срыве сроков раньше вас

Пятница, статус-митинг. PM открывает слайд: «Мы отстаём от плана на две недели». Руководитель задаёт единственный вопрос, который имеет значение: «Когда стало понятно?»

PM честно отвечает: «Неделю назад. Когда собирал данные для отчёта».

Пауза. Руководитель думает: данные лежали в трекере всё это время. Они были доступны в понедельник, во вторник, в среду. Просто никто на них не смотрел. А когда посмотрел – уже нечего было делать, кроме как поставить команду перед фактом. Окно для дешёвого вмешательства – перекинуть одного разработчика, переговорить с заказчиком, вырезать фичу из релиза – закрылось дней пять назад.

Эта ситуация повторяется в тысячах команд каждую пятницу. И проблема не в PM, не в команде и не в Jira. Проблема в самом формате статус-отчёта.

Статус-отчёт описывает прошлое. Он собирается раз в неделю, агрегирует данные за прошедший период и укладывается в слайд. По структуре это ретроспектива, а не прогноз. К моменту, когда отклонение попадает в пятничную презентацию, команда уже живёт с ним несколько дней, заинтересованные лица уже слышат тревожные сигналы в коридорах, а PM, который собирал данные вчера вечером, только сейчас видит картину целиком.

Так устроен сам процесс.

Проскальзывание можно обнаружить за два-три спринта до того, как команда сообщит о нём сама. Методы для этого существуют – Earned Value Management, Monte Carlo-симуляции на основе реальной пропускной способности команды. Работают ли они точнее человека – вопрос спорный, и данные неоднозначны. Но это не главное. Реальная сила не в точности формулы, а в том, что агент смотрит на данные каждый день, а PM – раз в неделю. Для классических методов нужен аналитик, статистическая грамотность и время. У PM команды из пяти разработчиков нет ни того, ни другого.

AI-агент делает ту же работу за пять минут. Если знать, что спросить.

Ниже – модельный спринт. Имена вымышлены, но паттерны – из реальных выгрузок Jira и Yandex Tracker, которые мы прогоняли через три модели при подготовке курса. Конкретная команда, конкретные данные, и что в них спрятано.

Финтех-стартап. Мобильное приложение для самозанятых. Команда из шести разработчиков – два бэкенда, два фронтенда, один мобильщик, один фуллстек (Сергей) – плюс один QA. Двухнедельные спринты. Sprint 23, шестой день из десяти. Цель спринта: интеграция с банковским API и редизайн экрана транзакций.

Вот velocity за последние шесть спринтов: 42, 38, 44, 40, 36, 31. На Sprint 23 запланировано 34 story points. С пика в Sprint 20 – четыре спринта снижения подряд: 44 → 40 → 36 → 31. Но PM мог бы объяснить каждое отдельное падение. В Sprint 19 один разработчик был в отпуске. В Sprint 21 вышла новая сотрудница, осваивалась. В Sprint 22 кто-то болел. Каждый спринт по отдельности – нормальная вариация. Шесть спринтов вместе – тренд, который кричит.

Но PM не видит тренд, потому что не смотрит на шесть спринтов одновременно. Он смотрит на текущий. В спринте 14 задач, из которых три закрыты, четыре в работе, остальные открыты. На стендапе звучит штатно. Но если выделить только то, что стоит, – картина другая:

Четыре строки. Прежде чем читать дальше – посмотрите на них и прикиньте: сколько из 34 SP реально закроется к концу спринта?

Теперь посмотрим глазами следователя, что за ними стоит.

От задачи по API банка зависят ещё две – баланс (3 SP) и история транзакций (5 SP). Авторизация (5) + баланс (3) + история (5) = 13 story points из 34 стоят колом из-за одного внешнего блокера, который никто не эскалирует. Это 38% содержания спринта. Алексей приходит на стендап и говорит: «Банк обещал завтра». Он говорит это пятый день подряд. Никто не замечает, что «завтра» стало привычным словом.

С Дмитрием другая история. Четвёртый день в «В работе», ноль принятых PR. Посмотрим в git: 6 коммитов за шесть дней при норме 15. Но размер каждого – 67 строк, вдвое больше обычного. Он накапливает изменения, потому что не уверен, что макеты не изменятся. От его редизайна зависят фильтры (ещё 3 SP). Итого 6 SP подвисают в ожидании дизайнера, который «финализирует».

А вот задача, которой вообще нет в sprint goal. Отчёт для CEO – без оценки, без планирования, добавлен в день 4. Мария бросила баг с дублированием транзакций и занимается им второй день. Два дня из десяти у одного из пяти разработчиков – скрытые 10% мощности команды просто испарились.

A/B тест добавлен в день 5. Свободных рук нет – но кто-то вспомнит про Сергея, единственного фуллстека, который пока тянет свои задачи в срок. Ему скинут A/B тест «пока есть время», и через три дня уже его задачи начнут буксовать. Задача в спринте, и через неделю кто-нибудь спросит: «А что с A/B тестом?»

Арифметика: из 34 запланированных SP закрыто 6. Заблокировано напрямую или по цепочке зависимостей – 19. Остаётся 9 SP в работе без блокеров – плюс 6 уже закрытых, получаем 15. Если sandbox появится в ближайшие два дня, разблокируется часть цепочки – до 18. Реалистичный прогноз: 14–18 SP. Sprint goal – «интеграция с банковским API» – не будет достигнута, если sandbox не появится в ближайшие 48 часов.

PM узнает об этом в пятницу, когда будет готовить слайд. Агент видит это за 30 секунд, если ему дать эту таблицу и промпт с просьбой проанализировать блокеры, зависимости и тренд velocity.

Вот что он выдаёт (сокращённо):

Тридцать секунд вместо часа ручной сборки данных.

Чем закончился Sprint 23? Sandbox появился на восьмой день – Алексей дописал авторизацию, но баланс и историю транзакций уже не успели. Дмитрий выбросил два дня работы, когда дизайнер прислал финальные макеты в день 7. Мария так и не вернулась к багу. Сергей получил A/B тест. Итого: 16 SP из 34. Sprint goal провален. PM узнал масштаб проблемы в пятницу.

Агент знал это во вторник. Но прежде чем вы побежите пробовать – вот как это ломается.

Загрузил выгрузку, получил отчёт, пришёл на планирование с умным видом. Я хочу испортить это ощущение.

Когда мы прогоняли такие промпты на реальных выгрузках из Jira и Yandex Tracker, в одном из проектов модель рассчитала, через сколько спринтов velocity упадёт ниже критического порога. Формула выглядела идеально. Таблица – аккуратная. Вывод: «5 спринтов до порога, запас есть». Только за точку отсчёта модель взяла среднее за полгода – 39,5 SP – вместо текущего значения в 28. Если считать от реальной velocity, до порога остаётся один-два спринта. Разница между «5 спринтов запаса» и «паника через две недели» – одна неправильная посылка, которую красивая формула маскирует.

И есть вещи, которые агент не увидит никогда. Модель не знает, что Дмитрий буксует из-за конфликта с дизайнером. Не знает, что Сергей молчит, потому что ищет работу. Не знает, что CEO зашёл в чат, потому что инвестор задал вопрос. Агент – черновик для проверки. Числа дают каркас, но картину собирает PM.

PM, который приходит на планирование с «что-то идёт не так», получает в ответ «ну, давайте посмотрим» – и ничего не происходит. PM, который приходит с конкретными цифрами, блокерами и прогнозом – получает решение. Первый разговор заканчивается обещаниями разобраться. Второй – действием.

Агент даёт PM аргументы, с которыми его невозможно проигнорировать.

Хотите попробовать на своих данных? Вот минимальный промпт – он найдёт блокеры, зависимости и scope creep. Для git-аномалий вроде истории с Дмитрием нужно скормить агенту ещё и данные коммитов – но начать стоит с простого. Вставьте в ChatGPT, DeepSeek или Gemini:

Попробуйте в понедельник. Если агент нашёл хотя бы один сигнал, которого вы не видели – вы знаете, что это работает.

Дальше возникает вопрос, который промпт не решает: как не забыть сделать это на следующей неделе, и на следующей, и через месяц. Разовый промпт находит проблему – но не строит привычку. Нужен навык отличать реальный сигнал от шума (вроде той ловушки с velocity выше). И нужна автоматизация – агент, который сам читает трекер и сам присылает отчёт по расписанию.

Как это автоматизировать – в открытом модуле на mysummit.school. 9 уроков, бесплатный – включая практику по распознаванию ошибок в AI-прогнозах.