Quando um pedido de funcionalidade é na verdade um bug
5 min de leitura
“Vocês podem adicionar uma configuração para aumentar o limite de exportação?” se lê como um pedido de funcionalidade, e a maioria dos sistemas de triagem etiqueta assim na hora. Às vezes é. Às vezes a exportação falha em um número abaixo do limite documentado por causa de um bug, e a cliente, incapaz de ver o código, inventou a solução mais plausível que consegue descrever: me dê um número maior e talvez funcione. Quais etiquetas valem a pena cobre a etiqueta de tipo que divide um backlog em pedidos de funcionalidade e bugs; este é o caso em que as próprias palavras de uma cliente apontam a etiqueta na direção errada, e o custo de errar é uma deriva lenta para um backlog cheio de pedidos que ninguém realmente quer quando se olha por baixo.
Como é um pedido de funcionalidade que na verdade é um bug?
Ele nomeia um contorno em vez do problema. Um pedido de funcionalidade genuíno geralmente descreve um resultado que o produto não suporta de jeito nenhum: “me deixe agendar isso para depois”, “adicionem um modo escuro”. Um bug classificado errado descreve um número, limite ou comportamento específico que soa como uma configuração faltando mas na verdade é um sintoma: “aumentem o timeout”, “adicionem uma opção de retry”, “me deixem exportar mais linhas de uma vez”. O sinal é que quem pede propõe uma implementação, uma configuração, um interruptor, uma sobreposição, em vez de descrever um objetivo, porque já testou a funcionalidade como está documentada e ela não fez o que a documentação diz que deveria fazer.
| Sinal | Pedido de funcionalidade | Bug disfarçado de pedido de funcionalidade |
|---|---|---|
| O que quem pede descreve | Um resultado que o produto não consegue fazer | Um parâmetro que quer mudar |
| Se o comportamento documentado já cobre isso | Não, realmente faltando | Sim, mas não funciona como documentado |
| Se mais esforço faz o pedido sumir | Não | Às vezes, se o bug depende de um limite |
| Para onde deveria ser roteado | Backlog de produto | Fila de bugs |
Por que isso importa mais do que parece?
Porque as duas filas têm donas, prazos e critérios de sucesso diferentes, e um bug arquivado como pedido de funcionalidade é priorizado contra pedidos de funcionalidade, competindo por atenção com lacunas reais de produto em vez de ser corrigido no prazo que um bug merece. Como rastrear pedidos de funcionalidade cobre por que misturar bugs e funcionalidades em uma fila só deixa as reclamações mais barulhentas passarem na frente dos pedidos reais; um pedido de funcionalidade que secretamente é um bug faz o dano oposto, fica no backlog de produto acumulando votos para uma “funcionalidade” que sumiria assim que o bug de base fosse corrigido, o que desperdiça o sinal de priorização para quem lê aquele backlog.
Como distinguir quando as próprias palavras da cliente apontam na direção errada?
Pergunte o que ela esperava que acontecesse, não o que quer que vocês adicionem. “A exportação travou em 500 linhas e eu preciso de 2.000, vocês podem aumentar o limite” soa como um pedido de funcionalidade de aumento de limite até a pergunta de acompanhamento, “500 é o limite documentado”, revelar que o número documentado era 5.000 e a exportação falha cedo demais. Só essa pergunta, o que ela esperava contra o que aconteceu, faz a maior parte do trabalho de triagem, porque um pedido de funcionalidade genuíno não tem um comportamento documentado do qual fica aquém; não há nada a esperar porque a capacidade ainda não existe.
Agentes de suporte ou engenheiras deveriam decidir isso?
Agentes de suporte fazem a primeira passagem, porque veem o ticket primeiro, mas a etiqueta deveria ser fácil de mudar e barata de errar, não uma decisão única que trava o item na fila errada para sempre. Uma segunda verificação leve, uma engenheira que passa os olhos semanalmente pelas novas etiquetas de “pedido de funcionalidade” atrás de qualquer coisa que cheire a bug disfarçado, pega as que um agente de suporte sem contexto de código não conseguiria reconhecer. Não precisa ser formal; é mais um olhar de cinco minutos do que um processo de revisão.
Fechar o loop muda depois que o bug de verdade é encontrado?
Sim, e melhora a mensagem que vocês podem enviar. Fechar o loop de feedback do cliente cobre avisar quem pediu quando o pedido é lançado; um bug recategorizado ganha uma versão melhor dessa mensagem, porque “encontramos e corrigimos o bug por trás disso” soa como competência, enquanto “construímos a funcionalidade que vocês pediram” só seria verdade por acidente, porque o pedido de funcionalidade real, um limite de exportação de verdade maior, talvez nunca seja construído assim que o bug sumir e o limite original de 5.000 linhas for suficiente.
O que acontece se a classificação errada nunca é percebida?
O backlog se enche de pedidos que parecem demanda real e não são, e as decisões de priorização tomadas contra aquele backlog herdam a distorção. Uma “funcionalidade” com quarenta votos pode na verdade ser quarenta pessoas esbarrando no mesmo bug, e construir o pedido literal, uma configuração para aumentar um limite que nunca foi de fato a restrição, entrega complexidade que não conserta nada, enquanto o bug de base continua gerando novos “pedidos de funcionalidade” de clientes que ainda não encontraram este tópico.
FAQ
Vale a pena adicionar um passo formal para checar cada pedido de funcionalidade contra bugs conhecidos? Não um passo formal, mais um hábito: quem quer que triage um novo pedido de funcionalidade deveria perguntar “o comportamento documentado já afirma fazer isso” antes de aplicar a etiqueta, porque só essa pergunta pega a maioria das classificações erradas sem adicionar sobrecarga de processo.
E se a cliente insistir que é um pedido de funcionalidade mesmo depois do bug ser encontrado? Expliquem o que encontraram e por que a configuração que ela propôs não seria mais necessária assim que o bug for corrigido. A maioria das clientes pede um contorno porque assumiu que o conserto de verdade não estava disponível, não porque queria especificamente aquela configuração.
Um item recategorizado perde os votos ou comentários que acumulou como pedido de funcionalidade? Deveria mantê-los, visíveis, porque esses votos são a evidência que levou a encontrar o bug em primeiro lugar, e esconder esse rastro dificulta pegar a mesma classificação errada da próxima vez, em um ticket diferente.
Isso pode acontecer ao contrário, um relatório de bug que na verdade é um pedido de funcionalidade? Menos vezes, mas sim: “isso está quebrado” às vezes significa “isso não faz o que eu assumi que faria”, que é uma capacidade faltando, não um defeito. A mesma pergunta, o que ela esperava contra o que está documentado, classifica também nessa direção.
As afirmações técnicas deste artigo não foram revisadas de forma independente. Se algo estiver errado, avise a gente e vamos corrigir.