Старая задача не обязательно заблокирована
Задача может долго оставаться открытой, потому что работа идёт по плану или зависит от календарного окна. Блокировка — это конкретное препятствие: нет решения, входного файла, внешнего согласования или назначенного ответственного. До анализа выберите одну доску, период и команду. Не ставьте цель «найти всех, кто задерживает проект»: вопрос должен касаться структуры процесса, а не оценки людей по срокам.
Экспортируйте только нужные поля
Для пробного разбора обычно достаточно ID, названия задачи, статуса, владельца, даты обновления, срока, связи с блокирующей задачей и короткого комментария. Уберите личные сообщения, вложения и закрытые проекты. Проверьте, можно ли передавать названия клиентов и внутренние коды за пределы системы. Если нужно лишь оценить структуру потока, замените имена нейтральными ролями или токенами.
Согласуйте определения до запроса
Команда должна договориться, что означает «заблокирована», «ожидает внешнюю сторону», «нужна проверка» и «не хватает данных». ИИ не может знать неформальные правила отдела по одному статусу. Запишите допустимые категории, примеры и исключения. Если задача переносилась по согласованному плану, она не должна автоматически считаться просроченной проблемой. Неясные случаи отправляйте на ручной разбор, а не заставляйте модель выбирать наиболее похожую метку.
Просите объяснимый результат
Для каждой рекомендации верните ID задачи, предполагаемую категорию, основание из полей, ссылку на зависимость и вопрос владельцу. Не просите составлять рейтинг сотрудников, прогнозировать их производительность или назначать новую дату. Если комментарий содержит только «ждём», уточните, кого или какое решение ждут. При отсутствии связи с исходной строкой результат нельзя принимать — краткое резюме без идентификатора не поможет вернуть сигнал к реальному проекту.
Ищите повторяющиеся причины
Полезная группировка показывает, сколько задач ждут внешнего согласования, сколько — уточнения требований и сколько — входного материала. Это не доказывает, что конкретный отдел работает медленно. Проверьте несколько примеров каждой группы вместе с руководителем проекта. Если классификация смешивает зависимость и личный комментарий, измените словарь. Сводка должна помогать убрать системное препятствие — например, ожидание решения без владельца, — а не стыдить автора самой старой строки.
Оставьте действия в руках команды
На первом этапе ИИ формирует только очередь для просмотра. Владелец проекта подтверждает блокировку, пишет человеку или корректирует срок по принятому процессу. Массовое изменение статусов, закрытие карточек, назначение сотрудников и отправка уведомлений отключены. Перед любым изменением проверьте историю задачи и зависимости: устаревший комментарий может описывать уже снятое препятствие. Сохраните исходную выгрузку, чтобы спорную рекомендацию можно было проверить и отменить.
Проверьте пилот на старых данных
Возьмите завершённый отрезок проекта и сравните сигналы модели с тем, что команда действительно считала блокировкой. Отдельно посчитайте пропущенные препятствия, лишние тревоги и время, которое ушло на подтверждение каждой строки. Покажите выборку второму руководителю, не участвовавшему в настройке. Если только автор запроса понимает метки, критерии плохо переданы. До запуска на текущей доске обновите категории и повторите выборочную проверку.
Ограничьте срок и область использования
Доска может содержать внутренние оценки, коммерческие сроки и клиентские данные. Используйте согласованный сервис, удалите временную копию по регламенту и не сохраняйте подробные комментарии дольше необходимого. Зафиксируйте, какая версия статусов анализировалась: изменение процесса делает сравнение недель некорректным. Если сотрудник оспаривает сигнал, должна быть возможность открыть основание, исправить категорию и убрать ошибочную отметку из отчёта.
Разберите один сигнал от начала до решения
Возьмите конкретную строку и пройдите путь вручную: откройте карточку, прочитайте актуальный комментарий, найдите зависимость, проверьте последнее изменение и спросите владельца, существует ли препятствие сейчас. Затем сравните эту картину с кратким выводом модели. Если системе понадобилось предположить причину, которой нет в полях, сигнал нельзя превращать в отчёт руководителю как установленный факт. Такая проверка показывает, каких данных не хватает: срока ответа внешней стороны, статуса решения или ответственного за входной материал. Добавьте только нужное поле, а не весь внутренний чат.
Измеряйте пользу без рейтинга людей
Сравнивайте две одинаковые недели по времени от обнаружения препятствия до его снятия, доле подтверждённых сигналов и числу задач, которые команда смогла разблокировать. Не используйте количество просроченных карточек как оценку сотрудника: на него влияют внешние ожидания, размер задачи и приоритеты. Отдельно спросите участников, стало ли понятнее, кто ждёт решения и что требуется дальше. Если система ускоряет сортировку, но создаёт больше тревожных уведомлений, сузьте поток. Хороший результат — более короткий путь к следующему конкретному действию, а не более внушительная панель метрик.
FAQ: можно ли автоматически переносить просроченную задачу?
Нет. ИИ может показать дату и зависимость, но новый срок согласует владелец проекта с командой и участниками процесса.
FAQ: означает ли частая блокировка низкую эффективность сотрудника?
Нет. Она может быть вызвана внешним решением, неясными требованиями или общей зависимостью. Не используйте категории доски как рейтинг людей.
FAQ: что делать, если комментарий содержит мало контекста?
Отметить задачу как неопределённую и запросить уточнение у владельца. Не выводить причину задержки по одному слову или старой дате.