O Que os Tickets Não Fazem Bem

Tickets rastreiam trabalho. Eles são péssimos para armazenar conhecimento. Um ticket que diz "migrar o serviço de autenticação para o novo formato de token" captura o que precisa acontecer e por quê — mas a decisão arquitetural resultante, a especificação do formato de token e a estratégia de migração não pertencem ao ticket. Eles pertencem à documentação que sobrevive ao ciclo de vida do ticket.

O modo de falha é familiar: uma equipe usa tickets como sua base de conhecimento e, seis meses depois, encontrar a decisão de migração de autenticação requer pesquisar em 2.000 tickets fechados com palavras-chave que correspondem a dezenas de resultados não relacionados. A decisão está lá em algum lugar — enterrada em uma descrição, um comentário ou um anexo — mas não é encontrável em nenhum tempo razoável.

Tickets são efêmeros por design. Eles representam uma unidade de trabalho com um início, um fim e um status. Decisões de arquitetura, contratos de API, procedimentos de runbook e guias de integração são conhecimento persistente que precisa de um lar persistente: uma wiki, um diretório /docs no repositório, um arquivo ADR (Architecture Decision Record). O ticket pode linkar para o documento. O documento não deve viver dentro do ticket.

Uma thread de 30 comentários em um ticket é uma conversa que deveria ter acontecido em outro lugar. Tickets são ferramentas de coordenação — eles respondem "o que precisa acontecer?" e "está pronto?" Eles não são o meio certo para debates de design, negociações de requisitos ou sessões de troubleshooting.

Quando um ticket se torna uma thread de chat, três coisas dão errado. Primeiro, a relação sinal-ruído cai: os requisitos reais ficam enterrados entre atualizações de status, perguntas tangenciais e pings de "alguma atualização sobre isso?" Segundo, a conversa não fica visível para pessoas que não estão acompanhando aquele ticket — uma decisão de design feita em um comentário de ticket não aparece no canal Slack da equipe, nas notas de reunião ou na documentação. Terceiro, os metadados do ticket (status, responsável, data de entrega) ficam desconectados da realidade de um escopo ainda em evolução.

Discussão pertence a ferramentas de discussão: threads do Slack com um resumo postado de volta no ticket, documentos de design linkados do ticket, ou uma chamada de 15 minutos com notas capturadas na descrição. O ticket é a página de destino para um pedaço de trabalho, não a transcrição de cada conversa sobre ele.

Um backlog não é um estacionamento para ideias — mas a maioria das equipes o trata como um. Cada solicitação de recurso, bug menor, "seria bom ter" e "provavelmente deveríamos fazer isso algum dia" ganha um ticket, e esse ticket fica intocado por meses. O backlog cresce. Ninguém o poda. Eventualmente você tem 800 tickets e nenhuma maneira de distinguir os 30 que importam dos 770 que não importam.

Backlogs obsoletos carregam custos reais. Desenvolvedores perdem tempo rolando por tickets mortos no planejamento de sprint. Novos membros da equipe não conseguem distinguir quais tickets são atuais e quais são fósseis de duas mudanças de produto atrás. Pesquisas retornam ruído. O backlog se torna um monumento indutor de culpa ao trabalho que a equipe nunca fará — e cada olhada nele mina a confiança no processo de planejamento.

Higiene de backlog é uma disciplina, não uma limpeza única. Uma cadência saudável: uma vez por mês, revise cada ticket com mais de 90 dias. Se não foi priorizado em três meses, ou não é importante o suficiente para fazer ou não está bem definido o suficiente para estimar. Feche-o. Se importa, voltará — e quando voltar, voltará com contexto fresco e prioridades atuais.

O instinto é manter tickets abertos "só por precaução." Esse instinto está errado. Um ticket fechado não é deletado — ele é pesquisável, linkável e reabrível. Fechá-lo apenas significa que a equipe está sendo honesta sobre o que está realmente no escopo. Um backlog de 50 tickets que reflete prioridades reais é infinitamente mais útil do que um backlog de 800 tickets que reflete cada ideia que alguém já teve.