Fare e costruire

“Dai forza, mangiane ancora uno…”
“Mamma, te l’ho detto, non mi va.”
“Devi mangiare altrimenti non cresci. Quante volte te lo devo dire Galactus.
Dai un ultimo pianeta poi basta…”

Quando una mia amica invia sulla chat una foto del genere significa che il livello di stress sul lavoro è alto.

Pensare di alleviare questo disagio con le patatine credo sia un’illusione.

Certo avventarsi su quelle croccanti sfoglie salate e lasciarsi cullare dalle basse frequenze dello sgranocchiare è liberatorio, ma non porta avanti il vostro lavoro, anzi probabilmente lo rallenta.

E’ come se le patatine rappresentassero i problemi che dovete affrontare: mangiarle vi dà l’illusione di affrontarli e risolverli.
Uno psicologo direbbe che siamo in presenza di un transfer. Vi sentite oppressi dal lavoro e scaricate la frustrazione distruggendo quelle povere patatine indifese, per dimostrare che avete il predominio su qualcosa.
A dirla tutta il potere magico di far sparire un pacchetto di patatine in poco tempo è molto diffuso, lo pratico anche io ogni tanto.
Galactus invece quando è stressato mastica piccoli asteroidi.

D’altra parte un segreto che quelli del marketing degli snack hanno tenuto ben custodito fino a qualche tempo è questo: qualunque cibo salato che faccia “crunch” vende un casino.

Con queste patatine come vogliamo fare ? L’ideale sarebbe andare alla radice del problema.
Usare la filosofia Toyota dei cinque perché, capire cosa sia fonte di stress e trovare una soluzione.
A volte la causa potrebbe risiedere nel ruolo ricoperto oppure peggio nell’ambiente tossico, ma in questo caso la soluzione potrebbe richiedere scelte drastiche e complesse.
Chiaro che risolvendo un problema del genere rischieremmo il tracollo del mercato degli snack e questo non ce lo possiamo permettere.

In alternativa vi consiglio di provare almeno ad invertire la logica.
Datevi dei piccoli obiettivi, concentratevi su di essi ed ogni volta che ne raggiungete uno fermatevi e premiatevi con qualcosa che vi gratifica
(anche il mercato degli orsetti di gomma va forte).
Probabilmente con questo metodo si ingrassa lo stesso, ma almeno si rimane produttivi.
Inoltre spuntando gli obiettivi raggiunti nell’arco della giornata, potreste rendervi conto che lo stress è causato dalla quantità esagerata di lavoro che dovete svolgere e non dalla vostra scarsa produttività.
Forse questo vi farà sentire meno in colpa e magari vi porterà a riflettere su voi e sul vostro lavoro.

Camminavo per la città con le mani in tasca perso nei miei pensieri.
Poi avvertì un sordo rombo in lontananza.
Alzai gli occhi al cielo e vidi sagome nere minacciose volare lente.
Seguì con lo sguardo la flotta dei neri bombardieri passare indisturbata sopra la città; nessuna contraerea.
Tutti sapevano che sarebbero arrivati, i civili erano stati evacuati per tempo.
Gli aerei oltrepassarono i grattacieli e li persi di vista.
Chiusi gli occhi e nella mente immaginai le bombe che venivano sganciate.
Non sapevo esattamente dove sarebbero cadute e quali danni avrebbero fatto.
Sapevo solo, che una volta terminato l’attacco, io e la mia squadra avremmo dovuto ripristinare ciò che era stato danneggiato per rendere la città nuovamente funzionate e vivibile.
Almeno fino al prossimo bombardamento.

Adeguamento normativo

Il software è un manufatto realizzato per risolvere problemi di business.
In un mercato caratterizzato da cambiamenti frequenti ed improvvisi il software è soggetto a continui adeguamenti.
L’adeguamento può scaturire da esigenze funzionali espresse dal cliente oppure da variazioni normative decise dal legislatore.
Nel primo caso il requisito può essere oggetto di un negoziato nel secondo caso no.
In Italia la normativa è una fonte inesauribile di adeguamenti, spesso complessi e complicati.
Il problema è che gli adeguamenti normativi sono requisiti con complessità incomprimibile e non negoziabile, pertanto rappresentano una seria minaccia rispetto alla quale andrebbero adottare opportune contromisure.

La triade

