Un cretino

Il collega inglese S.G. è da giovedi scorso ufficialmente un cretino. D’ora in poi poco prima di iniziare una conversazione con lui mi prenderò qualche istante di riflessione in modo da lasciare che il giudizio si formi con chiarezza nella mia mente e crei il contesto necessario alle sue successive affermazioni:”Sto parlando con un cretino”.

Chiunque abbia anche solo una vaga esperienza di progetti IT basati sull’implementazione di una applicazione software sa che per soddisfare un requisito utente è sempre opportuno privilegiare l’adozione di una funzionalità standard già presente nell’applicazione rispetto alla creazione di feature personalizzate: nel primo caso si utilizza una caratteristica del software che (sperabilmente) ha superato determinati test di qualità, non sono richieste ulteriori attività di progettazione, sviluppo, test e documentazione, e se il software è disegnato con un minimo di accortezza ci si deve attendere che tale funzionalità sia preservata nelle future versioni del software.

Anche quando si è costretti a sviluppare una funzionalità personalizzata, qualora essa diventi in seguito parte del software standard (in genere questo accade quando gli architetti dell’applicazione riconoscono che di quella particolare feature beneficerebbe l’intera comunità di utenti ed è quindi opportuno renderla disponibile a tutti), durante la pianificazione della migrazione del sistema alla nuova realease io prenderei in seria considerazione la possibilità di dismettere la versione “custom” della funzionalità e sostituirla con la sua controparte “built-in” perché da quel momento in poi aprofitterei di tutti i vantaggi citati sopra. È evidente che questa considerazione di principio deve essere accompagnata da una valutazione di costi e benefici: se il costo della conversione da “personalizzato” a “standard” è superiore ai benefici a lungo termine derivanti dal passaggio, è bene lasciar perdere.

Giovedi ho dovuto sprecare alcuni minuti del mio prezioso tempo (che sarebbero stati molti di più se non ci avessi dato un taglio brusco) per spiegare a S.G. questo elementare concetto che secondo me avrebbe già dovuto far parte del suo bagaglio culturale. E invece alla fine mi sono persino sentito replicare:”Se la funzionalità personalizzata fa quello che deve e soddisfa il requisito originale perché sostituirla con una standard?”. Per la serie: se funziona non toccare niente, non pensarci nemmeno, è male.

A S.G. non dovrebbe essere consentito di stare lì, nella posizione di responsabilità in cui si trova a propalare idee perniciose che esercitano un’influenza nefasta sulle menti dei nostri giovani business analyst.

Perché?

Perché è un cretino.

Alla rovescia

Relax © by ailatan

Forse ci siamo, forse incrociando dita, falangi, falangine, falangette e polpastrelli riusciamo a chiudere il dannatissimo progetto K**, difficilissimo Cliente di L*, Germania.

La firma che ci avrebbe permesso di fatturare il residuo sarebbe dovuta arrivare due , quattro no aspetta, sette… un numero imprecisato di mesi fa e invece probabilmente arriverà domani, dopodomani… insomma un giorno della prossima settimana sicuramente.

Avrete capito che trattasi di progetto travagliato, che ha visto coinvolte un discreto numero di persone impegnate a portare a casa un risultato utile, tra cui, in veste di protagonista, l’ormai mitico G.M. Di recente si è aggiunto anche il nuovo acquisto in casa Sales, il promettente A.D., come “supportante” Account Manager.

Negli ultimi 5 mesi con questo Cliente non si è fatto altro che negoziare al mercato delle “issues”: “no questo non è un problema causato dal nostro software bensì dalla vostra infrastruttura di rete”, “questo non l’avevate chiesto e quindi non ve lo sistemiamo a meno che non ci paghiate l’intervento”, “no questo non lo firmo perché non c’è il sotto-vice-assistente-precario del responsabile” (cliente pubblico) ecc.

Suona quindi strano che  presso un Cliente così problematico in una fase così delicata del progetto si organizzi una dimostrazione di un modulo software di analisi statistica e reportistica avanzata per il quale quelli di K** hanno manifestato un notevole interesse. Organizzatori: G.M. e A.D., il dinamico duo.

