Un cretino #2

Il solo fatto che si stia delineando una serie sul tema delle corbellerie seriali perpetrate dal soggetto è di per sé preoccupante ma tant’è.

Il Nostro (sempre S.G.) ha illustrato una interessante teoria su come si dovrebbe impostare la strategia di vendita dei nostri prodotti software e dei relativi progetti di implementazione.

Poiché stiamo assistendo a un picco di lavoro per i servizi professionali, che, mancando del numero di consulenti che sarebbe necessario, gestiscono con difficoltà (com’è ovvio e umano) l’allocazione efficiente delle risorse sui progetti, bisognerebbe RALLENTARE la vendita e acquisizione di nuove attività per consentire di evadere il backlog di ordini pregresso, pronti ovviamente a ripartire di gran carriera quando il backlog sia stato ricondotto a una dimensione più gestibile e si siano finalmente liberate risorse.

Tanto il mercato e la concorrenza sono lì che aspettano i comodacci nostri no, S.G.? Sottospecie di ruminante biungulato fissipede!

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.