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!
venerdì, aprile 28, 2006, 05:24 PM
Chissà perchè ma leggendo questo post mi viene in mente questa storiella:
Un tipo sta guidando in macchina, quando a un certo punto capisce di essersi perso; avvista un uomo che passa per la strada, accosta al marciapiede e gli grida:
- Mi scusi, mi potrebbe aiutare? Ho promesso a un amico di incontrarlo alle due, sono in ritardo di mezzora e non so dove mi trovo...
- Certo che posso aiutarla. Lei si trova in un'automobile, tra 40 e 42 gradi latitudine Nord e tra 58 e 60 gradi longitudine Ovest, sono le 14 e 2 minuti e 35 secondi e oggi è venerdì e ci sono 24,5 gradi centigradi.
- Lei è un informatico?- chiede quello dentro l'automobile.
- Certamente. Come fa a saperlo?
- Perché tutto ciò che mi ha detto è "tecnicamente" corretto, ma
"praticamente" inutile. Infatti non so che fare con l'informazione che mi ha dato e mi ritrovo ancora qui perso per strada.
- Lei allora deve essere un Manager, vero? risponde l'informatico.
- Infatti, lo sono. Ma... come lo ha capito?
- Abbastanza facile: non sa né dove si trova, né dove andare, ha fatto una promessa che non sa assolutamente come mantenere ed ora spera che un altro le risolva il problema. Di fatto, è esattamente nella stessa situazione in cui si trovava prima che ci si incontrasse... ma adesso, per qualche strano motivo... risulta che la colpa è mia!"
venerdì, aprile 28, 2006, 05:33 PM
Ogni tanto sento parlare di progetti che falliscono e tutte le volte mi chiedo:
Cosa si intende per fallimento ?
- il cliente non è soddisfatto
- l'applicazione non funziona
- il progetto non è terminato
- il fornitore non è stato pagato
In 10 anni di questo lavoro penso di aver visto solo un progetto fallire, in breve:
- il fornitore aveva subappaltato l'attività
- il fornitore se ne era fregato dell'attività
- il subfornitore ha fatto quasi niente
- il fornitore non ha pagato il subfornitore
Il progetto partiva da un vincolo, usare Lotus Domino, perchè il cliente usa Lotus Notes. Nessuno aveva esperienza di sviluppo con Domino e Notes, e questo contribuì al disastro.
Ricordo i dettagli di questo progetto solo perchè mi era stato chiesto di dare una mano in extremis (sabato e domenica).
Ovviamente mi incazzai parecchio, perchè il vincolo iniziale era già un errore in partenza (tutti i PC hanno un Browser ed anche Notes è un Browser) ed io non conoscendo lo strumento non potevo fare il miracolo di sabato e di domenica.
Il caso che descrivi Enri mi è ahimè noto ed ha delle analogie con quello sopra, nonostante tutto non lo ritengo un fallimento.
Anche in questo caso si è partiti dal vincolo di usare un sistema invece di capire prima le esigenze, prima ancora che il vincolo venisse posto io ed altri colleghi avevamo ipotizzato delle alternative.
Quando però non ci è più stato possibile percorrere questa strada, abbiamo cercato di approcciare il problema cercando di interagire coll'utente per cercare di fornirgli uno strumento utile.
Tuttavia anche questa strada è stata sbarrata, non si doveva concedere troppo al cliente perchè il conquibus era stato stabilito, quindi non si poteva stravolgere il sistema, bisognava piantare i famosi paletti, definire il perimetro.
Fortunatamente il cliente A ci ha dato le risorse necessarie per fare in modo che il peso degli sviluppi e dei test venisse bilanciato.
Non lo ritengo quindi un fallimento perchè tutto il lavoro indispensabile è stato fatto, purtoppo questo costituisce il 90% del progetto ed è la parte meno visibile, per il resto non ci vedo niente di drammatico.
Semmai c'è da riflettere su come questi progetti vengano gestiti e su come al solito il gioco consista nel far sentire ottime persone, volenterose e capaci delle persone che non fanno abbastanza affinchè i progetti non falliscano.
I progetti sono fatti di tante componenti, tecniche, organizzative, commerciali, in una squadra si gioca tutti per vincere ognuno cercando di fare bene il proprio ruolo.
E comunque nel caso perdiate la partita, nonostante abbiate giocato per vincere, ricordatevi che
"Non esistono insuccessi, esistono solo successi rimandati"
venerdì, aprile 28, 2006, 07:31 PM
Un veloce chiarimento per non essere frainteso sul significato dei post: nè il cliente B nè tantomeno il cliente A hanno deciso di rompere la relazione con noi, ma anzi penso che proprio per le motivazioni di cui ho parlato, nutrano stima nei nostri confronti. Il mio approccio vuole essere volto al continuo miglioramento, e al contrario di quanto forse possa apparire è un approccio molto "ottimista", opposto ad un "piangersi addosso". In questo senso tutte le esperienze avute fino ad oggi per me sono stati successi, sia oggettivamente (per stessa ammissione dei committenti), e sia perché penso di essermi sempre posto con spirito critico per fare sì che quanto fatto oggi sia almeno un centimetro più avanti di quanto fatto ieri.
Per trovare la ripetibilità dei successi bisogna anche sapere riconoscere e comprendere il grande valore dei (piccoli o grandi) fallimenti. La strumentalizzazione dei fallimenti (spero non ne avrò mai esperienza e sinceramente non ne vedo le premesse) poi è tutt'altra cosa: significa non aver compreso cosa voglia dire gestire al meglio le persone, e voler distruggere invece che costruire.
venerdì, giugno 11, 2010, 08:54 AM
welcome to ffxi gil and wow power leveling and wow gold OR Final Fantasy XI GIL
