Confessioni di un consulente IT

Il vortice

Posted in Outsourcing, Progetti, Storie Aziendali by pigreco314 on 26 settembre, 2006

Per il nuovo progetto presso il cliente L. a B*, Spagna, hai deciso di affidarti a un ex-dipendente, D.V., che ora lavora come consulente freelance (e che finora è riuscito a trovarsi un solo cliente ma questi non sono problemi tuoi).

Piccola premessa: il progetto è uno degli scheletri nell’armadio lasciati da I.D.-C., il documento di offerta grida vendetta, la stima dei costi non c’è, le spese di trasferta non sono contemplate (ovvio, I.D.-C. abitava a B*) e… vabbè, fermiamoci qui.

D.V. conosce bene la realtà di L. avendoci lavorato parecchio quando eravate ancora colleghi. Risulta quindi la scelta più ovvia per consegnare presto e bene i 5 report Oracle che ti sono stati commissionati anche se si dichiara impossibilitato a lavorare direttamente presso L. . Già gongoli per le impressionanti performance che otterrai con il margine su questo progetto. Cosa può andare storto?

Un sacco di cose, perché hai sottovalutato tre aspetti fondamentali di questo progetto apparentemente semplice: la comunicazione tra le parti, la verifica del software consegnato e le procedure di validazione (L. è una società farmaceutica).

D.V. ti consegnerà il software via email e tu lo girerai al cliente che eseguirà i propri test e ti segnalerà eventuali incongruenze a fronte delle quali tu preparerai un bel bug report chiedendo allo sviluppatore di correggere gli errori. Al termine di questa iterazione D.V. ti consegnerà la nuova versione dei report che girerai di nuovo al cliente, che provvederà a ripetere i test, a notificarti l’esito ecc. Non è difficile immaginare che con questo processo i tempi di accettazione (e quindi di fatturazione) si allungano enormemente. Per il cliente ogni minuzia (l’etichetta un po’ più a destra, questa scritta in grassetto, il logo sbagliato) è un errore che va risolto. Inoltre, quando gli errori sono particolarmente gravi (es. “non funziona niente” punto) il feedback dal cliente non è nemmeno significativo: devi essere là per capire cosa non funziona e mandare indicazioni chiare allo sviluppatore. Ed eccoti smarrito nel vortice no.1, quello delle email con i feedback che allegramente contribuiscono a intasare la tua povera inbox.

Un modo per limitare le dimensioni del vortice è quello di farsi mandare dal cliente quante più informazioni possibile per riprodurre i problemi: gli identificativi dei dati con cui sono stati fatti i test, per ciascun dato erroneamente visualizzato l’indicazione di che cosa dovrebbe comparire al suo posto, esatte indicazioni su come modificare il layout di un report (anche via fax con scritte a mano che dicano cose del tipo: “questa colonna un po’ più a destra, la scritta di 10 pixels più grande”,ecc.) possibilmente utilizzando per i bug report un template predefinito. Ovviamente ogni bug deve essere registrato e tracciato: potrebbe bastare un file excel ma sarebbe meglio un sistema di bug tracking (io mi trovo molto bene con Bugzilla)

Inoltre le verifiche effettuate dal cliente se possibile dovrebbero essere trasmesse in videoconferenza o webex in modo che sia possibile vedere con i propri occhi che cosa sta andando storto e annotare ogni dettaglio: tieni presente che molto spesso una videoconferenza o un webcast si possono registrare e analizzare i filmati in seguito con più calma.

Dicevo dei test: ovviamente hai commesso l’errore di pensare che D.V. fosse dotato di poteri sovrannaturali e in grado di rilasciare codice esente da errori al primo colpo. Hai pensato che l’avergli fatto avere una macchina virtuale VMWare con una copia del sistema installato presso il cliente fosse sufficiente a eliminare qualsiasi rischio al punto che non ti sei nemmeno preoccupato di procurarti tu stesso una copia della virtual machine.

La prima versione dei 5 report è un disastro: l’hai girata direttamente al cliente senza nemmeno verificarla (e come avresti potuto senza un ambiente di test?) . Com’era da prevedersi il cliente ti ha rispedito indietro un email con la madre di tutti i feedback (“non funziona niente punto”). E ti è andata ancora bene. Avrebbe potuto scrivere: “Divertente! Però ora mandami i report veri…”.

Ti alteri un pochino anche con D.V. che ovviamente è tutto un “Oopss! Ho dimenticato di ricompilare”, “Acc! Non ho installato quel tal package sul database”, “Quella cosa non funziona? Impossibile!”, ecc.

Da questo momento in poi si procede per approssimazioni successive e comincia il vortice no.2, quello delle versioni del software che spesso il povero D.V. ti manda a orari impossibili: tu stai dormendo ma lui lavora e, ahimè, con una percentuale di accuratezza non certo favorita dallo sviluppare report nel cuore della notte. I file che ricevi e mandi al cliente non sono identificati da un numero di versione e capita a volte che i test vengano eseguiti utilizzando revisioni obsolete. Tutto ciò contribuisce ovviamente ad incrementare l’entropia dell’Universo. La prossima volta ricordati di chiedere che il numero di versione del software sia chiaramente indicato sul report stampato e venga incrementato a ogni consegna ufficiale. E, per favore, deciditi finalmente a utilizzare il Software Configuration Manager di cui la società ha acquistato un cospicuo numero di licenze (usiamo Perforce).

Piano piano la lista di problemi si riduce, ne sono rimasti 4 o 5. Vedi la luce: hai deciso di farla finita e di correggere personalmente i bug. Ma non hai un ambiente di test e quindi sei costretto a connetterti via dial-up al server RAS del cliente per effettuare le correzioni e le prove. Velocità di connessione: 33.6Kbit/s . Tempo per ricompilare e provare un report dopo ogni modifica: circa 15 minuti. Ti sei giocato un giorno intero (per tacere della bolletta telefonica) per sistemare quelle 4 o 5 cosucce.

Ma sei felice perchè puoi mandare finalmente la versione definitiva dei report che girano come un violino. In quella che pensi sia la conference call conclusiva hai appena pronunciato il fatidico “Bene, allora… si fattura. Giusto?”. E ti senti rispondere un “Aspetta aspetta. Mancano ancora i documenti che certificano l’esecuzione dei test . A proposito, dovresti anche venire qui a firmarci i documenti di specifica”.

Una risata isterica ti si disegna sul viso. Ti vedi già preda del vortice no.3, quello dei documenti di convalida che forse dovranno anche viaggiare per posta ordinaria.

Mancano 3 giorni alla chiusura del trimestre fiscale: ce la farai a fatturare il 100% del tuo forecast su questo progetto?

La risposta tra qualche giorno.

Annoti distrattamente su un pezzo di carta: la prossima volta chiedere a D.V. di dormire la notte, lavorare di giorno e sviluppare i report direttamente dal cliente, cercando di compiacere in ogni modo la gentile responsabile QA che ha commissionato i report.

Annunci

Una Risposta

Subscribe to comments with RSS.

  1. […] Ieri notte ho dormito circa tre ore. Sono a B*, penisola iberica, a chiudere le questioni pendenti raccontate qualche giorno fa. […]


Rispondi qui

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger hanno fatto clic su Mi Piace per questo: