Antifragilità e l’antica arte di migliorare quando le cose peggiorano

II parte: Essere antifragilidi

Antifragile dai concetti alla pratica

Ci siamo lasciati nella puntata precedente dopo aver fatto una panoramica sui concetti di fragile, robusto, resiliente e antifragile. Ma cosa significa nel concreto “migliorare nelle avversità”? Con questo articolo introduciamo ulteriori riflessioni, citando direttamente alcuni passi dal libro di Taleb [1], per gettare un ponte verso le prossime puntate di questa serie in cui — con esempi reali — guarderemo più nel dettaglio come favorire l’antifragilità nelle organizzazioni.

Parlando di antifragilità delle organizzazioni, infatti, un interessante spunto ci viene offerto dall’autore di Antifragile quando fa notare che i sistemi naturali che ci circondano sono sopravvissuti, o meglio si sono evoluti, grazie alla loro capacità di convivere con i fattori di stress esterni.

Il mondo naturale è infatti un classico esempio di antifragilità sviluppata nel continuo confronto con fattori di stress, volatilità, casualità. Privare quindi un sistema della volatilità, della casualità e dei fattori di stress e proteggerlo oltremisura in realtà finisce per danneggiarlo, impedendo lo sviluppo di quelle capacità evolutive che ci hanno permesso di giungere fin qui.

Antifragilità e sistemi complessi

Un sistema naturale complesso è per sua natura antifragile, oppure muore. Qui il termine complesso non è casuale, ma è riferito ai temi della complessità che abbiamo riassunto, ad esempio, nella prima parte della nostra Guida galattica per Agilisti [3], e che abbiamo trattato più volte quando abbiamo parlato del modello interpretativo Cynefin [4].

In breve, per complesso in ambito organizzativo intendiamo quel contesto in cui I rapporti di causa ed effetto non sono evidenti, non abbiamo a disposizione pattern o best practice da applicare, non possiamo affidarci agli esperti di dominio. Pertanto il comportamento preferibile inizia da un sondaggio del contesto — per esempio tramite esperimenti — a cui seguono misurazioni e analisi dei dati, e infine l’azione conseguente.

 

L’instabilità alla base del progresso

Un errore tipico che facciamo nelle organizzazioni attuali è quello di cercare di perseguire un ordine precostituito calato dall’alto, fatto di sicurezza e stabilità. Sulla base di questa “piattaforma di certezze” desideriamo costruire dei sistemi che vorremmo si innovassero, sperimentassero. Citando un passo da Antifragile [1], come faremo nel corso di tutto l’articolo:

…nella società attuale si cerca di innovare a partire da situazioni di agio, sicurezza e prevedibilità, anziché accettare l’idea che “la necessità sia davvero la madre di ogni progresso”

Creare sistemi di sicurezza e protezione contro ogni forma di stress, se sul breve termine protegge il sistema stesso, sul lungo periodo finisce per farci perdere la capacità di affrontare le difficoltà, elimina i nostri anticorpi; è un comportamento analogo a quello di chi cerca di aiutarci e finisce per farci più male come

certi genitori nevrotici e iperprotettivi, spesso continuamente concentrati nel cercare di proteggere i figli

Purtroppo creiamo questo tipo di danno più frequentemente di quanto possiamo immaginare e ne è dimostrazione il tipico modello organizzativo gerarchico — in cui regole, direttive, convenzioni sono calate dall’alto — che rende più fragili perché impedisce la crescita e la sperimentazione. Nella costante ricerca per evitare gli errori, si finisce per chiudersi in una gabbia dorata che impedisce il confronto con il resto del mondo, con altri attori e concorrenti.

Il disordine come stimolo alla conoscenza

Taleb nel suo libro spinge a rifuggire la ricerca indefessa dell’ordine dei sistemi, esaltando I vantaggi gnoseologici del disordine.

Cercate l’ordine e avrete pseudo-ordine. Un po’ di disordine nei sistemi crea stabilità: se una moneta non fluttua mai nella sua serie storica, la minima variazione creerà il panico. Se oscilla più o meno stabilmente, probabilmente nessuno si metterà a dare di matto se c’è una variazione, ma anzi proviamo a vedere le cose con maggior distacco. […] Allo stesso modo, l’assenza di fluttuazioni del mercato favorisce impunemente l’accumulo di rischi nascosti. Più a lungo si procede senza un evento traumatico sui mercati, peggiore sarà il danno nel momento dello scompiglio.

Una crisi, un fallimento spesso ci mettono di fronte in modo diretto ai nostri errori, alle debolezze accumulate, alla falsa tranquillità che tutto fosse sotto controllo. L’errore è un veicolo d’informazione e quindi una forma di sense making molto potente, sempre che si sia in grado di misurarlo e analizzarlo, come avviene per esempio nelle “cerimonie” tipiche di una metodologia agile come Scrum.

