В вашем экземпляре Jira прямо сейчас существует метафорическое кладбище. Где-то между столбцом «В процессе» и глубинами вашего бэклога, вероятно, есть тикет, созданный три года назад с пометкой «Исследовать потенциальные улучшения производительности», на который никто не обращал внимания со времён Великой Рефакторинга 2023 года. Может быть, таких пятьдесят. А может, пятьсот.
Я собираюсь сделать спорное заявление и готов к гневным комментариям: вероятно, вам стоит удалить большинство из них.
Это не обычная статья с советами по повышению продуктивности, в которой вам говорят использовать более качественные метки и внедрять больше автоматизации (хотя это тоже важно). Речь идёт о признании того, что ваш экземпляр Jira превратился в ситуацию цифрового накопления, и, как и при любом хорошем вмешательстве в накопительство, иногда самое полезное, что вы можете сделать, — это выбросить что-то.
Позвольте мне объяснить почему, и, что более важно, как это сделать, не удалив случайно тикет, содержащий единственную документацию для вашей критической платёжной системы.
Проблема с тикетами в Jira, о которой никто не говорит
Ваш экземпляр Jira лжёт вам. Не злонамеренно — он просто делает то, для чего был предназначен. Каждый созданный вами тикет сохраняется навсегда, индексируется и становится доступным для поиска. Звучит здорово, пока вы не поймёте, что доступность для поиска без отбора — это просто шум.
Когда вы в последний раз просматривали пятьдесят нерелевантных тикетов, чтобы найти нужный? Когда вы в последний раз видели, как новый член команды открывает старый тикет, предполагает, что он всё ещё актуален, и тратит два часа на расследование проблемы, которая уже была решена в 2024 году? Когда вы в последний раз испытывали это неприятное чувство, что, возможно, вам всё же стоит проверить статус тикета, прежде чем реализовывать что-то, что, возможно, уже реализовано?
Это проблема тикетного долга. И, как и технический долг, тикетный долг со временем накапливается.
Симптомы следующие:
- В вашем бэклоге тысячи тикетов, и вы не помните, зачем большинство из них существует.
- Новые члены команды спрашивают: «Это всё ещё актуально?» чаще, чем «Как это исправить?».
- Фильтры настолько сложны, что только три человека знают, как их правильно использовать.
- У вас есть несколько тикетов для одной и той же проблемы, созданных разными людьми в разное время.
- Ваши показатели скорости бессмысленны, потому что половина ваших тикетов относится к проектам, которых больше нет.
Почему это произошло (и почему это не ваша вина)
Jira была разработана как постоянная система учёта. Всё поступает, и всё остаётся, потому что никогда не знаешь, когда тебе понадобится найти тот единственный тикет 2019 года о том единственном особом случае в системе аутентификации. Это фундаментально консервативная философия проектирования — лучше сохранить, чем потерять.
Но вот в чём дело: эта философия отлично работала, когда в вашей команде было восемь человек и пятьдесят активных проектов. Она не работает, когда у вас пятьдесят человек, двести проектов и шестнадцать лет накопленных тикетов.
Большинство команд попадают в ловушку: вы создаёте тикет, когда что-то требует внимания. Вы обновляете его, если работаете над ним. Затем происходит одно из двух:
- Вы завершаете его и отмечаете как выполненное (может быть).
- Он навсегда застревает в каком-то наполовину завершённом состоянии, пока не появится работа с более высоким приоритетом, и вы в конечном итоге перестаёте на него смотреть.
Проблема в том, что вторая категория встречается гораздо чаще, чем кто-либо хочет признать. И эти тикеты как цифровые сквоттеры — они ничего не делают, занимают мысленное пространство и активно ухудшают вашу систему.
Аргументы в пользу радикального удаления
Вот что происходит, когда вы удаляете половину своих тикетов:
- Ваши фильтры снова начинают работать. Те запросы JQL, которые возвращали шестьсот результатов? Вдруг становятся полезными. Фильтр «Требуется проверка», который показывал всё, что старше трёх месяцев? Вдруг показывает фактических кандидатов на проверку.
- Новые члены команды перестают путаться. Они открывают тикет и обычно могут предположить, что это что-то, что действительно волнует команду. Революционно, я знаю.
- Ваши метрики становятся значимыми. Скорость, диаграммы сгорания, время цикла — все эти измерения становятся реальными данными, а не шумом. Вы можете увидеть, действительно ли вы стали быстрее решать проблемы.
- Вы перестаёте повторяться. После очистки дубликатов тикетов вы не решаете одну и ту же проблему дважды и не удивляетесь, почему она снова сломалась.
- Ваш бэклог становится стратегическим документом. Вместо того чтобы быть «местом, где идеи работы отправляются умирать», он становится фактическим представлением будущей работы.
Это не значит быть жестоким по отношению к старым тикетам. Это о том, чтобы сохранять честность вашей системы.
Что подлежит удалению?
Не всё должно быть удалено. Вы не проводите политику выжженной земли. Вот структура, которую я рекомендую:
Удаляйте тикеты без сожаления, если они:
- Не тронуты более 18 месяцев.
- Не имеют комментариев, а описание расплывчато или непонятно.
- Отмечены как «Не исправлять» или «Дубликат» и находятся в этом состоянии шесть месяцев.
- Связаны с продуктами/проектами, которые больше не существуют.
- Предлагают изменения в нечто, что уже изменено.
- Являются функциями «было бы неплохо», которые ни один реальный пользователь не запрашивал в прошлом году.
- Отмечены «Заблокировано» дольше, чем типичный спринт вашей команды.
- Содержат информацию, которая уже задокументирована в другом месте и более чётко.
Сохраняйте (и обновляйте) тикеты, если они:
- Имеют активное обсуждение и над ними работают или отслеживают.
- Представляют известные ошибки в производственных системах.
- Связаны с требованиями соответствия, безопасности или регулирования.
- Были явно включены в дорожную карту.
- Были упомянуты в документации или архитектурных решениях.
- Заблокированы по конкретным зависимостям, которые могут быть разблокированы.
Объединяйте/консолидируйте тикеты, если:
- Несколько тикетов описывают одну и ту же проблему.
- Тикет является дубликатом более нового тикета с лучшей информацией.
- Подзадачи на самом деле являются просто копиями одной и той же работы.
Пошаговый процесс удаления (не паникуйте)
Здесь вы фактически выполняете действие. Вот процесс:
Шаг 1: Экспорт и резервное копирование
Перед тем как удалить что-либо, экспортируйте данные Jira. Вы можете использовать Atlassian Data Center или облачные функции экспорта или использовать сторонний инструмент. Сохраните их где-нибудь. Они вам не понадобятся, но и не будут лишними.
# Если вы используете REST API Jira Cloud, вы можете экспортировать задачи
# Пример: получить все задачи за последние 18 месяцев
curl -X GET "https://your-domain.atlassian.net/rest/api/3/search" \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"jql": "updated < -18m",
"maxResults": 1000,
"fields": ["key", "summary", "status", "updated"]
}' > backup.json
Шаг 2: Создание фильтров для кандидатов на удаление
Используйте JQL для определения тикетов на удаление. Вот несколько полезных запросов:
# Нетронутые тикеты из старых проектов
updated < -18m AND assignee is EMPTY
# Дубликаты
type = "Duplicate" AND resolution = "Duplicate" AND updated < -6m
# Древние тикеты «Не исправлять»
resolution = "Won't Fix" AND updated < -12m
# Всё в заархивированном проекте
project = "OLDPROJ" AND status != Done
# Заблокированные запросы функций
type = "Feature Request" AND status = "Blocked" AND updated < -12m
# Низкий приоритет, никогда не тронутый, явно помеченный как будущая работа
priority = Low AND assignee is EMPTY AND labels = "future-consideration" AND created < -12m
Шаг 3: Проверка перед удалением
Создайте фильтр Jira для каждой категории удаления. Поделитесь им с командой. Попросите обратную связь. Дайте людям неделю на возражения. Это не наказание; это весенняя уборка.
Шаг 4: Удаление по категориям
Не удаляйте все пятьсот тикетов за один раз. Делайте это по категориям, распределённо во времени. Это даст вам шанс осознать, если вы случайно удалили что-то важное.
Для массового удаления через API:
# Получить список задач для удаления (используя ваш фильтр)
curl -X GET "https://your-domain.atlassian.net/rest/api/3/search" \
-H "Authorization: Bearer YOUR_TOKEN" \
-d '{"jql": "your-deletion-filter"}' > issues_to_delete.json
# Удалить каждую задачу (пройтись по результатам)
# Примечание: вам нужны права на удаление, и тикет не должен быть связан с другими задачами
curl