Innovare significa anche dire no: il nuovo compito degli IT manager

“I no che aiutano a crescere” è un testo pedagogico di Asha Phillips, che in estrema sintesi spiega che talvolta il dire “no” ai propri figli sia un vantaggio per la loro crescita caratteriale. E come, viceversa, il dar sempre loro ragione abbia delle ripercussioni anche a lungo termine sui loro comportamenti.

Qui non parliamo di genitori e bambini, ma di IT manager e loro colleghi. I quali molto spesso chiedono di tutto in ambito informatico, principalmente software, e devono essere talvolta frenati nelle loro ambizioni innovative.

Dai terminali stupidi all’“ubellino”

Erano tempi felici quelli dei terminali stupidi, come ho scritto altrove. Il sistema informativo era accessibile solo da un numero molto limitato di postazioni, sedendo davanti a degli scatoloni dallo schermo nero con caratteri verdi. A nessuno sarebbe venuto in mente di chiedere ulteriori funzioni rispetto a quelle di uso lavorativo già fornite. Il terminale era uno strumento di lavoro, una specie di macchina da scrivere evoluta, dalla quale non c’era da aspettarsi niente di trascendentale.

Poi arrivarono i Personal Computer, i sistemi operativi con interfaccia grafica (quelli con il mouse, per intendersi) e poi ancora Internet. E così crebbero di parecchio le aspettative, le richieste, le curiosità.

Nasce il fenomeno da me denominato “ubellino”. Che poi sarebbe l’esclamazione “Uh, bellino!” pronunciata alla vista di qualsiasi software nuovo e colorato, anche se inutile. Negli anni ‘90 qualcuno li chiamava “gorgonzolaware”, o “incatzware” per evidenziare la loro mera bellezza estetica e funzionale che ne nascondeva la sostanziale inutilità. Addirittura ci fu chi teorizzò che un software per essere classificato come davvero utile e produttivo doveva contenere almeno due o tre bug con tanto di crash e maschera blu.

Quando il “no” tutela il sistema informativo

Ma dove si potevano trovare i gorgonzolaware, visto che ancora Internet in pratica non esisteva, almeno in Italia? Erano allora diffusissime le riviste mensili con un CD o DVD allegato, che conteneva decine di programmi, alcuni in versione “demo”, pochi altri completi, pronti da installare sul proprio PC. Ricordo in quegli anni un collega al quale dovevamo reinstallare da zero il computer ogni due mesi, perché dal gran numero di software “ubellini” si era “incriccato” definitivamente. C’è anche da dire a sua parziale discolpa che con Windows 95 non era poi così difficile bloccare il sistema.

A quel tempo il “no” rimaneva spesso lettera morta, nel senso che chiunque poteva installare ciò che preferiva sul proprio PC. Ma almeno formalmente andava pronunciato, per la sicurezza e la funzionalità di tutto il sistema informativo aziendale.

Software fai da te e responsabilità dell’IT manager

Con le versioni di sistema operativo successive (Windows 2000 in testa) e l’avvio di politiche di sicurezza un minimo stringenti, l’installazione compulsiva fu arginata, ma non altrettanto si poté dire per la creatività informatica degli utenti (è di allora la nascita del termine non propriamente garbato “utonti”, largamente diffuso in campo IT). Sì, perché con l’evoluzione ed il potenziamento dei sistemi anche le funzioni delle “suite” da ufficio (Microsoft Office in testa) si estesero a dismisura, arrivando ad offrire anche veri e propri ambienti di sviluppo applicativi visuali con tanto di database relazionale incluso (sto parlando di MS Access, ovviamente). E fu l’inizio degli applicativi “fai da te”, nati di solito da una tabellina Excel divenuta un file Access al quale poi erano state collegate form in numero crescente. In genere la giustificazione addotta dai programmatori self-made era quella dell’inerzia del settore informatico, talvolta anche con qualche motivazione reale. Ma negli anni successivi molti di questi “programmini”, talvolta anche realizzati con un certo estro, diventarono degli applicativi di settore veri e propri, con ovvi problemi al momento del pensionamento o del trasferimento del creatore.

