“Il triangolo solo in geometria è una costruzione innocua.”
Anonimo
Quando si realizza un prodotto software i tre indicatori dell’andamento del progetto sono:
- il tempo impiegato per completare il progetto;
- il budget utilizzato (non quello previsto);
- l’obiettivo raggiunto, ovvero le funzionalità (utili) realizzate.
Mentre l’esistenza di questi indicatori è intuitiva, è molto più difficile convincersi che le tre misure sono tra loro dipendenti.
Più precisamente non sembra possibile riuscire a definire i tre indicatori in modo indipendente.
Per esempio, stanziando un certo budget per la realizzazione di determinate funzionalità, non si riesce a determinare a priori quanto tempo sarà necessario per completare il progetto. Analogamente, fissando un tetto di costo e una data di consegna irrinunciabile, le funzionalità realizzate non saranno quelle inizialmente previste.
Il fatto che il fenomeno si verifichi in quasi tutti i progetti , anche se in misura molto variabile, e sia presente anche nel caso di team competenti e affiatati suggerisce che potrebbe trattarsi di un errore metodologico.
L’errore risiede nel credere possibile definire a priori e in maniera esaustiva le funzionalità che un software deve fornire per soddisfare le necessità del sistema informativo in cui sarà utilizzato.
E’ infatti normale che durante lo sviluppo le funzionalità richieste al prodotto siano in continua evoluzione, con aggiunte, profonde modifiche ed eliminazioni. Tali sconvolgimenti influenzano inevitabilmente costi e tempi di realizzazione.
In un mondo ideale si procederebbe fino al raggiungimento degli obiettivi incuranti di tempi e costi; nella realtà tempi e costi sono quasi sempre gli elementi non negoziabili.
Il problema sembra irrisolvibile: il mutare imprevedibile dei requisiti causa l’inevitabile sforamento dei tempi e costi.
Invece la soluzione è insita proprio nella mutabilità dei requisiti.
Procedendo con una graduale realizzazione e messa in esercizio delle funzionalità richieste, lasciando definire le priorità al cliente, approfondendo i dettagli il più tardi possibile e misurando il conseguimento degli obiettivi dal punto di vista del valore per l’utente si scopre che molte funzioni “immaginate” mesi prima non sono necessarie, che è possibile sostituire una nuova funzionalità con la combinazione di alcune esistenti e che l’80% del lavoro viene fatto con il 20% delle funzionalità.
La nota dolente è che per questa soluzione si deve cambiare un po’ il modo di affrontare lo sviluppo del software. L’argomento è vasto e sarà il tema di molte delle prossime puntate.