A Porsche publicou um relato de experiência interessante sobre a zero bug policy, aplicada ao My Porsche. A ideia pode parecer irreal à primeira vista. Todo mundo sabe que software sem bug não existe. Até os melhores produtos têm defeitos, regressões, comportamentos inesperados, casos-limite.

Mas não é disso que se trata.

Uma política de zero bug não promete código perfeito. Ela quer outra coisa: não aceitar mais guardar bugs conhecidos como um estoque permanente para priorizar, requalificar e adiar.

O verdadeiro problema dos bugs não é só existirem. O verdadeiro problema é a organização que se acostuma a guardá-los.

A gente abre um ticket. Dá uma prioridade a ele. Classifica. Revisa duas semanas depois. Muda a prioridade. Discute em comitê. Adia porque uma feature do roadmap é mais urgente. Aí um cliente reclama, o bug volta à tona, e o time trata na urgência o que deveria ter decidido claramente muito antes.

Nesse momento, o bug não é mais só um defeito de software. É um defeito de decisão.

Os bugs não contam até virarem urgência

Em muitas organizações, os bugs ficam num limbo estranho.

Eles existem. Todo mundo os vê. Consomem energia. Irritam os clientes. Sobrecarregam o suporte. Mas não contam de verdade no planejamento.

O roadmap avança. As features previstas chegam. Os prazos ficam visíveis. As decisões são tomadas em cima dos assuntos novos. E os bugs ficam ali de lado, como uma carga implícita que a gente vai tratar quando tiver tempo.

Só que a gente nunca tem tempo.

Aí os bugs viram prioridade só quando ficam visíveis demais: um cliente grande reclama, uma demo quebra, o suporte satura, uma regressão atinge um fluxo crítico, um diretor esbarra nele.

Essa lógica opõe artificialmente roadmap e qualidade. Como se as features fossem o trabalho de verdade, e os bugs um ruído para gerenciar em volta. Mas um bug consome capacidade. Consome também confiança do cliente, credibilidade interna, tempo de suporte e atenção de produto.

Não contá-lo não faz dele algo gratuito.

O que "zero bug" quer dizer de verdade

Uma política de zero bug não significa que nunca haverá bug.

Significa: zero bug conhecido sem decisão.

A nuance é essencial. O objetivo não é eliminar o desconhecido. O objetivo é não organizar a aceitação permanente de defeitos conhecidos.

Quando um sinal chega, o time precisa decidir rápido: é um defeito ou não?

Se for um defeito, corrige.

Se não for um defeito, não trata como bug. Pode ser uma melhoria. Pode ser um pedido de feature. Pode ser um mal-entendido. Pode ser um assunto interessante, mas fora de prioridade.

Em todos os casos, existe uma decisão.

O que a política de zero bug recusa é o terceiro estado: "Sabemos que é um bug, mas guardamos numa lista para depois."

Esse "depois" costuma ser o verdadeiro problema.

A armadilha do backlog de bugs

Um backlog de bugs dá uma impressão de controle.

Está tudo listado. Cada bug tem uma prioridade. Alguns são blocker, outros major, minor, trivial. Dá para filtrar. Dá para ordenar. Dá para montar um comitê. Dá para produzir tabelas. Dá para dizer que o assunto está sob controle.

Mas priorizar um bug todo mês não é tratá-lo.

Muitas vezes é só aceitar que ele continue ali.

O estoque de bugs cria o próprio trabalho. É preciso verificar se o bug ainda existe. É preciso saber se ele ainda é prioritário. É preciso saber se o cliente em questão ainda é cliente. É preciso saber se ele ainda é reproduzível. É preciso saber se ele deve passar na frente de outra anomalia. É preciso reler, requalificar, replanejar.

A organização então gasta energia administrando defeitos em vez de restaurar a qualidade.

E o mais absurdo é que muitos desses bugs nunca serão corrigidos.

A gente sabe. O time sabe. O suporte sabe. O Product Manager sabe. Mas o ticket continua aberto, porque fechá-lo significa assumir uma decisão que ninguém quer carregar.

Uma política de zero bug força essa decisão.

Duas decisões: defeito ou não-defeito

A força da abordagem da Porsche está na simplicidade.

Em vez de multiplicar as categorias, o time reduz a decisão:

• defect: é um defeito, então corrige;
• no defect: não é um defeito, então não trata como bug.

Essa simplificação não quer dizer que tudo vira brutal ou automático. Ainda é preciso entender o impacto, o contexto, o cliente, a frequência, a gravidade. Mas a discussão precisa levar a uma decisão, não a uma nova categoria.

Uma melhoria pode ser útil sem ser um defeito.

Um pedido de cliente pode ser pertinente sem ser um bug.

Um comportamento pode ser frustrante sem ser prioritário.

O que importa é não esconder a decisão atrás de uma tipologia.

Se for um defeito real, a gente trata. Se não for, a gente assume. Mas não guarda indefinidamente um bug conhecido numa fila que serve principalmente para evitar escolher.

Bug ou feature: o cliente não está nem aí

Do ponto de vista do cliente, a distinção entre bug e feature tem pouco interesse.

O cliente não fica se perguntando se está sofrendo com um bug, com uma feature ausente, com uma feature malfeita ou com uma feature que não corresponde à necessidade dele. Ele sente uma dor.

Um software pode não ter nenhum bug técnico e mesmo assim não atender à necessidade do cliente. A dor continua real.

Ao contrário, alguns bugs são objetivamente defeitos, mas o impacto é baixo. Se o usuário precisa clicar duas vezes num botão, não é o ideal. Mas se, ao lado disso, uma feature ausente o impede de fazer uma declaração fiscal ou legal obrigatória, a ausência da feature é mais crítica do que o bug menor.

É por isso que a categoria do ticket não deve substituir a análise da dor.

A verdadeira pergunta não é: "É um bug ou uma feature?"

A verdadeira pergunta é:

• que dor isso cria?
• para quem?
• com que frequência?
• com que impacto?
• é bloqueante?
• é regulatório?
• gera suporte?
• destrói a confiança?

A tipologia pode ajudar a medir. Ela não deve decidir no lugar do time.

Assumir uma posição radical: chega de cartões de bug separados

Dá para ir mais longe.

Em muitas organizações, eu eliminaria os cartões de bug separados no Jira ou nas ferramentas equivalentes. Eu manteria só cartões de trabalho.

Por quê?

Porque a separação bug / feature acaba muitas vezes criando dois sistemas de prioridade. As features são conduzidas pelo roadmap. Os bugs são conduzidos pela urgência, pelo suporte, pela pressão do cliente ou por comitês de priorização. E entre os dois, ninguém olha de verdade o conjunto sob o ângulo da dor e do valor.

Um cartão de trabalho deveria carregar um problema a resolver.

Às vezes esse problema vem de um defeito de software. Às vezes vem de uma capacidade ausente. Às vezes vem de um design ruim. Às vezes vem de uma dívida técnica. Mas a decisão deve continuar a mesma: qual dor, qual valor, qual impacto, qual decisão?

O daily da manhã pode então servir para decidir o que realmente importa agora. Não para debater vinte minutos se o item é um bug, uma feature, uma melhoria ou um rework.

Claro, algumas organizações precisam de reporting de qualidade. Dá para manter tags, métricas, categorias mínimas. Mas isso são informações secundárias. Elas não devem estruturar toda a decisão.

Ou trata agora, ou recusa

O pior status de um bug não é "não corrigido".

O pior status é "priorizar mais tarde".

"Mais tarde" parece razoável. Na prática, costuma ser uma forma educada de não decidir.

Alguns bugs precisam ser tratados na hora.

Outros precisam ser recusados explicitamente. Dá para escrever um cartão mínimo se você quiser deixar um registro: "Não vamos fazer." Mas não dá para alimentar um backlog de bugs interminável só para ter a sensação de que o assunto ainda existe.

A disciplina é simples:

• se for um defeito real e importante, corrige;
• se não for um defeito, tira da gestão de bug;
• se for fraco demais para ser tratado, assume;
• se voltar com frequência, reavalia com sinais.

O objetivo não é virar dogmático. O objetivo é forçar a organização a produzir uma decisão.

A velocidade precisa absorver a qualidade

Corrigir um defeito na hora pode afetar a velocidade.

Pode impedir de terminar uma feature. Pode atrapalhar um sprint goal. Pode adiar um assunto do roadmap. É desagradável, mas é normal.