Il software per sua natura è plastico, ma qualunque adeguamento ha un costo e può avere degli effetti collaterali sul suo funzionamento.
Più l’adeguamento è ampio e profondo maggiore sarà l’impatto e maggiore sarà il costo.
Più elementi del software debbono essere modificati, più complicato e lungo sarà l’intervento di adeguamento.
Più il software è progettato male e scritto in modo incomprensibile, maggiori saranno i neuroni bruciati da chi deve modificarlo. Un momento, questo aspetto non e’ considerato tra i costi aziendali, quindi non frega a nessuno (sigh!).
Il lato oscuro dell’adeguamento normativo e’ che esprime anche una scadenza, pertanto definisce a priori il tempo che si ha disposizione per lo sviluppo per i test e per la delivery sui clienti.
Perciò nel caso di un adeguamento normativo, se prendiamo la triade: Time, Scope e Cost, abbiamo i primi due assi fissi e possiamo modulare solo il Cost: forse.
Si ma, di che effort stiamo parlando ? Facciamo una stima dell’impatto.

Stallo

Non è infrequente che la stima per l’adeguamento ecceda il tempo utile a disposizione e qui casca l’asino.
In questi casi la via aurea del manager illuminato (male) è spingere sul budget: cioè aumentare le persone che lavoreranno al progetto.
Il problema è che questa strada seppur costosa non sempre è praticabile: dipende da come è stato progettato il software.
Se il software non è modulare, lavorarci in parallelo potrebbe risultare talmente caotico da indurre l’effetto contrario.
E’ come pensare di aumentare la produttività di una minuscola cucina mettendoci a lavorare in contemporanea tre cuochi della stazza di Giorgione: una ben triste un’utopia.
Quando il parallelismo non è attuabile siamo in presenza di uno stallo in cui l’apporto del management è pari a zero.
In questi casi la realtà inconfessabile è che l’adeguamento nei tempi previsti semplicemente: non è umanamente possibile.
Nessun manager ama udire queste parole e Caterina lo sa bene:

La verità ti fa male, lo so

Caterina Caselli “Nessuno mi può giudicare”

Un eroe al tavolo 5

Come si esce dallo stallo ? Serve un eroe.
“Accendiamo il Bat-segnale.” disse il Capitano Gordon.
Si cerca qualcuno sprezzante del pericolo, con alto senso del dovere pronto ad immolarsi per il bene dell’azienda.
Qualcuno pronto al sacrificio che, esercitando il super-poter dell’extra-effort (non retribuito) curvi abilmente lo spazio-tempo e lavorando 12 ore al giorno prenda in mano quel groviglio infernale di codice e ne dipani la matassa.
E il miracolo si compie ogni volta, come la liquefazione del sangue di San Gennaro.
Ma possiamo veramente definirlo un miracolo ?
Non è piuttosto una perversa roulette russa ?
Magia nera alimentata dal sacrificio umano ?

E se ha funzionato una volta, forse e’ ripetibile, quindi perche’ prendere provvedimenti?

Manager certificati, ma privi di buonsenso, empatia e competenza non funzionano.
Sono individui che, non avendo adottato in tempo utile opportune contromisure, trovandosi spalle al muro, attribuiscono agli Dei le colpe della propria inettitudine per poi invocarne subito dopo l’intercessione e l’invio dell’eroe salvatore…
Non abbiamo veramente bisogno di figure del genere in azienda. Saremmo in grado di fare gli stessi danni anche da soli. Per fare meglio servono manager competenti e proattivi.

Quel debito ? Non e mio!

Queste situazioni di stallo non possono essere gestite in nessun modo ortodosso, ma possono essere evitate facendo prevenzione.
In un’azienda IT il debito tecnico è un problema di tutti, ma sembra non interessi a nessuno, tranne gli sviluppatori che ci combattono quotidianamente.
Il debito tecnico deve essere mantenuto basso perché è un costo aziendale e prima o poi i debiti vanno saldati.
Se il software è soggetto ad adeguamento normativo frequente, il debito tecnico ne amplifica gli effetti negativi, pertanto non può essere sottovalutato.
In uno scenario del genere convivere con codice legacy senza investire per reingegnerizzarlo è una mancanza grave che denota miopia e scarso rispetto per le persone.

