La qualità appartiene a chi consegna

Una politica zero bug permette di smettere di gestire stock di difetti.

Ma non è sufficiente.

Se il team corregge i bug più in fretta senza cambiare come produce, rimane in un ciclo di riparazione. Il backlog scende, poi risale. Le urgenze spariscono, poi tornano. Il supporto respira, poi si satura di nuovo.

Il vero problema è a monte.

Come evitare di produrre tanti bug?

Non si riducono i bug solo con un'organizzazione migliore del triage. Li si riduce responsabilizzando chi consegna, rifiutando le specifiche troppo vaghe, testando prima e dando a QA un ruolo di politica della qualità invece che di rete di sicurezza.

La qualità non è qualcosa che si delega a posteriori.

La qualità appartiene a chi consegna.

Correggere i bug degli altri diluisce la responsabilità

In molti team, l'organizzazione assomiglia a questa.

Uno sviluppatore lavora a una feature. Consegna. Passa a un altro argomento. Compaiono i bug. Siccome è già occupato, qualcun altro li prende. Uno sviluppatore disponibile. Una persona di rotazione. Un team di supporto tecnico. A volte un team dedicato ai bug.

Sulla carta, sembra efficiente. Si ottimizza la disponibilità.

In realtà, si diluisce la responsabilità.

Chi ha introdotto il difetto non vede sempre il costo di ciò che ha consegnato. Chi corregge deve capire un contesto che non ha creato. Il tempo perso diventa collettivo, quindi meno visibile. E ognuno può rifugiarsi dietro una frase classica: «Sono passato ad altro.»

Questo sistema crea un segnale sbagliato.

Dice implicitamente: puoi consegnare, e se qualcosa si rompe, qualcun altro assorbirà.

Anche se nessuno lo formula così, l'effetto esiste.

Chi crea il bug lo corregge

La regola più sana è semplice: chi crea il bug lo corregge.

Non per punire.

Non per umiliare.

Ma perché la responsabilità della correzione deve restare legata alla responsabilità della produzione.

Se uno sviluppatore sa che i suoi bug gli torneranno direttamente, consegnerà in modo diverso. Testerà di più. Rileggerà con più cura. Eviterà di spingere una modifica fragile solo per rispettare una scadenza. Accetterà meno facilmente di produrre su un'ambiguità forte.

Non è una garanzia. Ma è un incentivo sano.

Certo, ci sono eccezioni.

Lo sviluppatore può essere assente. Il bug può venire da più contributi. Il problema può essere nel codice legacy. La responsabilità può essere condivisa. Un'altra persona può essere a volte meglio posizionata per correggere.

Questi casi esistono.

Ma non devono diventare una scusa per abbandonare la regola generale.

Nella maggior parte dei casi, se uno sviluppatore ha creato il difetto, deve correggerlo. Anche se è passato a un argomento importante. Anche se questo disturba la pianificazione. Anche se rallenta la feature successiva.

La qualità consuma capacità. Nasconderlo non la rende gratuita.

Responsabilità non è colpa

Bisogna distinguere qui tra responsabilità e cultura della colpa.

Responsabilizzare non significa cercare un colpevole. Non significa esporre pubblicamente chi ha rotto qualcosa. Non significa creare paura di consegnare.

Una cultura della colpa distrugge la qualità. Le persone nascondono i problemi, minimizzano i difetti, evitano di prendere rischi, documentano per proteggersi — e il team impara più lentamente.

La responsabilità utile è diversa.

Dice: sei il proprietario di ciò che consegni, quindi partecipi alla sua correzione, al suo apprendimento e al suo miglioramento.

Non si cerca di punire. Si cerca di chiudere il ciclo.

Lo sviluppatore che corregge il proprio bug capisce meglio cosa si è rotto. Vede dove la sua comprensione era insufficiente. Vede se mancava il test. Vede se la spec era vaga. Vede se l'architettura rendeva probabile l'errore.

È questo ciclo che crea qualità.

Gli sviluppatori non sono esecutori

Questa responsabilità presuppone un'altra idea: gli sviluppatori non sono esecutori.

Non sono lì per «sputare codice».

Sono creatori di valore.

Il Product Manager è responsabile delle scelte di prodotto: perché questo argomento, per quale target, con quale impatto, con quale priorità. Ma gli sviluppatori sono responsabili della qualità tecnica, della codebase e di ciò che consegnano.

Ognuno ha la propria zona di responsabilità.

Se il Product Manager fa una cattiva scelta di prodotto, deve assumerla.

Se gli sviluppatori consegnano codice fragile, poco testato, mal compreso o difficile da mantenere, devono assumerlo anche loro.

Questo non significa che le responsabilità siano isolate. Si parlano. Un buon prodotto si costruisce nel dialogo tra scelte di prodotto, fattibilità, utilizzo, qualità e vincoli tecnici.

Ma il dialogo non deve servire a dissolvere la responsabilità.

Una specifica troppo vaga deve essere rifiutata

Un difetto non viene sempre da codice scadente.

Può venire da una specifica incompleta, da una decisione di prodotto ambigua, da un caso non considerato, da un flusso mal compreso.

Ma questo non significa che nessuno sia responsabile.

Se una spec è troppo vaga, gli sviluppatori devono poter rifiutare di produrre.

Rifiutare non significa bloccare. Significa: il quadro non è abbastanza chiaro per consegnare correttamente.

È meglio chiedere un chiarimento prima di codificare che creare una funzionalità traballante che genererà poi bug, supporto, rework e discussioni interminabili.

Uno sviluppatore responsabile non si limita a eseguire una richiesta ambigua. Cerca di capire il comportamento atteso, i casi limite, i criteri di accettazione, i rischi, i dati, le dipendenze.

