Caro J.
Adesso che è passato un po' di tempo e siamo tutti e due più tranquilli e possiamo guardare al passato in maniera un po' più rilassata, mi permetto, nel mio piccolo, di darti qualche consiglio spassionato che potrebbe tornarti utile per la prossima volta - approfittando del fatto che ho poco da fare in attesa della partenza per un viaggio di lavoro.
Capisco che quando sei arrivato ti sei trovato, e non per colpa tua, in una situazione difficile: il senior management aveva cancellato ogni residua fiducia nel futuro in un bel po' di gente, l'IT manager che stavi rimpiazzando era una delle poche persone decenti, che non a caso ad un certo punto aveva detto basta e s'era diretto a più verdi pascoli, i nostri programmatori e analisti migliori se ne andavano ad un ritmo di uno a settimana (non l'hai mai saputo, ma c'era un giro di scommesse mica da ridere su chi sarebbe stato il prossimo). Tutto verissimo, e non lo metto in dubbio: per qualche giorno, infatti, sei stato oggetto della massima solidarietà di tutti i superstiti. Credo sinceramente, però, che avresti potuto far meglio nella gestione della situazione. Ad esempio, quella famigerata settimana in cui perdemmo 3 persone (non l'hai mai saputo, ma c'è voluta più di una birra per convincerli a darti la lettera di dimissioni uno al giorno, tutti e tre alla stessa ora: N. te la doveva consegnare la settimana prima, per esempio) credo che quando il direttore europeo ti mandò un'email chiedendo "ma è un problema?" non avresti dovuto rispondere "ma no, li rimpiazziamo con niente con qualche scimmia ammaestrata a Bombay"; o almeno, prima di rispondere avresti dovuto controllare che le prime tre lettere del nome del direttore europeo non fossero in comune con le prime tre lettere di una certa lista di distribuzione di Exchange; e questo non tanto perchè l'email avrebbe potuto essere interpretata come razzista (tranquillo, non ce ne poteva fregare di meno; avevamo P. come collega, dopotutto, uno le cui uscite avrebbero fatto arrossire Nick Griffin) quanto perchè a) faceva capire a tutti in quanta considerazione era tenuto il nostro lavoro e b) faceva capire a tutti che il nostro IT manager non aveva la minima idea della complessità del lavoro che era chiamato a gestire. No, dico, ma pensavi davvero che tre-quattro programmatori neolaureati di Bombay potessero prendersi carico di qualcosa come 50.000 righe di codice C++ per HPC e occuparsi della manutenzione e bug fixing "come niente"? Programmatori che avrebbero dovuto correggere bug e occuparsi della QA prima di portare le patch in produzione? Su un sistema ASP su cui le 10-12 maggiori banche d'investimento del mondo facevano girare ogni mattina le proprie valutazioni?
Un altro consiglio che mi sento di darti è di evitare, per quanto possibile, di parlar male della gente che lavora per te; soprattutto poi se (ancora) parli male soprattutto delle loro capacità professionali senza averne un'idea ben precisa. Se dividi i programmatori in Tier-1 e Tier-2 dove il Tier-1 è composto di assunti -da te- da una settimana che dovrebbero in qualche maniera riscrivere da zero il software che costituisce il core business della società (che io non abbia mai visto una sola riga di codice scritta da loro non è grave; che non l'abbia vista neanche il server CVS, magari, lo è di più), e il Tier-2 si compone delle uniche persone che sanno come quel software esattamente funziona, che hanno passato gli ultimi due anni a tradurre in algoritmi i modelli sfornati dai nostri matematici (sì, si sono licenziati anche loro e lavorano per BNP-Paribas, adesso: e tu non te ne sei neanche accorto perchè credevi che i modelli si prendessero da qualche libro), si compone insomma delle persone che tengono in piedi e fanno funzionare l'unica fonte di reddito per la compagnia, ecco, in questi casi non è una buona idea venire a dire a me e a P. che quelli li hai messi nel Tier-2 perchè sono programmatori e analisti di second'ordine; primo, perchè è (evidentemente) falso, e secondo perchè, Cristo, sai benissimo che la senior programmer del Tier-2 è anche la mia migliore amica, e P. e la moglie vanno in vacanza ogni anno con la famiglia del senior analyst Tier-2.
Per finire, devo consigliarti anche, laddove possibile, di non limitarti a fare in modo che i tuoi piani siano buzzword compliant. Capisco che ogni buzzword che riesci a mettere nel piano aggiunge qualcosa al tuo bonus di fine anno; capisco anche che in una situazione in cui i profitti si sono dimezzati, la gente se ne va ad un ritmo di uno a settimana, l'affidabilità del software si degrada con ogni "miglioramento" che viene aggiunto senza essere testato (no, eliminare i sistemi per il QA per ridurre il budget non è stata una delle tue decisioni più brillanti, ma magari ne parliamo un'altra volta), diventa necessario far contenti i piani alti; con tutto questo, a volte le buzzword da sole non solo non bastano, ma possono diventare controproducenti.
Mi spiego.
Se il core business è costituito da un sistema ASP composto di un'interfaccia (Linux/Apache/Tomcat) a cui i clienti sottopongono i portafogli azionari da valutare, un cluster Rocks/Linux su cui il sofwtare che valuta i portafogli gira, diversi database (Linux/Mysql) a cui il cluster attinge per i dati del mercato su cui basare le estrapolazioni, e un'intera infrastruttura Linux per lo sviluppo, il QA (almeno fino ad un certo punto) e le comunicazioni, bene, in questo caso pronunciare la magica parolina "outsourcing" potrebbe non essere il toccasana che molti ritengono.
Certo, in teoria è possibile riscrivere il software che gira sul cluster in modo da disaccoppiarlo dal database; questo probabilmente significherebbe caricare sul cluster quantità enormi di dati per accompagnare i vettori delle valutazioni - pensa, due anni di dati delle tre o quattro maggiori borse mondiali, in formato XML, ogni mattina. Certo, in teoria è possibile allo stesso tempo portare quelle 50.000 righe di codice da Linux a Solaris (sì, il C++ è portabile; Rosy Bindi è di sinistra; quei soldi mi servivano per andare a trovare mia nonna malata; no, davvero, lei non è niente per me, io amo solo te). Certo, in teoria, visto che ci siamo, è possibile anche cancellare ogni riferimento alle librerie MPI e tradurre ogni chiamata ad una corrispondente chiamata alle librerie Solaris Grid, o come cavolo si chiamano questa settimana. E certo, in teoria è possibile, dopo aver fatto tutto questo, eseguire tutte le valutazioni in outsourcing sui Grid Cluster pubblici di Sun - ammesso, ovviamente, che si riesca a rendere sicura secondo gli standard, piuttosto stringenti, di una dozzina di banche d'investimento sia la comunicazione con il cluster, sia l'elaborazione stessa dei dati, visto che ci si troverebbe a condividere gli stessi nodi con lo sa Manitù quanti altri clienti di Sun. Tu lo sai, vero, che la mia amica Annarella in questo momento sta visualizzando un enorme diagramma GANTT in cui ogni tanto compare una casella con l'iscrizione "A miracle happens here", e sta scuotendo la testa; ma Annarella è una malfidata, non starla a sentire.
In teoria, tutto questo è possibile. In teoria, tutto questo è possibile contemporaneamente. Ma se mi permetti di darti un ultimo consiglio, magari per la prossima volta, tieni a mente questo semplice fatto: non licenziare tutti quelli che dovrebbero fare il lavoro in base al fatto che una volta che avranno fatto il lavoro, diventeranno superflui.
Perchè se lo rifai, ti ritroverai un'altra volta a spasso, con poche offerte di lavoro e costretto ad elemosinare referenze da quelli che lavoravano per te, che è veramente una delle cose più umilianti del mondo - non è che di te me ne freghi qualcosa, ma la business unit (un tempo una compagnia indipendente) che hai trascinato nel fango e portato allo smembramento, un tempo era tosta, all'avanguardia e ricca di potenzialità, e sarò sentimentale, ma un po' mi dispiace.
