Ogni tanto mi capita di pensare al mondo IT come a un’automobile d’epoca in mezzo al traffico di oggi. Una Giulietta del ’62, magari: perfetta, elegante, costruita con cura artigianale, ma con il motore che ansima tra SUV elettrici e veicoli autonomi. In mezzo a tutto questo, la domanda è: ha ancora senso guidarla?
In quell’immagine si nasconde una tensione che molti di noi, nel lavoro, avvertono ogni giorno. I modelli classici – quelli che ci hanno insegnato a usare ITIL come fosse una Bibbia – si trovano oggi a convivere con approcci nati in un contesto completamente diverso: incerto, mutevole, distribuito, spesso contraddittorio. E qui mi torna in mente Aristotele, quando distingue tra episteme e techne. Non basta sapere: bisogna anche saper fare. E, aggiungerei, saper dire con precisione cosa si sta facendo. Perché il linguaggio – lo dice la sociolinguistica prima ancora che l’informatica – non è solo uno strumento: è un ambiente.
Il pericolo delle parole vuote
DevOps, Agile, ITSM, SDLC: termini che si accumulano come etichette sul bagaglio di chi viaggia tanto ma senza fermarsi mai. Ma cosa succede quando queste parole diventano vuote formule? Succede che si progetta senza sapere davvero cosa si sta facendo, si implementano processi che sembrano sensati solo perché “lo dice il framework”.
Il problema non è il framework: è la perdita di contatto tra linguaggio e realtà.
Dal punto di vista di un project manager con formazione tecnica, l’affermazione “ogni tentativo di costruire un sistema immune al cambiamento è destinato a fallire” va letta in chiave epistemologica e operativa, soprattutto se si lavora nell’ambito dell’IT governance o della progettazione di sistemi complessi.
L’acqua, la leggerezza e il controllo
Zygmunt Bauman ci ha parlato di modernità liquida, ma questa liquidità non è necessariamente un valore: è una condizione. Il punto è decidere come attraversarla. DevOps ci chiede proprio questo: smettere di costruire dighe e imparare a navigare. Non per seguire la corrente in modo passivo, ma per governarla. Gene Kim lo dice bene nel Visible Ops Handbook: servono controlli, ma devono essere leggeri. E Calvino – quello delle Lezioni americane – ci ricorda che la leggerezza non è superficialità, ma la capacità di portare il peso senza esserne schiacciati.
La leggerezza è una forma di resistenza, non di rinuncia. Un progetto può essere complesso e rigoroso senza essere rigido. E può essere agile senza essere approssimativo. Tutto dipende da come si tiene insieme pensiero e azione, parola e risultato.
Karl Popper, filosofo della scienza, sostiene che nessun sistema teorico può essere considerato definitivamente vero o immutabile. Un sistema che non prevede la possibilità di essere falsificato, adattato o evoluto è dogmatico, e dunque epistemologicamente debole. Traslando questo principio nel dominio dei progetti IT, ciò implica che ogni architettura, framework o modello di gestione dei servizi deve essere progettato per essere modificabile, ovvero capace di accogliere nuove evidenze, contesti e requisiti.
Il pragmatismo è un’etica
C’è una frase che mi accompagna spesso. William James, in Pragmatismo, scrive: “Il valore di un’idea sta nella sua capacità di produrre risultati concreti”. Non è un invito alla banalità dell’efficienza, ma alla responsabilità. Se dici una cosa, se scegli un processo, se imposti una cultura di lavoro, devi sapere dove ti porterà. Devi esserne responsabile.
Non esiste idea neutra, come non esiste processo neutro. Ogni scelta porta con sé una visione del mondo. E ogni visione del mondo si riflette nella lingua che usiamo per raccontarla. Per questo il linguaggio progettuale merita attenzione almeno quanto gli strumenti. Perché è lì, in quel lessico tecnico che diamo per scontato, che si annida il modo in cui immaginiamo di poter agire sulla realtà.
In ambito IT, i sistemi “chiusi al cambiamento” sono quelli che non contemplano meccanismi di retroazione (feedback loop), versioning, interoperabilità o estendibilità. Un’infrastruttura rigida non è solo fragile sotto stress, ma diventa un vincolo al miglioramento continuo. La stessa logica si applica ai processi: quando un’organizzazione adotta ITIL, DevOps o Agile come dottrina e non come framework adattabile, finisce per irrigidirsi su procedure che non rispondono più al contesto reale.
Le metodologie non salvano nessuno
DevOps non è la salvezza, così come Agile non è la verità. Sono strumenti, prospettive, cornici. Non sono la realtà. La realtà è fatta di persone, contesti, limiti. E anche del modo in cui ci parliamo dentro i progetti.
Cambiare linguaggio – e intendo sul serio: parole, toni, metafore – può essere il primo vero atto progettuale. Perché ogni progetto è, in fondo, un tentativo di costruire senso. E se non partiamo da lì, resteremo a trafficare con la nostra bella Giulietta su un’autostrada che non abbiamo capito.
Quando si afferma che anche il linguaggio può diventare un sistema rigido, si intende che i termini, i modelli e le tassonomie usate nei progetti (ad esempio: “incident”, “change”, “velocity”, “ownership”) tendono a cristallizzarsi in formule ripetitive, che perdono aderenza al significato originario. Questo fenomeno è particolarmente insidioso nei contesti IT perché il lessico tecnico è parte integrante del design: se i concetti non vengono continuamente riesaminati e ridefiniti in base ai contesti concreti, si genera una distorsione semantica che compromette la chiarezza decisionale e la coerenza operativa.
Lettura consigliata
Bruno Latour – La scienza in azione. Introduzione alla sociologia della scienza
(Edizioni di Comunità, 1998)
Latour ci invita a osservare il sapere tecnico non come qualcosa di già dato, ma come una costruzione sociale in continua negoziazione. Ogni metodologia – DevOps incluso – non è un oggetto neutro ma una rete di relazioni, pratiche, linguaggi. Capire come un sistema diventa “funzionante” significa anche imparare a leggere le dinamiche che lo rendono possibile. Un testo fondamentale per chi vuole fare tecnologia con lucidità, senza farsi dominare dalle sue narrazioni.