Всем привет, это команда продукта SimpleOne SDLC. Поговорим о вещи, которую в командах обычно не обсуждают вслух — о бэклоге дефектов, который никто не разгребает.

И даже не потому, что лень, а потому, что нет выстроенного процесса.

Разговор, который случается в каждой второй команде. Понедельник, утро перед демо:

— Сколько у нас открытых дефектов?

— Около пятисот.

— Из них критичных?

— Сейчас посмотрю… Тут написано P1, но это, кажется, вообще из прошлого квартала. Репродьюсить уже не получается.

— А вот эти триста P3 — они вообще актуальны?

— Не знаю. Их Вася заводил, а Вася уволился в феврале…

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

Но сегодня не про Васю. Сегодня про то, что делать с этими пятьюстами тикетами — независимо от того, кто их заводил.

Эта статья для руководителей, которые смотрят на этот список и не понимают, с чего начать. Расскажем, как навести порядок — и главное, как не дать ему снова превратиться в свалку.

Отдельную благодарность за помощь в написании статьи выражаем Панфиловой Яне.

Severity ≠ Priority: фундамент, без которого все сломается

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

1. Severity — технический масштаб проблемы: насколько сильно баг ломает функциональность. Оценивает QA или разработчик.

2. Priority — бизнес-решение о срочности исправления. Принимает Product Owner с учетом контекста: сколько пользователей затронуто, есть ли обходной путь, каков риск.

Пример, который не бьется с интуицией: баг с неправильным порядком сортировки в отчете для CFO — Severity: Low (технически косметика), Priority: Critical (CFO ждет отчет завтра утром). И наоборот: падение редко используемого внутреннего инструмента — Severity: Critical, Priority: Low.

Если в команде нет явного соглашения, кто что оценивает и по каким критериям, приоритизация всегда будет субъективной. Вот практическая матрица, которую можно взять за основу:

SLA для дефектов: «возьмем в следующем спринте» — это не ответ

Для P0 и P1 спринтовая логика не работает: нужны явные временные обязательства с цепочкой эскалации — иначе «критический баг» будет висеть неделями просто потому, что никто не обозначил дедлайн.

Важный момент про P0: это не просто «очень важный баг». P0 — это инцидент, который обрабатывается по процессу incident management, а не через обычный бэклог. Если команда не разделяет эти два потока — это первое, что нужно исправить. В enterprise-контексте P0 на проде еще и проходит через Change Advisory Board: отдельный трек с формальным согласованием.

Кто решает «чинить или нет»: цепочка ответственности

Типичная ошибка — отдавать приоритизацию полностью разработчикам. Разработчик честно ставит P1: любой баг кажется серьезным, когда ты сам его нашел или тебе за него прилетело. 

Правильная цепочка выглядит так:

1. QA фиксирует факт и технический контекст — шаги воспроизведения (без них тикет не принимается), severity-оценку, затронутый сценарий, частоту проявления, версию и среду.

2. Разработчик/Тимлид оценивает техническую сторону — трудозатраты, риск регрессии, наличие workaround, связь с техдолгом.

3. Product Owner принимает бизнес-решение — сколько пользователей затронуто (реальная цифра, не интуиция), какова стоимость задержки, есть ли обходной путь, который можно коммуницировать.

4. Архитектор или Security-инженер подключается при любом баге, затрагивающем данные, авторизацию или архитектурные контракты между сервисами.

Что обязательно должно быть в тикете

Баг без контекста — это не баг. Открываете тикет «Кнопка не работает. При нажатии ничего не происходит. P2. Автор: Миша (уволился). Создан: 14 месяцев назад» — и закрываете обратно. Какая кнопка? В каком модуле? Воспроизводится ли сейчас? Непонятно.

Минимальный стандарт тикета, который можно взять в работу:

Сравните: «Кнопка не работает. P2» и «Кнопка Submit на странице оформления заказа не реагирует при quantity > 99. Staging v3.2.1, Chrome 120. Workaround: ввести значение через консоль». Первый тикет вернётся к автору. Второй — в работу через час.

Груминг бэклога: как проводить, а не просто планировать

Груминг дефектов — это отдельная встреча. Не часть груминга фич, не «обсудим в конце планирования». Когда их смешивают, дефекты всегда проигрывают фичам в борьбе за время. 

Состав: QA-лид, тимлид, PO. Архитектор по необходимости, не постоянно.

Частота: раз в спринт, 45–60 минут. При бэклоге > 200 тикетов первые 3–4 сессии лучше сделать по 2 часа — для «расчистки».

Повестка:

• новые дефекты за спринт: severity/priority review — 15 мин;

• дефекты без движения > 2 спринтов: решение по каждому — 20 мин;

• Reopen-баги: разбор причин, почему DoD не сработал — 10 мин;

• метрики бэклога: тренды за последние 3 спринта — 5–10 мин.

Выходной артефакт: не «обсудили», а конкретные решения по каждому пересмотренному тикету: «закрыли как won't fix», «перенесли в P3», «взяли в следующий спринт». Если после груминга статусы не поменялись — встреча не состоялась.

При 500+ тикетах пересматривать все каждую неделю физически невозможно. Сегментируйте:

Won't Fix: как закрывать без конфликтов и с памятью

Won't Fix — это не провал и не «не хотим делать». Это честное признание: баг реальный, но исправлять его нецелесообразно. Разница между этими двумя формулировками огромная — и именно поэтому каждый Won't Fix требует явного обоснования.

