Uma política de zero bug permite parar de gerenciar estoques de defeitos.

Mas não basta.

Se o time corrige os bugs mais rápido sem mudar a forma como produz, ele continua preso num ciclo de conserto. O backlog diminui, depois volta a subir. As urgências desaparecem, depois voltam. O suporte respira, depois satura de novo.

O verdadeiro tema está lá na origem.

Como evitar produzir tantos bugs?

Você não reduz os bugs só com uma organização melhor de triagem. Você os reduz dando ownership a quem entrega, recusando especificações vagas demais, testando mais cedo e dando à QA um papel de política de qualidade em vez de um papel de salva-vidas.

A qualidade não é algo que você delega depois.

A qualidade pertence a quem entrega.

Corrigir os bugs dos outros dilui a responsabilidade

Em muitos times, a organização se parece com isto.

Um desenvolvedor trabalha numa feature. Ele entrega. Passa para outro assunto. Aparecem bugs. Como ele já está ocupado, outra pessoa assume. Um desenvolvedor disponível. Alguém na escala de plantão. Um time de suporte técnico. Às vezes um time dedicado a bugs.

No papel, parece eficiente. Você otimiza a disponibilidade.

Na prática, você dilui a responsabilidade.

Quem introduziu o defeito nem sempre enxerga o custo do que entregou. Quem corrige precisa entender um contexto que não criou. O tempo perdido vira coletivo, e por isso menos visível. E cada um pode se proteger atrás de uma frase clássica: "Já passei para outra coisa."

Esse sistema cria um sinal ruim.

Ele diz, de forma implícita: você pode entregar, e se quebrar, outra pessoa vai absorver.

Mesmo que ninguém formule assim, o efeito existe.

Quem cria o bug o corrige

A regra mais saudável é simples: quem cria o bug o corrige.

Não porque seja preciso punir.

Não porque seja preciso humilhar.

E sim porque a responsabilidade de correção deve continuar ligada à responsabilidade de produção.

Se um desenvolvedor sabe que os bugs dele vão voltar direto para as mãos dele, ele vai entregar de outro jeito. Vai testar mais. Vai revisar melhor. Vai evitar empurrar uma mudança frágil só para bater um prazo. Vai aceitar com menos facilidade produzir em cima de uma ambiguidade forte.

Não é uma garantia. Mas é um incentivo saudável.

Claro que há exceções.

O desenvolvedor pode estar ausente. O bug pode vir de várias contribuições. O problema pode estar num legacy. A responsabilidade pode ser compartilhada. Outra pessoa pode, às vezes, estar mais bem posicionada para corrigir.

Esses casos existem.

Mas eles não podem virar uma desculpa para abandonar a regra geral.

Na maioria dos casos, se um desenvolvedor criou o defeito, ele deve corrigi-lo. Mesmo que já tenha passado para um assunto importante. Mesmo que isso atrapalhe o planejamento. Mesmo que isso atrase a próxima feature.

A qualidade consome capacidade. Escondê-la não a torna gratuita.

Responsabilidade não é culpabilização

Aqui vale distinguir responsabilidade de cultura de culpa.

Dar ownership não quer dizer procurar um culpado. Não quer dizer expor publicamente quem quebrou. Não quer dizer criar um medo de entregar.

Uma cultura de culpa destrói a qualidade. As pessoas escondem os problemas, minimizam os defeitos, evitam correr riscos, documentam para se proteger, e o time aprende mais devagar.

A responsabilidade útil é diferente.

Ela diz: você é dono do que entrega, então você participa da correção, do aprendizado e da melhoria disso.

Não se busca punir. Busca-se fechar o ciclo.

O desenvolvedor que corrige o próprio bug entende melhor o que quebrou. Ele vê onde a compreensão dele estava insuficiente. Vê se faltava o teste. Vê se a spec estava vaga. Vê se a arquitetura tornava o erro provável.

É esse ciclo que cria qualidade.

Os desenvolvedores não são executores

Essa responsabilidade pressupõe outra ideia: os desenvolvedores não são executores.

Eles não estão ali para "sair despejando código".

Eles são criadores de valor.

O Product Manager é responsável pelas escolhas de produto: por que este assunto, para qual público, com que impacto, em que prioridade. Mas os desenvolvedores são responsáveis pela qualidade técnica, pela code base e pelo que entregam.

Cada um tem uma área de responsabilidade.

Se o Product Manager faz uma escolha de produto ruim, ele precisa assumir.

Se os desenvolvedores entregam um código frágil, pouco testado, mal compreendido ou difícil de manter, eles também precisam assumir.

Isso não quer dizer que as responsabilidades ficam isoladas. Elas conversam. Um bom produto se constrói no diálogo entre escolhas de produto, viabilidade, uso, qualidade e restrições técnicas.

Mas o diálogo não pode servir para dissolver a responsabilidade.

Uma especificação vaga demais deve ser recusada

Um defeito nem sempre vem de um código ruim.

Ele pode vir de uma especificação incompleta, de uma decisão de produto ambígua, de um caso não pensado, de um fluxo mal compreendido.

Mas isso não significa que ninguém é responsável.

Se uma spec está vaga demais, os desenvolvedores precisam poder recusar produzir.

Recusar não quer dizer travar. Quer dizer: o enquadramento não está claro o suficiente para entregar direito.

É melhor pedir um esclarecimento antes de codar do que criar uma funcionalidade capenga que depois vai gerar bugs, suporte, retrabalho e discussões intermináveis.

Um desenvolvedor responsável não se limita a executar um pedido ambíguo. Ele procura entender o comportamento esperado, os casos-limite, os critérios de aceitação, os riscos, os dados, as dependências.

