Il prototipo prima dello sviluppo, invece del capitolato: perché cento pagine di specifiche non salvano il progetto

Un'azienda prepara per diversi mesi il capitolato. Il documento supera le cento pagine e lo hanno commentato vendite, operations, finanza e IT. Dopo la firma del contratto con il fornitore seguono mesi di sviluppo e alla prima demo si sente dire: «Non era questo che intendevamo».

Lo scenario è un modello, ma il problema che c'è dietro è reale. Nell'indagine internazionale NaPiRE, completata da 228 organizzazioni di 10 paesi, i rispondenti hanno scelto i problemi più critici nella gestione dei requisiti. I più citati sono stati i requisiti incompleti o nascosti (48 per cento dei rispondenti). Le carenze di comunicazione tra team e cliente sono state indicate dal 41 per cento e, tra i primi dieci problemi, sono quelle che i rispondenti hanno segnalato più spesso come causa rilevante del fallimento di un progetto.

Un capitolato corposo dà una sensazione di sicurezza, ma non permette di verificare l'essenziale: se le persone capiranno la soluzione e riusciranno a svolgere il proprio lavoro con essa. Un prototipo software lo mostra in pochi giorni o settimane, quando correggere costa ancora poco, e non dopo mesi di sviluppo.

Perché la firma sul capitolato non protegge dai malintesi

La firma conferma l'accordo sul testo, non che entrambe le parti immaginino la stessa cosa. Frederick P. Brooks Jr., nel saggio No Silver Bullet del 1987, scrisse che la parte più difficile della costruzione del software è decidere con precisione che cosa costruire e che nessun'altra parte è più difficile da correggere in seguito. Secondo lui per il cliente è di fatto impossibile specificare in modo completo, preciso e corretto i requisiti di un software moderno prima di averne provate alcune versioni.

A nostro avviso un documento voluminoso tende piuttosto a nascondere il problema. A ogni pagina cresce la sensazione di completezza, ma ogni reparto legge soprattutto il proprio capitolo e le cose ovvie non le scrive nessuno. Il primo feedback su qualcosa di tangibile l'azienda lo riceve solo quando sul malinteso poggia già il codice. Nello stesso saggio Brooks definì fondamentalmente errato il presupposto delle procedure di acquisizione del software dell'epoca, secondo cui un sistema si può specificare in anticipo in modo soddisfacente, mettere a gara, costruire e installare.

La stessa frase, schermate diverse

Un testo non si può usare, quindi non vi permette di verificare se tutti lo capiscono allo stesso modo. Prendete il requisito modello «gli ordini oltre il limite li approva il responsabile». La direttrice finanziaria immagina un riepilogo mattutino per l'approvazione in blocco, il responsabile di magazzino una notifica sul cellulare, il programmatore un campo di stato in una tabella. Tutte le interpretazioni sono coerenti con la frase e ognuna porta a un impegno e a un costo diversi.

Le eccezioni emergono solo quando il compito viene svolto davvero. Chi approva quando il responsabile è in ferie? L'approvazione vale anche dopo una modifica della quantità?

Un quarto dei rispondenti NaPiRE ha inoltre inserito tra i problemi più critici il fatto che gli stakeholder faticano a separare i requisiti dalle soluzioni che già conoscono. La guida del governo britannico GOV.UK Service Manual consiglia, nella fase di discovery, cioè nell'esplorazione del problema prima di costruire, di riformulare una soluzione decisa in anticipo come problema: non «costruire una mappa interattiva dei centri di contatto», ma «come aiutare le persone a trovare il centro più vicino».

Che cos'è un prototipo e che cosa non è

Il prototipo è una forma semplificata del prodotto futuro, su cui si può provare la soluzione prima di programmarla. Kara Pernice del Nielsen Norman Group lo descrive come un'ipotesi, cioè una soluzione candidata che si verifica nel modo più diretto osservando le persone mentre la usano. Non è un prodotto minimo funzionante (MVP), che secondo Eric Ries è la versione di un nuovo prodotto che permette al team di raccogliere, con il minimo sforzo, il massimo apprendimento convalidato sui clienti. Il prototipo è uno strumento più circoscritto: verifica la soluzione proposta prima che venga costruita.

La fedeltà del prototipo è, secondo Pernice, il grado in cui somiglia al sistema finale nell'interattività, nella resa visiva e anche nei contenuti e nei comandi. Per decidere prima dello sviluppo, nella pratica distinguiamo tre livelli:

• Schizzo o prototipo cartaceo. Al posto del sistema reagisce una persona che conosce il progetto e porge all'utente le schermate disegnate successive. Con il metodo affine Wizard of Oz la schermata è gestita da una persona in un'altra stanza, così si può provare anche un comportamento che nessuno ha ancora programmato. Jakob Nielsen annovera la prototipazione su carta tra le tecniche più rapide ed economiche. È adatta a verificare l'approccio di base e il flusso.
• Prototipo cliccabile. Schermate collegate che reagiscono come un'applicazione, anche se dietro non gira nulla. Verifica se le persone riescono a svolgere i compiti chiave senza aiuto.
• Prototipo funzionante su dati reali. Una porzione limitata di codice vero, collegata a un campione di dati o a un'integrazione a rischio. È adatto quando l'incertezza non riguarda l'interfaccia, ma i dati o la tecnologia.

