Angolo

Un dispositivo di qualità collocato dopo la consegna — il team che prende i bug degli altri, la QA come ultimo argine, la coda dei difetti, la metrica del rework — non si limita a recuperare difetti: devia verso un terzo il ritorno di informazione che avrebbe insegnato al loro autore come non produrli. È questo, e non il loro costo diretto, a rendere questi dispositivi strutturalmente perdenti: proteggono il prodotto una volta, e degradano la produzione ogni volta. La qualità appartiene quindi a chi consegna nel senso più letterale — sono gli unici a occupare la posizione da cui il difetto poteva ancora non esistere, e ogni spostamento a valle svuota quella posizione di ciò che la rendeva utile.

Sintesi

Il movimento si ripete in quattro punti della catena, e ogni volta ha l'aspetto di una buona pratica.

Anzitutto nell'assegnazione. Affidare un difetto allo sviluppatore disponibile ottimizza la pianificazione e recide il legame fra una consegna e il suo costo. L'autore non vede ciò che la sua consegna ha prodotto; chi corregge ricostruisce un contesto che non ha creato e trova una causa tecnica, mai una causa decisionale. La regola opposta — chi crea il difetto lo corregge — vale allora meno per il lavoro che assegna che per i due effetti che ristabilisce: un incentivo che agisce prima della consegna, e un apprendimento che non si trova in nessun altro punto.

Poi all'ingresso. Una specifica ambigua trasmessa così com'è non sparisce: viene sciolta più tardi, in silenzio, da chi scrive il codice. Il diritto di rifiutarsi di produrre nel vago è l'esatto corrispettivo del dovere di correggere i propri difetti — in entrambi i casi, ci si rifiuta di lasciare che la decisione e la sua conseguenza si separino. Il test scritto prima del codice compie lo stesso spostamento in forma strumentata: fissa il comportamento atteso quando è ancora discutibile, invece di verificarlo quando è diventato costoso cambiarlo.

Infine all'uscita, con la forma più istituzionalizzata. Una QA collocata come ultimo argine può solo bloccare o lasciar passare; lo stesso mestiere collocato a monte scrive i criteri, le soglie e i rischi da coprire. È la posizione, non la missione, a decidere se la funzione definisce il quadro o rimedia a valle — e l'automazione, assorbendo la parte ripetitiva, rende praticabile questo spostamento proprio nel momento in cui diventava indispensabile.

Ciò che lega questi quattro punti è un'asimmetria temporale. Il costo della qualità è minimo nell'istante della produzione e poi cresce senza mai ridiscendere; l'informazione necessaria per esercitarla segue esattamente la curva inversa. Ogni dispositivo a valle sceglie quindi la comodità di pianificazione a scapito dell'unica posizione in cui il difetto poteva non nascere.

Due condizioni delimitano il movimento, e si reggono a vicenda. La prima è che la responsabilità restituita a chi consegna arrivi come proprietà e non come colpa: appena serve a designare un colpevole, i difetti escono dalle conversazioni prima di uscire dal prodotto. La seconda è che la sua zona resti distinta da quella del prodotto — il dialogo fra scelta di prodotto e qualità tecnica prepara la decisione, non la mette in comune, altrimenti la responsabilità si dissolve senza che nessuno l'abbia spostata.

Il conto finale si legge nel legacy. Ciò che chiamiamo eredità è in parte una produzione corrente: ogni difetto passato ad altri, ogni ambiguità accettata, ogni test non scritto, ogni regressione ripercorsa a mano è un rimedio a valle scelto oggi, di cui il prodotto conserverà la traccia molto dopo che il vincolo che l'ha motivato sarà stato dimenticato.

Tensioni / contraddizioni

Riportare la qualità a chi consegna e lasciargli il margine per esercitarla non vanno sempre insieme. La regola «chi crea il difetto lo corregge» agisce come incentivo a condizione che lo sviluppatore avesse voce in capitolo su ciò che consegnava; imposta sotto un vincolo di tempo che non ha fissato lui, diventa una sanzione per una decisione presa altrove. Queste note non dicono dove stia la soglia.

C'è tensione anche con il metodo per uscire da un arretrato esistente: trattare ogni settimana i tre problemi più segnalati dal supporto è un dispositivo a valle dichiarato, utile, e che contraddice la tesi finché resta in vigore. Si giustifica come transizione, il che presuppone una scadenza che qui nulla fissa.

Domande

• In un team di diverse decine di sviluppatori, quale forma minima di ritorno dalla produzione mantiene il legame fra un difetto e il suo autore, quando non è più praticabile che sia lui a correggerlo?
• Quali vincoli esterni — certificazione, impegno contrattuale, audit — rendono non negoziabile un controllo finale, e come mantenerlo senza che torni a essere l'unico meccanismo di qualità?