Nel mondo IT questo rischio si manifesta per esempio quando lo sviluppo del software procede a ritmi sostenuti senza un vero meccanismo di verifica e confronto con l’utente finale — si preferisce magari far finta che tutto vada bene — oppure quando si accumula debito tecnico sul codice che non viene stressato a dovere o provato da utenti reali.

 

Risk management vs fragilità

Sempre da Antifragile è interessante citare il cosiddetto “principio di Lucrezio”:

Solo lo stolto crede che la montagna più alta del mondo sia pari a quella più alta da lui osservata, oppure scambia la prova dell’assenza con l’assenza della prova.

Quando si parla di gestione del rischio, la strategia comunemente in uso è quella di cercare nella sequenza di eventi passati il cosiddetto scenario peggiore e utilizzarlo per calcolare l’impatto di un evento futuro. Si tratta del cosiddetto stress test: analizzando la peggiore catastrofe del passato si prova a vedere gli impatti di tale fenomeno attualizzato ai correnti valori.

Questa strategia, non porta alcun beneficio al sistema: il focus è sul calcolo del danno, non sul rafforzare il sistema per renderlo più resistente ai fattori di stress. Inoltre, prendere in esame l’impatto del peggior evento accaduto non impedisce che poi se ne verifichi uno ancor più grave.

A tal proposito, ricollegandosi a quanto detto ne Il cigno nero [2], Taleb afferma:

Per come la intendiamo oggi, la gestione del rischio è lo studio di un evento collocabile nel futuro, e solo alcuni economisti e altri folli possono pretendere, in barba all’esperienza, di “misurare” l’incidenza futura di questi eventi rari […] Più è raro l’evento, meno è gestibile e meno sappiamo sulla frequenza con cui accade. Eppure, più l’evento è raro e più questi “scienziati” che si occupano di prevedere si sentono fiduciosi.

Un esempio sul risk management

La gestione del rischio quindi, oltre ad avere una debolezza di fondo, non ci permette di migliorare. Per capire meglio proviamo a prendere in considerazione l’immagine del ponte di figura 1.

Figura 1 – Qual è la probabilità di attraversare questo ponte?

Figura 1 – Qual è la probabilità di attraversare questo ponte?

 

Immaginiamo che si tratti del ponte di un villaggio che frequentemente rimane isolato per il crollo di tale ponte. Proviamo a confrontare la frequenza di tale evento con la probabilità che si rompa domani. Per esempio se provassimo a chiederci qual è la probabilità che domani il ponte crolli se ci passa un gatto. Bassa? OK. E se ci passasse un cavallo? E se ci passasse un uomo a cavallo? Due uomini a cavallo? Due uomini a cavallo con un gatto sulla testa?

Molto probabile il lettore avrà detto che la probabilità di crollo nei primi casi è molto bassa, mentre il rischio di incidente aumenta considerevolmente nei casi successivi.

Ma sapere questo numero — a patto di averlo definito in modo sufficientemente preciso — non rende meno grave il problema di fondo: abbiamo un ponte pericolante. Quindi la gestione del rischio è una disciplina che non ci fa migliorare, non ci rende meno fragili, anzi.

 

Rischio e antifragilità nel mondo dell’IT

Si possono tradurre questi concetti all’interno di una organizzazione IT, per esempio una software house? Come coach agile mi trovo piuttosto spesso a dover spiegare la differenza fra fragilità e rischio. In particolare, quando si parla di stime di lavorazione — una particolare derivazione del concetto di rischio — spesso mi sento dire che “è assolutamente necessario introdurre una qualche metodologia o strumento per arrivare ad avere delle stime più precise sui tempi di consegna del prodotto finito”.

Al netto del fatto che “stima precisa” è un ossimoro — si veda la definizione di “stima” su un qualsiasi buon dizionario — concentrarsi troppo sulle stime spesso finisce per tralasciare tutta una serie di aspetti i cui impatti sono molto più importanti rispetto allo sbagliare una stima.

Quando le stime non servono…

Non so quanto il lettore sia in accordo con questo mio personalissimo pensiero, ma trovo poco utile stimare — o cercare una tecnica di stima migliore — quando il progetto è gestito all’interno di un contesto ricco di disfunzioni: stime fatte da chi non conosce il progetto o non dovrà svilupparlo, team che non interagiscono perché dislocati sul territorio, persone scarsamente coinvolte, body rental, separazione fra chi progetta e chi fa… e molto altro ancora.

A rafforzare questa affermazione “scandalosa”, molti casi reali, presentati in svariati contesti, illustrano come le tempistiche di realizzazione di un software siano solo in minima parte dipendenti dall’effort intrinseco dei task da completare e invece siano in larga parte dipendenti dai tempi di attesa di risposte che devono arrivare da parte di altri elementi, esterni al team di sviluppo.