Della serie: prima risolviamo la faccenduola relativa alla chiusura del progetto e poi vi facciamo vedere tutto quello che volete, vi contiamo in diretta anche i pixel dell’interfaccia grafica utente se volete. Dopo però.

Saltiamo qualche passaggio e diciamo che stando ai resoconti del dinamico duo il Cliente firmerà la chiusura del progetto, consentendoci di fatturare il residuo e pure ordinando un giorno di consulenza per una micro attività aggiuntiva.

Curioso il modo in cui A.D. riporta la notizia, al termine della riunione di ieri:

Vi informo che siamo riusciti nel nostro intento di generare interesse presso K** circa i software X e Y, cosa che era l’obiettivo primario (sic!) della riunione. Tra le altre cose, abbiamo poi stabilito una relazione col Cliente (questa non l’ho capita bene) il quale ha accennato al fatto che firmerà la chiusura del progetto blah blah…

Ovviamente sono sicuro del fatto che l’entusiasmo del dinamico duo è ben motivato e che tra poco vedrò materializzare nella mia inbox (o nel mio GTalk, veggasi articoli sul bot) il pezzo di carta firmato, tuttavia la differenza di prospettiva rispetto a cosa sia veramente importante in una situazione è cosa che colpisce.

PS: alla fine della giornata di lavoro di oggi (20/05), nessuna traccia del pezzo di carta. Seguiranno aggiornamenti.

PPS: nulla nemmeno a tutto il 25/05

PPPS: 28 maggio, giornata storica il sign-off è arrivato!!!!!

PPPPS: non ci credo: abbiamo chiuso il progetto e fatturato il 29 maggio 2009

Un trimestre disastroso

Fire: Disaster in the city © millzero.com

Il primo trimestre fiscale dell’anno si è chiuso l’altro giorno in modo disastroso con risultati che definirei estivi, anzi balneari: nel senso che di solito fatturiamo queste cifre tra luglio e settembre quando molti dei nostri clienti chiudono per ferie, i consulenti sono in vacanza ecc.

Quasi quasi inauguro la nuova categoria del “Perché mi rattristro” per i post.

Pur nell’ecatombe finanziaria che abbiamo sperimentato possiamo tuttavia trovare qualche motivo di consolazione. Infatti, le cause del tracollo sono essenzialmente legate ai mancati introiti di due soli progetti che se avessimo potuto fatturare ci avrebbero portato molto vicino al piano finanziario del trimestre.

La storia di uno di questo due progetti era nota da circa due mesi, quando un impedimento circa le condizioni contrattuali che stavamo negoziando (mentre il progetto, per accelerare i tempi e adempiere alle necessità del Cliente, era già iniziato) ci ha fatto realizzare che non avremmo visto i soldi derivanti dalle attività di consulenza fino a Giugno 2009: stornati circa 200K dal forecast. Boom.

Come definireste la decisione di mantenere le risorse impegnate su questo progetto anche a fronte di un deferimento imprevisto dei pagamenti? Probabilmente in molti modi: uno di questi è che si è trattato di una decisione strategica motivata dalla necessità di accontentare un Cliente chiave per il nostro business e non solo. Ok. Sottoscrivo.

Il secondo progetto (un grosso Cliente petrolchimico) attendeva di vedere riconosciute attività eseguite sin dal 2008 che per una storia iper-contorta di allocazione di budget, riduzione e storno del medesimo, stato confusionale di alcuni decision makers erano state svolte senza la copertura di un ordine. L’obiettivo era quindi di far emettere l’ordine da parte del Cliente, registrarlo  e immediatamente richiedere la firma per approvazione delle attività pregresse in modo da fatturare subito dopo.

Cosa è andato storto in questo caso?

Come si sia potuti arrivare al 30 Marzo 2009 senza avere l’emissione di un ordine che mancava dal 2008 è cosa che trascende le mie facoltà intellettive.La cosa divertente qui è che giustappunto il 30 Marzo l’ordine siamo riusciti ad ottenerlo, dopo averlo quasi prelevato fisicamente all’ufficio acquisti. Ci restava quindi un giorno per poter conseguire le firme sulle attività svolte. Peccato che la persona preposta alla firma, il 31 Marzo era irreperibile, in trasferta da qualche parte in Liguria. Anche in questa situazione abbiamo deciso scientemente di svolgere un discreto volume di attività (80K circa) senza avere l’ordine da parte del cliente, pur contando di ottenerlo prima della fine del trimestre. Il fatto che alla fine non si arrivato ha avuto quindi un impatto piuttosto pesante e imprevisto sul forecast.

