Un paradosso:
Il committente è il principale decisore dei progetti di sviluppo software, ma non esiste una formazione per diventare committente: la strada più comune è quella di imparare dai propri sbagli.

Questo scritto, intenzionalmente sintetico, si propone di fornire alcune indicazioni per aiutare i committenti a non farsi travolgere dai progetti.

Prima di tutto, cosa è un committente? “Chi ordina un lavoro, una prestazione, o si impegna ad acquistare una merce per conto proprio” secondo G. Devoto, G.C. Oli – Dizionario della lingua italiana – editrice Le Monnier. Il termine deriva dal latino committens, ‘colui che affida’.

In generale, il committente è la figura disposta a sostenere i costi per il progetto, e che ha la responsabilità di valutare se il prodotto risultante è accettabile. E’ il principale decisore del progetto, ed il suo ruolo deve essere noto ed accettato da tutte le parti interessate all’andamento ed agli esiti del progetto (gli “stakeholder”).

Tra le responsabilità tipiche di un committente troviamo:

• partecipare in modo attivo al progetto
• coinvolgere nel progetto le altre parti interessate (stakeholder)
• esprimere requisiti, e chiarimenti sui requisiti
• definire le priorità sui requisiti
• controllare l’avanzamento dei lavori, ed i prodotti / servizi che costituiscono il risultato del progetto
• gestire i rischi di progetto
• prendere decisioni in caso di conflitto (ad esempio, di contrasto tra i punti di vista dei vari stakeholder), o di incongruenza tra risorse e obiettivi (ad esempio, in caso di ritardi nello sviluppo non rimediabili, il committente deve decidere se è meglio rispettare una data di rilascio prevista rimandando lo sviluppo di alcune funzionalità oppure se completare tutte le funzionalità rimandando il rilascio).

Suggerimenti:

1 – Non lasciarsi intimorire dall’ignoranza sugli aspetti tecnici. Dal punto di vista linguistico, alcuni sviluppatori usano abitualmente espressioni gergali, che possono rendere più difficile la comunicazione. E’ un loro problema, ma voi potete pretendere che si esprimano in modo comprensibile.

Dal punto di vista sostanziale, non è affatto necessario che il committente debba accettare dilazioni o maggiorazione di costi o soluzioni non ottimali a fronte di inesplicabili motivazioni tecniche.

2 – Evitare progetti di lunga durata. I rischi di fallimento dei progetti sono direttamente proporzionali alla durata, secondo tutte le statistiche. Se il prodotto da realizzare è complesso, meglio (meno rischioso, meno costoso) segmentare il lavoro in una serie successiva di progetti (il primo realizzerà una parte iniziale del prodotto, i successivi le parti restanti). La durata di ogni progetto deve essere comunque inferiore ad un anno, anche meno.

All’inizio, ogni progetto ha un cono d’ombra provocato dalla mancanza di conoscenza, dalla indeterminatezza, che va progressivamente rischiarato. La natura dello sviluppo software consiste nella progressiva acquisizione di conoscenza su un problema concreto (l’ambito applicativo, ad esempio bancario o medico), e nella trasposizione di questa conoscenza, tramite processi di astrazione, in un sistema informatico.

Il chiarimento, cioè l’acquisizione di conoscenza, avviene tramite la collaborazione sistematica tra il committente che vuole il sistema e lo sviluppatore che lo deve realizzare. Nella maggioranza dei casi, né il problema né le soluzioni sono perfettamente definiti all’inizio dello sviluppo: vengono determinati progressivamente nel corso del progetto.

3 – Decidere le priorità di sviluppo sulla base delle motivazioni di business, non di motivazioni “tecniche”. E’ il fornitore che si deve adattare alle esigenze del committente, non viceversa.

4 – Se possibile, scegliere il fornitore, non farselo imporre. Le differenze di qualità e produttività nel campo dello sviluppo software sono enormi, e la breve storia dello sviluppo è piena di relazioni contrastate e improduttive tra cliente e fornitore . In ogni caso, sia che la scelta del fornitore sia libera oppure obbligata, è indispensabile che il committente stabilisca le proprie condizioni per il progetto (come quelle contenute in questo elenco), e imposti il contratto in modo da non vincolarsi al fornitore senza possibilità di uscita.

5 – Pretendere al più presto software funzionante, non solo documenti. Alcune società di software sono abituate a lavorare con lunghi periodi iniziali (mesi e mesi) di analisi, durante i quali vengono prodotti solo documenti e non software concreto da far vedere al committente. In questo lungo periodo iniziale, il fornitore richiede al committente di chiarire tutti i requisiti prima di mettersi a progettare e realizzare il software. E’ un approccio inefficace ed inefficiente, perché i requisiti si chiariscono molto più facilmente e più velocemente quando committente ed utilizzatori hanno a disposizione una versione iniziale del sistema.

L’eventuale richiesta del fornitore di chiarire tutti i requisiti in anticipo, quando il prodotto software esiste solo allo stato di idea, aumenta notevolmente i rischi di incomprensione
reciproca, in quanto pone il committente nella scomoda situazione di dover prendere delle decisioni senza avere ancora tutti gli elementi per farlo.
E’ un sintomo di scarsa professionalità da parte del fornitore, ed è opportuno che il committente rifiuti questo modo di lavorare. Il committente non deve impegnare le proprie decisioni troppo a lungo senza ottenere riscontri concreti da verificare.

6 – Pretendere dal fornitore verifiche periodiche frequenti, comunque non superiori al mese, in cui vengano dimostrati concretamente gli avanzamenti del progetto (non accettare dichiarazioni di avanzamento a percentuale: “è pronto al 90%” significa semplicemente che il prodotto non è pronto). In ogni verifica periodica va verificato il piano dei lavori fino al termine del progetto.

7 – Evitare, se possibile, contratti “a corpo” (a prezzo fisso) stipulati troppo presto, troppo precoci. Se si è obbligati a fissare il prezzo subito all’inizio del progetto, meglio stipulare una serie successiva di contratti, in modo da tenere conto dell’acquisizione progressiva delle conoscenze in corso d’opera. Ad esempio, un contratto iniziale per uno studio di fattibilità, uno successivo per una prima versione “iniziale” del sistema, altri per le ulteriori evoluzioni.

8 – Se non si ha tempo per seguire direttamente il progetto, delegare quante attività operative sia possibile a qualcun altro che abbia tempo e capacità adeguate, o a un esperto di cui ci si possa fidare.
La partecipazione sistematica del committente (che è il principale decisore del progetto) o di suoi rappresentanti è una condizione necessaria per il successo del progetto.

9 – Identificare tutti i potenziali stakeholder (le parti in causa), e coinvolgerli nel progetto. Gestire in modo trasparente priorità e conflitti tra i punti di vista degli stakeholder. In caso di necessità di scelta tra diverse possibili soluzioni, l’ultima decisione spetta comunque al committente.

10 – Produrre e aggiornare sistematicamente un proprio elenco dei rischi di progetto, e richiedere al fornitore un elenco sempre aggiornato dei suoi rischi “tecnici”. Individuare i fattori di rischio che possono compromettere il successo del progetto (e mantenere un controllo costante sulla loro evoluzione nel tempo) è una condizione necessaria per non farsene travolgere.