Come prepararsi e sopravvivere alle decisioni Ship/No-Ship

Ed è proprio di questo che parla questo articolo. Non ha nulla di nuovo o “rivoluzionario” da offrire, solo riflessioni molto pratiche e consigli nati dalle mie esperienze vissute, spesso col fiato sospeso, come responsabile QA nell’arco di diversi decenni, e lezioni che ho tratto da esse. Una sorta di autenticità da dirigente QA, se così vogliamo chiamarla. Lezioni che, naturalmente, siete liberissimi di ignorare, contraddire o deridere a vostro piacimento.

È evidente a chiunque abbia ricoperto ruoli di leadership nel QA per un minimo di tempo che il trauma centrale di quell’esperienza consiste nel gestire il famigerato meeting “si rilascia o no”. E sopravvivere ad esso. 

Perché è qui che tutto arriva al punto critico, e il QA viene interrogato come un sospetto omicida, e i detective sono tutti gli altri “stakeholder” (un eufemismo se mai ne esistesse uno). E, proprio come dei veri detective, tutto quello che vogliono da te è che tu firmi la confessione.

Ma non deve per forza essere così. Basta che tu abbia un alibi inattaccabile. Sto scrivendo questo articolo per fornirtene uno.

È l’ora delle storie

Il più grande errore che i responsabili QA commettono prima di entrare in un meeting sul rilascio è la mancanza di preparazione. O meglio, la mancanza di una preparazione efficace. 

La maggior parte dei lead o manager QA affronta il meeting “preparata” principalmente, e spesso esclusivamente, con metriche relative ai bug. Il numero di problemi aperti, il numero di problemi di Categoria A aperti, il numero di quelli di Categoria B, bla bla bla. A volte, se il resto del team è fortunato, il lead QA riuscirà a dare una qualche vaga e impressionistica idea di quale copertura di test sia stata raggiunta fino a quel momento. Anche se, di solito, i dati utilizzati sono semplicemente un inventario dei test e degli script eseguiti. Che non è per niente una misurazione della reale copertura dei test. Quelli sono metriche di sforzo, non veri indicatori di qualità.

L’errore dietro questa strategia va oltre l’uso di metriche ambigue o senza senso per difendere (chissà quale?) posizione sul rilascio. L'errore commesso qui è ben più profondo.

Perché la strategia di decisione QA appena descritta si basa su un evidente errore di categoria. In questo scenario, la leadership QA presume che lo scopo dell’incontro sia presentare dati affinché altri possano prenderne visione e decidere da soli. Niente di più lontano dalla verità, e niente di più dannoso per l’autorità del QA.

Quello che il resto del prodotto si aspetta dalla leadership QA non sono ulteriori dati. Si aspetta un verdetto chiaro e autorevole sul rilascio del prodotto. Qui. Ora.. 

È ovvio che i dati su test e difetti saranno necessari per difendere e far accettare qualsiasi verdetto da parte di QA. Ma un verdetto autorevole è quello che il QA deve dare. 

Altrimenti, il QA abbandona la propria responsabilità e autorità uniche all’interno dell’organizzazione che consegna il prodotto. È un atteggiamento di evitamento e passivo-aggressivo. Che certo non migliora la posizione del QA nella stessa organizzazione. 

Col tempo, è una spirale discendente che azzera le possibilità per il QA di avere voce pari nel processo di sviluppo. Una situazione di cui il QA si lamenta sempre, ma di cui spesso è artefice a causa proprio di questo motivo.

Questo significa che la leadership QA deve andare all’incontro sul rilascio con una storia coerente e convincente che porti a una raccomandazione inequivocabile. Detto altrimenti, devi entrare in quel meeting pronto e disponibile a firmare col sangue digitale qualsiasi sia la raccomandazione che proponi. Niente scommesse a metà. Niente nascondersi dietro la plausibile negazione. 

Perché se non lo fai, tu e il tuo team perderete tutta la vostra credibilità in azienda. E, cosa ancora peggiore, sarete i primi ad essere accusati se altri dovranno prendere la decisione al posto vostro, e il risultato sarà un disastro di qualità sul campo. Che, ad essere sinceri, è esattamente ciò che le altre funzioni sperano succeda. Vogliono incolpare voi di tutto e usare le vostre indecisioni sulla qualità del prodotto come prova contro di voi.