Imprevisto.

Se l’ordine fosse arrivato due mesi prima, un mese prima, due settimane prima della fine del trimestre, la mancata fatturazione si sarebbe potuta considerare uno spiacevole imprevisto. Ma se ci trastulliamo con il dannato ordine fino a quasi l’ultimo giorno utile concedendo solo 8 ore lavorative per le restanti formalità necessarie a fatturare, un esito positivo della vicenda avrebbe quasi del miracoloso.

Insomma: in entrambe le situazioni che hanno fatto la differenza tra il successo e il tracollo di questo trimestre, direi che poco ha a che fare con l’inaspettato o l’accidentale e molto con la decisione strategica di consentire, dato il tipo di relazione che vogliamo mantenere e sviluppare con il Cliente, l’esecuzione di attività di consulenza sapendo che la fatturazione sarebbe stata a rischio. Decisione che come ho detto posso anche sottoscrivere.

Ecco perché il giorno 31 Marzo 2009 poco prima di mezzogiorno, quando tre dei quattro responsabili del business europeo si ritrovano in una stanza a discutere su come presentare la situazione al Senior Management e uno dei tre se ne esce con una roba del tipo: “Dirò che non sono arrivati alcuni sign-off dei progetti”, mi incazzo.

Alcuni sign-off?!

Perché cercare ancora di nascondere la polvere sotto il tappeto? Perché non spiegare che questi risultati derivano da decisioni dolorose ma consapevoli che non pregiudicano il nostro livello di controllo del business?

Una posizione del genere la sottoscrivo. La solita scusa del bambino che ha fatto la marachella, no.

Pensavo che questi retaggi dell’era R.C. ce li fossimo lasciati alle spalle e invece vedo che c’è ancora il complesso della stanza dei bottoni e della solitudine della leadership.

Probabilmente è la nostra Azienda che non ha mai instillato nei manager una cultura della collegialità e delle decisioni condivise.

La vera notizia in realtà è un’altra: il silenzio assordante del mio capo che a quanto pare è poco interessato a temi così aridi come i risultati finanziari.

Project Premortem Analysis

In questo articolo del 1989 (“Back to the Future: Temporal Perspective in the Explanation of Events”)  Mitchell, Russo e Pennington riportano i risultati di una ricerca secondo la quale immaginare che un evento sia già accaduto consente di incrementare del 30% la capacità di prevederne future conseguenze.

Su questa scoperta si basa l’idea dell’analisi pre-mortem, un metodo per aiutare la valutazione dei rischi in un progetto, descritto in questo articolo pubblicato nel numero di Settembre 2007 della Harvard Business Review.

A differenza di una tipica sessione di risk assessment nella quale i convenuti si chiedono che cosa potrebbe andare storto, nell’analisi pre-mortem l’assunto è che il paziente è morto e l’obiettivo è spiegare che cosa è andato storto.

Il compito dei membri del team è generare un insieme di ragioni plausibili per il fallimento del progetto.

Una sessione premortem tipica si potrebbe svolgere in questo modo: dopo aver ragguagliato il team circa il piano di progetto, il facilitatore  informa che il progetto è fallito. Nei minuti seguenti, ciascun componente del team indipendentemente dagli altri elenca una lista di ragioni che spieghino il fallimento.

Nella fase di revisione, il facilitatore chiede a ciascun membro del team, a cominciare dal project manager, di elencare una ragione differente sino a che non siano state registrate tutte le opinioni.

Una volta raccolti tutti i contributi, il project manager passa in rassegna la lista e riflette su come rafforzare il piano di progetto.

Anche quest’ultima fase può essere svolta coinvolgendo il team e utilizzando tecniche quali per esempio il brainstorming.

È sempre colpa di qualcun altro

Krieg ist Terror by Stewf

