Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Сценарий и границы задачи
Руководитель видит тысячи открытых задач, но не понимает, какие из них действительно требуют решения сегодня. Общий список по дате создания смешивает новые обращения, согласованные ожидания и забытые работы. Нужны небольшие проверяемые выборки, каждая из которых отвечает на один управленческий вопрос.
Начните с вопроса руководителя, например: какие незавершённые задачи уже требуют нового решения о сроке. Не пытайтесь сразу построить универсальный запрос для любого отклонения. Несколько коротких фильтров с понятными владельцами обычно проще проверять, объяснять и обсуждать на операционном обзоре.
Модель и договорённости
Выделите три сигнала: незавершённая задача без ответственного, нарушенный срок и отсутствие движения. Для каждого определите допустимые исключения. Поле updated отражает любое обновление, поэтому не следует называть его временем последней полезной работы. Если нужен именно бизнес-сигнал, согласуйте отдельный способ фиксации события.
У каждого сигнала должна быть договорённая реакция. Задача без срока не обязательно просрочена, а отсутствие обновлений не всегда означает забытый запрос. В описание фильтра добавьте ограничения интерпретации: он предлагает кандидатов для разбора, а не автоматически устанавливает вину или необходимость закрытия.
Порядок внедрения
Начните с одного проекта и явного условия незавершённости. Добавляйте только один предикат за раз, сверяя результаты с несколькими известными задачами. Для отсутствующего исполнителя используйте assignee IS EMPTY, для сортировки — понятный пользователям порядок. Сохраните фильтр с описанием смысла, владельца и периодичности обзора, затем настройте доступ читателям.
Публикуйте каждый фильтр вместе с одним предложением о решении, которое он поддерживает. Например, список неназначенных задач нужен дежурному для распределения работы, а список просроченных обязательств — владельцу процесса для пересогласования срока. После первой недели сравните спорные результаты с исходной формулировкой вопроса, а не усложняйте запрос сразу для всех исключений.
Проверки на реальных сценариях
Составьте набор: просроченная задача, будущий срок, пустой срок, завершённая задача, исключение и задача без исполнителя. Проверьте присутствие каждой в нужной выборке. Повторите поиск от имени руководителя и исполнителя: различия в правах могут объяснять несовпадение числа результатов лучше, чем ошибка в JQL.
Для каждого условия включите задачу ровно на границе выбранного интервала и по обе стороны границы. Проверьте пустые значения явно. Если фильтр использует относительное время, повторите контроль в другой день и сохраните дату проверки, чтобы объяснить нормальное изменение состава результатов.
Ошибки и диагностика
Условие по статусу с конкретным названием ломается при переименовании или разных workflow. Пустые значения также часто выпадают из логики отрицания. Перед исправлением запроса сформулируйте ожидаемый результат словами и разберите спорные задачи по одной. Не добавляйте всё новые OR без скобок и проверки приоритета условий.
Сохраните ключи задач, которые спорно попали в выборку, вместе с текстом запроса и датой. Это позволяет отличить ошибку логики от нормального изменения данных после обзора.
Возврат и восстановление
Сохраните прежний текст фильтра перед редактированием и предупредите владельцев зависимых дашбордов. Если новый запрос создаёт неверную картину, верните предыдущую версию и временно опубликуйте уточнённую выборку отдельно. Не закрывайте массово задачи лишь потому, что они попали в список старой работы: сначала подтвердите их действительный смысл.
При возврате старого фильтра проверьте дашборды и подписки, которые его используют. Изменение запроса способно повлиять на регулярные управленческие решения даже без изменения задач. Если по ошибочной выборке уже закрыли работу, список этих ключей передайте владельцам для отдельного восстановления, сохраняя причину каждого обратного действия.
Приёмка и дальнейший контроль
На еженедельном обзоре считайте, сколько найденных задач получили решение: назначение, новый срок, подтверждённое ожидание или обоснованное закрытие. Число результатов само по себе не является показателем эффективности. Полезный фильтр сокращает время разбора и приводит к конкретному действию, сохраняя понятные исключения и воспроизводимость.
Полезно вести небольшой журнал решений по найденным задачам: кто назначен, какой срок согласован, почему работа остаётся в ожидании. Это позволяет отличать уменьшение списка благодаря управлению от уменьшения из-за изменившегося запроса. Сам фильтр не исправляет бэклог, он только делает обсуждение точнее.
Механизм продукта и применимость
Расширенный поиск Jira использует JQL для задания критериев и сортировки результатов через ORDER BY. Сохранённую выборку можно использовать как основу регулярного рабочего обзора.
JQL в статье используется для поиска кандидатов на операционный разбор. Он не определяет автоматически, полезна ли работа и виноват ли исполнитель. Источник подтверждает механизм запроса; интерпретацию обновлений, просрочек и пустых значений команда должна согласовать с собственным процессом управления задачами.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу