Zero bug: smettiamo di gestire scorte di difetti

Porsche ha pubblicato un caso pratico interessante sulla zero bug policy, applicata a My Porsche. L'idea può sembrare poco realistica a prima vista. Tutti sanno che un software senza bug non esiste. Anche i migliori prodotti hanno difetti, regressioni, comportamenti inattesi, casi limite.

Ma non è questo il punto.

Una policy zero bug non promette codice perfetto. Punta ad altro: non accettare più di conservare bug noti come scorta permanente da prioritizzare, riclassificare e rimandare.

Il vero problema dei bug non è solo che esistano. Il vero problema è l'organizzazione che si abitua a tenerli.

Si apre un ticket. Gli si assegna una priorità. Lo si classifica. Lo si rivede due settimane dopo. Si cambia la sua priorità. Lo si discute in comitato. Lo si rimanda perché una feature della roadmap è più urgente. Poi un cliente si lamenta, il bug riemerge e il team gestisce in urgenza quello che avrebbe dovuto decidere chiaramente da tempo.

A quel punto, il bug non è più solo un difetto software. È un difetto di decisione.

I bug non contano fino all'urgenza

In molte organizzazioni, i bug vivono in uno strano limbo.

Esistono. Tutti li vedono. Consumano energia. Irritano i clienti. Intasano il supporto. Ma non contano davvero nella pianificazione.

La roadmap avanza. Le feature previste arrivano. Le scadenze sono visibili. I trade-off si fanno sui nuovi argomenti. E i bug restano di lato, come un peso implicito che si tratterà quando ci sarà tempo.

Solo che non c'è mai tempo.

Così i bug diventano prioritari solo quando sono troppo visibili: un cliente importante si lamenta, una demo si rompe, il supporto satura, una regressione colpisce un flusso critico, un dirigente ci inciampa.

Questa logica oppone artificialmente roadmap e qualità. Come se le feature fossero il vero lavoro e i bug un rumore da gestire intorno. Ma un bug consuma capacità. Consuma anche fiducia dei clienti, credibilità interna, tempo di supporto e attenzione di prodotto.

Non contarlo non lo rende gratuito.

Cosa significa davvero «zero bug»

Una policy zero bug non significa che non ci sarà mai un bug.

Significa: zero bug noti senza decisione.

La sfumatura è essenziale. L'obiettivo non è eliminare l'ignoto. L'obiettivo è non organizzare l'accettazione permanente di difetti noti.

Quando arriva un segnale, il team deve decidere rapidamente: è un difetto o no?

Se è un difetto, si corregge.

Se non è un difetto, non lo si tratta come bug. Può essere un miglioramento. Può essere una richiesta di feature. Può essere un malinteso. Può essere un argomento interessante, ma fuori priorità.

In ogni caso, c'è una decisione.

Quello che la policy zero bug rifiuta è il terzo stato: «Sappiamo che è un bug, ma lo teniamo in una lista per dopo.»

Quel «dopo» è spesso il vero problema.

La trappola del backlog di bug

Un backlog di bug dà una sensazione di controllo.

Tutto è elencato. Ogni bug ha una priorità. Alcuni sono blocker, altri major, minor, trivial. Si può filtrare. Si può ordinare. Si può fare un comitato. Si possono produrre tabelle. Si può dire che l'argomento è sotto controllo.

Ma prioritizzare un bug ogni mese non significa trattarlo.

Spesso è solo accettare che rimanga lì.

La scorta di bug crea il suo stesso lavoro. Bisogna verificare se il bug esiste ancora. Bisogna sapere se è ancora prioritario. Bisogna sapere se il cliente coinvolto è ancora cliente. Bisogna sapere se è ancora riproducibile. Bisogna sapere se deve passare davanti a un'altra anomalia. Bisogna rileggere, riclassificare, ripianificare.

L'organizzazione spende energia ad amministrare difetti invece di ripristinare la qualità.

E la cosa più assurda è che molti di questi bug non saranno mai corretti.

Lo si sa. Il team lo sa. Il supporto lo sa. Il Product Manager lo sa. Ma il ticket resta aperto, perché chiuderlo equivale ad assumersi una decisione che nessuno vuole portare.

Una policy zero bug forza quella decisione.

Due decisioni: difetto o non difetto

La forza dell'approccio di Porsche sta nella sua semplicità.

Invece di moltiplicare le categorie, il team riduce la decisione:

• defect: è un difetto, quindi si corregge;
• no defect: non è un difetto, quindi non lo si tratta come bug.

Questa semplificazione non significa che tutto diventa brutale o automatico. Bisogna sempre capire l'impatto, il contesto, il cliente, la frequenza, la gravità. Ma la discussione deve portare a una decisione, non a una nuova categoria.

Un miglioramento può essere utile senza essere un difetto.

Una richiesta del cliente può essere pertinente senza essere un bug.

Un comportamento può essere frustrante senza essere prioritario.

Quello che conta è non nascondere il trade-off dietro una tipologia.

Se è un difetto reale, lo si tratta. Se non lo è, lo si accetta. Ma non si tiene indefinitamente un bug noto in una coda che serve soprattutto ad evitare di scegliere.

Bug o feature: al cliente non importa

Dal punto di vista del cliente, la distinzione tra bug e feature ha poco interesse.

Il cliente non si chiede se soffre a causa di un bug, di una feature assente, di una feature mal fatta o di una feature che non risponde al suo bisogno. Sente un dolore.

Un software può non avere nessun bug tecnico e tuttavia non rispondere al bisogno del cliente. Il dolore resta reale.

Al contrario, alcuni bug sono oggettivamente difetti, ma il loro impatto è basso. Se l'utente deve fare doppio clic su un pulsante, non è ideale. Ma se, di lato, una feature assente gli impedisce di fare una dichiarazione fiscale o legale obbligatoria, l'assenza di feature è più critica del bug minore.

Per questo la categoria del ticket non deve sostituire l'analisi del dolore.

La vera domanda non è: «È un bug o una feature?»

La vera domanda è:

• che dolore genera?
• per chi?
• con quale frequenza?
• con quale impatto?
• è bloccante?
• è regolatorio?
• genera supporto?
• distrugge la fiducia?

La tipologia può aiutare a misurare. Non deve decidere al posto del team.

Assumere una posizione radicale: nessuna card bug separata

Si può andare oltre.

In molte organizzazioni, eliminerei le card bug separate in Jira o negli strumenti equivalenti. Terrei solo card di lavoro.

Perché?

Perché la separazione bug / feature finisce spesso per creare due sistemi di priorità. Le feature sono pilotate dalla roadmap. I bug sono pilotati dall'urgenza, dal supporto, dalla pressione del cliente o dai comitati di prioritizzazione. E tra i due, nessuno guarda davvero l'insieme dal punto di vista del dolore e del valore.

Una card di lavoro dovrebbe rappresentare un problema da trattare.

A volte quel problema viene da un difetto software. A volte da una capacità assente. A volte da una progettazione sbagliata. A volte da debito tecnico. Ma il trade-off deve restare lo stesso: quale dolore, quale valore, quale impatto, quale decisione?

Il daily mattutino può allora servire a decidere cosa conta davvero adesso. Non a dibattere per venti minuti se qualcosa è un bug, una feature, un miglioramento o un rework.

Certo, alcune organizzazioni hanno bisogno di reporting sulla qualità. Si possono mantenere tag, metriche, categorie minimali. Ma sono informazioni secondarie. Non devono strutturare tutta la decisione.

O si tratta adesso, o si rifiuta

Il peggior stato di un bug non è «non corretto».

Il peggior stato è «da prioritizzare più tardi».

«Più tardi» sembra ragionevole. In realtà, è spesso un modo educato per non decidere.

Alcuni bug devono essere trattati subito.

Altri devono essere esplicitamente rifiutati. Si può scrivere una card minimale se si vuole tenere traccia: «Non lo faremo.» Ma non si deve alimentare un backlog di bug interminabile per dare l'impressione che l'argomento esista ancora.

La disciplina è semplice:

• se è un difetto reale e importante, si corregge;
• se non è un difetto, lo si toglie dalla gestione bug;
• se è troppo lieve per essere trattato, lo si accetta;
• se torna spesso, lo si rivaluta con nuovi segnali.

L'obiettivo non è diventare dogmatici. L'obiettivo è obbligare l'organizzazione a produrre una decisione.

La velocity deve assorbire la qualità

Correggere immediatamente un difetto può incidere sulla velocity.

Può impedire di finire una feature. Può disturbare uno sprint goal. Può rimandare un argomento della roadmap. È scomodo, ma è normale.

