Giocare per vincere 
giovedì, aprile 27, 2006, 11:11 PM - Diario di bordo
Ieri, mercoledì 26 Aprile, si è svolta una riunione alla presenza del direttore dei sistemi informativi (S.I.) (per i quali io ed altri miei colleghi prestiamo consulenza), il mio CEO ed altri membri del team. Ordine lo stato avanzamento lavori del progetto andato in produzione la settimana scorsa, di cui vi ho parlato nel precedente post. Si è affrontato il tema per entrambi i committenti del progetto: il committente A (ha collaborato molto testando anche quanto chiesto da B e dando feedback lungo tutto il progetto), ed il committente B (di fatto per mancanza di interesse ha cominciato a testare in produzione). Inevitabilmente durante la produzione sono emersi da parte di B delle osservazioni su funzionalità che non rispettano i reali bisogni di B stesso. Sarebbe quindi necessario un effort aggiuntivo per tale implementazioni e per soddisfare il cliente. Il problema è che sono finiti i giorni. Durante la riunione di cui sopra, i S.I. hanno deciso "semplicemente" di non estendere l'ordine, ma di considerare il progetto come chiavi in mano (sigh!), dal momento che "è colpa del cliente B se le anomalie sono emerse solo in questa fase". Ovviamente questa decisione porta all'azienda per cui lavoro una situazione di conflittualità di rapporti e di insoddisfazione per il cliente B, che ha sempre avuto rapporti con noi ed il team di cui faccio parte.

Questo (parziale)fallimento ha dato modo di comprendere e misurare cosa non ha funzionato.
La strategia di far testare al committente A lungo il corso del progetto le funzionalità chieste da B, a causa della scarsa volontà di collaborazione da parte di quest'ultimo, non si è rivelata sufficiente nè vincente: bisognava in qualche modo aumentare la collaborazione di B dall'inizio del progetto: creare un gruppo di tester come in A, facendo magari lavorare insieme i tester di A con quelli di B. Purtroppo tale eventualità e necessità non è stata percepita da B, a causa di carenze a livello organizzativo e mancanza di esperienza in progetti informatici.
Nel corso delle ultime riunioni alla presenza del direttore di B e del mio CEO, analizzando i fatti (ed i fallimenti) è stato finalmente accettato da parte dei vertici di B di superare gli ostacoli organizzativi creando tale gruppo di tester, con l'aiuto e la formazione del gruppo di tester di A. E' stato inoltre deciso di effettuare incontri settimanali (ed email giornaliere) per monitorare l'avanzamento delle attività di test. Considero queste due decisioni una grande fonte di speranza per i progetti futuri con B.

Di seguito i punti fondamentali da tenere in considerazione per i prossimi progetti:

* un approccio in cui il committente non collabora/partecipa durante lo svolgimento del progetto porta sempre e comunque a situazioni fallimentari sia per il fornitore che per il cliente stesso: alla fine "per cautelarsi" i S.I. interni hanno deciso di interpretare il progetto come un chiavi in mano, con un sistema che non soddisfa il cliente B e che di conseguenza getta una cattiva luce sul fornitore ingaggiato dagli stessi S.I.!

* il problema non risiede nel numero di giorni mancanti e in una stima iniziale troppo bassa: anche se si fosse stimata la durata del progetto con X giorni in più, ciò avrebbe voluto dire aspettare altri X giorni prima di trovarsi di fronte alla realtà delle cose, e cioè che B non ha chiesto ciò che in realtà voleva (cosa tipica di ogni progetto informatico)!

* dare da testare le funzionalità il più presto possibile: già dopo qualche settimana dall'inizio degli sviluppi, in modo da far emergere il più presto possibile cosa realmente voglia il committente!

* cercare sempre con ogni mezzo e con ogni forza la collaborazione e la partecipazione del cliente durante tutto lo svolgersi del progetto, per mezzo di riunioni settimanali durante le quali si decidono le funzionalità da implementare e da testare nella settimana successiva! Tracciare sottoforma di test quanto deciso ad ogni riunione.

* un cliente che partecipa è condizione necessaria ed insostituibile al successo!

* per quanto i documenti delle specifiche scritti ad inizio progetto possano essere dettagliati e chiari e quindi facilmente impugnabili dal fornitore in fase di rilascio finale, si verrà sempre e comunque a creare una situazione di "guerra di interpretazione" del documento stesso tra cliente e fornitore, nel caso in cui il cliente stesso non sia stato coinvolto/non abbia seguito il progetto!

* un cliente non è mai sostituibile nei suoi desiderata con un altro!

Giocare per vincere, no per non perdere!

69 commenti ( 7489 visite )   |  permalink   |   ( 3 / 1278 )


Indietro Altre notizie