Era quello un momento in cui il Responsabile doveva dire “no”, anche a costo di divenire largamente impopolare. Cercando al tempo stesso una soluzione informatica che potesse almeno in parte sopperire alle funzioni sviluppate dal creativo collega.

IT manager e intelligenza artificiale: il nuovo “ubellino”

E a questo punto poteva mancare un accenno all’intelligenza artificiale?

L’AI presenta enormi potenzialità e vari problemi di fondo: principalmente, è bella e accattivante. Fa sembrare semplici tanti processi che in realtà non lo sono, nasconde la complessità e presenta soluzioni veloci a problemi anche di livello elevato. “L’ho fatto con Claude! Lo chiedo a ChatGPT!” stanno diventando il nuovo “Lo dice Google” degli anni 2000.

I rischi dell’AI nello sviluppo software

Ma mi sento di esprimere un caveat: il lavoro delle schiere di programmatori che dagli anni ‘60 ad oggi hanno alimentato lo sterminato parco software che gira nei computer di tutto il mondo non si impara in tre giorni. E non può essere sostituito tout-court da un LLM.

So che questa frase mi fa apparire un tirannosauro in un mondo di velociraptor (o di robot umanoidi, per restare in tema) ma vi propongo alcuni esempi.

Un cardiochirurgo non diventa tale in una settimana: laurea, specializzazione, e poi tanta gavetta prima di arrivare a aprire un torace e smontare e rimontare i pezzetti all’interno. “Ma che c’entra, lì c’è di mezzo la vita umana” diranno molti di voi. Certo, ma pensate che il software scritto male non possa causare danni enormi? Un solo esempio che costò decine di milioni di dollari, descritto nel mio articolo https://www.healthtech360.it/storie-innovazione/tat-turn-around-time-laboratorio-ospedale/
potrebbe bastare a convincervi. E allora perché chiunque può scrivere software anche strategico, senza avere la minima conoscenza di cosa sta facendo davvero?

Direte: ma la bravura nel coding prescinde da lauree e altri titoli. Di sicuro: ho avuto colleghi che scrivevano software egregio senza né lauree, né master, né certificazioni tecniche.

Ma, d’altro canto, non posso fare a meno di notare come la qualità del software applicativo, anche in ambito sanitario dove la riduzione dei bug e l’affidabilità dovrebbe essere fuori discussione, sta viceversa degradando in maniera evidente anno dopo anno.

E temo, tornando alla AI, che lungi dal rappresentare una soluzione, accentuerà il problema rendendo molto più difficile la rimozione dei bug, l’aggiornamento, il versioning e la messa in sicurezza dei sistemi.

Capire cosa c’è dentro resta importante

Poi può darsi che mi sbagli, del resto negli anni ‘60 per prendere la patente di guida bisognava conoscere il funzionamento del mitico spinterogeno, adesso basta sapere dove si mette la benzina e non provare a bere l’acido della batteria (voi lo sapete cos’era lo spinterogeno? No? In effetti oggi non esiste più). Questo per dire che la comprensione del “cosa c’è dentro, come funziona, cosa succede poi” è sempre meno importante. Purtroppo, dico io.

Ma non credo di fare testo: credo di aver smontato e rimontato il mio motorino almeno cento volte, e senza che fosse guasto. Non trovando mai lo spinterogeno, fra l’altro.

AI in azienda, RTD e sovranità digitale

L’invito per i colleghi RTD (Responsabili per la Transizione Digitale) è quindi quello di essere prudenti nella diffusione in azienda di questi strumenti, a costo di risultare impopolari.

L’AI può dare dipendenza, e in un’Europa che parla finalmente di sovranità digitale è bene prestarci attenzione.