Da un'indicazione vaga a una specifica eseguibile.
«Come prima, ma più veloce e con qualche funzione nuova» è una richiesta sincera. Non è ancora qualcosa su cui si possa lavorare.
Una richiesta tipica, riportata quasi alla lettera: «vogliamo quello che avevamo sul vecchio sistema, ma più veloce, con una grafica migliore e con qualche funzionalità in più». È una frase onesta. Chi la pronuncia sa cosa non va e sa che vuole qualcosa di meglio. Non è però una specifica: non dice cosa significa «più veloce» sul catalogo reale, quali funzioni nuove hanno peso operativo, cosa del vecchio sistema va conservato perché funziona e cosa viene ricordato come funzionante solo per abitudine.
Il lavoro che sta in mezzo
Fra la richiesta e lo sviluppo c’è un lavoro autonomo, che a volte dura settimane. Consiste nell’estrarre le specifiche reali dal sistema esistente, osservando come viene usato e non solo come era stato pensato; nell’ascoltare chi lo usa per distinguere ciò che serve da ciò che è familiare; nel misurare, dove si può, invece di stimare.
Il risultato è un documento che descrive cosa il nuovo sistema deve fare, in termini verificabili. Non «più veloce», ma «la pagina di categoria con duemila articoli si carica in meno di un secondo». Non «qualche funzione nuova», ma un elenco ordinato per peso operativo, con le prime tre che entrano nella prima versione e le altre che aspettano.
Perché è consulenza, non preventivo
Questo lavoro si può fare in due modi. Si può comprimerlo in una stima veloce, scrivere un preventivo basato su ipotesi e scoprire le ipotesi sbagliate durante lo sviluppo, quando correggere costa di più. Oppure si può riconoscerlo come fase a sé, con il suo tempo e il suo valore.
Noi lo trattiamo nel secondo modo. La specifica eseguibile è un deliverable: il cliente la porta a casa e può usarla anche con un altro fornitore. Il preventivo per lo sviluppo arriva dopo, ed è più preciso perché poggia su qualcosa di scritto.
Cosa cambia per lo sviluppo
Quando la specifica è eseguibile, lo sviluppo ha un perimetro netto. Le iterazioni con il cliente servono a raffinare, non a scoprire. I tempi reggono meglio, perché le sorprese sono già state incontrate prima. E il software che ne esce fa meno cose, ma le fa per una ragione che si può rileggere.