Introduzione
La domanda è: gestire i problemi che possono bloccare il sistema nel momento in cui si verificano (fail-safe) oppure fare in modo che i problemi “non abbiano effetto” (safe-to-fail)?
Dobbiamo costruire protezioni intorno al nostro sistema o fare in modo che gli “eventi negativi” siano in qualche modo utili per farlo evolvere?
In questo articolo vorrei confrontare il primo approccio (fail-safe) con il secondo (safe-to-fail) evidenziando le caratteristiche di ciascuno.
Il “sistema”
Definire la parola sistema in questo ambito è cosa già ardita quindi semplifichiamo, togliamo, come ci insegna l’Agilità.
Per sistema possiamo pensare ad un prodotto, alla nostra stessa vita, ad un programma software. Un “sistema” nelle sue fasi di realizzazione richiede dei passaggi intermedi atti a validare la strada che stiamo percorrendo. Altre volte il sistema è validato solo al termine del suo processo di realizzazione.
Quale che sia il nostro mindset per realizzarlo, se il sistema è critico come facciamo a proteggerlo e proteggerci dalle situazioni critiche?
Fail-Safe
Nella subacquea, uno dei miei sport preferiti, per respirare sott’acqua un sub respira attraverso un erogatore collegato ad una bombola piena di aria. Cosa succede se l’erogatore si rompe? Il subacqueo deve precipitarsi in superficie senza aria? Potrebbe essere molto pericoloso soprattutto se siamo ad una profondità elevata. Se fosse così i progettisti di erogatori subacquei non avrebbero costruito un sistema fail-safe. Quello che succede nella realtà è che l’erogatore continua a fornire aria, ma la fornisce continuamente senza interruzione, generando un flusso di bolle che dà modo al subacqueo di risalire con una certa tranquillità in superficie.
Il sistema è intrinsecamente fail-safe perchè a fronte di un evento critico, la rottura di un suo componente, va meccanicamente in una situazione “safe” per chi lo sta utilizzando.
Pensiamo ora ad un software in grado di gestire un aereo in fase di atterraggio. La prima cosa che mi viene in mente è: “che cosa deve succedere se non funziona?”. Forse anche qui come nel caso dell’erogatore, il sistema dovrebbe essere disattivabile in ogni momento dai piloti umani andando in una situazione safe.
In ambito cinematografico ci sono diversi film che mostrano cosa potrebbe succedere se un sistema con una catena di comando (es protocolli militari) non prevedono la gestione fail-safe, ad esempio: “A prova di errore” un film del 1964 oppure “Il dottor stranamore”.
Quindi a volte è possibile costruire sistemi che in caso di failure vanno automaticamente in uno stato safe. Altre no. Per proteggere questi sistemi è necessario mettere in atto controlli, cambiare la modalità di implementazione in modo da ridurre gli errori. In informatica ad esempio il test driven development (tdd) è un approccio che prevede, prima ancora di iniziare a scrivere codice, la realizzazione di tutti i test ai quali il prodotto dovrà rispondere. Questo contribuisce a creare prodotti software di maggior robustezza.
Nelle aziende si utilizzano le teorie legate al risk management che è definito come “l'insieme di attività, metodologie e risorse coordinate per guidare e tenere sotto controllo un’organizzazione con riferimento ai rischi” e inoltre “Il risk management è un processo continuo, graduale e proattivo….”
La misurazione del rischio è necessariamente un calcolo di probabilità che quindi deve continuamente modificarsi in base all’evoluzione dei processi che va a monitorare. Per quanto accurato e come anche Taleb dice, non può mai darci una certezza.
Safe-to-Fail
Sebbene sia sempre stato un fan di Tesla, vorrei aprire questa sezione con un pensiero di Edison, i due si fronteggiarono lungamente nella loro vita.
Edison prima di riuscire a mettere a punto la lampadina al tungsteno fallì molte volte. Per lui però i fallimenti non erano eventi negativi ma semplicemente un modo modo per imparare come non fare qualcosa, in questo caso una lampadina.
L’esperimento per imparare, l’esperimento per arrivare a un prototipo (non al prodotto finale) e poi, nel caso peggiore buttarlo via e ricominciare.
Possiamo quindi fallire, ci è riconosciuta una libertà che ci permette di lavorare più tranquillamente.
Daniel Ek il fondatore di Spotify dice: "We aim to make mistakes faster than anyone else."
Ammettere l’errore anziché condannare chi lo ha commesso vuol dire anzitutto parlarne e stare su un piano di comunicazione positiva.
Il problema con il fallimento è che pesa di più sul futuro. Anche se riusciamo ad entrare in un mood come quello espresso da Edison, è relativamente facile farlo per il passato mentre per il futuro è più difficile. A fronte di un fallimento ci auguriamo di non sbagliare ancora...
In quest’ottica è importante, almeno in un contesto aziendale, lo stile di leadership.
Leadership Safe-to-Fail
Il Ceo di Microsoft, Satya Nadella, a fronte di un notevole problema di immagine provocato da un errore di programmazione su Tay, il bot utilizzato per interagire con gli utenti Twitter, trasmise ai diretti responsabili il pensiero che dagli errori si può imparare ed è meglio fare scelte errate piuttosto che non farle.
Ogni volta che si parla di mindset e di cambiamenti i leader sono figure centrali.
A questo proposito è sempre divertente e illuminante vedere su youtube il cortometraggio dei pinguini che cercano un altro iceberg su cui vivere quando capiscono che il loro si sta sciogliendo, è intitolato Our iceberg is melting di Paul Kotter.
Il gruppo di pinguini leader, dopo alcune verifiche capiscono che non è attuabile la modalità Fail-Safe ovvero l’iceberg non può essere protetto dal calore. Allo stesso modo i futuri iceberg non potranno essere messi sotto una “campana di vetro”, una bolla che li proteggerà per sempre.
Decidono, con diversi passi, di attuare un cambiamento e approcciare il metodo Safe-to-fail. Scelgono un gruppo di giovani e forti pinguini che inizia ad esplorare gli altri iceberg nelle vicinanze. Per diversi giorni le esplorazioni saranno fallimentari!
Ma invece di scoraggiarsi i pinguini ne traggono un insegnamento che alla fine li condurrà alla meta.
Nulla di tutto ciò sarebbe stato possibile senza i pinguini leader e il loro mindset safe-to-fail.
Conclusioni
Taleb definisce il "cigno nero" come un evento negativo e assolutamente imprevedibile.. Come tale, anzichè concentrarci sulle conseguenze per arginarle, meglio avere "sistemi" che a fronte di un evento "cigno nero" si possano riconfigurare traendone beneficio per migliorarsi. Proteggiamo quindi il nostro sistema e ci ostiniamo a calcolare la probabilità del “cigno nero” oppure andiamo verso un approccio sperimentale in cui ci saranno sicuramente fallimenti e modifiche al nostro percorso prima di arrivare al successo?
L’ambito è determinante, la cultura aziendale anche, ma soprattutto l’apertura al cambiamento.
Partendo quindi dal “perché”, "perché devo cambiare approccio?", e verificare attraverso una serie di esperimenti se è possibile utilizzare la modalità safe-to-fail costruendo un sistema che può fallire. Se siamo in un ambito critico e quindi il sistema non può fallire perché, ad esempio, metterebbe a rischio l’incolumità di qualcuno, allora l’approccio safe-to-fail può comunque aiutarci a costruire prototipi sempre più resistenti al “cigno nero”.
Resisto e mi preparo a fronteggiare il nemico oppure lo accolgo e provo a farci "amicizia"?