Predisponiamo la contraerea ed adottiamo dei criteri costruttivi diversi per ridurre e mitigare gli effetti devastanti dei bombardieri normativi e magari così non avremo più bisogno degli eroi.

Ho atteso parecchio per scrivere questo post, perché volevo poter guardare agli eventi narrati con il giusto distacco.
Nella vita di ciascuno ci sono eventi che alterano il corso delle cose: una scelta, qualcosa che abbiamo detto o fatto.
Diamo però molta enfasi all’evento in se, spesso senza fermarci a riflettere sul percorso che ci ha condotti fino a lì.
In questo caso proverò a ripercorrere il filo degli eventi.

Quasi per scherzo

Era una domenica di dicembre 2018 quando decisi di presentare la mia proposta di talk all’evento Oracle Code di Roma per il marzo successivo.
Da qualche anno frequentavo alcune community di sviluppatori software, seguivo talk online e avevo partecipato di persona ad alcuni eventi di settore.
L’idea di fare un talk mi attirava molto, ma dovevo trovare un argomento ed un contesto adatto.
Avevo alle spalle una solida esperienza da formatore, ma non avevo alcuna esperienza di talk.
In quel periodo frequentavo l’Italian Oracle User Group (ITOUG) e quando venne annunciato un evento Oracle a Roma l’allora presidente Francesco Tisiot mi incitò a partecipare.
Sembrava l’occasione giusta, ma dovevo trovare un tema da discutere.

A quei tempi, insieme ai miei colleghi, lavoravo ad un software con molti anni sulle spalle realizzato con tecnologie Oracle.
La sua età non giustificava investimenti per innovazione, ma nonostante ciò noi avevamo il compito di farlo funzionare al meglio e adeguarlo alle nuove esigenze di volta in volta sempre più sfidanti.
Così avevamo fatto di necessità virtù e, con i pochi mezzi a nostra disposizione, avevamo realizzato un framework che alla fine ci aveva consentito di risolvere brillantemente tutta una classe di problemi.
La soluzione che avevamo progetto, realizzato ed adottato meritava di essere raccontata, perché a mio modo di vedere rappresentava un bel esempio d’innovazione frugale (Jugaad).

Quel mattino di dicembre decisi quindi di proporre il mio talk .
In fase di registrazione veniva richiesto il link ad un precedente talk o una breve video presentazione.
Non avendo esperienze pregresse, optai per la seconda opzione e registrai un breve video.
Ero piuttosto imbarazzato, ma superai l’indecisione, completai la registrazione e cercai di non pensarci più.

Si fa sul serio

Qualche tempo dopo arrivò l’accettazione del talk.
Quella che era solo un’ambizione aveva trovato la forza di concretizzarsi in una sfida con me stesso. A quel punto avevo preso un impegno e avrei cercato di portarlo avanti nel migliore dei modi.
Cominciai così a scrivere una bozza della presentazione per il talk.
Coinvolsi i miei colleghi ed usai i loro preziosi feedback per migliorarla.
Mi documentai sulle migliori pratiche per condurre dei talk.
Trovai numerosi spunti interessanti, ma soprattutto mi convinsi che serviva un elemento narrativo per rendere fluida e piacevole la presentazione.
Ci pensai un pò e alla fine trovai che il concetto di metamorfosi era adatto.
Quella fu la svolta. Aggiunsi immagini sufficientemente evocative e la presentazione prese corpo.
Feci due e tre prove del talk, video registrandomi per vedere se rientravo nei 45 minuti a disposizione: dovetti ridurre ancora le slide ma funzionava! (Link alla presentazione)
Prima del talk si concretizzò l’opportunità di cambiare azienda.
Soppesai tutti i pro e contro, ma era da tempo che meditavo di cambiare strada: decisi che era ora.
La consapevolezza di questa scelta, mi consentì di affrontare il talk sereno, cosciente che a seguire mi attendevano cambiamenti ben più ardui.

Si va in scena

Organizzai la trasferta a Roma con l’aiuto del mio caro amico Marco.
Andai a Roma e fu un piacere enorme ritrovarsi con lui dopo tanti anni.
L’indomani sarebbe venuto anche lui a seguire l’evento.

Giovedì 4 aprile Eur Salone delle Fontane.

