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.

È 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!