La nostra regola di scelta: la fedeltà più bassa che risponde ancora alla domanda del momento. Secondo Nielsen un test precoce ha su uno tardivo un vantaggio tale da superare anche la differenza di qualità del prototipo. Il Design Kit di IDEO.org prevede per la prototipazione rapida da alcuni giorni ad alcune settimane, a seconda di ciò che si testa.

Che cosa deve dimostrare un prototipo software

Il prototipo è un test, non una presentazione. Secondo la guida GOV.UK non occorre prototipare l'intero percorso dell'utente: spesso basta concentrarsi sulle parti più complesse e testare le ipotesi più rischiose. Prima dello sviluppo il prototipo dovrebbe rispondere a queste domande:

1. Le persone capiscono il flusso? Riesce a svolgere il compito dall'inizio alla fine anche chi non ha partecipato alla progettazione? Ogni esitazione nel test può diventare, in esercizio, una telefonata all'assistenza o un errore in un ordine.
2. Sono state prese le decisioni chiave? Il testo permette di rimandare una controversia, la schermata no. Ciò che si decide ora non resta come incertezza nell'offerta economica.
3. Il progetto regge con dati reali? I nomi veri sono spesso più lunghi che nella demo, i campi vuoti e i record duplicati.
4. Funziona l'integrazione più rischiosa? L'integrazione è il collegamento con un altro sistema, per esempio con la contabilità. Il servizio britannico Register to vote non avrebbe funzionato senza un'API, cioè un'interfaccia per lo scambio di dati, collegata ai sistemi di registrazione di oltre 400 amministrazioni locali. Per questo il team vi si è concentrato già nella fase alpha, dedicata ai prototipi.
5. Gli utenti lo accetteranno? Il prototipo non garantisce l'adozione, ma indica se le persone preferirebbero il nuovo procedimento ai workaround di oggi. Perché questo conti lo approfondisce l'articolo Il sistema più caro è quello che le vostre persone non usano.

Test con gli utenti: osservare, non chiedere

Il test con gli utenti significa che una persona del gruppo target svolge sul prototipo un compito reale, per esempio il compito modello «emettete una nota di credito per questa fattura», e voi osservate dove esita e che cosa interpreta diversamente. Un questionario rileva ciò che le persone pensano che farebbero. L'osservazione mostra ciò che fanno davvero.

Jakob Nielsen parte da un modello secondo cui un primo studio con cinque partecipanti fa emergere circa l'85 per cento dei problemi di usabilità, cioè dei punti in cui le persone si bloccano o sbagliano. Invece di un unico studio con 15 persone consiglia tre cicli da cinque, perché ogni ciclo successivo verifica le correzioni e fa emergere problemi più profondi. Vale per utenti comparabili: con due gruppi nettamente diversi consiglia da tre a quattro persone per ciascun gruppo.

Quando una modifica tardiva costa davvero cara

Il costo del cambiamento è quanto costa modificare una decisione in una determinata fase del progetto. Barry Boehm e Victor Basili, in un articolo del 2001, hanno scritto che trovare e correggere un problema software dopo la consegna costa spesso 100 volte di più che nella fase dei requisiti e della progettazione. La parola «spesso» l'hanno aggiunta di proposito: per i sistemi piccoli e non critici il rapporto è, secondo loro, più vicino a 5:1. Hanno inoltre riportato che i progetti di allora spendevano tra il 40 e il 50 per cento circa dello sforzo in rilavorazioni evitabili e tra le due fonti principali di queste rilavorazioni indicavano i requisiti specificati in fretta.

L'aumento del costo nel tempo, però, non è universale. Tim Menzies e i coautori, su 171 progetti, non hanno trovato prove che risolvere i problemi in una fase successiva richiedesse in modo costante o sostanziale più sforzo che poco dopo la loro comparsa. Si trattava perlopiù di progetti di dimensioni piccole e medie con la metodologia Team Software Process, senza dati sul periodo successivo alla consegna. Gli autori stessi avvertono che l'effetto potrebbe manifestarsi solo in alcuni tipi di progetti.

A nostro avviso a rendere cara una modifica tardiva non è il calendario, ma ciò che nel frattempo è cresciuto sulla decisione sbagliata: codice, integrazioni, documentazione, formazione e modello dei dati. Kara Pernice ricorda che buttare via il codice è molto costoso, buttare via un prototipo no. Il malinteso non corretto, inoltre, l'azienda lo paga ogni giorno dopo l'avvio come attrito nel lavoro quotidiano, il cui calcolo è illustrato nell'articolo Il buon design non è decorazione.

