Ideia principal

Lida ao pé da letra, a fórmula anuncia um software sem defeito — o que nenhum time entrega, e a objeção cai na hora. O objetivo é outro: zero defeito conhecido sem decisão.

O desconhecido continua fora de alcance. O que se mira é a aceitação permanente e organizada de defeitos que já conhecemos. Quando chega um sinal — um retorno do suporte, uma regressão detectada num aplicativo como o My Porsche —, o time decide: isso é um defeito? Se sim, corrigimos. Se não, tiramos aquilo da gestão de defeitos: melhoria, pedido de capacidade, mal-entendido, assunto interessante mas fora da prioridade.

O que a regra proíbe é o terceiro estado: "sabemos que é um defeito, guardamos numa lista para depois". Um defeito conhecido que se conserva sem decidir deixou de ser um defeito de software; é um defeito de decisão.

Por que isso importa

Isso vira do avesso a objeção mais comum. Não se promete a perfeição, se proíbe um estado intermediário — e o estado intermediário é perfeitamente alcançável.

Também desloca a medida. Deixamos de contar os defeitos do produto e passamos a contar os defeitos conhecidos sem decisão. O primeiro número depende do sistema de produção; o segundo depende apenas da organização.

Nuances e limites

A regra não diz nada sobre a qualidade das decisões tomadas. Um time que requalifica em massa como não-defeito satisfaz a letra e esvazia o sentido.

Ela só alcança o conhecido: um produto pouco instrumentado, sem suporte estruturado, exibe poucos defeitos conhecidos sem ter menos defeitos.

Questões em aberto

• Como detectar uma requalificação de conveniência, que encerra a decisão sem tratar a dor?