Uno dei motivi principali che abilita questo atteggiamento passivo-aggressivo nella decisione è la convinzione — spesso usata in modo opportunistico — che “Non importa quello che dico, tanto rilasciano comunque”. Questa mentalità, questa scelta strategica dell’impotenza, è esattamente ciò che perpetua il senso di impotenza del QA nell’organizzazione. Ecco la profezia che si autoavvera! 

Al di là delle logiche politiche e degli errori psicologici, questa strategia parte da un fraintendimento di fondo su ciò che davvero si chiede al QA in quell’incontro. Perché in realtà non si richiede di fornire una decisione irrevocabile sul rilascio, anche se la decisione che ti viene chiesto pubblicamente di assumere assume proprio quella forma. 

E sì, devi comunque presentare un verdetto autorevole. Ma, per farlo, devi comprendere quale sia la domanda alla quale devi effettivamente rispondere con autorità.

La vera domanda a cui si chiede di rispondere ai responsabili della QA è questa: Quali sono i rischi — la loro probabile diffusione e gravità una volta che il prodotto sarà rilasciato — se spediamo oggi? Invece che, ad esempio, il mese prossimo? In altre parole, vi si chiede di fornire una valutazione dei rischi per permettere al top management di compiere una scelta di rischio razionale in quel momento. 

Questo significa che la vostra risposta definitiva nella riunione del "go-no go" è una risposta definitiva che riguarda in ultima analisi il rischio. Non se premere o meno il pulsante che lancia il razzo nello spazio.

Il che significa a sua volta che la storia della qualità che racconterete in quella riunione deve essere basata su scenari. Cioè, non sarà un semplice sì o no, non importa quanto tutti gli altri lo desiderino per lavarsi le mani da ogni responsabilità della decisione (cosa che in realtà non accade mai, giusto?). Per schematizzare un po', la vostra esposizione dovrebbe avere due parti:

• Primo, una dichiarazione autorevole e *realmente* basata sui dati dello stato attuale della qualità del prodotto. Con metriche a supporto. Piccolo spoiler: vi servirà più delle semplici metriche di difettosità per riuscirci.
• Secondo, una valutazione autorevole della qualità latente che verrebbe lasciata "sul tavolo" qualora si decidesse di rilasciare subito il prodotto. È talmente significativa che varrebbe la pena aggiungere tempo al piano di rilascio per "recuperare" quel debito di qualità? E se sì, quali sono i compromessi tempo/qualità che la QA raccomanda? E quali aree specifiche di funzionalità andrebbero indirizzate in questa estensione, e come sapremmo che la qualità latente è stata effettivamente realizzata?

Questa, in realtà, non è una strategia per eludere la domanda posta. È un modo di rispondervi tenendo conto di tutti i parametri, le variabili e i costi associati a quella decisione — oggi, la prossima settimana o il prossimo mese. 

Perché, e questo è un concetto che dovete imprimervi nella coscienza QA, il vostro vero pubblico in quella riunione non sono gli altri responsabili funzionali. È la direzione. Che siano fisicamente presenti o meno alla riunione. Quello che dite sarà comunque riferito a loro in tempi rapidissimi. Fidatevi di me.

E tutto questo gioca a vostro vantaggio. Perché ciò che CEO e COO apprezzano più di ogni altra cosa è ricevere opzioni sensate, supportate da fatti e dati concreti. Quello che detestano più di ogni altra cosa è sentirsi dire: “Eh, non siamo pronti a spedire. E non sappiamo dirvi esattamente perché. Forse tra quattro mesi.” È per questo che i CEO vanno a caccia di nuove acquisizioni — per trovare un nuovo team di delivery prodotto. 

La lamentela perenne dei team di delivery è che la direzione impone, per decreto, una data di rilascio fissa sulla quale non c’è possibilità di compromesso. Vale la pena domandarsi perché lo fanno così spesso. 

È perché non riescono mai ad avere una risposta definitiva sullo stato della qualità del prodotto, e se la loro data preferita non può essere rispettata, quale sia la data in cui sarà possibile. Così la impongono loro. Perché il team prodotto non ha offerto alternative concrete.

Quindi dovete presentarvi alla riunione "ship-no ship" con una storia avvincente, tridimensionale, basata su fatti e scenari, che conduca a un set di raccomandazioni autorevoli, le quali includano opzioni significative in termini di costi e benefici legati alla qualità rispetto alla decisione di spedire — o meno. Balbettare per qualche minuto sulle metriche dei bug e poi lasciare agli altri la decisione, non è sufficiente.