I Professional Services si distinguono in svariate discipline e una di queste è la lamentela fingerpointing, quel livore egoista con cui si punta il dito verso un collega a piacere dicendo: “È colpa tua!”.  I Sales hanno svenduto il progetto promettendo l’impossibile a margine zero o negativo e non hanno tenuto conto di quel piccolo particolare tecnico che rende impossibile l’implementazione. Il Product Department è notoriamente composto da un plotone di nullafacenti, ignari delle più elementari procedure di controllo qualità e certificati per la produzione di software bacato. Il Marketing è specializzato nella distribuzione di una serie di “volantini” che magnificano caratteristiche inesistenti del software per i quali meriterebbero la denuncia ecc. ecc.

E se tutto ciò non bastasse, il povero consulente si trova a fronteggiare un Cliente “raggirato” al quale (metafora tipica) è stata promessa una Ferrari ed è stata venduta una Fiat Palio.

Sebbene tutto ciò abbia qualche fondo di verità, il complesso del parafulmine impedisce al consulente, field specialist, solution architect, membro dei professional services in generale e al team di progetto in particolare di svolgere una serena autocritica e riflettere in maniera costruttiva sulle proprie responsabilità.

Durante il team meeting della settimana scorsa a N* è andato in scena un piccolo showdown tra noi Professional Services e un rappresentante del Product Department, l’Olandese Frizzante P.B., il quale in verità, più che un semplice rappresentante, stando all’ultimo organigramma risulta essere il responsabile del Product Department medesimo. Ma è notorio che dello sviluppo del prodotto non gli importa granché, probabilmente manco ci capisce, ha delegato praticamente tutte le attività a uno dei suoi luogotenenti negli USA ed è molto più interessato alle attività di marketing di cui pure è responsabile. E infatti, dopo un aggiornamento sulle attività di marketing durato 45 minuti (avevo richiesto durasse un quarto d’ora), il Nostro, che avrebbe dovuto guidare una discussione di 45 minuti (durata effettivamente tanto, a scapito della pausa pranzo)  su come migliorare la comunicazione tra Field e Product Department nei casi in cui bug gravi nel software si rivelino nelle fasi critiche di un progetto,  si è eclissato lasciando i Professional Services a esercitarsi nello loro sport preferito.

Il caso in questione si riferiva al Cliente R* che a quanto pare 14 mesi fa (“F o u r t e e n  m o n t h s  a g o!” ha enfatizzato J. nell’illustrazione del tema) ha chiamato il nostro servizio di help desk per segnalare un problema nel software. La chiamata di assistenza si è trasformata in un bug formale nel software che ad oggi non è stato ancora risolto dal P.D. (Product Department non Partito Democratico, che al momento ha ben altri problemi). Presumo che ciò sia accaduto per motivi più che validi, quelli che guidano la pianificazione delle risorse in tutti i gruppi di sviluppo e supporto software di questo mondo. Ma si sa che i Professional Services non concepiscono (tranne per il software progettato da loro stessi medesimi) l’esistenza di bugs non ancora risolti, anche se impattano un Cliente su cinquemila.

Peccato che nel frattempo il Cliente R* ha deciso di migrare alla nuova versione del nostro software e il bug con il quale ha convissuto senza problemi per quasi 14 mesi (dico io q u a t t o r d i c i  m e s i!) nella presunzione risultasse risolto nella nuova release, è diventato improvvisamente di importanza capitale.

Morale: non si firma la chiusura del progetto se non si risolve il bug.

Facile, troppo facile lamentarsi con il Product Department e il suo contumace responsabile per aver dormito 14 mesi e non aver risolto quell’unico difettuccio del software tanto importante per il Cliente R*.

Tanto facile che da rappresentante Professional Services chiedo ai Professional Services per quale motivo non fosse stata fatta un’analisi preliminare sui rischi del progetto, su quali fossero le aspettative di R* circa le funzionalità del sistema migrato e se ci fosse registrato da qualche parte un bug originato dallo stesso R* che essi si aspettassero di vedere risolto nella nuova release, un bug con il quale tuttavia è stato possibile continuare a utilizzare il software in produzione per quasi 14 mesi.

Silenzio.