Il prototipo conviene quindi soprattutto dove sulla decisione sbagliata crescerebbe di più: con molti utenti, più integrazioni e uno sviluppo lungo. La sua portata e il suo costo si possono delimitare in anticipo, il costo di un errore no.

Il prototipo come base per l'offerta e la stima

Quando i fornitori quotano un testo di cento pagine, ciascuno quota la propria interpretazione e il proprio margine per l'incertezza. Il più prudente gonfia il prezzo, il meno prudente lo sottostima e la differenza emerge più avanti nelle richieste di modifica, cioè lavori al di fuori dell'accordo iniziale che vengono fatturati a parte.

Un prototipo cliccabile con criteri di accettazione cambia il punto di partenza. I criteri di accettazione sono, secondo la guida GOV.UK, un elenco di risultati che serve da checklist per confermare che il servizio ha svolto il suo compito e ha soddisfatto il bisogno dell'utente. Spesso si scrivono nella forma «è fatto quando…», per esempio per il servizio Register to vote: l'utente sa come registrarsi online. Il prototipo mostra come deve funzionare, i criteri stabiliscono quando il lavoro è finito, e così i fornitori quotano la stessa cosa.

La guida consiglia anche di riconsiderare perché vi serve una funzionalità, se non riuscite a formularne l'obiettivo. Una funzionalità non costruita non costa nulla né nello sviluppo né nella manutenzione.

I rischi del prototipo

• Scambiarlo per il prodotto finito. Un prototipo cliccabile sembra finito, ma gli mancano la sicurezza, la gestione dei dati e il trattamento degli errori. Pernice avverte che, davanti a un design rifinito, la direzione cede facilmente alla tentazione di metterlo direttamente in produzione.
• Curare troppo la resa visiva. Con una fedeltà bassa, secondo Pernice, gli utenti esprimono più facilmente reazioni negative, i designer si affezionano meno al progetto e gli stakeholder vedono che il lavoro non è finito. La rifinitura tende quindi ad attenuare un feedback sincero.
• Destino del prototipo non chiarito. GOV.UK consiglia di costruire nella fase alpha solo ciò che basta per testare le idee, non codice di qualità da produzione, e di mettere in conto che il codice verrà buttato via al termine della fase. Se il prototipo verrà buttato via o sviluppato ulteriormente va deciso prima di costruirlo. Altrimenti, per inerzia, può diventare la base del prodotto insieme al debito tecnico, cioè alle scorciatoie che rendono più cara ogni modifica successiva.

Quando il prototipo non serve

Il prototipo riduce l'incertezza. Dove non ce n'è, o dove si può ridurre a un costo inferiore, è una spesa inutile.

• Acquistate un software pronto senza personalizzazioni. Il ruolo del prototipo lo svolge una versione di prova o una demo su cui le persone provano i propri compiti reali.
• Il sistema è piccolo e non critico. Boehm e Basili scrivono che questi sistemi si possono sviluppare in modo più efficiente con un approccio meno formale di prototipazione continua. Qui il prototipo separato è sostituito dal prodotto stesso, sviluppato a piccoli passi.
• La domanda non è come, ma se a qualcuno interessa. In quel caso può bastare uno smoke test, cioè la verifica dell'interesse prima che la soluzione esista. Eric Ries racconta come il suo team abbia passato due settimane a costruire una funzionalità che non interessava a nessuno, benché secondo lui l'avrebbe rivelato già un semplice smoke test con un annuncio su AdWords.
• Il problema non è nel software. Se il processo contiene un passaggio inutile, un prototipo software si limita a trasferirlo sullo schermo. Il passaggio va prima eliminato. Se un sistema su misura convenga davvero lo analizza l'articolo Un buon sistema interno può ripagarsi prima di una nuova assunzione.

Secondo GOV.UK fermare un progetto al termine della fase di discovery non è un fallimento, se la ricerca mostra che è la decisione migliore: si risparmiano tempo e denaro. Sul prototipo decidete quindi in base a dove si trova la maggiore incertezza del progetto e a quanto costerebbe un errore.

Cosa portarsi a casa

• Prima di firmare un capitolato corposo verificate con un prototipo la parte più rischiosa: il flusso più frequente, l'eccezione controversa o l'integrazione non verificata.
• A ogni prototipo assegnate in anticipo una domanda e un criterio di successo, altrimenti del test resta solo una presentazione.
• Testate con cinque persone comparabili su compiti reali e, dopo le correzioni, fate un altro ciclo.
• Basate il capitolato e la scelta del fornitore su un prototipo testato e su criteri di accettazione, così tutti quotano la stessa cosa.
• Prima di tutto date un nome all'incertezza che state affrontando. A volte la elimina a un costo inferiore una versione di prova di un software pronto, uno smoke test o una modifica del processo.