|
Professor Seleznov
|
Всем привет, это команда продукта SimpleOne SDLC. Поговорим о вещи, которую в командах обычно не обсуждают вслух — о бэклоге дефектов, который никто не разгребает.
И даже не потому, что лень, а потому, что нет выстроенного процесса.
Разговор, который случается в каждой второй команде. Понедельник, утро перед демо:
— Сколько у нас открытых дефектов?
— Около пятисот.
— Из них критичных?
— Сейчас посмотрю… Тут написано P1, но это, кажется, вообще из прошлого квартала. Репродьюсить уже не получается.
— А вот эти триста P3 — они вообще актуальны?
— Не знаю. Их Вася заводил, а Вася уволился в феврале…
Вася — это отдельная история. Мы уже писали о том, что происходит, когда ключевой человек уходит и уносит с собой контекст. Бэклог дефектов — один из самых болезненных примеров: баги без автора, без контекста, без понимания, воспроизводится ли это вообще сейчас.
Но сегодня не про Васю. Сегодня про то, что делать с этими пятьюстами тикетами — независимо от того, кто их заводил.
Эта статья для руководителей, которые смотрят на этот список и не понимают, с чего начать. Расскажем, как навести порядок — и главное, как не дать ему снова превратиться в свалку.
Отдельную благодарность за помощь в написании статьи выражаем Панфиловой Яне.
Severity ≠ Priority: фундамент, без которого все сломается
Начнем с самого частого источника хаоса — смешения severity (критичности) и priority (приоритета). Это не синонимы, как вам могло показаться, и именно их путаница порождает ситуацию, когда P2-баг с опечаткой в интерфейсе соседствует с P2-багом, из-за которого данные записываются с ошибкой.
- Severity — технический масштаб проблемы: насколько сильно баг ломает функциональность. Оценивает QA или разработчик.
- Priority — бизнес-решение о срочности исправления. Принимает Product Owner с учетом контекста: сколько пользователей затронуто, есть ли обходной путь, каков риск.
Пример, который не бьется с интуицией: баг с неправильным порядком сортировки в отчете для CFO — Severity: Low (технически косметика), Priority: Critical (CFO ждет отчет завтра утром). И наоборот: падение редко используемого внутреннего инструмента — Severity: Critical, Priority: Low.
Если в команде нет явного соглашения, кто что оценивает и по каким критериям, приоритизация всегда будет субъективной. Вот практическая матрица, которую можно взять за основу:
|
Severity: Critical |
Severity: High |
Severity: Medium |
Severity: Low |
| Бизнес-риск: High |
P0 — fix now |
P1 — текущий спринт |
P2 — следующий спринт |
P2 — следующий спринт |
| Бизнес-риск: Medium |
P1 — текущий спринт |
P2 |
P3 |
Won't Fix / Backlog |
| Бизнес-риск: Low |
P2 |
P3 |
Won't Fix |
Won't Fix |
SLA для дефектов: «возьмем в следующем спринте» — это не ответ
Для P0 и P1 спринтовая логика не работает: нужны явные временные обязательства с цепочкой эскалации — иначе «критический баг» будет висеть неделями просто потому, что никто не обозначил дедлайн.
| Приоритет |
Time to Acknowledge |
Time to Resolve |
Эскалация |
| P0 |
15 минут |
4 часа |
Немедленно → Engineering Manager + PO |
| P1 |
2 часа |
24 часа |
Тимлид + PO |
| P2 |
1 рабочий день |
Текущий или следующий спринт |
Тимлид |
| P3 |
Следующий груминг |
По усмотрению команды |
— |
Важный момент про P0: это не просто «очень важный баг». P0 — это инцидент, который обрабатывается по процессу incident management, а не через обычный бэклог. Если команда не разделяет эти два потока — это первое, что нужно исправить. В enterprise-контексте P0 на проде еще и проходит через Change Advisory Board: отдельный трек с формальным согласованием.
Кто решает «чинить или нет»: цепочка ответственности
Типичная ошибка — отдавать приоритизацию полностью разработчикам. Разработчик честно ставит P1: любой баг кажется серьезным, когда ты сам его нашел или тебе за него прилетело.
Правильная цепочка выглядит так:
- QA фиксирует факт и технический контекст — шаги воспроизведения (без них тикет не принимается), severity-оценку, затронутый сценарий, частоту проявления, версию и среду.
- Разработчик/Тимлид оценивает техническую сторону — трудозатраты, риск регрессии, наличие workaround, связь с техдолгом.
- Product Owner принимает бизнес-решение — сколько пользователей затронуто (реальная цифра, не интуиция), какова стоимость задержки, есть ли обходной путь, который можно коммуницировать.
- Архитектор или Security-инженер подключается при любом баге, затрагивающем данные, авторизацию или архитектурные контракты между сервисами.
Что обязательно должно быть в тикете
Баг без контекста — это не баг. Открываете тикет «Кнопка не работает. При нажатии ничего не происходит. P2. Автор: Миша (уволился). Создан: 14 месяцев назад» — и закрываете обратно. Какая кнопка? В каком модуле? Воспроизводится ли сейчас? Непонятно.
Минимальный стандарт тикета, который можно взять в работу:
Заголовок: [Модуль] Краткое описание проблемы
Не «кнопка не работает», а «Кнопка Submit на странице
оформления заказа не реагирует при quantity > 99»
Severity: [Critical / High / Medium / Low]
Модуль: [обязательное поле]
Версия/среда: [конкретная версия + staging/prod/dev]
Частота: [всегда / иногда / при условии X]
Шаги воспроизведения:
1. ...
2. ...
3. ...
Ожидаемый результат: ...
Фактический результат: ...
Затронутые пользователи: [метрика или оценка, если известна]
Обходной путь: [есть / нет / описание]
Связанный инцидент: [ссылка, если баг пришел с прода] |
Сравните: «Кнопка не работает. P2» и «Кнопка Submit на странице оформления заказа не реагирует при quantity > 99. Staging v3.2.1, Chrome 120. Workaround: ввести значение через консоль». Первый тикет вернётся к автору. Второй — в работу через час.
SimpleOne SDLC: карточка дефекта, в которой есть всё: шаги, статус, приоритет, трудозатраты.
Груминг бэклога: как проводить, а не просто планировать
Груминг дефектов — это отдельная встреча. Не часть груминга фич, не «обсудим в конце планирования». Когда их смешивают, дефекты всегда проигрывают фичам в борьбе за время.
Состав: QA-лид, тимлид, PO. Архитектор по необходимости, не постоянно.
Частота: раз в спринт, 45–60 минут. При бэклоге > 200 тикетов первые 3–4 сессии лучше сделать по 2 часа — для «расчистки».
Повестка:
- новые дефекты за спринт: severity/priority review — 15 мин;
- дефекты без движения > 2 спринтов: решение по каждому — 20 мин;
- Reopen-баги: разбор причин, почему DoD не сработал — 10 мин;
- метрики бэклога: тренды за последние 3 спринта — 5–10 мин.
Типичный бэклог дефектов до расчистки: задача на 254 часа соседствует с пятью "(Не задано)", а Васи, который мог бы объяснить почему, уже нет в команде
Выходной артефакт: не «обсудили», а конкретные решения по каждому пересмотренному тикету: «закрыли как won't fix», «перенесли в P3», «взяли в следующий спринт». Если после груминга статусы не поменялись — встреча не состоялась.
При 500+ тикетах пересматривать все каждую неделю физически невозможно. Сегментируйте:
| Приоритет |
Частота пересмотра |
| P0/P1 |
Каждую неделю |
| P2 |
Каждые 2 спринта |
| P3 |
Раз в квартал / при квартальном планировании |
| Без приоритета / In Triage |
Каждые 2 недели, пока не расставлены |
Won't Fix: как закрывать без конфликтов и с памятью
Won't Fix — это не провал и не «не хотим делать». Это честное признание: баг реальный, но исправлять его нецелесообразно. Разница между этими двумя формулировками огромная — и именно поэтому каждый Won't Fix требует явного обоснования.
Когда Won't Fix оправдан:
- Сценарий затрагивает < N% активных пользователей (порог должна определить команда явно, не «мало»).
- Исправление требует рефакторинга модуля, который запланирован к переписыванию.
- Стоимость исправления несопоставима с бизнес-риском.
- Существует задокументированный workaround, который покрывает потребность.
Шаблон закрытия, который снимет все вопросы через полгода:
Статус: Won't Fix
Причина: [одна из категорий выше + 2–3 предложения обоснования]
Кто принял решение: [имя PO + имя тимлида]
Затронутые пользователи: [цифра или оценка]
Workaround: [описание или N/A]
Дата пересмотра: [конкретная дата или триггер — «после релиза v4.0»] |
Поле «Дата пересмотра» — не формальность. Без него Won't Fix превращается в мусорную корзину, куда удобно выбрасывать то, что не хочется делать. Метрика для самопроверки: если Won't Fix > 30% всех закрытых дефектов — это симптом либо слишком низкого quality bar при заведении, либо технического долга, который не признается таковым.
Баг из прода — это не просто еще один тикет
Дефект, который обнаружил пользователь или мониторинг в проде, несет контекст, которого нет в обычном баге: сколько людей пострадало, было ли нарушение SLA, дошло ли до бизнеса. Без этого контекста разработчик видит технический дефект. С ним — видит бизнес-последствие. Это кардинально меняет приоритизацию.
Минимальная цепочка, которая не должна разрываться:
Последний пункт — самый важный и самый редкий. Без постмортема для P0/P1 команда бесконечно исправляет симптомы. RCA должен отвечать на вопрос: какое системное условие позволило этому багу добраться до прода? Не «разработчик ошибся», а «у нас нет интеграционного теста для этого сценария» или «мониторинг не покрывает этот путь». Первый ответ закрывает один баг. Второй — предотвращает класс багов.
Как эта цепочка выглядит на практике — в демонстрации плагина кросс-продуктовой интеграции SDLC и ITSM:
Метрики: что измерять и как не врать самим себе
Интуиция говорит: «у нас много багов, это плохо». Метрики говорят точнее — где именно сломан процесс.
| Метрика |
Формула |
На что смотреть |
Сигнал тревоги |
| Escape Rate |
Баги из прода / Все баги × 100% |
Динамика от релиза к релизу |
Растущий тренд |
| Defect Density |
Баги / Размер модуля (KLOC, endpoints) |
Сравнение по модулям |
Один модуль генерирует > 30% всех дефектов |
| MTTR по приоритетам |
Считать отдельно для P0/P1/P2/P3 |
Рост MTTR у P2 при стабильном P1 |
Команда тушит пожары, не работает над качеством |
| Reopen Rate |
Переоткрытые / Все закрытые × 100% |
Кто закрывает с высоким reopen |
> 10–15% — слабый DoD |
Важная оговорка: доля дефектов, дошедших до прода 20% для внутреннего инструмента с 50 пользователями и 20% для платежного сервиса — принципиально разные ситуации. Метрики имеют смысл только в динамике и только в контексте. Смотрите тренд, а не абсолют.
Дефекты как симптом — не как болезнь
Если один модуль стабильно генерирует > 30% всех дефектов — это не проблема QA. Это сигнал технического долга: высокая цикломатическая сложность, низкое тестовое покрытие или размытая ответственность за код. Возможные причины: модуль менялся много раз без рефакторинга, тестовое покрытие < 40%, размытая ответственность («все вносят правки, никто не владеет»).
Когда вам нужно пойти к бизнесу с аргументом про рефакторинг, забудьте про «код выглядит плохо» — это не то, что бизнес воспримет как реальный аргумент.
С бизнесом нужно говорить иначе: «За последний квартал мы закрыли 34 дефекта в модуле оплаты. Это 180 часов работы команды — только на исправления, без новых фич. Рефакторинг модуля займет 3 спринта, после чего этот поток дефектов сократится в разы. По нашей оценке, вложение окупится уже через два квартала».
Бизнес понимает деньги и время, а не красоту кода.
Anti-patterns, которые убивают процесс
Мы видели эти паттерны достаточно часто, чтобы дать им имена.
- «Все P1» — команда выставляет высокий приоритет всему, чтобы не расстраивать стейкхолдеров. В итоге P1 теряет смысл. Лечится явной матрицей с критериями.
- Груминг без решений — встреча прошла, тикеты обсудили, но статусы не поменялись.Правило простое: каждый тикет на груминге завершается явным решением.
- «Вася разберется» — баг назначен человеку, а не модулю. Вася ушел — баг завис. Назначайте на модуль или команду, не на человека.
- Бесконечный triage — новые баги неделями висят без severity-оценки. Правило: тикет старше 3 рабочих дней без оценки автоматически попадает в повестку следующего груминга. В SimpleOne SDLC, Jira, YouTrack это настраивается за 15 минут.
- 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 раз. Оставшееся — реально актуальные задачи с понятными приоритетами. Это не магия — это просто наведенный порядок, который не случился раньше, потому что не было времени и процесса.
***
А сколько тикетов в вашем бэклоге заведены людьми, которых уже нет в компании?-Источник
|