Ovviamente, per farlo dovrete avere la vostra metodologia QA, la formazione e le metriche in uno stato impeccabile. Ho scritto articoli dettagliati su questi argomenti altrove (ad es. su LI), ma essendo riflessioni teorico-procedurali, esulano dal focus pragmatico di questo articolo.

Un lieto fine

Quello che ho scritto sopra potrebbe sembrare severo e, forse, un po' contraddittorio — in apparenza. Chiudo allora l’articolo raccontando una mia esperienza durante una riunione di "ship-no ship" andata a buon fine. Andata in modo diverso da quanto descritto sopra e anche da quanto mi aspettassi.

Il mio team stava testando un prodotto totalmente nuovo. Non solo nuovo, ma indirizzato a una nicchia dove l’azienda non aveva mai avuto esperienza. Quindi una maratona di insidie nascoste, imprevisti assoluti e spiacevoli sorprese fin dall’inizio.

È arrivato il momento della riunione "ship-no ship". Avevo, all’inizio del mio mandato come QA Director, imposto un regime rigido su come avremmo definito le metriche di qualità, incluse quelle di copertura dei test sulla base dei requisiti (non semplicemente per moduli/script). Non solo metriche sui bug ma anche metriche sui trend dei bug e sulla velocità delle modifiche al codice per rafforzare la nostra valutazione. 

E tutte queste metriche erano indiscutibilmente positive. Tutti i sistemi erano "via libera". Nessuno scenario if/then/else necessario. Per una volta, non vedevo ragione per non dire con chiarezza: “Rilasciamo!”, senza riserve. 

Eppure, tecnicamente, non era il mio ruolo farlo. Perché il progetto era stato seguito da uno dei miei QA Manager e spettava a quella persona dare il verdetto autorevole. Il manager ha riassunto accuratamente tutte le metriche e confermato la loro positività. 

Poi, con mia sorpresa, ha titubato sul fatto che si potesse rilasciare o meno. Sorprendente, anche perché avevamo discusso la nostra posizione QA prima della riunione. (Nota importante: Non sorprendete mai il vostro capo in una riunione. Mai.)

Ho chiesto al manager: “Cosa ti servirebbe per sentirti a tuo agio nel raccomandare il rilascio? Se non oggi, in futuro?”

Ancora una volta, con mia sorpresa, il responsabile non ha potuto — o non ha voluto — rispondere alla mia domanda. Mi è diventato chiaro che questo manager semplicemente non voleva assumersi la responsabilità di prendere quella decisione, di firmare sulla linea tratteggiata. Cosa che ho trovato oltremodo deludente. 

È stato anche un insulto per il responsabile tecnico del progetto, che era stato instancabilmente di supporto all'attività di QA e aveva progettato un prodotto di prim'ordine. Non meritava di essere colto alla sprovvista in questo modo. E nemmeno io.

Quindi sono intervenuto e ho detto: “Non ho visto, né sentito, nessuna valida ragione per non rilasciare questo prodotto OGGI. Questo è il verdetto del QA, e io, come Direttore QA, mi assumo la piena responsabilità di questa decisione.”

Ho pensato che il responsabile tecnico stesse per baciarmi. Ma dopo quella riunione, il reparto QA ha ottenuto un'enorme credibilità e grandissimo rispetto da parte di ingegneria, project management e product management. 

Perché il percorso per essere presi sul serio nel nostro mondo è assumersi pubblicamente la responsabilità. Cosa che ho sentito di poter fare in tutta sicurezza in quel momento perché la nostra storia era stata preparata fin dall'inizio. E scritta prevedendo un lieto fine.

Il prodotto, una volta rilasciato, ha dimostrato grande qualità sul campo. Ed è stato un grande successo. Ritardarne il rilascio solo per evitare la responsabilità di prendere una decisione su quando spedire o meno avrebbe portato solo a un incremento minuscolo della qualità a fronte di un costo irragionevole in termini di denaro e time-to-market. 

Come ci siamo riusciti è un'altra storia per un altro giorno.

Come sempre, vi auguro il meglio nei vostri sforzi di QA.

Podcast correlato: TEAMWORK, AI E CONTAINERIZZAZIONE (CON MICHAEL RITCHSON DELLA NASA)