Come progettare software quando la conoscenza del problema arriva anche dopo l'inizio del progetto

Quando un'azienda decide di sviluppare un software, le prime domande sono quasi sempre le stesse:

• Quanto costerà?

• Quanto tempo servirà?

• Quali funzionalità dovrà avere?

Sono domande corrette. Ma ne esiste una meno frequente, e spesso più importante:

Quanto conosciamo davvero oggi del problema che il software dovrà risolvere?

Molti progetti partono dal presupposto che la risposta sia: tutto.

Si pensa che, attraverso l'analisi iniziale, sia possibile raccogliere ogni esigenza, definire ogni comportamento del sistema e arrivare a una soluzione completa prima ancora che il software venga utilizzato.

Nella realtà, però, questa condizione raramente esiste. Non perché l'azienda non conosca il proprio lavoro. Al contrario: spesso lo conosce così bene da non riuscire più a distinguere ciò che è una regola esplicita da ciò che è diventato un'abitudine.

Chi lavora ogni giorno con un processo tende naturalmente a descriverne gli obiettivi, le regole principali e i passaggi fondamentali, ma molti dettagli rimangono impliciti.

Sono decisioni prese automaticamente, eccezioni gestite sulla base dell'esperienza, piccoli passaggi che nessuno considera informazioni da comunicare perché fanno semplicemente parte del modo abituale di lavorare.

Finché il processo rimane manuale, questi elementi non rappresentano un problema.

Diventano evidenti quando il lavoro viene trasferito all'interno di un nuovo strumento.

È in quel momento che emergono domande che durante l'analisi iniziale non potevano essere previste:

• cosa succede in questa eccezione?

• quale informazione serve davvero in questo passaggio?

• quale attività potrebbe essere semplificata?

• quale funzione pensata inizialmente non viene utilizzata?

Per questo un processo raccontato non coincide mai completamente con un processo reale ed un software progettato esclusivamente sulla base della conoscenza iniziale rischia di essere corretto sulla carta, ma distante dal lavoro quotidiano.

Se una parte della conoscenza emerge solo durante l'utilizzo, anche il modo di progettare deve cambiare.

L'obiettivo non diventa prevedere tutto prima di iniziare, ma creare un percorso che permetta al progetto di raccogliere nuove informazioni e utilizzarle per prendere decisioni migliori.

Alcuni elementi possono essere definiti fin dall'inizio:

• gli obiettivi del sistema;

• i processi da migliorare;

• le integrazioni necessarie;

• i risultati attesi.

Altri, invece, dipendono inevitabilmente dall'esperienza degli utenti.

In questi casi sviluppare tutto subito non significa progettare meglio. Significa prendere decisioni quando ancora mancano informazioni fondamentali.

Alcuni progetti vengono costruiti progressivamente, perché alcune decisioni possono essere prese correttamente solo quando esiste un riscontro concreto dall'utilizzo. Non significa progettare senza una visione complessiva, ma riconoscere che alcune scelte diventano più consapevoli quando il progetto incontra la realtà.

Il primo rilascio non è quindi soltanto una parte del software completata. È il momento in cui il progetto inizia ad apprendere.

Un edificio viene progettato per raggiungere una configurazione definita.

Una volta completato, la sua struttura rimane sostanzialmente stabile.

Una città, invece, cresce mentre viene abitata.

È possibile progettare le strade principali, le infrastrutture fondamentali e i collegamenti necessari. Ma solo il tempo permette di capire quali percorsi saranno realmente utilizzati, quali aree cresceranno e quali nuove esigenze emergeranno.

Un cambiamento successivo non significa che il progetto iniziale fosse sbagliato.

Significa che l'utilizzo ha prodotto nuove informazioni.

Con il software accade qualcosa di simile.

La progettazione iniziale deve definire direzione e fondamenta. Ma un sistema efficace deve anche poter evolvere quando l'esperienza reale rende disponibili informazioni che prima non potevano essere conosciute.

Progettare bene non significa decidere tutto subito, piuttosto, capire quali decisioni devono essere prese oggi e quali, invece, è più corretto rimandare.

A volte la scelta più professionale non è aggiungere una nuova funzionalità, ma aspettare che il sistema venga utilizzato abbastanza da capire se quella funzionalità sia realmente necessaria.

Anticipare una decisione senza informazioni sufficienti può portare a sviluppare soluzioni costose, difficili da modificare e poco aderenti al bisogno reale.

Esiste una differenza sostanziale tra progettare un software e progettare il percorso attraverso cui il software prenderà forma.

Nel primo caso si cerca di definire tutto prima dell'utilizzo.

Nel secondo si costruisce una direzione, si stabiliscono priorità e si crea un sistema capace di evolvere sulla base dell'esperienza.

 Questo non significa improvvisare. Significa riconoscere che, nei progetti complessi, l'incertezza non può sempre essere eliminata prima di iniziare. Può però essere gestita.

Il vero obiettivo non è conoscere tutto prima del primo sviluppo, ma è fare in modo che ogni fase del progetto renda più precise le decisioni della fase successiva. Per questo alcuni software non vengono progettati tutti insieme, vengono progettati abbastanza da poter essere utilizzati, osservati e migliorati.

Non perché il progetto sia incompleto, ma perché è il modo più efficace per costruire un sistema aderente al lavoro reale.