Ecco bravi, fate silenzio e meditate.

E… J. please, abbassa ‘sto cazzo di dito!

In che mani siamo!

Il dinamico duo H.G. (l’Olandese Volante, mio ex-capo che se ci penso…) e R.B. (l’ineffabile Cicciopasticcio) è di nuovo in azione.

Cosmic Hand by h.koppdelaney on Flickr

Il mandato del capo B.P. (che è pure il mio manager) è di implementare una soluzione basata su Microsoft Sharepoint per sostituire una varietà di sistemi informativi (Lotus Notes, Groove, ecc.) che vanno armonizzati su un’unica piattaforma.

R.B. è il nostro responsabile PMO (Project Management Office). Dovrebbe essere certificato PMP (Project Management Professional) ma è sistematicamente incapace di gestire un progetto.  In realtà nemmeno questa caratterizzazione è esatta. Qualunque cosa affidata alle sue sapienti mani e vibranti meningi non arriva mai allo stadio di “progetto”. Rimane bensì un guazzabuglio caotico, uno spreco di energie e di risorse finalizzato a produrre il residuo di un incubo. Purtroppo quasi tutti i nostri progetti interni sono affidati a questo minus habens: nessuno che io conosca ha mai preso visione di un project plan da lui redatto, nessuno ha mai avuto il piacere di esaminare i suoi raffinati quanto inesistenti risk management plan, i suoi communication plan sono copiati di sana pianta dal primo risultato ottenuto cercando la voce con Google, nessuno ha mai  rintracciato i suoi project status report, mai visto un documento di lessons learned da lui prodotto. Peccato che il personaggio sia poi designato a fare le pulci ai nostri Project Managers che guadagnano la metà di questo inutile parassita e da lui devono pure essere giudicati. E’ un politico nato, quando ha torto è sempre colpa di qualcun altro oppure gliel’ha chiesto il capo. Occasionalmente indice conference call totalmente inutili e da lì capisci che probabilmente il boss gli ha chiesto un aggiornamento sul progresso delle attività e deve rubare un po’ di idee dagli ignari colleghi. Oggi per esempio abbiamo partecipato a una telefonata proprio sul tema Sharepoint.  Questo giusto per spiegare l’utilità pari a zero di una certificazione PMP quando il soggetto è una zucca vuota. Secondo me all’esame per la certificazione ha copiato.

H.G. vive in un mondo tutto suo. Sono convinto che non veda l’ora di essere buttato fuori dalla azienda con congrua buona uscita e si trascina stancamente verso il miraggio dello scivolo d’oro. In fondo è un buon diavolo ma si trova aimè in una posizione nella quale può fare molti danni. E’ geneticamente incapace di riflettere sui dettagli. Manda messaggi broadcast a tutta l’organizzazione annunciando grandi iniziative. Quando gli fanno notare che forse è una cazzata partono le ammende, le smentite oppure… nulla! Tanto basta lasciar passare qualche giorno e nessuno si ricorderà più. Qualche settimana fa scrisse un annuncio sull’iniziativa di condividere con tutti i nostri Clienti il codice sorgente sviluppato nei progetti, nell’intento di creare una sorta di community open source. Il messaggio conteneva direttive, tempistiche e modalità. Dopo averlo letto mi sono venute in mente circa 57 domande sul tema ma mi sono trattenuto dal fornire qualunque tipo di contributo perché mi sono rotto di fare da balia al pivello ultracinquantenne come quando riportavo a lui. Dopo qualche tempo, visto che nessuno dei membri del team si muoveva eccolo che scrive a noi team leader chiedendo collaborazione per sensibilizzare le persone a supportare questa grande iniziativa. “Caro H.G., non sarebbe meglio se organizzassi una conference call in cui spieghi esattamente cosa vuoi che facciamo?”. “Grande idea” fu la risposta. Eccerto, tutto al contrario, accidenti! Durante la conference call e la sua sbrodolata introduttiva ecco il fuoco di fila delle ovvie domande:

• visto che condividiamo codice sorgente siamo sicuri che siamo coperti dal punto di vista legale?
• abbiamo chiarito di chi ne detiene  la proprietà intellettuale?
• cosa facciamo se la documentazione tecnica è stata  scritta in lingua locale?
• che si fa con le informazioni personali contenute nei documenti o nei commenti al codice sorgente (nomi, numeri di telefono, indirizzi email) ?
• come ci comportiamo se un Cliente che ha speso diciamo 50mila euro per la personalizzazione se la ritrova pubblicata liberamente accessibile da altri a costo zero?
• ecc. ecc.

Massacrato. Che pena sentirlo abbozzare una risposta bofonchiata a ogni domanda e immancabilmente avvertire persino attraverso il telefono la manciata di neuroni ancora in grado di funzionare nel suo cervello recitare in coro “Azz! Non ci avevo pensato!”. In olandese ovviamente.

La logica di H.G. ricorda a volte un treno in corsa su un binario morto. Oggi ne abbiamo avuto un esempio particolarmente divertente, ma ci sarebbe da piangere…

Orbene, nella famosa telefonata di oggi sul “progetto” Sharepoint (in collegamento Cicciopasticcio, i colleghi S.N. e M.E. dall’America e in ufficio con me il collega S.B.) H.G. illustra come il sistema verrà anche utilizzato per il controllo di revisione del codice sorgente sostituendo (illuso!) il mio caro Perforce. Premetto che avevo avuto l’occasione poco prima di Natale di esprimere i miei dubbi sulla soluzione da lui proposta: un mix di Sourceforge, Subversion, Tortoise che tra l’altro con Sharepoint non c’entrava assolutamente nulla. I dubbi erano principalmente legati al fatto che a quanto pare Tortoise non si comporta in maniera molto robusta quando due utenti effettuano contemporaneamente il check-out dello stesso file ingenerando la possibilità di corrompere i file.

Oggi risollevo lo stesso argomento di fronte all’audience allargata.

Io:”H., ti ricordi i problemi evidenziati rispetto alla possibilità che i file risultino corrotti se adottiamo l’approccio che proponi?”

H.G.:”Sì, certo!”

Io:”E come conti di risolverli?”

H.G.:”In nessuno modo, è una caratteristica del software che intendo adottare e non c’è nulla da fare”

Io:”Ne devo concludere quindi che l’integrità del codice sorgente non costituisce per te un requisito fondamentale di questo progetto”

H.G.:”Bè, direi che questa è la conclusione logica, sì”.

Ottimo: un sistema di controllo di revisione del codice sorgente che non è in grado di garantirne l’integrità.

Quando frequentavo il liceo, il professore di filosofia ci parlò del seguente sillogismo:

“Pietro e Paolo sono Apostoli, gli Apostoli sono dodici ergo Pietro e Paolo sono dodici!”

Secondo me lo ha escogitato H.G.

Aritmetica creativa

Ci deve essere un virus in circolazione nella zona di B* perché molti dei nostri clienti in quell’area stanno dando evidenti segni di progressivo rinfanciullimento.

L’ultimo esempio è quello offerto dalla mitica C.P., responsabile progetto presso il cliente D.E.

Il progetto, trascinatosi per anni, è giunto a una svolta cruciale nelle ultime settimane.

Lo steering commitee del cliente, addossandoci tutta la responsabilità del mancato obiettivo di validare il sistema (ovviamente iper-personalizzato) ed entrare finalmente in produzione, è sbottato in un clamoroso “Mò bbasta” e ha fermato il progetto preparandosi a chiederci i consueti danni.

Organizzata una task force composta da project manager, account manager e qualche senior assortito abbiamo negoziato un ultimo disperato tentativo di recuperare la situazione.

Innanzitutto sono stati verificati i reclami del cliente circa una presunta instabilità del sistema: è risultato che durante l’arco di alcuni mesi gli eventi relativi a crash del software coincidevano in realtà con i normali shutdown a startup per le operazioni di backup. Vabbè, non sottilizziamo: a rigore, lo spegnimento di un sistema è da considerarsi un crash ai fini del calcolo dell’uptime.

Chiariti questi punti passiamo alle questioni relative ai malfunzionamenti dell’applicativo.

La scena vede i colleghi S.B. e J.A.G. ascoltare le lamentele della C.P. per un report Oracle che non funziona. Il solito incipit: “Il report non funziona punto”.

