Ideia principal

O padrão é comum: um desenvolvedor entrega uma funcionalidade, passa para o assunto seguinte, e os defeitos que aparecem são pegos por outra pessoa — um desenvolvedor livre, alguém de plantão, um time de suporte técnico, às vezes um time dedicado a bugs. O critério de alocação é a disponibilidade.

Otimizar a disponibilidade parece um ganho de sequenciamento. O efeito real está em outro lugar. Quem introduziu o defeito nunca vê o que a entrega dele custou. Quem corrige precisa reconstituir um contexto que não criou, e por isso paga duas vezes: a correção e o entendimento. E o tempo perdido, agora coletivo, deixa de ser imputável a uma entrega específica.

O sistema emite então um sinal que ninguém formula: dá para entregar rápido, e se quebrar, outra pessoa absorve. "Eu já passei para outra coisa" vira uma resposta aceitável.

Por que isso importa

Isso desloca o diagnóstico de um time que produz defeitos demais: antes de olhar as competências ou as ferramentas dele, olhamos a regra de alocação das correções. Uma regra que otimiza a vazão no curto prazo pode ser justamente o que alimenta a fila a corrigir.

Isso também dá uma leitura dos times "dedicados a bugs": eles não são apenas um modo de organização, são um dispositivo que corta o vínculo entre uma entrega e o custo dela.

Nuances e limites

A alocação por disponibilidade nem sempre é evitável — um desenvolvedor que saiu, um defeito vindo de várias contribuições, uma área de legado sem autor identificável, uma pessoa objetivamente mais bem posicionada. Esses casos existem e não se contestam.

O que se contesta é o uso que se faz deles: muitas vezes servem para justificar a regra geral inversa, em que a disponibilidade decide por padrão em vez de decidir por exceção.

Questões em aberto

• Como atribuir um defeito vindo de várias contribuições sucessivas sem transformar a atribuição numa investigação mais cara do que a correção?