Se ele não consegue entender o que precisa entregar, não consegue garantir a qualidade do que entrega.

A responsabilidade de produto e a responsabilidade técnica se encontram aí: o Product Manager deve esclarecer a escolha de produto; os desenvolvedores devem recusar transformar uma ambiguidade forte em código frágil.

O TDD: o quê antes do como

O TDD, Test Driven Development, é uma resposta concreta a essa lógica.

Em vez de escrever primeiro o código e depois verificar se ele funciona, você escreve primeiro o teste.

O teste descreve o quê.

O código implementa o como.

É uma distinção importante. O teste formaliza uma parte da especificação: este é o comportamento esperado, isto é o que deve continuar verdadeiro, isto é o que não pode quebrar.

Depois, o código pode evoluir. Pode ser refatorado. Pode interagir com novos dados. Outras funcionalidades podem surgir ao redor. Mas se o comportamento esperado quebra, o teste quebra.

No cenário ideal, o problema é detectado na máquina do desenvolvedor ou na qualificação, não em produção.

O TDD não elimina todos os bugs. Não substitui a reflexão de produto. Não transforma uma spec ruim em bom produto.

Mas ele muda uma coisa essencial: obriga a tornar uma parte da qualidade verificável antes da implementação.

Numa organização que quer menos bugs, essa disciplina conta.

A QA não é uma rede de proteção

A QA não deve ser o lugar onde os desenvolvedores depositam a responsabilidade pela qualidade.

Se a QA é só uma rede de proteção no fim da cadeia, ela chega tarde demais. Ela testa o que deveria ter sido pensado, esclarecido, automatizado ou evitado mais cedo. Ela vira a última barreira antes da produção, e por isso o lugar onde a organização terceiriza os próprios defeitos.

Isso não basta.

A QA pode assumir um papel muito mais estratégico.

Ela pode definir os critérios de qualidade. As políticas de teste. Os padrões de entrega. Os limites de regressão aceitáveis. Os riscos a cobrir. As áreas do produto a proteger. Os testes a automatizar. Os sinais que mostram que um time está entregando melhor ou pior.

Com a inteligência artificial e a automação, esse papel fica ainda mais importante.

Como em muitas profissões, a IA permite reduzir uma parte do operacional repetitivo para focar mais na estratégia. Para a QA, isso significa menos testes manuais repetitivos, menos regressões refeitas tela por tela, e mais reflexão sobre o sistema de qualidade.

O valor da QA se desloca.

Menos: refazer mecanicamente as mesmas verificações.

Mais: definir o que verificar, por quê, com que nível de automação, sobre quais riscos, com quais critérios.

A QA não substitui a responsabilidade dos desenvolvedores. Ela constrói o enquadramento no qual essa responsabilidade se torna praticável, mensurável e duradoura.

As métricas devem servir à qualidade

Medir pode ser útil.

O retrabalho, por exemplo, pode mostrar que um time volta com frequência demais aos mesmos assuntos. O cycle time pode revelar que as reincidências atrasam muito a entrega. As regressões podem mostrar que certas áreas do produto quebram com frequência demais.

Esses sinais são úteis se servem para melhorar o sistema.

Eles ficam tóxicos se recriam uma obsessão administrativa.

Não adianta gastar um tempo infinito para saber se um defeito é um bug, uma feature, uma melhoria, uma reincidência, uma anomalia de QA ou outra coisa, se essa classificação não muda a decisão.

A medição deve iluminar.

Ela não deve substituir o julgamento.

O objetivo continua simples: soltar rápido o que importa, com um nível de qualidade aceitável, e reduzir a dor real.

O legacy do futuro

O legacy existe.

Todos os times precisam, em algum momento, trabalhar com código antigo, decisões passadas, arquiteturas frágeis, dependências mal documentadas, escolhas que talvez fizessem sentido ontem e que hoje complicam tudo.

Você nem sempre consegue evitar o legacy que já existe.

Mas você pode evitar fabricar o legacy de amanhã.

Um bug transferido para outra pessoa, uma spec vaga aceita sem discussão, um teste nunca escrito, uma regressão manual repetida sem automação, uma QA usada como barreira final, um código entregue rápido mas mal compreendido: tudo isso vira legacy futuro.

Dar ownership aos desenvolvedores não resolve tudo. Mas muda a trajetória.

Quando quem entrega é dono da qualidade do que entrega, ele produz de outro jeito. Quando ele pode recusar uma spec ambígua demais, evita transformar o vago em complexidade. Quando o TDD formaliza uma parte da especificação, o produto fica mais robusto. Quando a QA define uma política de qualidade, o sistema inteiro fica mais claro.

O legacy futuro não é uma fatalidade.

É, muitas vezes, o resultado de responsabilidades mal colocadas hoje.

Conclusão

Um time que quer menos bugs não deve só classificá-los melhor.

Ele deve tornar a qualidade impossível de delegar.

A política de zero bug trata o estoque de defeitos conhecidos. Mas a qualidade de entrega impede de recriar esse estoque. Para isso, cada um precisa segurar a própria responsabilidade.

O Product Manager é dono da escolha de produto.

Os desenvolvedores são donos da qualidade técnica do que entregam.

A QA constrói o enquadramento de qualidade: critérios, padrões, riscos, testes, automação.

E o time, coletivamente, precisa recusar as organizações onde os bugs viram sempre o problema de outra pessoa.

Responsabilidade não quer dizer culpa. Quer dizer ownership.

A qualidade pertence a quem entrega, porque são eles que podem construí-la no momento em que ela custa menos: antes de o bug existir.

Para saber mais

Zero bug: vamos parar de administrar estoques de defeitos Code centric