Баг-трекинг: workflow, приоритеты и SLA на исправление

Рабочий баг-трекинг держится на четырёх решениях. Отдельный тип задачи Bug с обязательными полями. Короткий workflow из семи статусов. Разделение серьёзности и приоритета. SLA, который считается от подтверждения бага, а не от момента, когда кто-то написал о проблеме. Всё это настраивается и в Plane, и в Jira. Сложность не в инструменте, а в договорённостях, которые команда соблюдает каждый день.

Статья для тимлидов, QA-лидов, продактов и руководителей IT-отделов, которые хотят навести порядок в багах. Ниже — поля бага, статусы, матрица серьёзности и приоритета, пример SLA, поток из поддержки и Sentry, метрики, типичные ошибки и короткая схема настройки в Plane и Jira.

Тип задачи Bug: какие поля нужны

Баг не должен быть обычной задачей с меткой «bug». Отдельный тип даёт свой набор полей, свой workflow и честную отчётность. В Jira это стандартный тип задачи Bug. В Plane — отдельный Work item type со своими свойствами.

Поле	Когда заполняется	Зачем
Краткое описание	При создании	Поиск дубликатов и понятный список
Шаги воспроизведения	При создании, обязательно	Без них баг не берут в работу
Ожидаемый и фактический результат	При создании	Отделяет баг от пожелания
Окружение и версия	При создании	Браузер, ОС, версия приложения, стенд
Серьёзность	При создании, уточняется на триаже	Насколько сломан продукт
Источник	При создании	Поддержка, QA, Sentry, внутренний пользователь
Приоритет	На триаже	Как быстро чиним
Компонент или модуль	На триаже	Кто владелец кода
Ответственный и срок	На триаже	Кто и к какому сроку
Версия исправления	При закрытии	Связь с релизом

Правило, которое экономит больше всего времени: баг без шагов воспроизведения возвращается автору. Не «разберёмся», а возвращается. Через две-три недели такой практики качество заявок заметно растёт.

Workflow: статусы от сообщения до закрытия

Workflow бага короче, чем кажется. Рабочий вариант:

1. Новый — баг заведён, никто его ещё не смотрел.
2. Триаж — дежурный проверяет дубликаты, воспроизводит, ставит серьёзность и приоритет.
3. Подтверждён — баг воспроизведён, приоритет и срок назначены. С этого момента считается SLA.
4. В работе — разработчик исправляет.
5. На проверке — код-ревью и проверка QA на стенде.
6. Готов к релизу — исправление влито и ждёт выкладки.
7. Закрыт — исправление в продакшене.

Два финальных исхода без исправления: Дубликат со ссылкой на основной баг и Не воспроизводится с комментарием, что именно проверяли. Отдельный статус «Отложен» лучше заменить приоритетом и сроком: отложенный баг без даты не вернётся никогда.

Переоткрытие делайте переходом из «Закрыт» обратно в «Подтверждён», а не новым багом. Тогда метрика переоткрытий считается автоматически.

Как проводить триаж

Триаж — это не совещание, а обязанность конкретного человека. Назначьте дежурного на неделю, по очереди из разработчиков или QA. Его задача на каждый новый баг:

1. Найти дубликаты по описанию и компоненту. Если нашёл — закрыть как «Дубликат» со ссылкой.
2. Воспроизвести на указанной версии. Не получилось — запросить данные у автора или закрыть как «Не воспроизводится».
3. Поставить серьёзность и охват, получить приоритет по матрице ниже.
4. Назначить компонент, ответственного и срок по SLA.
5. Для P1 сразу поднять тревогу в рабочем канале, не дожидаясь, пока кто-то откроет трекер.

Для P1 и P2 триаж идёт непрерывно, для остальных достаточно одного-двух проходов в день. Раз в неделю владелец продукта просматривает решения дежурного и при необходимости меняет приоритеты. Так ответственность за решение остаётся у одного человека, а проверка — у другого.

Серьёзность и приоритет: матрица

Серьёзность (severity) — свойство самого бага. Приоритет (priority) — решение команды. Их путают, когда одно поле пытается ответить на оба вопроса. Например, опечатка на главной странице имеет низкую серьёзность, но может получить высокий приоритет перед запуском рекламы.

Серьёзность в четыре уровня:

