Todo issue tracker acaba ganhando campos personalizados, e toda equipe que os ganha passa pela mesma curva: uma onda de entusiasmo, onze campos novos e, seis semanas depois, um formulário em que nove deles estão vazios em todos os tickets.
O problema não são os campos personalizados. É que «seria útil saber isso?» é a pergunta errada a fazer antes de criar um. Quase tudo seria útil saber.
O teste que vale aplicar
Antes de adicionar um campo, pergunte: que decisão muda por causa dele?
Não «o que isso diria», e sim o que você faria de diferente. Se a resposta honesta é «a gente conseguiria ver», esse é um campo que vai estar vazio em um mês, porque ninguém preenche uma caixa que não muda nada.
Dois exemplos da mesma informação passando e reprovando no teste:
Versão afetada, numa equipe que lança toda semana e mantém duas versões: passa. Ela decide se um bug precisa de backport.
Versão afetada, num app web com deploy contínuo: reprova. Todo mundo está na mesma versão. É uma caixa que registra a data num formato pior.
O campo é idêntico. A decisão não.
O segundo teste: quem preenche?
Um campo preenchido por quem faz a triagem é realista. Já um campo que exige uma informação que só quem relatou tem, ou que só um engenheiro tem depois de investigar, é pulado na triagem e nunca mais revisitado.
Se um campo só pode ser respondido tarde, ele não é um campo de triagem, e colocá-lo ao lado da prioridade significa que ele vai atrasar toda rodada de triagem enquanto continua vazio.
Campos que sempre se pagam
Plano do cliente (Selecionar). Se a urgência de um bug depende de verdade de quem foi afetado, esse é o campo que mais muda a ordem da triagem. Ele passa no teste da decisão sem esforço.
Regressão? (Caixa de seleção). Um bit, preenchido na triagem, e ele divide o backlog em «a gente quebrou isso» e «isso nunca esteve certo». São duas filas diferentes, com duas urgências diferentes.
PR vinculado (URL). Não para acompanhamento, e sim para a pessoa que reabre o bug daqui a quatro meses e quer saber o que já foi tentado.
Revisor ou Responsável por QA (Membro). Só se uma segunda pessoa realmente precisar aprovar. Se «responsável» é o único papel que existe na sua equipe, esse campo vai ser sempre igual ao responsável.
Campos a evitar
Qualquer coisa que dá para calcular. Dias em aberto, número de relatórios, tem anexos: o tracker já sabe, e uma cópia mantida manualmente fica desatualizada na primeira vez que alguém esquece.
Um segundo status. Bloqueada, Precisa de informações, Aguardando cliente como um campo ao lado da coluna do quadro significa que o estado real da tarefa mora em dois lugares que vão discordar. Se é um estado, é uma coluna. E, se você não quer uma coluna para ele, provavelmente também não quer o estado.
Texto livre onde caberia uma lista de opções. Um campo de texto chamado Componente vai acumular checkout, Checkout, check-out e chkout, e aí não dá mais para filtrar nem contar. Se você quer agrupar por ele, ele precisa ser uma lista fixa.
Qualquer coisa que você está adicionando porque uma pessoa pediu uma vez. Campos são baratos de criar e socialmente caros de remover. A régua deveria ser mais alta que «alguém comentou».
Escolhendo o tipo certo
Tipos não são enfeite. Eles decidem o que você vai poder perguntar ao quadro depois.
Tipo | Use quando | Permite |
|---|---|---|
Selecionar | Um conjunto fixo de opções | Filtrar e agrupar sem bagunça |
Seleção múltipla | Várias de um conjunto fixo | Perguntar «afeta iOS ou Android» |
Número | Uma quantidade real | Filtrar por intervalo |
Data | Um ponto no tempo | Filtrar por intervalo |
Caixa de seleção | Um bit | Dividir o quadro em dois |
Texto / URL | Qualquer outra coisa | Só busca por trecho de texto |
O erro principal é escolher texto porque é o mais rápido de configurar. Texto é o tipo que você escolhe quando já aceitou que nunca vai filtrar por aquele campo.
No BugDump, o tipo de uma propriedade não pode ser alterado depois da criação, porque os valores já guardados têm o formato daquele tipo. Então vale gastar os trinta segundos escolhendo.
Menos campos, preenchidos
O que torna um quadro útil não é quanto ele consegue registrar. É poder confiar no que ele registra.
Três campos preenchidos em todas as tarefas valem mais que onze preenchidos, cada um, em um terço delas. Um campo esparso é pior que nenhum campo: ele parece dado, então as pessoas filtram por ele, e o filtro exclui em silêncio toda tarefa em que alguém estava com pressa.
Um hábito prático: depois de um mês, veja com que frequência cada campo personalizado está preenchido. Qualquer coisa abaixo de mais ou menos metade está com nome ruim, no lugar errado ou respondendo a uma pergunta que ninguém faz. Apague. No BugDump, apagar uma propriedade remove a propriedade e os valores dela, mas não mexe nas tarefas, então podar só custa a decisão.
Como funciona no BugDump
As propriedades personalizadas ficam na página Propriedades do projeto, ao lado das cinco nativas (status, responsável, prioridade, etiquetas e data de entrega), que usam o mesmo mecanismo e se editam do mesmo jeito.
São oito tipos (Texto, Número, Data, Caixa de seleção, URL, Selecionar, Seleção múltipla e Membro), e cada um ganha no quadro o controle de filtro que combina com ele: caixas de seleção para listas de opções, um intervalo para números e datas, uma caixa «contém» para texto. Os filtros se combinam com AND e ficam na URL, então um quadro filtrado é um link.
Elas também chegam ao seu agente de IA. O servidor MCP retorna cada propriedade com as opções dela, e o list_tasks aceita filtros por propriedade, então «tarefas abertas em que o Plano do cliente é Enterprise» é uma chamada só, e não um buscar-tudo-e-varrer.
As propriedades personalizadas estão nos planos Pro e Ultra; as cinco nativas, incluindo a lista editável de prioridades, estão em todos os planos.
Leia também
Níveis de prioridade de bugs: por que quatro opções fixas nunca servem — para que serve uma escala de prioridade, quantos níveis você precisa e por que as palavras têm de ser suas.
Métricas de bugs que importam de verdade — quatro métricas que mostram se a equipe está dando conta dos bugs, e as que enganam sem ninguém perceber.
Notificações no bug tracker: quem deve ficar sabendo de uma mudança? — como um campo de membro decide quem é avisado sobre uma tarefa, sem lista de observadores para manter.