Misurare la fragilità, non il rischio

Citando ancora una frase del libro di Taleb, questi due esempi ci fanno comprendere che

se la fragilità è abbastanza misurabile, il rischio non lo è affatto, in particolare il rischio associato a eventi rari.

Continuare a concentrare i propri sforzi sul rischio — o sulle stime — senza portare alcun tipo di intervento strutturale volto a ridurre la fragilità intrinseca è una forma di attaccamento miope a vecchie tradizioni pericolose.

Figura 2 – I tacchini seguono la loro routine giornaliera…

Figura 2 – I tacchini seguono la loro routine giornaliera…

 

Un’altra citazione di Taleb dice che

un tacchino che analizza “le prove” ignaro dell’esistenza del Giorno del Ringraziamento, effettua “rigorose” proiezioni basandosi sugli eventi passati.

 

Antifragilità diretta (debole)

Un primo tipo di antifragilità, che Taleb chiama “debole”, è quella che si ha livello del singolo elemento di un sistema complesso: una persona appartenente a un gruppo, un singolo animale appartenente a un branco, una singola attività di ristorazione appartenente al tessuto imprenditoriale di una città. Da questo punto di vista, piccoli fattori di stress possono portare a livello locale lievi miglioramenti.

In medicina, per esempio, si parla di “mitridatismo” — dal nome del sovrano Mitridate VI del Ponto (132–63 a.C.) che temeva di essere avvelenato — quel fenomeno che consiste nell’abituare gradualmente una persona a tollerare sostanze nocive: per esempio si può immunizzare una persona sensibile al veleno di un imenottero tramite piccole e crescenti dosi del veleno.

Una variante dello stesso principio è rappresentata dalla “ormesi”, riconosciuta chiaramente da Paracelso, il fisico-alchimista tedesco Theophrastus Bombastus von Hohenheim (1493-1541). Paracelso si era reso conto nella pratica medica che l'efficacia delle sostanze tossiche dipendeva principalmente dalla dose: per esempio, a piccole dosi, alcool, caffeina e nicotina — tutte sostanze tossiche ad alte concentrazioni — avevano effetti stimolanti tollerabili dall’organismo.

L’ormesi quindi è un modo per arrecare una piccola dose di stress o di danno in modo da portare un beneficio alla persona. Si tratta di un primo esempio di antifragilità debole” che Taleb chiama proto-antifragilità perché, sebbene il beneficio possa essere molto importante, oltre un certo limite la sostanza tossica non porta alcun miglioramento ma anzi risulta dannosa.

 

Antifragilità nelle gerarchie (una forma di antifragilità forte)

Un aspetto interessante dell’antifragilità che la lega nuovamente alla teoria dei sistemi complessi è l’antifragilità di un sistema aggregato, gerarchico o meglio complesso. Come nel caso dell’antifragilità debole, anche qui l’esposizione a fattori di stress esterni porta a un rafforzamento; tale miglioramento, però, si manifesta a livello sistemico, mentre il singolo non si rafforza ma subisce un danno, e a volte muore (nel caso di un’azienda, ad esempio, fallisce).

Potremmo dire che l’evoluzione è possibile grazie alla fragilità del singolo e che un sistema complesso è antifragile solo se il singolo è libero di muoversi, sperimentare, agire senza preoccuparsi troppo delle eventuali conseguenze.

Danno locale, miglioramento globale

Se questo atteggiamento “disinteressato” è uno dei pilastri fondamentali della natura, negli esseri umani l’istinto di protezione ha rappresentato nel corso della storia una forma di protezione per il singolo individuo: siamo portati a curarci, a prendere antibiotici, ci ripariamo in inverno in abitazioni riscaldate, adoperiamo un abbigliamento protettivo quando andiamo in motocicletta. In fondo nessuno oggigiorno è disposto ad ammalarsi per dare la possibilità di sviluppare in due o trecento anni una forma di resistenza a un particolare virus. Umanamente siamo diventati quindi molto meno antifragili rispetto al passato.

Spesso i benefici che derivano dagli errori ricadono su altri, sulla comunità, come se gli individui fossero destinati a sbagliare per il bene comune e non per il proprio. In genere, ahimè, quando parliamo degli errori trascuriamo questo aspetto della stratificazione […] Gli individui sono costretti a morire affinché la natura (opportunista, spietata ed egoista) sia antifragile.

Il danno locale porta quindi un beneficio al sistema nel suo complesso: se un singolo individuo può subire un danno permanente da una malattia, allora grazie alla selezione o alla mutazione del DNA si ottiene un beneficio per l’intera specie. Analogamente, se la singola azienda fallisce — o perché ha sbagliato strategia di business o per una sfortunata concomitanza di eventi che non era preparata a fronteggiare — le altre aziende superstiti molto probabilmente imparano qualcosa di nuovo, per esempio implementando strategie differenti