• S1 Критичная — продукт или ключевая функция недоступны, есть потеря данных или денег, нарушена безопасность.
• S2 Высокая — важная функция работает неправильно, обходного пути нет.
• S3 Средняя — функция работает с ошибкой, обходной путь есть.
• S4 Низкая — косметика, тексты, неудобство.

Матрица для триажа: по строкам серьёзность, по столбцам охват.

Серьёзность ↓ / Охват →	Все или ключевые клиенты	Часть пользователей	Единичные случаи
S1 Критичная	P1	P1	P2
S2 Высокая	P1	P2	P3
S3 Средняя	P2	P3	P4
S4 Низкая	P3	P4	P4

Матрица даёт приоритет по умолчанию. Владелец продукта может его поднять или опустить, но с комментарием, почему. Так спорные решения остаются видимыми.

SLA на исправление: пример стартовых целей

Цифры ниже — пример для продуктовой команды с рабочими часами и дежурством для P1. Это ориентир для первой версии, а не норма. Подберите сроки под свой продукт, договоры с клиентами и реальный состав команды.

Приоритет	Реакция (до подтверждения)	Исправление	Когда работаем	Эскалация
P1	В течение часа	В тот же день, hotfix	Круглосуточно дежурный	Сразу тимлиду и руководителю
P2	В течение рабочего дня	В текущем спринте	Рабочие часы	Тимлиду при угрозе срока
P3	В течение двух рабочих дней	В ближайшие два спринта	Рабочие часы	На планировании спринта
P4	На еженедельном триаже	По возможности	Рабочие часы	Пересмотр раз в квартал

Три правила, без которых SLA превращается в декорацию:

• SLA считается от статуса «Подтверждён», а реакция — от статуса «Новый».
• Срок проставляется на триаже, вручную или автоматизацией, если ваша версия трекера это позволяет.
• Просроченные баги ищутся сохранённым фильтром — PQL в Plane, JQL в Jira — и выводятся на дашборд, который команда видит каждый день.

В Jira Service Management есть полноценные таймеры SLA. В Plane и в обычной Jira контроль строится на сроках, фильтрах и дашбордах. Для большинства продуктовых команд этого достаточно.

Поток из поддержки и Sentry

Из поддержки

Баги от клиентов приходят через поддержку, и здесь важно не пускать сырые обращения прямо в бэклог разработки. Схема: одна входящая очередь, дежурный на триаже, перевод в баг только после проверки.

В Plane входящую очередь закрывает Intake: заявки и email-формы попадают в отдельный поток, откуда их принимают в проект или отклоняют. В Jira эту роль обычно играет Jira Service Management. Связь сохраняется ссылкой: в баге — номер обращения, в обращении — ссылка на баг. Клиенту отвечает поддержка, разработчики не переписываются с клиентами в комментариях к задаче.

Из Sentry

Sentry ловит ошибки раньше пользователей, но если создавать задачу на каждое событие, трекер утонет за неделю. Правила:

• Задача создаётся на проблему в Sentry, а не на каждое событие.
• Автоматически — только после порога: частота, число затронутых пользователей, новая ошибка в свежем релизе.
• Остальное разбирает дежурный вручную раз в день.
• В задаче хранится ссылка на проблему в Sentry, а серьёзность ставит человек.

У Plane есть штатная интеграция с Sentry. Для Jira связку настраивают через интеграцию на стороне Sentry, через Jira Automation или вебхуки. Проверьте, какой вариант доступен для вашей версии и тарифа.

Контекст Казахстана. Многие клиенты сообщают о проблемах в WhatsApp, голосовыми и скриншотами, на русском или казахском. Поддержке нужен шаблон, по которому она переводит такое сообщение в баг с шагами воспроизведения, а не пересылает его разработчику целиком. Второй момент — персональные данные: скриншоты из личных кабинетов, телефоны и ИИН в описаниях, данные пользователей в событиях Sentry. Маскируйте их до заведения бага. Если без них не обойтись и важно, чтобы они хранились в Казахстане, держите трекер и мониторинг ошибок в self-hosted контуре на сервере в РК.

Метрики баг-трекинга

Метрик немного, и все они считаются из статусов, если workflow настроен честно:

