Ideia principal

O roadmap carrega as funcionalidades previstas. Os prazos ficam visíveis ali, as arbitragens acontecem ali, os compromissos são assumidos ali. Os defeitos ficam ao lado, como uma carga implícita que será tratada "quando der tempo".

E mesmo assim eles consomem a mesma capacidade: tempo de desenvolvedor na hora da correção, tempo de suporte a cada contorno explicado, atenção de produto a cada releitura de ticket. E consomem o que não se planeja — a confiança do cliente que encontra duas vezes o mesmo comportamento, a credibilidade interna de um time do qual se sabe que os incômodos não saem do lugar.

Não registrá-los não os torna gratuitos. Só os torna invisíveis no único lugar onde se arbitra.

Camada trazida por "A qualidade pertence a quem entrega" (2026-06-03). A mesma constatação se volta contra a objeção de cronograma oposta a qualquer regra de qualidade: trazer um desenvolvedor de volta ao próprio defeito atrapalha o sprint, empurra a funcionalidade seguinte, custa de forma visível. A qualidade consome capacidade, e excluí-la do plano não a torna gratuita — apenas retira a despesa do único lugar onde ela se compara às demais.

Por que isso importa

Isso desfaz a oposição entre roadmap e qualidade, que faz as funcionalidades passarem pelo trabalho de verdade e os defeitos por um ruído a administrar em volta. Os dois puxam do mesmo orçamento; só um é contado.

A questão não é, portanto, achar tempo para os defeitos, mas fazê-los entrar no plano em que o tempo é distribuído.

Nuances e limites

Registrar não basta. Uma fila de defeitos é um registro, e pode ficar indefinidamente sem arbitragem real.

E a carga não é uniforme: um defeito nunca encontrado não consome nada enquanto ninguém esbarrar nele.

Questões em aberto

• Como estimar a carga de suporte de um defeito antes de tê-lo corrigido?