Idea principale

La roadmap contiene le feature previste. Lì le scadenze sono visibili, lì si fanno i trade-off, lì si prendono gli impegni. I difetti restano di lato, come un carico implicito che si tratterà «quando ci sarà tempo».

Eppure consumano la stessa capacità: tempo degli sviluppatori al momento della correzione, tempo del supporto a ogni workaround spiegato, attenzione di prodotto a ogni rilettura di ticket. E consumano ciò che non si pianifica — la fiducia del cliente che incontra due volte lo stesso comportamento, la credibilità interna di un team i cui fastidi, lo sanno tutti, restano lì.

Non registrarli non li rende gratuiti. Li rende invisibili nell'unico posto in cui si decide.

Strato aggiunto da «La qualità appartiene a chi consegna» (2026-06-03). La stessa constatazione si ritorce contro l'obiezione di pianificazione che si oppone a qualunque regola di qualità: rimettere uno sviluppatore a lavorare sul proprio difetto disturba lo sprint, rimanda la feature successiva, ha un costo visibile. La qualità consuma capacità, ed escluderla dal piano non la rende gratuita — toglie soltanto la spesa dall'unico posto in cui si confronta con le altre.

Perché è importante

Questo scioglie l'opposizione fra roadmap e qualità, che fa passare le feature per il vero lavoro e i difetti per un rumore da gestire a margine. Entrambi attingono allo stesso budget; solo uno viene contato.

La questione non è quindi trovare tempo per i difetti, ma farli entrare nel piano in cui il tempo viene distribuito.

Sfumature e limiti

Registrare non basta. Una coda di difetti è una registrazione, e può restare lì indefinitamente senza che si decida davvero.

E il carico non è uniforme: un difetto che nessuno incontra non consuma nulla finché nessuno ci inciampa.

Domande aperte

• Come quantificare il carico di supporto di un difetto prima di averlo corretto?