Parte la procedura di troubleshooting.

Noi: “Cos’è di preciso che non funziona?”

Lei: “La media! Il report non stampa la media!”

Noi: “La media de che?”

Lei (cominciando a innervosirsi): “Mai dei risultati no!? La media dei r i s u l t a t i !”

Noi: “Ok, senti, facciamo così. Cominciamo da capo. Inizializza i dati, inserisci i risultati nel sistema e noi cerchiamo di capire dove si inceppa questo bricconcello, va bene?”

I colleghi osservano attentamente ogni mossa della strega fino al punto in cui deve inserire ‘sti benedetti numeri.

Già: numeri.

Ma chi ha mai parlato di numeri? Invece di inserire una sequenza di “3 4.5 12.45 76.2” cosa ti scrive la megera? “CONFORME”, “NON CONFORME”, “NON CONFORME”, “CONFORME”, “CONFORME”, ecc.

Noi: “Scusa cara, forse ci sta sfuggendo qualche insignificante particolare. Orbene, la media tra 3, 5 e 7 è 5 visto che (3+5+7)/3 fa 5. Fin qui ci siamo. Ci spieghi come sia possibile ricavare un valore medio da una sequenza di valori non numerici?”

Lei: “Che c’entra? Il report deve comunque calcolare la media!”

Noi (il nostro turno di manifestare segni di nervosismo): “E quale dovrebbe essere la media tra, diciamo, CONFORME e NON CONFORME? Qualcosa del tipo SEMI CONFORME oppure NON CONFORME MA QUASI? Insomma come diavolo si calcola CONFORME + NON CONFORME diviso due ??!!”

Lei (affettando la malcelata indulgenza che si riserva ai minus habens): “Se tutti i risultati sono CONFORME è CONFORME se ce n’è almeno uno NON CONFORME è NON CONFORME. Più chiaro di così!”

E questa lei la chiama media. Di quali mirabolanti capacità avrà dato prova la virago per conseguire la laurea, posto che ne abbia una?

La scena si chiude con un J.A.G. scomparso sotto il tavolo (non è dato sapere se per il riso incontrollato o un calo di zuccheri) e S.B. che gli implora contegno e chiede: “Passami le specifiche funzionali”.

Il vortice

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.

Hispanicus

Immag016-1
Originally uploaded by seaan.

Il caro I.D.-C. ha lasciato il team e un buon numero di clienti ora orfani dei suoi “pregiati” servizi in Spagna.
Come conseguenza, da qualche tempo trascorro alcuni giorni ogni settimana nella assolata penisola iberica impegnato in varie attività come: bug fixing, installazioni, gestione progetti, sviluppo, viaggi in taxi, notti in bianco in hotel, etc. Proprio io! Un team leader costretto a lavori di bassa manovalanza!
In realtà non posso dire che mi dispiaccia: il contatto con in Clienti è sempre gratificante, anche in situazioni difficili o disperate perchè a meno che non abbiano ormai deciso di depennarti dalla lista dei fornitori si aggrappano al Consulente come all’unica risorsa che può salvare il loro progetto ed evitare che il dipartimento IT, l’anno successivo, non si ritrovi con il budget dimezzato.
Madrid dunque e in particolare l’Università Autonoma dove abbiamo un paio di progetti in corso ormai da anni basati sul famoso W.L. di uno dei post precedenti.
Il programma della settimana è stato abbastanza travagliato:

• Martedi 27 Giugno: partenza da Linate con il volo Alitalia delle 7.50, ovviamente in ritardo di un’ora. Giornata dedicata al bug fixing di W.L. La cosa simpatica è che essendo il programma un’applicazione two-tier con database Oracle e application server
  Tomcat, ho potuto eseguire i test sul mio laptop (dove gira un server tomcat) prima di rilasciare le modifiche sul server di produzione. Lista completa dei bug tracciata sul nostro server Bugzilla.
