Откройте любой баг-трекер, и вы найдёте те же четыре слова: низкий, средний, высокий, критический. Они настолько стандартны, что их никто не ставит под сомнение. И для большинства команд они неправильные — не потому, что четыре — неправильное число, а потому, что слова чужие.
Шкала приоритетов — это сжатое общее решение
Поле приоритета нужно не для того, чтобы описать баг. Оно отвечает на один вопрос того, кто следующим посмотрит на доску: браться ли за это раньше, чем за то, что я собирался делать?
Поэтому уровень приоритета — это сжатая договорённость. «Критический» в вашей команде означает что-то конкретное: может быть, «будим дежурного», может быть, «выходит в следующем патче», может быть, «останавливаем релиз». Слово работает, только если все разворачивают его одинаково.
Именно поэтому типовая шкала деградирует. Никто не договаривался, что значит «высокий» в вашем трекере, поэтому каждый подставляет своё определение, и поле перестаёт нести информацию.
Два вопроса, которые путают
Большинство споров о приоритете — это на деле споры о двух разных вопросах:
Серьёзность (severity): насколько плох сбой? Падение приложения — серьёзно. Съехавшая иконка — нет.
Приоритет: когда это чинить? Съехавшая иконка на странице с ценами за час до запуска — срочно, но не серьёзно.
Одно поле не вместит и то и другое, и команды, которые пытаются, получают шкалу, которая по понедельникам означает серьёзность, а по пятницам — приоритет. Выберите одно — для большинства продуктовых команд полезнее приоритет, потому что именно он меняет то, что вы делаете дальше, — а если вам действительно нужны оба, сделайте серьёзность отдельным полем.
Сколько уровней
Меньше, чем кажется.
Длинная шкала ломается не потому, что люди выбирают неправильно, а потому, что они перестают выбирать. Если есть уровни от P0 до P4, большинство команд пользуется P1 и P3, а остальные тихо забрасывает. Пятиуровневая шкала делает работу двухуровневой.
Проверка: для каждой пары соседних уровней можете ли вы сформулировать правило, которое без раздумий решает, какой из них выбрать? Если «высокий» и «средний» отличаются только ощущением, это один уровень под двумя именами.
Три уровня, которые люди применяют последовательно, лучше пяти, которые они угадывают. Часто останавливаются на четырёх: это два оттенка «скоро» и два оттенка «потом».
Второе правило: верхний уровень должен быть редким. Если треть доски — критические задачи, слово уже переопределили как «мне это важно», и доска больше не говорит, с чего начать. Полезный верхний уровень описывает то, ради чего вы прервёте работу, — а этого по определению не может быть треть чего бы то ни было.
Называйте уровни так, как говорит ваша команда
Если на стендапе спрашивают «это блокер?», значит, Блокер должен быть значением в трекере. Каждый шаг перевода между тем, как говорят люди, и тем, что предлагает инструмент, — это место, где поле заполнят неправильно или пропустят.
Это самый сильный довод за редактируемые приоритеты, и гибкость ради гибкости тут ни при чём. Поле, на которое люди могут ответить своими словами, — это поле, на которое они действительно ответят.
Несколько шкал, которые стоит позаимствовать:
Команды, где главное — поддержка: Блокер · Срочный · Обычный · Низкий — чисто ложится на SLA.
Продуктовые команды: Сейчас · Скоро · Потом — три уровня, никакой двусмысленности, заодно работает как дорожная карта.
Работа в режиме инцидентов: P0 · P1 · P2 — если в runbook дежурных уже есть эти номера, используйте те же.
Как изменить шкалу в BugDump
BugDump создаёт в каждом проекте «Низкий», «Средний», «Высокий» и «Критический», и ни один из них не зафиксирован. На странице Свойства выберите Приоритет и отредактируйте список: переименуйте прямо на месте, поменяйте цвет, добавьте свои, удалите то, чем не пользуетесь.
Переименование сразу распространяется на всё. Задачи, уже отмеченные как «Критический», показывают новое слово на карточках, в панели задачи, на публичном портале и через MCP-сервер — без миграции и без повторной разметки, потому что задача ссылается на вариант, а не хранит копию его названия.
Удаление уровня сохраняет его задачи: они просто теряют этот приоритет. Поэтому урезать шкалу, которую вы сделали слишком сложной, дёшево. Это важно: большинство команд находит правильную шкалу, только месяц поработав с неправильной.
Доска фильтрует по всему, что есть в вашем списке, по нескольким значениям сразу.
Что проверить при переименовании
Всё, что задаёт приоритет по имени. Встроенный виджет, который передаёт priority: 'critical', или скрипт, который ходит в API. Сопоставление не учитывает регистр, поэтому critical по-прежнему находит Critical, но если переименовать «Критический» в «Блокер», старое имя ни с чем не совпадёт. Анонимные отчёты всё равно придут, просто без приоритета; запросы с авторизацией отклоняются, чтобы вы это заметили.
Интеграции со своими уровнями серьёзности. У Jira и Freshdesk свои шкалы, и у придуманного вами уровня там нет аналога, поэтому такие тикеты получают средний уровень системы-получателя. Если это сопоставление важно, добавляйте уровни, а не переименовывайте стандартные.
Честный итог
Приоритет — маленькое поле, которое определяет порядок всего остального, и работает оно, только когда команда действительно договорилась, что значит каждый уровень. Фиксированный словарь мешает этой договорённости. Пусть лучше трекер выучит ваши слова.
А дальше пользуйтесь шкалой с некоторой дисциплиной: держите верхний уровень редким, удаляйте уровень, который никто не выбирает, и пересмотрите шкалу после месяца реальных багов.
Читайте также
Метрики баг-трекинга, которые стоит считать — четыре метрики, которые показывают, успевает ли команда за багами, и еженедельный пятиминутный обзор на их основе.
Как разбирать баги быстрее: работа с клавиатуры — разбор, в котором не нужно думать быстрее: из него убрана навигация вокруг решений.
Машинное имя, которое было ещё и отображаемым — что пришлось переделать в коде, чтобы приоритеты стало можно переименовывать, и какие баги при этом ломаются молча.