Dei contratti e delle pene 3

ladro_ideaDopo aver bocciato le due soluzioni più intuitive per la gestione del rapporto cliente/fornitore nello sviluppo di piccoli software personalizzati, proviamo a proporre una soluzione. Nessuna delle idee esposte è originale ma si vuole unirle in una ricetta di taglio pratico.

Per la tipologia di progetti presi in considerazione i rischi da mitigare sono i seguenti.

  • Incertezza sugli obiettivi da raggiungere: soprattutto quanto si tratta di sistemi per la gestione delle informazioni, è comune che l’acquisto di un software personalizzato sia parte di un processo di revisione delle procedure aziendali; in tal caso gli obiettivi possono non essere del tutto definiti o cambiare parzialmente con l’evolvere della revisione.
  • Ottenere un prodotto incompleto: per diverse ragioni, tra cui quella finanziaria, c’è il pericolo che il progetto sia interrotto prima del previsto, col rischio di ottenere un prodotto inutile o molto carente e lasciando il cliente a metà del guado.
  • Esplosione dei costi: mescolando una lista di funzionalità stilata con l’intento di prevedere ogni futura esigenza con qualche errata scelta archittetturale i costi possono superare di molto la previsione anche prima di vedere avvicinarsi la fine del progetto.
  • Mancato pagamento: se il progetto si protrae troppo ed è soggetto a cambi di rotta, il cliente potrebbe non essere in grado o non avere intenzione di pagare per intero il lavoro svolto.

Per ridurre i rischi si possono adottare le seguenti tecniche.

  • Redigere un breve documento che inquadra il prodotto da realizzare all’interno degli obiettivi del cliente evidenziando sia i benefici che si vogliono ottenere che l’impatto sulle procedure aziendali. In teoria dovrebbe essere scritto dal cliente ma può anche essere preparato dal fornitore con il pretesto di dimostrare che ha ben compreso il contesto e gli obiettivi. L’utilità principale di tale documento è mantenere il progetto in carreggiata e rendere espliciti i cambi di rotta.
  • Esprimere le caratteristiche richieste mediante la tecnica delle storie utente (user story) che hanno il vantaggio di definire quali sono i risultati che il cliente vuole ottenere indipendentemente dal come tali risultati saranno ottenuti. Le funzionalità più complesse o per le quali c’è un’evidente difficoltà di comunicazione possono essere descritte utilizzando i casi d’uso (use case) che consentono di risolvere ogni ambiguità definendo nel dettaglio il comportamento del sistema dal punto di vista del cliente.
  • Iniziare definendo le storie utente solo ad alto livello (es. “emissione fattura”) raffinandole successivamente solo quando si decide di realizzarle.
  • Chiarire che i costi di realizzazione calcolati sulla base delle storie di alto livello sono solo una stima.
  • Realizzare il prodotto per fasi rilasciando per ognuna di esse un prodotto funzionante che fornisce solo le funzionalità che realizzano l’insieme di storie che si è deciso di implementare.
  • Far scegliere al cliente quali storie realizzare nella prossima fase. Sono da evitare la pianificazione delle fasi successive e la definizione di priorità.
  • Indicare i costi della singola fase in base alle storie di cui è richiesta la realizzazione; se possibile esplicitare i costi della singola storia per consentire al cliente di scegliere anche in base a considerazione economiche.
  • Prevedere un tempo di utilizzo “in produzione” delle storie implementate prima di scegliere cosa sviluppare nella fase successiva.
  • Concordare il pagamento dopo il rilascio di ogni versione e prima dell’avvio della successiva (e non solo l’emissione della fattura!). Fornire esplicitamente la garanzia illimitata per i difetti di realizzazione eliminando così l’antipatica abitudine di ritardare i pagamenti per ottenere una garanzia implicita.

Utilizzando questa metodologia il cliente è in grado di gestire l’investimento nel tempo in funzione delle funzionalità richieste; ha inoltre la possibilità di interrompere o sospendere il progetto quando ritiene di aver raggiunto gli obiettivi o i vincoli di spesa.

Nello stimare i costi, il fornitore deve considerare l’eventualità di dover reingegnerizzare alcune funzioni già realizzate sulla base di quanto emerge raffinando nuove storie utente. Tale evento è una caratteristica della metodologia e non un errore di cui trovare un responsabile.

Quanto proposto, oltre a richiedere un cambio di mentalità, ha lo svantaggio di non permettere la definizione certa della data di completamento del progetto nel suo complesso ma solo delle singole fasi. In realtà si tratta di un difetto molto piccolo se si considera che i progetti a data fissa (fixed time) non sono quasi mi conclusi nei tempi previsti.