Abra qualquer bug tracker e você vai encontrar as mesmas quatro palavras: baixa, média, alta, crítica. São tão padrão que ninguém as questiona. E, para a maioria das equipes, estão erradas, não porque quatro seja o número errado, mas porque as palavras são de outra pessoa.
Uma escala de prioridade é uma decisão compartilhada, comprimida
O objetivo de um campo de prioridade não é descrever o bug. É responder a uma pergunta para quem olhar o quadro em seguida: eu trabalho nisto antes daquilo em que eu ia trabalhar?
Isso faz de um nível de prioridade um acordo comprimido. «Crítica» significa algo específico na sua equipe: talvez «acionar alguém do plantão», talvez «sai no próximo patch», talvez «segurar o lançamento». A palavra só funciona se todo mundo a descomprime do mesmo jeito.
É exatamente por isso que uma escala genérica se degrada. Ninguém combinou o que significa a «alta» do seu tracker, então cada pessoa traz a própria definição, e o campo deixa de carregar informação.
As duas perguntas que as pessoas confundem
A maioria das discussões sobre prioridade é, na verdade, uma discussão sobre duas perguntas diferentes:
Severidade: quão grave é a falha? Um crash é grave. Um ícone desalinhado não é.
Prioridade: quando vamos corrigir? Um ícone desalinhado na página de preços uma hora antes de um lançamento é urgente e não é grave.
Um único campo não comporta as duas, e as equipes que tentam acabam com uma escala que significa severidade às segundas e prioridade às sextas. Escolha uma. Para a maioria das equipes de produto, a útil é a prioridade, porque é ela que muda o que você faz em seguida. Se você realmente precisa das duas, faça da severidade um campo separado.
Quantos níveis
Menos do que você imagina.
O modo de falha de uma escala longa não é as pessoas escolherem errado; é elas pararem de escolher. Com P0 a P4, a maioria das equipes usa P1 e P3 e abandona o resto em silêncio. Você tem uma escala de cinco níveis fazendo o trabalho de dois.
Um teste: para cada par de níveis vizinhos, você consegue enunciar uma regra que decida entre eles sem pensar? Se «alta» e «média» só diferem pela sensação, são um nível só usando dois nomes.
Três níveis que as pessoas aplicam com consistência valem mais que cinco em que elas chutam. Quatro é um ponto de chegada comum porque dá dois sabores de «logo» e dois de «depois».
A outra regra é que o nível mais alto tem de ser raro. Se um terço do quadro é crítico, a palavra foi redefinida como «eu me importo com isso», e o quadro não diz mais por onde começar. Um nível mais alto útil descreve algo pelo qual você interromperia o trabalho, o que, por definição, não pode ser um terço de nada.
Dê aos níveis os nomes que a sua equipe usa
Se na daily alguém pergunta «isso é bloqueante?», então Bloqueante deveria ser um valor no tracker. Cada etapa de tradução entre o jeito como as pessoas falam e o que a ferramenta oferece é um lugar onde o campo é preenchido errado ou pulado.
Esse é o argumento mais forte a favor de prioridades editáveis, e ele não tem nada a ver com flexibilidade por si só. É que um campo que as pessoas conseguem responder com o próprio vocabulário é um campo que elas vão de fato responder.
Algumas escalas que vale roubar:
Equipes guiadas pelo suporte: Bloqueante · Urgente · Normal · Baixa, que se encaixa direto num SLA.
Equipes de produto: Agora · Próximo · Depois, três níveis, sem ambiguidade, e ainda serve de roteiro.
Trabalho com cara de incidente: P0 · P1 · P2. Se o runbook do seu plantão já usa esses números, use os mesmos aqui.
Editando a escala no BugDump
O BugDump começa todo projeto com Baixo, Médio, Alto e Crítico, e nenhum deles é fixo. Na página Propriedades, selecione Prioridade e edite a lista: renomeie ali mesmo, mude as cores, adicione as suas, apague o que você não usa.
Uma renomeação chega a tudo de uma vez. Tarefas já marcadas como Crítico mostram a palavra nova nos cards, no painel da tarefa, no portal público e pelo servidor MCP. Não há migração nem remarcação, porque a tarefa aponta para a opção em vez de guardar uma cópia do nome dela.
Apagar um nível mantém as tarefas dele; elas só perdem aquela prioridade. Então podar uma escala que você desenhou demais sai barato, e isso importa, porque a maioria das equipes só descobre a escala certa usando a errada por um mês.
O quadro filtra pelo que a sua lista tiver, vários valores de uma vez.
Duas coisas a observar quando você renomeia
Qualquer coisa que define uma prioridade pelo nome. Um widget incorporado que passa priority: 'critical', ou um script que chama a API. A comparação ignora maiúsculas, então critical ainda encontra Critical. Mas, se você renomear Crítico para Bloqueante, o nome antigo não casa com mais nada. Relatórios anônimos continuam chegando, só que sem prioridade; chamadas autenticadas são rejeitadas, para que você perceba.
Integrações que convertem para as próprias severidades. O Jira e o Freshdesk têm escalas próprias, e um nível que você inventou não tem equivalente, então esses tickets recebem a severidade do meio do destino. Se esse mapeamento importa, adicione níveis em vez de renomear os níveis padrão.
O resumo honesto
A prioridade é um campo pequeno que decide a ordem de todo o resto, e ela só funciona quando a equipe combinou de verdade o que cada nível significa. Um vocabulário fixo atrapalha esse acordo. Deixe o tracker aprender as suas palavras.
Depois, use a escala com alguma disciplina: mantenha o nível mais alto raro, apague o nível que ninguém escolhe e reveja a escala depois de um mês de bugs reais.
Leia também
Métricas de bugs que importam de verdade — quatro métricas que mostram se a equipe está dando conta dos bugs, e uma revisão semanal de cinco minutos baseada nelas.
Como fazer a triagem de bugs mais rápido: um fluxo guiado pelo teclado — uma rotina de triagem que corta a navegação em vez de pedir que você pense mais rápido.
O nome de máquina que também era o nome de exibição — o lado de engenharia das prioridades editáveis: o que quebrou quando os quatro valores fixos viraram uma lista que se renomeia.