Ero piuttosto emozionato.
Ironia della sorte di fronte si stagliava in tutta la sua imponenza la nuova sede dell’azienda per cui lavoravo.
Fatto il check-in ci presentammo alla postazione ITOUG, dove ci accolse
Mario Fusciardi che con la sua simpatia e la sua gentilezza ci fece sentire subito a casa.

Andai nella sala del talk a fare un check del collegamento al proiettore: tutto a posto.

A metà mattina la sala si riempì e fu ora di cominciare.
L’evento veniva ripreso ed andava anche in live streaming quindi mi stavano seguendo anche i miei colleghi dall’ufficio.
Io ero lì anche per loro: per rendere onore ad un ottimo lavoro fatto insieme.
Partì un pò incerto, ma poi mi scaldai e tutto andò liscio.

La presenza del mio amico Marco, in prima fila, contribuì a farmi sentire a mio agio.
In definitiva ciò di cui parlai era lo ciò su cui avevamo lavorato negli ultimi 10 anni quindi era un argomento che avevo vissuto sulla mia pelle.
Anzi a dirla tutta alcune frasi di quel discorso erano le stesse che con cui avevo ammorbato i miei colleghi negli ultimi anni: in sala caffè, in pausa pranzo perfino nell’antibagno. Insomma erano concetti che avevo avuto modo di affinare lungamente.
I feedback che raccolsi in sala e i contatti che ebbi con le persone che incontrai in giro per il resto della giornata furono tutti positivi: segno che il talk aveva funzionato.
Da casa chi aveva seguito il talk in streaming mi fece i complimenti via Whats App.
A pensarci bene la cosa fu paradossale. In tanti anni di lavoro, nella concitazione della quotidianità, non eravamo riusciti a trovare un momento istituzionale per fermarci a riflettere su ciò che avevamo costruito insieme.
Alla fine, poco prima di lasciare l’azienda, ero dovuto andare fino a Roma per parlare di questi temi ai miei colleghi che mi ascoltavo in streaming live da Ancona. A volte per andare in buca, bisogna giocare di sponda.
Fu una bella soddisfazione per me, ma volevo che rappresentasse anche una piccola rivincita, per tutti coloro che nell’ombra avevano contribuito a questo risultato e credo di esserci riuscito.

Quel giorno ho avuto la prova di ciò che avevo già letto.
Un talk deve contenere un messaggio chiaro supportato da una narrazione efficace e, per mantenere viva l’attenzione per 45 minuti, chi presenta deve mettere passione in ciò che dice.
Sul resto lascio giudicare a voi, ma la passione era sicuramente tanta.
Passammo il resto della giornata a seguire altri talk e conobbi Ludovico Caldara un altro collega ITOUG.

E vissero per sempre felici e contenti, o no ?

Questo evento è stato uno snodo storico per la mia carriera professionale ? No. Di lì a poco avrei smesso di usare Oracle e comunque nessuno mi ha contatto in merito a ciò che ho presentato.
Questa esperienza mi ha cambiato ? Si molto perché ho superato una sfida che ho cercato. Questo ha alimentato la mia autostima in un momento in cui, dopo 13 anni, cambiavo azienda e mi attendevano altre sfide di cambiamento.
Il talk alla fine ha rappresentato anche un personale ringraziamento a tutti gli ex-colleghi con cui ho condiviso questa lunga ed intensa esperienza lavorativa.

In definitiva qualunque esperienza vissuta ci cambia ed influenza le nostre azioni future. Non è possibile risalire esattamente la catena degli eventi che si sono succeduti e che ci hanno reso ciò che siamo.

Dopo qualche tempo mi sono reso conto che la metafora del cambiamento non era casuale bensì inconscia.
A pensarci bene la metamorfosi che ho raccontato durante il talk aveva molto a che fare con il mio personale percorso di cambiamento che era in quel momento in pieno svolgimento.
Ironia della sorte nel periodo successivo la mia trasformazione non andò a buon fine: a volte succede.
Per una serie di motivi, nella nuova azienda, nonostante gli sforzi miei e dei colleghi, non riuscì ad integrarmi.
La mia autostima dopo un massimo storico scese ad un minimo storico.
Fu una lezione importante sulla natura intrinseca della mia persona.
Trovai la forza di cambiare nuovamente azienda.
Oggi a due anni di distanza, con un pò di pazienza, ho raggiunto un nuovo soddisfacente equilibrio, quindi posso considerare quella metamorfosi finalmente compiuta.