Когда баги начинают лезть со всех сторон - от вендоров, своей команды, саппорта - появляется главный вопрос: а кто их приоритизирует?
На бумаге обычно пишут: PO, тимлид или техдир. В реальности у них спринты, архитектура, горящие задачи, и времени на «ходить по багам» нет.
Что получается: саппорт обязан закрывать тикеты в срок, но реально повлиять на исправления не может. QA видят, что продукт трещит, но в их силах только протестировать и зафиксировать. PM - между огнём SLA и отсутствием времени у техлида.
И вот здесь важно не упасть в ловушку двух крайностей:
• «пинать и ждать» - SLA срывается, бизнес злится;
• «звать на встречи» - никто не приходит, все равно не работает.
Что реально может сработать:
1. Ввести многоуровневый фильтр багов.
• Support фиксирует и отмечает все, что напрямую мешает SLA.
• QA первично классифицирует (сломанный сценарий, UI, производительность).
• Разработчики отмечают те баги, где нужен архитектурный взгляд.
• А тимлид/техдир включаются только точечно - там, где спорно или критично.
2. Согласовать простую матрицу приоритизации.
Severity (на пользователя) × Impact (на бизнес/SLA).
Всё, что падает в красную зону - уходит в работу без дискуссий.
3. Синхронизация не через встречи, а через прозрачный реестр.
Jira-доска/Confluence-страница/таблица, где видно: какой баг, кто фильтровал, какой приоритет. Это снимает часть хаоса и снижает потребность в бесконечных созвонах.
В результате у саппорта появляется аргументированная позиция («мы передали X критичных багов по SLA»), у команды - прозрачный фильтр, у тимлида - минимальная нагрузка (только спорные кейсы), а у бизнеса - меньше сюрпризов.
Если этого не сделать, баги превращаются в пинг-понг между командами.
А если фильтр и матрица есть, система работает даже при дефиците времени у техлидов.