• Mercoledi 28 Giugno:prosecuzione bug-fixing e finalmente compreso il meccanismo di un oscuro job Oracle lasciato attivo dal nostro I., resa felice Maite dopo la disattivazione del famigerato job di Oracle (ovviamente lei, essendo un chimico, non ha la più pallida idea di cosa sia un job… Oracle), sostituito con qualcosa di più pratico e intuitivo. Nel pomeriggio conference call con i danesi della N.N. per un nuovo progetto: il nostro outsourcing provider T. necessitava di alcuni chiarimenti
• Giovedi 29 Giugno: teoricamente dovevo andare da P.M. per una installazione. Il suo dipartimento si trova sempre nello stesso complesso dell’Università Autonoma. Cominciamo col dire che è arrivato con mezz’ora di ritardo, il nostro francese che ancora gongolava per la vittoria della Francia sulla Spagna ai Mondiali di Germania. Nonostante gli avessi raccomandato di verificare la presenza dei CD di installazione, nel suo armadio non si trovano. Ergo, tutto rimandato. Ma prima imparo qualcosa: il database server dove occorre fare l’installazione è infatti una pezzo di metallo, plastica e silicio sui cui gira Sun Solaris. No monitor, no scheda grafica, no lettore CD. Come si installa utilizzando un’applicazione come Oracle installer che gira in ambiente grafico? Semplice, se si ha a disposizione da qualche altra parte nella rete una macchina su cui gira un X-Server (anche quello di Cygwin va bene).

1. 1. Fai login sulla macchina dove gira l’X-Server
   2. Usa xhost per aggiungere la macchina Sun alla lista delle macchine autorizzate a usare l’X-Server (ma sarebbe meglio usare i magic cookie).
   3. Fai login sulla Sun e assegna il valore della variabile DISPLAY=xserver.host:0
   4. Lancia un’applicazione X sulla Sun: e voilà, verrà visualizzata sull’X-Server (ma eseguiti sulla Sun)

Me ne torno quindi a fare bug fixing sino a circa le 18.00 quando chiamo il solito taxi che mi aspetta “frente al rectorado”. E inizia una odissea: volo Alitalia cancellato, pernottamento a Madrid e partenza il Venerdi alle 6 di mattina. Ma questa è un’altra storia…

Ingegneri! 33,33,33…

IMG_1661
Originally uploaded by seaan.

L’altro giorno ho avuto una lunga conversazione sotto forma di Groove chat con uno dei nostri collaboratori indiani impiegati a Dubai, S.K.
Alcuni mesi fa, S.K., insieme ai suoi colleghi, aveva trascorso due settimane in Italia per un corso di aggiornamento sui nostri prodotti software. L’obiettivo era metterli in condizione di lavorare sui nostri progetti nell’area Middle-East limitando il coinvolgimento del personale europeo e dare una bella botta al Gross Margin.
Con l’occasione, illustrammo loro anche due progetti particolarmente critici in Arabia Saudita che avremmo voluto portassero a compimento.
La chiaccherata era durata una mezza giornata.
Avete mai avuto occasione di parlare con una persona proveniente dall’India?
In segno di comprensione e assenso a quello che dite, scuote la testa con un movimento basculante che per un europeo significherebbe: “nonononono, ma che stai addì!?”.
Nel dubbio che quel basculare tous ensemble significasse veramente che non avevano capito un’acca, davo già per perduti i due progetti e mi sentivo in tasca di nuovo un biglietto per Riyadh.
Ebbene, durante la chat durata circa un’ora, S.K. mi ha aggiornato su uno dei due progetti.
Inizialmente, S.K. ha menzionato una serie di problemi chiedendomi suggerimenti su come risolverli. Ma a ogni mia risposta, S.K. ribatteva che una soluzione alternativa l’aveve già trovata e provata con successo.
Alla fine, era chiaro che tutte le questioni aperte erano state risolte, il cliente era contento e possiamo sperare di avere il verbale di collaudo firmato entro la fine dell’anno.
Proprio come nel film “Non ci resta che piangere”, quando Leonardo scende da un treno a vapore sbuffante, realizzato sulla base delle indicazioni strampalate date in un pomeriggio d’estate da Benigni e Troisi e dice, dimostrandosi ancora più smaliziato: “Ingegneri: trentatrè, trentatrè, trentatrè!”.
Questo però S.K. non me l’ha detto.