Competizione e antifragilità

In economia e imprenditoria, se sussiste una reale competizione, possiamo invece sperimentare una forma più chiara di antifragilità. Si pensi per esempio a un distretto economico: il circolo dei ristoranti asiatici in una città metropolita come Milano, o la comunità degli artigiani che lavorano la pelle nella provincia di Pisa, così come le startup della Silicon Valley.

In queste comunità troviamo antifragilità nel fatto che aziende e imprenditori riescono a prosperare e crescere grazie alel possibilità dei singoli di sperimentare, trovare nuove soluzioni, ma anche rimetterci e persino fallire.

In questo senso le singole botteghe di artigiani sono fragili e si fanno concorrenza, ma l’insieme dei piccoli imprenditori di una località è antifragile per lo stesso motivo.

Solo se ci si confronta con il rischio di fallimento locale si ottiene un beneficio sistemico e quindi si diventa antifragili: costantemente si evolve, si mutano le strategie, si implementano nuove soluzioni, ci si reinventa in modo opportunistico.

In questo senso una frase di Taleb dovrebbe essere il manifesto dell’antifragilità sistemica imprenditoriale:

E confrontate gli imprenditori con quei manager ossessionati dalle statistiche che nelle società salgono la scala gerarchica senza mai una vera perdita. Raramente la loro corporazione è a rischio. Il mio sogno, o soluzione, è che venga istituita la Giornata nazionale dell’imprenditore, con il seguente slogan: “La maggior parte di voi fallirà, non sarà rispettata, diventerà povera, ma vi siamo grati per i rischi che correte e per i sacrifici che state facendo per il bene della crescita economica mondiale e per liberare gli altri dalla povertà. Siete la fonte della nostra antifragilità. La nazione vi ringrazia”.

 

Pensiero finale

Il concetto di antifragilità applicato al mondo delle aziende — e in particolare dell’IT — è estremamente interessante e stimolante per la generazione di nuove strategie operative, come avremo modo di vedere dalla prossima puntata. Il concetto di miglioramento continuo, pilastro fondamentale del pensiero Agile, trova nella ricerca dell’antifragiltà un importante sostegno. Nelle prossime puntate di questa serie di articoli, cercheremo di mostrare cosa significhi ricercare l’antifragilità in un team di sviluppo software o più genericamente in un’azienda che vive e lavora nell’Information Technology.

Visto che la citazione di passaggi significativi dal libro di Taleb [1] è stata una costante di questo articolo, concludiamo l’articolo con un passo proveniente da una sezione in cui l’autore prova comprendere le caratteristiche più adatte affinché un organismo o unessere vivente possa superare le difficoltà e prosperare indefinitamente in una sorta di immortalità.

Tale organismo dovrebbe poter prevedere perfettamente il futuro in modo da prepararsi “prima” all’arrivo degli eventi distruttori. In realtà, prendendo spunto da quello che fa la natura da milioni di anni, non si tratta di adattamento preventivo, bensì di una continua e costante evoluzione in risposta alle perturbazioni esterne. Anche noi possiamo — dovremmo — applicare una strategia di questo tipo e qui viene preziosa la frase che considero forse la più importante del libro, e che è certamente di effetto:

Il fatto che coloro dai quali traiamo più benefici non siano soltanto quelli che cercano di aiutarci (per esempio, con un “consiglio”), ma le persone che hanno provato a danneggiarci, e alla fine non ci sono riuscite, è alquanto sconcertante.

 

Riferimenti

[1] Nassim Nicholas Taleb, Antifragile. Prosperare nel disordine. Il Saggiatore, 2013 (ed. originale 2012)

 

[2] Nassim Nicholas Taleb, Il cigno nero. Come l'improbabile governa la nostra vita. Il Saggiatore, 2014 (ed. originale 2007)

 

[3] Guida galattica per Agilisti, Parte I: Verso Agile

http://www.guidagalatticaperagilisti.com/download.html

 

[4] David J. Snowden – Mary E. Boone, A Leader's Framework for Decision Making, “Harvard Business Review”, November 2007, pp. 69–76

 

Condividi

Pubblicato nel numero
230 luglio 2017
Giovanni Puliti lavora come consulente nel settore dell’IT da oltre 20 anni. Nel 1996, insieme ad altri collaboratori crea MokaByte, la prima rivista italiana web dedicata a Java. Da allora ha svolto attività di formazione e consulenza su tecnologie JavaEE. Autore di numerosi articoli pubblicate sia su MokaByte.it che su…
Articoli nella stessa serie
Ti potrebbe interessare anche