La qualità consuma capacità.

Quando un team ignora i bug per preservare la sua velocity, protegge una metrica a scapito del prodotto. Dà l'impressione di avanzare veloce, ma accumula attrito, supporto, debito e sfiducia.

Una policy zero bug rende visibile quel costo.

Se i difetti rallentano il team, non è la policy zero bug a creare il problema. Rivela semplicemente che il sistema produce troppi difetti o li rileva troppo tardi.

La risposta giusta non è nascondere i bug in un backlog. La risposta giusta è migliorare il sistema di produzione: test, QA, TDD, automazione, chiarimento delle specifiche, responsabilità degli sviluppatori.

Sarà l'argomento del prossimo articolo.

Come iniziare con una scorta esistente

La difficoltà arriva quando il team ha già una scorta di bug.

Si può scegliere un'opzione radicale: chiudere tutti i bug esistenti e ripartire da zero. È pulito, ma politicamente difficile. Richiede forte fiducia interna e capacità di assumersi i rifiuti.

Si può anche scegliere un'opzione progressiva.

L'articolo di Porsche propone una logica di riduzione per fasi: prioritizzare un'ultima volta, trattare un piccolo numero di difetti per sprint e definire un nuovo zero temporaneo. L'importante è che questa fase resti una transizione, non una nuova forma normale di backlog.

Un metodo molto efficace consiste nel passare attraverso il supporto.

Ogni settimana, il supporto elenca il top 3 dei ritorni dei clienti legati a bug.

Questo top 3 diventa i 3 bug prioritari da trattare.

La settimana successiva, se uno, due o tre bug sono stati corretti, il supporto propone i successivi.

Si avanza per Pareto. Si tratta prima quello che torna più spesso, quello che fa più male, quello che genera più carico di supporto. Non si comincia a riprioritizzare cento ticket. Si trattano i punti critici che ostruiscono davvero l'organizzazione.

Questo metodo ha un doppio vantaggio.

Prima di tutto, riduce il dolore del cliente visibile.

Poi, decongestionna il supporto.

Il supporto vede che i suoi ritorni servono a qualcosa. Il team di prodotto tratta i problemi che tornano davvero. Gli sviluppatori non si disperdono in una lista astratta. La direzione vede scomparire i problemi ricorrenti.

Per uscire da una scorta di bug, non bisogna iniziare a riprioritizzare tutto. Bisogna trattare quello che torna più spesso e fa più male.

Le metriche utili, senza ossessione amministrativa

Non si tratta di sopprimere ogni misurazione.

Alcune metriche sono utili:

• il rework;
• il cycle time;
• le regressioni;
• i difetti trovati prima della produzione;
• i difetti trovati in produzione;
• il carico di supporto legato a certi bug.

Queste misure possono illuminare la qualità. Permettono di vedere se il team rifà troppo spesso il suo lavoro, se certi flussi si rompono regolarmente, se una zona del prodotto genera troppo supporto, se i difetti vengono rilevati troppo tardi.

Ma la metrica deve restare uno strumento.

Se il team passa più tempo a qualificare i difetti che a migliorare il sistema, ricrea il problema che voleva risolvere. Si sostituisce allora il backlog di bug con un backlog di categorie.

La finalità non è misurare tutto. La finalità è ridurre il dolore e migliorare il flusso.

Conclusione

Una policy zero bug non rende il software magico.

Rende solo impossibile nascondere i difetti noti dietro un backlog.

Obbliga a decidere. Rende la qualità visibile. Impedisce ai bug di diventare una scorta amministrativa. Forza l'organizzazione a scegliere: correggere, rifiutare o riclassificare come qualcos'altro.

È radicale, ma è esattamente questo che rende l'approccio utile.

Finché un bug può dormire in un backlog per sei mesi, nessuno è davvero responsabile della decisione. Una policy zero bug rimette quella responsabilità al centro.

Ma non basta.

Se il team corregge velocemente senza cambiare il modo in cui consegna, resterà in un ciclo di riparazione. Il vero argomento successivo è quindi la prevenzione: responsabilità degli sviluppatori, specifiche chiare, TDD, QA, automazione, legacy futuro.

In altre parole: una policy zero bug tratta la scorta. La qualità di consegna impedisce di ricrearla.

Per saperne di più

La qualità appartiene a chi consegna Il backlog non è una discarica: è uno strumento d'azione