Se non riesce a capire cosa deve consegnare, non può garantire la qualità di ciò che consegna.

La responsabilità di prodotto e la responsabilità tecnica si incontrano qui: il Product Manager deve chiarire la scelta di prodotto; gli sviluppatori devono rifiutare di trasformare un'ambiguità forte in codice fragile.

Il TDD: il cosa prima del come

Il TDD, Test Driven Development, è una risposta concreta a questa logica.

Invece di scrivere prima il codice e verificare poi se funziona, si scrive prima il test.

Il test descrive il cosa.

Il codice implementa il come.

È una distinzione importante. Il test formalizza una parte della specifica: questo è il comportamento atteso, questo è ciò che deve restare vero, questo è ciò che non deve rompersi.

Poi il codice può evolvere. Può essere refactorizzato. Può interagire con nuovi dati. Altre funzionalità possono arrivare intorno. Ma se il comportamento atteso si rompe, il test fallisce.

Idealmente, il problema viene rilevato nell'ambiente dello sviluppatore o in qualificazione, non in produzione.

Il TDD non elimina tutti i bug. Non sostituisce la riflessione di prodotto. Non trasforma una spec scadente in un buon prodotto.

Ma cambia qualcosa di essenziale: obbliga a rendere verificabile una parte della qualità prima dell'implementazione.

In un'organizzazione che vuole meno bug, questa disciplina conta.

QA non è una rete di sicurezza

QA non deve essere il luogo in cui gli sviluppatori depositano la loro responsabilità sulla qualità.

Se QA è solo una rete di sicurezza alla fine della catena, arriva troppo tardi. Testa ciò che avrebbe dovuto essere pensato, chiarito, automatizzato o evitato prima. Diventa l'ultimo argine prima della produzione — cioè il posto in cui l'organizzazione esternalizza i propri difetti.

Non è sufficiente.

QA può svolgere un ruolo molto più strategico.

Può definire i criteri di qualità. Le politiche di test. Gli standard di consegna. Le soglie di regressione accettabili. I rischi da coprire. Le aree del prodotto da mettere in sicurezza. I test da automatizzare. I segnali che mostrano se un team consegna meglio o peggio.

Con l'intelligenza artificiale e l'automazione, questo ruolo diventa ancora più importante.

Come in molti mestieri, l'IA permette di ridurre una parte del lavoro operativo ripetitivo per concentrarsi maggiormente sulla strategia. Per QA, questo significa meno test manuali ripetitivi, meno regressioni ripercorse schermata per schermata, e più riflessione sul sistema della qualità.

Il valore di QA si sposta.

Meno: ripetere meccanicamente le stesse verifiche.

Più: definire cosa verificare, perché, con quale livello di automazione, su quali rischi, con quali criteri.

QA non sostituisce la responsabilità degli sviluppatori. Costruisce il quadro in cui questa responsabilità diventa praticabile, misurabile e duratura.

Le metriche devono servire la qualità

Misurare può essere utile.

Il rework, per esempio, può mostrare che un team ritorna troppo spesso sugli stessi argomenti. Il cycle time può rivelare che le rielaborazioni rallentano notevolmente la consegna. Le regressioni possono mostrare che certe aree del prodotto si rompono troppo spesso.

Questi segnali sono utili se servono a migliorare il sistema.

Diventano tossici se ricreano un'ossessione amministrativa.

Non serve a nulla passare un tempo infinito a stabilire se un difetto è un bug, una feature, un miglioramento, una rielaborazione, un'anomalia QA o altro — se questa qualificazione non cambia la decisione.

La misurazione deve illuminare.

Non deve sostituire il giudizio.

L'obiettivo resta semplice: consegnare in fretta ciò che conta, con un livello di qualità accettabile, e ridurre il dolore reale.

Il legacy del futuro

Il legacy esiste.

Tutti i team devono, a un certo punto, lavorare con codice vecchio, decisioni passate, architetture fragili, dipendenze mal documentate, scelte che forse avevano senso ieri e che oggi complicano tutto.

Non si può sempre evitare il legacy esistente.

Ma si può evitare di fabbricare il legacy di domani.

Un bug trasferito a qualcun altro, una spec vaga accettata senza discussione, un test mai scritto, una regressione manuale ripetuta senza automazione, una QA usata come ultima rete, codice consegnato in fretta ma mal compreso: tutto questo diventa legacy futuro.

Responsabilizzare gli sviluppatori non risolve tutto. Ma cambia la traiettoria.

Quando chi consegna possiede la qualità di ciò che consegna, produce in modo diverso. Quando può rifiutare una spec troppo ambigua, evita di trasformare il vago in complessità. Quando il TDD formalizza una parte della specifica, il prodotto diventa più robusto. Quando QA definisce una politica della qualità, l'intero sistema diventa più chiaro.

Il legacy futuro non è una fatalità.

È spesso il risultato di responsabilità mal collocate oggi.

Conclusione

Un team che vuole meno bug non deve solo classificarli meglio.

Deve rendere la qualità impossibile da delegare.

La politica zero bug tratta lo stock di difetti noti. Ma la qualità di consegna impedisce di ricreare quello stock. Per questo, ognuno deve tenere la propria responsabilità.

Il Product Manager possiede la scelta di prodotto.

Gli sviluppatori possiedono la qualità tecnica di ciò che consegnano.

QA costruisce il quadro della qualità: criteri, standard, rischi, test, automazione.

E il team, collettivamente, deve rifiutare le organizzazioni in cui i bug diventano sempre il problema di qualcun altro.

Responsabilità non significa colpa. Significa ownership.

La qualità appartiene a chi consegna, perché sono loro a poterla costruire nel momento in cui costa meno: prima che il bug esista.

Per saperne di più

Zero bug: smettiamo di gestire scorte di difetti Code centric