Когда Won't Fix оправдан:

1. Сценарий затрагивает < N% активных пользователей (порог должна определить команда явно, не «мало»).

2. Исправление требует рефакторинга модуля, который запланирован к переписыванию.

3. Стоимость исправления несопоставима с бизнес-риском.

4. Существует задокументированный workaround, который покрывает потребность.

Шаблон закрытия, который снимет все вопросы через полгода:

Поле «Дата пересмотра» — не формальность. Без него Won't Fix превращается в мусорную корзину, куда удобно выбрасывать то, что не хочется делать. Метрика для самопроверки: если Won't Fix > 30% всех закрытых дефектов — это симптом либо слишком низкого quality bar при заведении, либо технического долга, который не признается таковым.

Баг из прода — это не просто еще один тикет

Дефект, который обнаружил пользователь или мониторинг в проде, несет контекст, которого нет в обычном баге: сколько людей пострадало, было ли нарушение SLA, дошло ли до бизнеса. Без этого контекста разработчик видит технический дефект. С ним — видит бизнес-последствие. Это кардинально меняет приоритизацию.

Минимальная цепочка, которая не должна разрываться:

Последний пункт — самый важный и самый редкий. Без постмортема для P0/P1 команда бесконечно исправляет симптомы. RCA должен отвечать на вопрос: какое системное условие позволило этому багу добраться до прода? Не «разработчик ошибся», а «у нас нет интеграционного теста для этого сценария» или «мониторинг не покрывает этот путь». Первый ответ закрывает один баг. Второй — предотвращает класс багов.

Как эта цепочка выглядит на практике — в демонстрации плагина кросс-продуктовой интеграции SDLC и ITSM:

Метрики: что измерять и как не врать самим себе

Интуиция говорит: «у нас много багов, это плохо». Метрики говорят точнее — где именно сломан процесс.

Важная оговорка: доля дефектов, дошедших до прода 20% для внутреннего инструмента с 50 пользователями и 20% для платежного сервиса — принципиально разные ситуации. Метрики имеют смысл только в динамике и только в контексте. Смотрите тренд, а не абсолют.

Дефекты как симптом — не как болезнь

Если один модуль стабильно генерирует > 30% всех дефектов — это не проблема QA. Это сигнал технического долга: высокая цикломатическая сложность, низкое тестовое покрытие или размытая ответственность за код. Возможные причины: модуль менялся много раз без рефакторинга, тестовое покрытие < 40%, размытая ответственность («все вносят правки, никто не владеет»).

Когда вам нужно пойти к бизнесу с аргументом про рефакторинг, забудьте про «код выглядит плохо» — это не то, что бизнес воспримет как реальный аргумент.

С бизнесом нужно говорить иначе: «За последний квартал мы закрыли 34 дефекта в модуле оплаты. Это 180 часов работы команды — только на исправления, без новых фич. Рефакторинг модуля займет 3 спринта, после чего этот поток дефектов сократится в разы. По нашей оценке, вложение окупится уже через два квартала».

Бизнес понимает деньги и время, а не красоту кода.

Anti-patterns, которые убивают процесс

Мы видели эти паттерны достаточно часто, чтобы дать им имена. 

1. «Все P1» — команда выставляет высокий приоритет всему, чтобы не расстраивать стейкхолдеров. В итоге P1 теряет смысл. Лечится явной матрицей с критериями.

2. Груминг без решений — встреча прошла, тикеты обсудили, но статусы не поменялись. Правило простое: каждый тикет на груминге завершается явным решением. 

3. «Вася разберется» — баг назначен человеку, а не модулю. Вася ушел — баг завис. Назначайте на модуль или команду, не на человека.

4. Бесконечный triage — новые баги неделями висят без severity-оценки. Правило: тикет старше 3 рабочих дней без оценки автоматически попадает в повестку следующего груминга. В SimpleOne SDLC, Jira, YouTrack это настраивается за 15 минут.

5. Won't Fix как корзина — используется для всего, что не хочется делать. Требуйте обоснования с цифрами. Без цифр — не принимается.

Если бэклог уже в хаосе: план на 4 недели

Не пытайтесь навести порядок за один груминг. Реалистичный план:

Недели 1–2: аудит

Пройдитесь по бэклогу и разбейте тикеты на категории: воспроизводится / не воспроизводится / дубль / нет контекста. Все невоспроизводимое и без контекста — закрыть с комментарием:

«Closed: cannot reproduce / insufficient info. Reopen with reproduction steps if still relevant.»

Недели 3–4: расстановка приоритетов

Оставшиеся актуальные баги прогнать через severity/priority матрицу. Все без четкого бизнес-обоснования для P1/P2 — перевести в P3 или Won't Fix.

С 5-й недели: регулярный процесс

Груминг раз в спринт. SLA для P0/P1 зафиксированы. Метрики в дашборде. В Jira, YouTrack и Linear настройте автоматические уведомления: тикет без движения 3 спринта — автотег для груминга.

По нашей практике после такой расчистки активный бэклог сжимается в 3–5 раз. Оставшееся — реально актуальные задачи с понятными приоритетами. Это не магия — это просто наведенный порядок, который не случился раньше, потому что не было времени и процесса.

***

А сколько тикетов в вашем бэклоге заведены людьми, которых уже нет в компании?