• Время до подтверждения — от «Новый» до «Подтверждён». Показывает, работает ли триаж.
• Время до исправления по приоритетам — от «Подтверждён» до «Закрыт».
• Доля нарушений SLA — по каждому приоритету отдельно.
• Доля переоткрытых багов — признак поспешных исправлений или слабой проверки.
• Доля багов из продакшена — сколько багов нашли пользователи и Sentry, а не QA.
• Возраст открытого бэклога — сколько багов висит дольше квартала.

В Plane метрики собираются на Dashboards по сохранённым представлениям, в Jira — на дашбордах по JQL. Смотрите их в динамике раз в неделю или раз в спринт. Одна цифра без тренда ничего не говорит.

Типичные ошибки

• Одно поле «Приоритет» вместо двух. Всё становится «высоким», и приоритет перестаёт что-то значить.
• Баги живут в общем бэклоге без отдельного типа. Отчёт по качеству собрать невозможно.
• SLA без дежурного. Если никто не отвечает за триаж, сроки нарушаются с первого дня.
• Автосоздание задач из Sentry без порога. Трекер заполняется шумом, и важные ошибки теряются.
• Workflow на 15 статусов. Люди перестают двигать задачи, и статусы врут.
• Баги закрываются при мерже, а не при выкладке. Клиент всё ещё видит ошибку, а в трекере она «закрыта».
• Нет регулярной чистки. Бэклог из сотен багов старше года никто не читает. Раз в квартал их либо переподтверждают, либо закрывают.

Настройка в Plane и в Jira

Элемент	Plane	Jira
Тип Bug	Work item type со своими свойствами	Стандартный тип Bug и поля
Статусы	Настраиваются в проекте	Workflow и схема workflow
Входящая очередь	Intake, email-формы	Jira Service Management
Фильтры и SLA-контроль	PQL, Views	JQL, фильтры
Автоматизация	Automations, Runner	Jira Automation
Отчётность	Dashboards	Дашборды
Связь с релизом	Releases, Cycles	Версии, спринты
Ошибки из кода	Интеграция с Sentry	Интеграция через Sentry, Automation или вебхуки

Если в трекере уже есть правила, которые двигают задачи и уведомляют дежурных, полезно разобраться, где хватит простого правила, а где нужен скрипт. Об этом — в статье Автоматизация в таск-трекере: правила, скрипты или AI-агенты. А если баги — лишь один из потоков вашей команды наряду с заявками и инцидентами, посмотрите разбор таск-трекера для IT-отдела.

Как мы это делаем

Мы начинаем с диагностики: смотрим, где сейчас живут баги, кто их заводит, сколько статусов и полей реально используется и где теряются сроки. Затем настраиваем тип Bug, workflow, матрицу и SLA на одной продуктовой команде, подключаем поддержку и Sentry и две-три недели собираем метрики. Когда схема прижилась, переносим её на остальные команды и оставляем владельцу процесса регламент триажа.

Как устроен процесс и что входит в результат, описано на странице внедрения таск-трекеров Jira и Plane.

---

Источники. Plane: репозиторий на GitHub и тарифы. Jira: прайс-лист и тарифы Atlassian.

Термины простыми словами

SLA (Service Level Agreement)

Договорённость о сроках: за сколько команда реагирует на баг и за сколько его исправляет. Здесь сроки зависят от приоритета и считаются от подтверждения бага.

Workflow

Последовательность статусов, через которые проходит баг: от «Новый» до «Закрыт». Короткий workflow люди реально соблюдают, длинный перестают обновлять.

Триаж

Первичный разбор нового бага: проверка на дубликат, воспроизведение, оценка серьёзности и приоритета. Его ведёт назначенный дежурный, а не совещание.

Серьёзность (severity) и приоритет (priority)

Серьёзность показывает, насколько баг ломает продукт. Приоритет показывает, как быстро его будут чинить с учётом бизнеса. Это два разных поля, и их не стоит смешивать.

Sentry

Сервис, который автоматически ловит ошибки в работающем продукте и собирает их в список. Часто замечает проблему раньше, чем пользователи напишут в поддержку.

Hotfix

Срочное исправление, которое выкладывают отдельно, не дожидаясь планового релиза. Применяется для самых критичных багов.

Продакшен

Рабочая версия продукта, которой пользуются клиенты, в отличие от тестовых стендов. Баг считается закрытым, только когда исправление попало туда.

JQL и PQL

Языки запросов в Jira и Plane для поиска задач по условиям. С их помощью сохраняют фильтры, например «просроченные баги», и выводят их на дашборд.