A qualidade consome capacidade.

Quando um time ignora os bugs para preservar a velocidade, ele protege uma métrica em detrimento do produto. Passa a impressão de avançar rápido, mas acumula atrito, suporte, dívida e desconfiança.

Uma política de zero bug torna esse custo visível.

Se os defeitos deixam o time mais lento, não é a política de zero bug que cria o problema. Ela só revela que o sistema produz defeitos demais ou os detecta tarde demais.

A resposta certa não é esconder os bugs num backlog. A resposta certa é melhorar o sistema de produção: testes, QA, TDD, automação, clareza das specs, responsabilidade dos desenvolvedores.

Esse vai ser o assunto do próximo artigo.

Como começar com um estoque existente

A dificuldade aparece quando o time já tem um estoque de bugs.

Dá para escolher uma opção radical: fechar todos os bugs existentes e começar do zero. É limpo, mas politicamente difícil. Exige muita confiança interna e capacidade de assumir as recusas.

Dá também para escolher uma opção gradual.

O artigo da Porsche propõe uma lógica de redução por etapas: priorizar uma última vez, tratar um pequeno número de defeitos por sprint, e definir um novo zero temporário. O importante é que essa fase continue sendo uma transição, não uma nova forma normal de backlog.

Um método muito eficaz consiste em passar pelo suporte.

Toda semana, o suporte lista o top 3 dos retornos de clientes ligados a bugs.

Esse top 3 vira o top 3 de bugs a tratar.

Na semana seguinte, se um, dois ou três bugs foram tratados, o suporte propõe os próximos.

A gente avança por Pareto. Trata primeiro o que volta com mais frequência, o que dói mais, o que gera mais carga de suporte. A gente não começa repriorizando cem tickets. Trata os incômodos que realmente sobrecarregam a organização.

Esse método tem uma vantagem dupla.

Primeiro, ele reduz a dor visível do cliente.

Depois, ele desafoga o suporte.

O suporte vê que os retornos dele servem para alguma coisa. O time de produto trata os problemas que voltam de verdade. Os desenvolvedores não se dispersam numa lista abstrata. A direção vê os incômodos desaparecerem.

Para sair de um estoque de bugs, não dá para começar repriorizando tudo. É preciso tratar o que volta com mais frequência e dói mais.

As métricas úteis, sem obsessão administrativa

Não se trata de eliminar toda medição.

Algumas métricas são úteis:

• o rework;
• o cycle time;
• as regressões;
• os defeitos encontrados antes da produção;
• os defeitos encontrados em produção;
• a carga de suporte ligada a certos bugs.

Essas medições podem esclarecer a qualidade. Permitem ver se o time refaz o próprio trabalho com frequência demais, se certos fluxos quebram regularmente, se uma área do produto gera suporte demais, se os defeitos são detectados tarde demais.

Mas a métrica precisa continuar sendo uma ferramenta.

Se o time passa mais tempo qualificando os defeitos do que melhorando o sistema, ele recria o problema que queria resolver. A gente troca então o backlog de bugs por um backlog de categorias.

A finalidade não é medir tudo. A finalidade é reduzir a dor e melhorar o fluxo.

Conclusão

Uma política de zero bug não torna o software mágico.

Ela só torna impossível esconder os defeitos conhecidos atrás de um backlog.

Ela obriga a decidir. Torna a qualidade visível. Impede que os bugs virem um estoque administrativo. Força a organização a escolher: corrigir, recusar ou requalificar como outra coisa.

É radical, mas é justamente isso que torna a abordagem útil.

Enquanto um bug puder dormir num backlog por seis meses, ninguém é de fato responsável pela decisão. Uma política de zero bug recoloca essa responsabilidade no centro.

Mas ela não basta.

Se o time corrige rápido sem mudar a forma como entrega, ele vai continuar num ciclo de conserto. O verdadeiro assunto seguinte é, portanto, a prevenção: responsabilidade dos desenvolvedores, especificações claras, TDD, QA, automação, o legacy futuro.

Ou seja: uma política de zero bug trata o estoque. A qualidade de entrega impede de recriá-lo.

Para saber mais

A qualidade pertence a quem entrega O backlog não é um depósito de lixo: é uma ferramenta de ação