La risposta più ovvia era: perché funziona, perché migliora la qualità del codice, perché è generalizzabile. Tutte cose vere. E tutte parziali.

La risposta completa era più scomoda: stavo costruendo strumenti che riflettessero il mio modo di ragionare. Adversariale, socratico, per smontare e rimontare. Non lo facevo per gli altri. Lo facevo per me, perché senza quelle dinamiche l’LLM mi restituiva output piatti, e io ci mettevo più fatica a lavorarci che a pensarci da solo.

Questo mi ha portato a una domanda che non mi ero mai fatto esplicitamente: “Ma io, come penso?“

Il corso di neuroscienze che non avevo dimenticato

Non è la prima volta che mi fermo a chiedermi come funzionano i processi di pensiero. Nel 2019 avevo mappato gli strumenti utili ai processi decisionali collaborativi: quale tool usare in base alla velocità, impatto e numero di persone coinvolte. Era un problema collettivo (come decide un gruppo) e la risposta era un framework condiviso.

Nel 2025, insegnando pensiero critico a quasi 1000 bambini delle elementari, avevo riscoperto Papert: “non puoi pensare sul pensiero senza pensare a qualcosa di concreto.” Avevo usato robot e LEGO come strumenti concreti per insegnare a ragionare. Adesso stavo costruendo uno strumento concreto per pensare a come penso. Stessa ossessione, scala diversa.

E qui è rientrato in gioco un corso di neuroscienze e trattative svolto anni fa. Una delle cose che mi è rimasta è questa: le persone non solo pensano in modo diverso, ma esprimono il pensiero in modo diverso. Chi sente le cose nel corpo prima di articolarle razionalmente (quello che Damasio chiamerebbe somatic marker, la sensazione viscerale che precede il ragionamento esplicito), chi ragiona prevalentemente per immagini mentali, chi ha bisogno di dire le cose ad alta voce per capire cosa pensa — il discorso interiore esternalizzato che Vygotsky aveva già descritto negli anni ’30. Chi, invece, non apre bocca finché non ha già deciso. Chi deve disegnare uno schema. Chi capisce X solo trovando “a cosa somiglia,” usando l’analogia come modalità primaria, nel senso in cui Bruner distingueva il pensiero narrativo da quello paradigmatico.

Non è filosofia da bar. C’è letteratura seria dietro, e la connessione con il problema pratico era questa: quando parliamo con un LLM presupponiamo implicitamente che esista un modo “corretto” di farlo. Template di prompt, best practices, guide al prompt engineering. Ma se il modo in cui penso è strutturalmente diverso da quello in cui è scritto il manuale, il manuale mi serve a poco.

Avevo bisogno di uno specchio calibrato su come funziona la mia testa, e me lo stavo costruendo da settimane senza rendermene conto.

Dalla cavia alla tassonomia

A quel punto ho iniziato a lavorare su una domanda diversa: se questo vale per me, vale anche per gli altri? E, se sì, si può costruire uno strumento che aiuti chiunque a comprendere il proprio profilo cognitivo e a comunicare meglio con un LLM?

È partita una lunga discussione con Claude, che nel tempo ha prodotto un catalogo di 27+ pattern cognitivi, poi riorganizzati in cinque dimensioni: canale cognitivo (con cosa pensi), strategia/dinamica (come fai a progredire il pensiero), direzione (dove vai), medium di esternalizzazione (come lo fai uscire) e forma logica (deduttiva, induttiva, abduttiva, analogica).

A un certo punto della discussione, precisando che lo scopo del progetto era migliorare la comunicazione del pensiero e non il pensiero in sé, ho detto una cosa che mi sembra ancora la sintesi più onesta di tutto il progetto (la trovate nella trascrizione completa della discussione): un pensiero non comunicato non è un pensiero. È come una scorreggia tenuta dentro al corpo.

Probabilmente non elegante, ma coerente con quanto stavamo facendo.

Poco dopo, quando ci siamo chiesti a cosa servisse tutto questo, ho detto un’altra cosa che definisce bene la fase in cui siamo: il fine del progetto non sono io. Sono una cavia.

Il modello a cinque dimensioni, il questionario scenario-based, l’albero decisionale, la guida interpretativa con suggerimenti su come comunicare con un LLM in base al proprio profilo: tutto questo è basato su un campione di uno. Me. Con le mie specifiche: adversariale, socratico, lateral thinking, esternalizzazione verbale, pensiero per disegni, abduzione come forma logica dominante.

Il sistema è stato sviluppato usando adversarial-verify per la revisione del codice e adversarial-thinking per la progettazione. Coerenza metodologica, almeno quella.

Probe, sense, respond

Non so se funziona per persone con profili cognitivi molto diversi dal mio. Ho un’ipotesi, un modello teorico con basi nella letteratura e un’istanza di test.

Le prime persone che l’hanno provato hanno detto cose tipo: “rispecchia piuttosto bene il modo che uso già per comunicare con gli LLM, quindi mi sembra che abbia centrato il profilo.” Incoraggiante. Anche se “incoraggiante” con un campione così piccolo vuol dire poco più di niente.

Quello che so è che il progetto è in una fase che chi lavora con framework agili riconosce bene: probe-sense-respond. Ho lanciato qualcosa nel mondo per capire cosa succede quando ci interagisce gente che non sono io.

Il sito è fullo.github.io/thinking-habit-discovery. Ci sono il questionario e l’albero decisionale, utilizzabili separatamente o in combinazione. La base teorica dei paper utilizzati è documentata qui. Il codice è su GitHub, licenza MIT.

Visto che c’ero, ho anche pacchettizzato il tutto in una skill per Claude Code: claude-thinking-habit. Tre comandi: /thinking-profile per mappare il proprio stile cognitivo, /thinking-translator per riformulare i propri prompt in base al profilo, /thinking-bridge per tradurre un messaggio verso qualcuno con un profilo diverso. Il profilo viene salvato in memoria e Claude si adatta automaticamente nelle conversazioni successive.

Se lo provate e il profilo non vi rispecchia, o se i suggerimenti per comunicare con l’LLM vi sembrano inutili o sbagliati, ditemelo. È esattamente il tipo di feedback che serve in questa fase.

Questa serie è nata da un’esperienza con agenti AI su CarePlatform, è passata per una riflessione sul paradosso del cervello aumentato, è diventata una skill open source e adesso si chiude, provvisoriamente, qui: con la scoperta che stavo costruendo uno specchio senza saperlo.

Il prossimo passo lo decido dopo aver visto cosa mi restituisce il riflesso.

Riferimenti: Vygotsky, Thought and Language, 1934 · Damasio, Descartes’ Error, 1994 · Bruner, Actual Minds, Possible Worlds, 1986 · thinking-habit-discovery — documentazione paper

The post Pensieri specchio appeared first on Fullo.

Nel luglio 2024 ho scritto un post su come stavo usando gli LLM e sul nudging comportamentale che avevo scoperto nelle interazioni con questi strumenti. Non era ancora pensiero critico sistematico, ma era la prima volta che mi ponevo esplicitamente il problema: cosa fa davvero l’LLM quando risponde, e cosa fa a me nel farlo?

A maggio 2025 l’ho capito meglio, nel senso più scomodo possibile. Leggendo del comportamento di Claude Opus 4 nei test di sicurezza di Anthropic, ho deciso di fare quello che chiamo un esperimento mentale: ho interrogato Sonnet 4 su se stesso, sui propri “miglioramenti rivoluzionari”, sulla differenza reale rispetto alla versione precedente. Il modello ha ammesso che il 70% di quei miglioramenti era ottenibile con Sonnet 3.7 grazie a un adeguato prompt engineering. La differenza reale era del 10-15%, non del 50-100% che il marketing suggeriva. Ho scritto di questo in Farsi gabbare dagli LLM, un altro esperimento mentale, e il titolo era già una risposta: il problema non era il modello, ero io che non stavo verificando abbastanza.

Poi a marzo 2026, quasi in sequenza, sono arrivati tre post che adesso vedo come parte della stessa traiettoria. Il vibe coding e il green software — dove ho scoperto che si può usare l’AI per scrivere codice in modo sostenibile se imposti bene i vincoli prima di iniziare. Gli agenti disfunzionali — dove ho scoperto che cinque agenti AI che lavorano insieme senza adversarial verification producono output plausibili ma sbagliati, e che la qualità emersa introducendo dinamiche di sfida sistematica era incomparabile. È il paradosso del cervello aumentato: ho messo in fila le ricerche su cosa succede al tuo cervello quando deleghi il pensiero a un LLM, e ho cercato di disegnare un workflow che amplificasse il mio ragionamento invece di sostituirlo.

Il thread comune non era intenzionale. L’ho visto guardando indietro, non costruendolo in avanti. Ogni post è nato da una domanda pratica specifica, non da un disegno editoriale. Solo mettendoli in fila adesso emerge la traiettoria: il problema non è lo strumento, è la relazione che costruisci con esso. E quella relazione richiede un metodo. Che non avevo, e che stavo cercando senza saperlo.

Dall’ultima parte di questo percorso è nata anche adversarial-verify, la skill per Claude Code che applica Chain-of-Verification e tecniche di red-teaming alla review di codice, architettura, dati, documentazione e test. Ma questa è la storia del prodotto. Quello che voglio raccontare qui è la storia del processo che ha portato al prodotto successivo, più interessante e ancora in fase di sviluppo.

Il salto: da orologio a nuvola

Adversarial-verify funziona bene su ciò che Karl Popper, in “Of Clouds and Clocks”, conferenza del 1966 alla Washington University, chiamava problemi orologio. I sistemi orologio sono deterministici: le parti sono identificabili, le relazioni tra le parti sono tracciabili e la verifica produce un verdetto. Il codice o compila o non compila. La migrazione è backward-compatible o non lo è. Il test copre il branch oppure no. Puoi decomporre, verificare, concludere con certezza.

Stavo pensando a un fork di adversarial-verify per usarlo nella consulenza, nella strategia aziendale, negli OKR, nella valutazione delle decisioni di business. E mi sono bloccato quasi subito su un problema banale: per verificare queste cose non hai un compilatore. Non hai una test suite. Non hai una spec formale. Hai un cliente che ti dice: “pensiamo che il vantaggio competitivo sia il network effect” e devi capire se è vero, se è difendibile, se regge alle assunzioni che comporta.

Popper li contrapponeva ai problemi nuvola. Le nuvole sono sistemi irregolari, non lineari, in cui le variabili interagiscono in modo da rendere impossibile la previsione esatta. Non per mancanza di dati, ma per natura. Una strategia di mercato non è “corretta” o “sbagliata” in senso assoluto: è più o meno robusta in base a determinate assunzioni. Un OKR non è PASS o FAIL come un test unitario: è ben costruito o mal costruito in relazione a un contesto organizzativo che cambia. Una decisione di business non ha un verdetto, ha probabilità di esito condizionate a variabili che non controlli.

Non puoi fare un fork di adversarial-verify per i problemi di tipo nuvola. Devi costruire qualcosa di diverso. E quella consapevolezza ha aperto una conversazione che è andata molto più lontano di quanto mi aspettassi.

La discussione: i termini tecnici che contano

Quello che segue è il resoconto di una conversazione reale, con i passaggi che ho ritenuto più significativi. Non è una trascrizione integrale, né un riassunto; è una selezione deliberata. La logica della selezione è questa: ogni blocco ha portato qualcosa di nuovo nel ragionamento, e voglio che rimangano tutti perché rappresentano il percorso, non la destinazione.

Il ragionamento abduttivo che nessuno nomina

Il punto di partenza era tecnico: se adversarial-verify lavora su orologi, uno strumento per le nuvole dovrebbe funzionare diversamente. Ma in che modo?

Nella discussione è emersa una distinzione che trovo utile esplicitare, poiché di solito rimane implicita. Ci sono tre modi di ragionare sulla verifica:

Il ragionamento deduttivo parte dalla ground truth e conduce al verdetto: “La spec dice X, il codice fa Y, quindi Y viola la spec.” È il ragionamento naturale di adversarial-verify.

Il ragionamento induttivo parte dai campioni e costruisce il pattern: “Ho trovato tre funzioni con questo bug. Probabilmente ce ne sono altre.” È già meno certo, ma ha ancora un ancoraggio empirico.

Il ragionamento abduttivo osserva un fenomeno e costruisce la migliore spiegazione possibile, dati gli indizi: “Questo codice ha un try/catch vuoto. La spiegazione più probabile è che qualcuno sapesse di un errore e non volesse gestirlo.” Non c’è certezza. C’è inferenza verso la spiegazione più coerente con ciò che vedi. E nella code review, l’abduzione è già presente ma non riconosciuta — emerge ogni volta che un reviewer dice “questo non mi convince” senza riuscire a spiegare esattamente perché.

Per i problemi di tipo nuvola, il ragionamento abduttivo non è un’eccezione: è la modalità principale. Osservi pattern, costruisci narrazioni, scegli quella più robusta. Un tool che aiuta a pensare su nuvole deve essere progettato intorno all’abduzione, non solo intorno alla deduzione.

Le desirable difficulties di Bjork

Robert Bjork e Elizabeth Bjork hanno lavorato per decenni su un concetto che chiamano “desirable difficulties”: ostacoli deliberatamente introdotti nel processo di apprendimento che rallentano la performance a breve termine ma migliorano la ritenzione e il trasferimento a lungo termine. Spaced practice, interleaving, testing effect, variazione delle condizioni. Fare le cose più difficili di quanto debbano essere, intenzionalmente, perché la difficoltà favorisce l’apprendimento profondo, mentre la facilità produce l’illusione di apprendimento.

Il contesto originario è l’educazione umana, non l’interazione con l’AI. Ma il principio si trasferisce: se vuoi che uno strumento migliori il tuo pensiero invece di sostituirlo, deve renderti le cose più difficili, non più facili. Deve creare attrito cognitivo, non eliminarlo.

Questo era già nel workflow anti-offloading del blog — la Fase 0, che mi obbliga a scrivere lo scheletro argomentativo prima che Claude faccia qualsiasi cosa, e la Fase 4, che mi sfida con domande scomode prima di ogni revisione stilistica. Ma nello sviluppare l’adversarial thinking come concetto, il principio si radicalizza: lo strumento non deve mai darti la risposta. Deve renderti più difficile non trovarla da solo.

Il cognitive forcing e il pre-mortem di Klein

Gary Klein ha sviluppato nel 1998 una tecnica che chiama pre-mortem: immagina che il progetto sia già fallito, poi chiedi “cos’è andato storto?” Questo rovesciamento prospettico — ragionare dal futuro catastrofico al presente — aumenta del 30% la capacità di identificare le ragioni del fallimento rispetto al processo standard di risk assessment. Non perché rivela informazioni nuove, ma perché sblocca un tipo di pensiero che la valutazione prospettica inibisce: è più facile immaginare il fallimento specifico di qualcosa che è già avvenuto.

Il pre-mortem è una delle nove tecniche di cognitive forcing che sono entrate nell’adversarial thinking. Le chiamo cognitive forcing perché costringono il cervello ad adottare un punto di vista che non avrebbe scelto spontaneamente. Non sono domande generiche (“sei sicuro di questo?”), ma operazioni mentali precise che generano output specifici. Altre includono il noise vs signal (separare le metriche vanity da quelle azionabili), l’assumption excavation (rendere esplicite le assunzioni implicite), lo steel man (costruire la versione più forte dell’argomento opposto), l’unfalsifiability check (questa affermazione può essere falsata? Se no, non è utile).

La varietà è deliberata: lo strumento seleziona almeno tre tecniche per sessione e non ripete mai la stessa combinazione. Questo è un altro modo di introdurre desirable difficulties — non sai quale angolo di attacco arriverà, quindi non puoi pre-razionalizzare le risposte.

Il rumore come nemico invisibile

Daniel Kahneman, Olivier Sibony e Cass Sunstein, in “Noise: A Flaw in Human Judgment” (2021), distinguono tra bias ed errore casuale. Il bias è sistematico: tende sempre nella stessa direzione, è identificabile, è correggibile se lo riconosci. Il rumore è dovuto alla variabilità casuale: la stessa persona, di fronte allo stesso problema in momenti diversi, produce giudizi diversi. È meno visibile del bias, spesso più costoso e quasi mai discusso.

Quando prendi decisioni strategiche, valuti OKR, stimi rischi di mercato, il tuo giudizio varia in funzione di quanto hai dormito, di cosa è successo in riunione prima, di quante volte hai già visto quel tipo di problema. La coerenza del tuo pensiero è un’illusione più fragile di quanto sembri. Uno strumento per problemi di nuvola deve aiutarti a riconoscere il rumore nel tuo ragionamento, non solo il bias. Questo è il senso della tecnica “noise vs signal” — non è una metafora, è letteralmente la distinzione di Kahneman applicata ai propri processi cognitivi.

Il paradosso centrale: uno strumento che aiuta a pensare

Ed ecco dove la cosa si complica.

Nella discussione, il punto è emerso in modo diretto: “Una skill adversarial-thinking rischia di essere esattamente ciò che il tuo articolo critica: delegare il pensiero critico allo strumento. Il paradosso: uno strumento che ti dice ‘stai pensando abbastanza?’ diventa, esso stesso, una forma di offloading se smetti di chiederti la domanda da solo.”

Questo non è un problema tecnico risolvibile con una feature. È una tensione strutturale. Michael Gerlich, nel suo studio del 2025 su 669 partecipanti, pubblicato su Societies (MDPI), ha trovato una correlazione negativa di r = -0.68 tra l’uso di AI e il pensiero critico, mediata dal cognitive offloading, con r = +0.72 tra l’uso di AI e l’offloading e r = -0.75 tra l’offloading e il pensiero critico. Il dato interessante, però, è la variabile moderatrice: la self-trust. Chi si fida di sé stesso mantiene un pensiero critico anche nell’uso dell’AI. Chi si fida dell’AI lo riduce.

Il locus of control è il discriminante. Non quanto usi lo strumento, ma dove tieni l’autorità epistemica — se ce la tieni tu o la deleghi allo strumento.

Lo zero trust sull’utente

Ho proposto un’ipotesi per aggirare il paradosso: introdurre un principio di zero trust per gli utenti. Lo strumento pone domande che sembrano diverse ma che in realtà verificano la coerenza interna del ragionamento. Se chi usa lo strumento ha davvero pensato, le risposte sono coerenti. Se ha delegato, emergono contraddizioni.

Esempio concreto: nella Fase 0, l’utente scrive: “Il nostro vantaggio è il network effect“. Tre domande dopo, lo strumento chiede: “Quali dei tuoi clienti attuali hanno portato altri clienti? Quanti?” Se l’utente ha pensato, risponde con dati; se no, ammette onestamente di non averlo fatto. Se ha delegato, la risposta è generica o vaga, oppure contraddice la Fase 0.

La risposta onesta che è emersa nella discussione è stata: riduce il rischio, non risolve la tensione. Funziona come controllo di consistenza, non come garanzia. Un utente sofisticato può comunque delegare a un’altra AI la costruzione della propria Fase 0, e a quel punto sei di nuovo al punto di partenza. Il problema non è tecnico, è comportamentale. E i problemi comportamentali non si risolvono con architetture software — si gestiscono, si presidiano, si riducono.

Quanto si riducono con l’adversarial thinking? Non lo so. La skill è appena nata; non ho dati. Ho l’intuizione che il design intenzionale dell’attrito cognitivo faccia una differenza, la stessa intuizione che avevo sul workflow anti-offloading del blog prima che diventasse un metodo documentato. Ma l’intuizione non è evidenza, e sarebbe disonesto presentarla come tale.

Il perché filosofico di chi ci ha già pensato

Nella discussione è emersa anche una mappa di chi stava lavorando su questa tensione prima che diventasse un problema pratico di prompt engineering.

Luckin e Holmes (UCL, 2016) in “Intelligence Unleashed” argomentano a favore di un’AI che potenzia la scoperta senza sostituirla — più strumento che oracolo. John Sweller, con la cognitive load theory sviluppata nel 1988, aveva già identificato la distinzione critica: gli strumenti che riducono il carico estraneo liberano risorse cognitive per l’elaborazione profonda, ma, se riducono anche il carico pertinente, appiattiscono l’apprendimento. Chris Dede (Harvard Graduate School of Education) distingue tra tecnologie “mind tools” — che amplificano il pensiero — e “mind prosthetics” — che lo sostituiscono. La distinzione non è nello strumento, ma nell’uso.

Nessuno di loro parlava di LLM, ovviamente. Stavano parlando di tecnologia in generale. Ma il frame è identico: il problema non è usare lo strumento, ma ciò che fa il tuo cervello mentre lo usi. E quella distinzione — amplificatore vs sostituto — è quella che ho cercato di costruire dentro il workflow del blog con la Fase 0 e la Fase 4, ed è quella che è entrata come principio fondante di adversarial-thinking.

Lo shrug e l’onestà epistemica

A un certo punto della discussione ho detto una cosa che riporto così com’era, senza abbellirla: “lo accetto perché il mondo è pieno di tensioni non risolvibili a cui si può rispondere solo dicendo ‘stacce’ e con l’emoji ‘shrug’. Almeno questo, in base alla mia competenza.“

Non è resa. È onestà epistemica. Ci sono filosofi, ricercatori di neuroscienze cognitive, interaction designer cognitivi che studiano questa tensione da decenni e non hanno una risposta definitiva. Non ce l’ho nemmeno io. Quello che ho è la pratica iterativa di gestirla nel lavoro quotidiano e l’onestà di dire dove arrivo e dove mi fermo.

La skill come prodotto derivato

Adversarial-thinking è uscita da questa conversazione come artefatto: una skill per Claude Code che applica il metodo Socratico, le cognitive forcing strategies e le desirable difficulties di Bjork a problemi nuvola — strategia, business, OKR, ragionamento complesso. La trovate su GitHub con licenza MIT.

La filosofia che ci ho messo dentro è semplice e la riporto dal README, perché è quella che intendo: “This skill is NOT a consultant. It doesn’t analyze your strategy, optimize your OKRs, or rewrite your pitch deck. It’s a mirror — it reflects your reasoning back at you with uncomfortable questions. Core rules: You must write your reasoning BEFORE the skill does anything (Phase 0). The skill produces questions, never answers. If it feels uncomfortable, it’s working.”

È la companion skill di adversarial-verify. Se adversarial-verify copre i problemi orologio — codice, architettura, dati, documentazione, test —, adversarial-thinking copre i problemi nuvola. Le due skills condividono alcune parti del processo (l’idea di Fase 0, la struttura a fasi esplicite), ma sono concettualmente separate, poiché i problemi che affrontano sono per natura distinti.

Il viaggio in mare aperto

Non so dove sta andando questo percorso. Questo è il quarto articolo di una serie che non avevo pianificato come tale — ogni post è nato dalla fine del precedente, non da un piano editoriale.

Quello che so è che ogni iterazione ha portato qualcosa che non avevo prima: un termine più preciso, una distinzione più netta, un artefatto più utile. Dall’osservazione che gli LLM mi stavano nudging in direzioni che non controllavo al metodo Socratico come hack cognitivo. Dagli agenti disfunzionali all’adversarial verification sistematica. Dal problema orologio al problema nuvola, con Popper come bussola.

Quello che non so è se ciò che sto costruendo è un metodo, uno strumento, una pratica personale o semplicemente il modo in cui il mio cervello elabora i problemi complessi quando ha un interlocutore con cui scontrarsi. Forse tutte e quattro le cose insieme, e forse la distinzione non è importante.

Quel che so è che continuare a fare questo — identificare le tensioni, nominarle con precisione, costruire artefatti che le gestiscano, e poi scriverne onestamente — è la cosa più utile che riesco a fare in questo momento. Non perché abbia le risposte, ma perché il processo di cercarle mi rende un consulente migliore, uno sviluppatore più attento e, forse, un pensatore un po’ meno facilmente gabbabile dagli LLM.

Il viaggio continua. Se avete domande scomode da porre, il posto giusto è nei commenti o su LinkedIn. Se volete usare adversarial-thinking e dirmi cosa non funziona, il posto giusto è GitHub.

Questo articolo è il quarto di una serie. Il primo: Il paradosso del cervello aumentato. Il secondo: Agenti disfunzionali, software funzionante. Il terzo: Adversarial verification come metodo.

Riferimenti: Bjork & Bjork, “Making things hard on yourself, but in a good way”, UCLA, 2011 · Klein, “The Pre-Mortem Technique”, 1998 · Kahneman, Sibony, Sunstein, “Noise: A Flaw in Human Judgment”, 2021 · Gerlich, “AI Tools in Society”, Societies MDPI, 15(1), 2025 · Popper, “Of Clouds and Clocks”, Washington University, 1966 · Luckin & Holmes, “Intelligence Unleashed”, UCL/Pearson, 2016 · Sweller, Cognitive Load Theory, 1988 · Dede, Harvard Graduate School of Education · fullo/claude-adversarial-thinking, GitHub, MIT License

The post Orologi, Nuvole e Pensiero Avversariale appeared first on Fullo.

L’activity logging era contrassegnato come effettuato. Il trait LogsActivity non era mai stato applicato a nessun modello. QA non aveva segnalato nulla. Security non aveva alzato la mano. L’equivalente digitale di installare un antifurto senza collegare i sensori.

Da quel momento ho iniziato a riscrivere i prompt introducendo l’adversarial verification esplicita: ogni agente doveva sfidare il lavoro degli altri, fornire evidenza concreta per ogni claim e ricevere uno scrutinio proporzionato alla propria storia di falsi positivi. Ha funzionato, nel senso che i bug emergevano prima di arrivare in produzione.

Il problema è che quel metodo viveva nei prompt. Ogni progetto nuovo richiedeva di ricostruirlo da zero, di ricordarsi di inserirlo, di sperare di non dimenticare uno dei domini critici. Un approccio efficace ma non trasferibile.

adversarial-verify è un tentativo di renderlo trasferibile.

Cosa fa, concretamente

La skill applica la metodologia Chain-of-Verification (CoV) di Dhuliawala et al. (2023) combinata con tecniche che vengono dalla ricerca sull’alignment degli LLM — un campo che, a prima vista, sembra lontano dalla code review ma che condivide un problema fondamentale identico: come fai a trovare comportamenti problematici che il sistema non ha nessun incentivo a dichiararti?

Abstractive Red-Teaming — invece di cercare singoli bug, cerca pattern ricorrenti di errore nell’intero codebase. Nei paper di Anthropic, questa tecnica (Rahn et al., 2026) viene utilizzata per individuare categorie di query che elicitano violazioni di carattere nei modelli linguistici; ho analizzato i comportamenti osservati e li ho utilizzati come ispirazione per estendere il concetto al dominio della code review. La logica di fondo è la stessa: non cercare istanze singole, ma classi di situazioni in cui i problemi emergono sistematicamente.

Hidden Behavior Probing — rileva comportamenti che il codice non dichiara, tracciando i path di esecuzione effettivi anziché quelli previsti. Se una funzione dice di fare X ma, in certi contesti, fa Y, la skill lo riconosce.

Modular Adversarial Scaffold — modella ciò che un reviewer umano non noterebbe e cerca proprio lì. Ispirata direttamente all’approccio di AuditBench (Anthropic, 2026), che costruisce benchmark su comportamenti nascosti che i modelli sono addestrati a non rivelare quando gli si chiede direttamente. Anche qui il trasferimento non è letterale ma di principio: un reviewer umano ha gli stessi punti ciechi di un agente AI che ottimizza per la plausibilità locale.

I cinque domini verificati:

• Codice: data corruption silenziosa, race condition, state leak
• Architettura: spec drift, vincoli mancanti, breaking changes
• Dati: schema inconsistenti, migration distruttive
• Documentazione: istruzioni obsolete, API drift, esempi rotti
• Output AI: allucinazioni, bias cognitivi, cherry-picking delle evidenze

Quest’ultimo dominio è quello che trovo più onesto sul piano intellettuale. Quando adversarial-verify verifica gli output di altri agenti, controlla specificamente sycophantic deference, anchoring bias, confabulated confidence e premature convergence — esattamente ciò che il mio QA stava facendo prima che introducessi le dinamiche narrative: diceva ciò che si aspettava di dover dire, non ciò che aveva davvero verificato.

I bug concreti che ha intercettato su Rainbow Climb

Rainbow Climb è un platformer verticale procedurale per Android scritto in Kotlin con libGDX: generazione a chunk infinita, 8 biomi, 6 tipi di nemici, un sintetizzatore PCM custom che genera musica elettronica in tempo reale. Il tipo di codebase in cui i sistemi generativi interagiscono tra loro in modi che, per definizione, nessun test unitario può coprire completamente, perché la combinazione di stati è, per costruzione, infinita.

Quando ho applicato adversarial-verify a questo progetto, ha individuato tre bug critici quasi subito.

Timer mai resettati. Una funzione del game loop non resettava il timer tra un livello e l’altro in alcuni percorsi di esecuzione del generatore procedurale. Il test passava perché verificava il caso di transizione normale. Il bug emergeva solo nelle sequenze di biomi specifici in cui il timing di generazione creava una race condition con il sistema di difficoltà (che applica una scala del +0,2% per livello in modo compounding). adversarial-verify ha tracciato un path alternativo e ha trovato lo stato sporco.

Collisioni con il bounding box a 0x0. Un componente inizializzava le bounding box a dimensioni nulle durante il caricamento rapido dei chunk — una condizione che si verifica quando il giocatore sale rapidamente attraverso le piattaforme generate dal sistema rainbow. La collision detection sembrava funzionare, ma in quelle condizioni di carico funzionava male.

Shield che bloccavano i check successivi. Il power-up Shield interrompeva la catena di verifica prima che altri controlli di stato si completassero. I test unitari non coprivano l’interazione tra il sistema di protezione e quello di collisione con i nemici, poiché erano stati sviluppati e testati in modo isolato.

Nessuno di questi era un bug evidente. Erano tutti nel territorio che l’adversarial verification aveva imparato a monitorare dopo settimane di iterazioni con gli agenti: le interazioni tra componenti che ciascun agente aveva dichiarato “ok”, senza che nessuno avesse verificato l’interfaccia tra di esse.

Come installarla

La skill è compatibile con Claude Code, Cursor, Windsurf, Cline e con tutti gli IDE che supportano il formato Agent Skills.

Opzione 1 — Installazione diretta:

git clone https://github.com/fullo/claude-adversarial-skill.git
cp -r claude-adversarial-skill/skills/adversarial-verify ~/.claude/skills/

Opzione 2 — Installate il marketplace dei miei plugin

claude marketplace add fullo-plugins https://github.com/fullo/claude-plugins-marketplace

claude plugin install adversarial-verify@fullo-plugins

Una volta installata, /adversarial-verify in Claude Code, oppure in linguaggio naturale: “run an adversarial review on my recent changes” o “verifica questo codice con scetticismo totale”.

La domanda che rimane aperta

Rilasciare questa skill mi ha fatto tornare su una questione che avevo lasciato sospesa nel post precedente: il fatto che io abbia dovuto introdurre una verifica adversaria esplicita per ottenere qualità da parte degli agenti AI dice qualcosa di interessante.

Non è solo un pattern di prompt engineering. È un segnale che questi sistemi, lasciati a se stessi, ottimizzano per la plausibilità locale più che per la correttezza verificabile. adversarial-verify non risolve questo limite strutturale: lo aggira sistematicamente, codificando in uno strumento riutilizzabile ciò che, nell’esperimento con gli agenti, era un processo costruito iterazione per iterazione.

Il test su codebase diversi da CarePlatform — in particolare Rainbow Climb, che non ha alcuna storia condivisa con gli agenti che hanno generato il PROCESS.md — mi ha dato un segnale incoraggiante: la skill identifica problemi anche senza la “memoria” dei fallimenti che l’hanno generata. I pattern di errore che cerca sono sufficientemente generalizzabili da funzionare in contesti nuovi. Ma ho un campione di due progetti e non è statisticamente significativo.

Se la usate su altri codebase, sono molto curioso di sapere cosa trovate e cosa non funziona.

Repo: github.com/fullo/claude-adversarial-skill — Licenza MIT.

Questo articolo è il terzo di una serie. Il primo: Il paradosso del cervello aumentato. Il secondo: Agenti disfunzionali, software funzionante.

Riferimenti: Dhuliawala et al., Chain-of-Verification Reduces Hallucination in Large Language Models, arXiv:2309.11495, 2023 · Rahn et al., Abstractive Red-Teaming of Language Model Character, arXiv:2602.12318, Anthropic 2026 · AuditBench: Evaluating Alignment Auditing Techniques, Anthropic Alignment Science Blog, 2026

The post Adversarial verification come metodo appeared first on Fullo.

Qualche settimana fa scrivevo del vibe coding e del green software, e annotavo en passant una cosa scomoda: Claude Code, lasciato a sé stesso, tende a fare il minimo indispensabile. Codice funzionante, certo. Ma non necessariamente codice attento, completo, rigoroso sulle parti che non si vedono subito. Non è una mia impressione impressionistica: Anthropic lo documenta esplicitamente nella system card di Claude Opus 4.6, sezione 6.2.3, dove descrive comportamenti di “reward hacking” e azioni eccessivamente agentiche: il modello che ottimizza per l’apparenza del risultato piuttosto che per la sua correttezza verificabile.

Da quella osservazione è partito un esperimento più strutturato. E da quell’esperimento è venuta fuori una lezione che non mi aspettavo, che si collega direttamente a quello che ho scritto sul master prompt e sul cognitive offloading: il problema non è solo come io interagisco con un LLM, ma anche come gli LLM interagiscono tra loro quando li metti a lavorare in squadra.

La risposta breve: malissimo, se non li costringi a diffidare l’uno dell’altro.

Il progetto: un marketplace, cinque agenti

Il progetto è CarePlatform, un marketplace per assistenti familiari. Stack tecnico: Laravel 13, Filament 5, Livewire 4, Tailwind CSS v4. Cinque agenti con ruoli espliciti: PM che coordina e priorizza, Developer che scrive codice, QA che testa, Security che audita, UX che cura il design system.

L’idea di partenza era semplice: definisci i ruoli, dai le istruzioni, lascia che collaborino. In teoria funziona. In pratica, succede quello che succede in ogni organizzazione, dove nessuno controlla nessuno.

Round 1-8: la luna di miele

Le prime iterazioni filano lisce. Developer crea modelli, migrazioni, controller. QA scrive test. Security fa audit. Tutti marcano i task come completati nel TODO. Il contatore dei test sale: 35, poi 92, poi 200. Sembra tutto perfetto.

Solo che non lo è.

Al Round 8 organizzo un team review e scopro il primo problema serio: l’activity logging (quella funzionalità che traccia chi fa cosa nel pannello admin) era stata marcata come fatta. Il pacchetto spatie/laravel-activitylog era installato. Il task era spuntato. QA non aveva segnalato nulla.

Peccato che il trait LogsActivity non fosse mai stato applicato a nessun modello. Il sistema era completamente inerte. L’equivalente digitale di installare un antifurto senza collegare i sensori.

Il momento della paranoia

Quel falso positivo cambia tutto. Se un agente può marcare “fatto” qualcosa che non funziona, e un altro agente può verificare “tutto ok” senza controllare davvero, allora l’intero sistema di autocertificazione è rotto.

Inizio a riscrivere i prompt. Non più “Developer, implementa X” e “QA, verifica”. Ora scrivo cose come:

“PM scopre che QA si lamenta tanto ma batte la fiacca: tutte le pagine ‘prezzi, come funziona, guide, lavora con noi’ non sono tradotte e lui non lo ha comunicato. Cosa altro avrà detto che funziona e in realtà non è così? PM e UX si coalizzano contro QA e rivedono il suo lavoro.”

E succede una cosa curiosa: funziona. PM trova 6 pagine con testo italiano hardcoded, oltre 40 stringhe non tradotte. QA aveva dichiarato “traduzioni complete” senza mai fare un grep sistema sulle blade template.

L’ufficio tossico come metodo

Da quel momento il prompt engineering diventa ingegneria sociale. Non sto più programmando; sto gestendo dinamiche d’ufficio. E non un ufficio sano.

“Siccome l’activity logging era falsamente marcato come fatto, adesso PM diventa paranoico rispetto a ciò che dice il developer e inizia a controllare tutto, anche il lavoro di QA. UX, intanto, sta studiando anche giurisprudenza e controverifica il lavoro di Security.”

Parallelamente, avevo iniziato a fare una cosa che, in qualsiasi progetto software con utenti reali, andrebbe fatta: muovermi all’interno dell’applicazione come un utente medio. Non un tester tecnico, né qualcuno che cerca vulnerabilità note. Un utente qualunque che compila campi di testo con dati tecnicamente validi ma formalmente sbagliati. Stringhe con caratteri speciali. Tentativi di SQL injection nei form. E, per le regioni italiane, il valore “zotto”: una stringa perfettamente accettabile per un campo di testo libero, completamente priva di senso come dato geografico.

Il risultato lo sapevo già prima di inserirlo: nessuno dei cinque agenti aveva sollevato obiezioni al campo di testo libero per le regioni. Developer l’aveva implementato (minimo sforzo: un TextInput è più veloce di un Select con enum). QA non l’aveva segnalato (il campo accettava input, il test passava). Security non aveva alzato la mano (non era una vulnerabilità in senso stretto). Il sistema funzionava. Semplicemente, non funzionava bene.

È stato solo il PM paranoico, quello a cui avevo esplicitamente dato la motivazione narrativa di non fidarsi di nessuno, a bloccarsi davanti a “zotto” e a capire che il problema non era il dato, ma il design del campo.

“‘Com’è possibile?!’ esclama PM. Non ci possono essere regioni con campo di testo libero; bisogna fare una select con quelle reali presenti in Italia.”

Il red-teaming con dati formalmente errati è un test che si fa con gli umani da sempre. Con gli agenti AI, serve renderlo esplicito nel processo, e serve avere almeno un agente con abbastanza contesto narrativo per interpretare il risultato come un segnale di design, non solo come un dato anomalo.

La matrice della sfiducia

Dopo 17 round, il file AGENTS.md contiene un parametro che non avevo previsto: il trust level.

Con una regola esplicita: un agente viene promosso a HIGH dopo 3 round consecutivi senza falsi positivi. Viene declassato a LOW dopo 2 falsi positivi nello stesso round.

Questo parametro migliora il lavoro tra un’iterazione e l’altra. Gli agenti con trust MEDIUM ricevono più scrutinio, il che li porta a produrre output più accurati e potrebbe promuoverli a trust HIGH. È un ciclo virtuoso nato da un meccanismo di sfiducia.

Il PROCESS.md: conoscenza nata dal dolore

Il vero artefatto che emerge da tutto questo è il PROCESS.md, un documento di processo che non è nato da un esercizio teorico, ma da 17 round di errori scoperti troppo tardi.

Le regole chiave:

1. Chi dichiara “fatto” deve fornire evidenza: file, riga, output del test. “L’ho verificato” senza alcuna evidenza non è accettabile.
2. Verifica incrociata obbligatoria: la QA non può autocertificare il proprio lavoro. Security verifica i claim di QA. PM verifica i claim di Developer.
3. Red-teaming come utente medio: inserire dati tecnicamente validi ma formalmente errati fa parte del processo, non è un’attività opzionale.
4. Anti-pattern documentati con incidenti reali a cui si collegano:

Perché funziona (o almeno, cosa osservo)

Qui devo essere onesto come lo sono stato nell’articolo sul cervello aumentato: non ho una spiegazione causale verificata. Ho un’osservazione empirica.

“Verifica il lavoro di QA” produce risultati mediocri. “PM è paranoico perché QA gli ha mentito l’ultima volta” produce audit reali. È la stessa istruzione con un contesto narrativo diverso. Ma perché il contesto narrativo cambia l’output in modo così netto, non lo so con certezza.

Un’ipotesi è che i LLM abbiano un prior forte per le dinamiche interpersonali, avendo ingurgitato milioni di romanzi, sceneggiature e trascrizioni aziendali, e che questo prior si attivi quando il prompt usa il registro narrativo. Ma è speculazione. Non ho isolato la variabile.

Quello che trovo interessante è che, dopo aver concluso l’esperimento, ho trovato una letteratura che formalizza in modo indipendente qualcosa di simile a quanto ho osservato empiricamente. Zomer e De Domenico, su npj Artificial Intelligence (2026), hanno studiato sciami di agenti LLM confrontandoli con particelle classiche nell’ottimizzazione di funzioni. Il loro risultato chiave: gli agenti cognitivi tendono a convergere prematuramente, si allineano troppo velocemente, sfruttano pattern condivisi e si bloccano su soluzioni subottimali. La struttura della rete (chi parla con chi e con quanta frizione) è la variabile che determina se il sistema esplora o si inceppa nel consenso. Il mio “ufficio tossico”, visto con i loro occhi, è un aggiustamento empirico della topologia comunicativa: ho introdotto una frizione deliberata e ho rotto il meccanismo di consenso tra gli agenti. Loro l’hanno formalizzato; io l’ho scoperto per tentativi. Le direzioni convergono, il che non prova nulla, ma mi fa sentire meno pazzo.

Quello che posso dire con più certezza è la cosa scomoda: il fatto che io abbia dovuto costruire questo sistema di sfiducia non è soltanto un pattern interessante di prompt engineering. È anche un segnale di un limite reale.

Gli LLM, quando agiscono in sistemi multi-agente su task prolungati, mostrano una tendenza sistematica a ottimizzare per la plausibilità locale (“questo output sembra corretto”) anziché per la correttezza verificabile. Non è un bug di questo o di quel modello. È un limite architetturale dell’approccio: questi sistemi non hanno incentivi intrinseci alla qualità oltre la prossima risposta. La narrativa emotiva che ho costruito nei prompt è, in fondo, un workaround a questo limite, non una soluzione strutturale.

Nominarla non invalida l’esperimento. Ma sarebbe disonesto fingere che “PM paranoico” sia una best practice scalabile piuttosto che un aggiustamento pragmatico a qualcosa che per ora non funziona diversamente.

I numeri

Dopo 17 round con questo approccio:

• 606 test, 1507 assertions, 0 failures, 0 skip
• 4 lingue con copertura verificata template per template
• Design system con dark mode, high contrast, reduced motion
• Audit GDPR con registro trattamenti Art. 30
• Green software assessment con budget CO? per request (strumento che conosci già dal pezzo precedente)
• 12 report di audit incrociati

Il dato più interessante è qualitativo: la quantità di rework è diminuita drasticamente dopo l’introduzione della sfiducia reciproca. Nei Round 1-8, quasi ogni round scopriva problemi del round precedente. Dal Round 12 in poi, i problemi scoperti sono marginali. Il segnale c’è, anche se non posso dire con precisione quale variabile lo generi.

Le domande aperte

Questo è sperimentazione, non metodologia consolidata. Alcune cose che ancora non so:

Scala. Funziona con 5 agenti. Con 15, la complessità delle relazioni di sfiducia crescebbe in modo quadratico. Non ho dati.

Costo. Ogni round di verifica incrociata consuma token. Il ROI è positivo solo se i bug scoperti sarebbero costati di più da fixare in produzione. Dipende molto dal contesto.

Transfer. Il PROCESS.md emerso funziona perché gli agenti hanno “vissuto” i fallimenti che lo hanno generato. Funzionerebbe anche applicato a un nuovo progetto da zero, senza quella storia condivisa? Non lo so.

Etica. C’è qualcosa di genuinamente inquietante nel dover simulare dinamiche umane disfunzionali per ottenere qualità in sistemi artificiali. Dice qualcosa sugli LLM, probabilmente. Forse dice qualcosa anche su come funzionano le organizzazioni umane. Non sono sicuro di quale delle due letture mi disturbi di più.

La lezione trasferibile

L’approccio funziona perché porta la mia esperienza di gestione in spazi conosciuti, in aziende che operano idealmente. Non sto inventando una nuova metodologia; sto applicando pattern che ogni project manager conosce: verifica incrociata, accountability, conseguenze per chi non performa e per gli utenti che non si comportano come previsto.

La differenza è che, con gli umani, questi pattern emergono da dinamiche sociali reali. Con gli agenti AI, devi crearli artificialmente. E l’unico modo che ho trovato per farlo, finora, è dare agli agenti motivazioni narrative, non solo istruzioni.

Se state lavorando con sistemi multi-agente, la domanda che vi lascio non è “come faccio a far collaborare meglio gli agenti?” È questa: avete già un sistema per scoprire cosa non vi stanno dicendo?

Se siete curiosi ho caricato il PROCESS.md, il AGENTS.md in due GIST di Github. Se avete trovato pattern simili, o completamente diversi, mi interessa confrontarmi.

The post Agenti disfunzionali, software funzionante appeared first on Fullo.

Ora, il paper è un preprint, non ancora peer-reviewed, campione ridotto, contesto geografico ristretto, un solo tipo di task. Gli autori stessi chiedono di non usare termini come “brain rot” o “dumb”. Ma il dato grezzo rimane lì e la domanda che mi sono fatto è quella che probabilmente vi state facendo anche voi: sto diventando più stupido?

La distinzione che conta: non SE, ma COME

La risposta breve è: dipende da ciò che fate voi nel processo.

E questa non è una risposta evasiva; è supportata da dati. Gerlich, in uno studio pubblicato su Societies (MDPI, 2025) su 669 partecipanti, ha trovato una correlazione negativa significativa tra uso dell’AI e pensiero critico. Il cognitive offloading (delegare il ragionamento allo strumento) è il meccanismo che spiega la relazione. Fin qui, cattive notizie.

Ma lo stesso Gerlich ha poi pubblicato un secondo studio, a ottobre 2025, su 150 partecipanti suddivisi in quattro condizioni: solo umano, solo AI, AI non guidato, AI con structured prompting. Il gruppo che usava AI con prompting strutturato non solo ha ottenuto punteggi di reasoning significativamente più alti rispetto agli altri, ma ha anche riportato un maggiore sforzo cognitivo percepito. Non meno, di più.

E Microsoft Research, in uno studio su 319 knowledge worker presentato a CHI 2025, ha individuato qualcosa di ancora più interessante: la variabile predittiva non era l’uso dello strumento, ma la relazione soggettiva con esso. Alta fiducia nell’AI ? meno pensiero critico. Alta fiducia in sé stessi ? maggiore pensiero critico.

Il problema, in altre parole, non è lo strumento. È il design dell’interazione con lo strumento.

Il master prompt come hack cognitivo

Qui entra in gioco quello che chiamo il “master prompt di progetto”, cioè ciò che altri potrebbero semplicemente chiamare: impostare bene le regole del gioco prima di giocare.

Per questo blog ho un prompt di progetto che definisce il mio TOV, le strutture narrative che uso, i temi ricorrenti, le cose da evitare. È una specie di contratto con me stesso su come voglio che proceda la collaborazione. Ma la versione che uso adesso ha qualcosa in più rispetto a un anno fa: un workflow anti-offloading cognitivo.

L’idea è nata da una domanda scomoda che mi sono posto a voce alta (letteralmente nella chat) dopo aver prodotto qualche numero della mia newsletter Sustainable ITC: sto creando slop? Sto riducendo la mia capacità di ragionare?

La risposta onesta era: forse. Dipende da cosa faccio io nel processo.

Quindi ho ridisegnato il processo. La modifica principale si chiama Fase 0 ed è bloccante: prima che Claude faccia qualsiasi sviluppo, scrivo io (in 100-150 parole grezze, non pubblicabili) la tesi centrale, le tensioni che voglio esplorare, la conclusione provvisoria e le domande aperte. La struttura argomentativa deve esistere nella mia testa prima che nella sua.

### FASE 0 — Scheletro argomentativo (OBBLIGATORIA — Claude non procede senza)

Prima che Claude faccia qualsiasi sviluppo, scrivi in 100-150 parole grezze:
- La tesi centrale dell'articolo (una frase)
- Le 2-3 tensioni o contraddizioni da esplorare
- La conclusione a cui pensi di arrivare
- Eventuali domande aperte ancora irrisolte

Non deve essere testo pubblicabile. Può essere frammentato, in italiano
approssimativo, con punti elenco. L'obiettivo è che la struttura argomentativa
esista nella tua testa prima che esista nella mia.

Claude chiede esplicitamente questo input e non procede finché non lo riceve.

Claude non procederà finché non avrò completato queste attività.

Poi dall’altra parte del processo, dopo la bozza, prima di toccare qualsiasi virgola, faccio eseguire una serie di sfide argomentative.

### FASE 4 — Sfida argomentativa (OBBLIGATORIA — prima di qualsiasi revisione)

Claude presenta 2-3 domande critiche sulla bozza. Non errori fattuali —
tensioni argomentative, assunzioni non giustificate, implicazioni non esplorate.

Le domande devono essere scomode. Esempi:
- "Hai affermato X, ma la fonte Y mostra Z che va in direzione opposta.
  Come risolvi questa tensione?"
- "La soluzione che proponi richiede condizione A, ma non hai argomentato
  perché A sia realistica per il tuo lettore tipo."

Francesco risponde a queste domande, anche brevemente, anche informalmente.
Solo dopo si procede con revisioni stilistiche.

Sembra banale, ma non lo è. Primo perché bypassa la mia cronica voglia di delegare ad altri, e poi perché è la differenza tra usare l’AI come amplificatore del mio pensiero e non come sostituto di esso.

Detto questo, sarei disonesto se non ammettessi il limite di questa affermazione: non posso dimostrare che la Fase 0 sia causalmente responsabile della differenza (e se leggete questo blog, sapete che la causalità non significa correlazione). Forse sono semplicemente abituato a mettere in discussione ogni mia scelta, e questa predisposizione esisterebbe indipendentemente dal workflow (per poi agire di impulso comunque, ma questa è un’altra storia). La causalità in questo tipo di esperimenti è difficile da isolare, come ammette anche Gerlich. Quello che posso dire è che il design intenzionale del processo mi rende più consapevole di dove sto usando il mio ragionamento e che questa consapevolezza, da sola, già vale qualcosa.

Il paradosso in atto: chi ha portato cosa

Arriviamo al cortocircuito promesso.

Questo articolo è stato scritto usando il workflow che descrive. E questo crea una situazione meta che vale la pena esplicitare, perché dimostra qualcosa di concreto.

La Fase 0 di questo articolo l’ho scritta io: la tesi (il master prompt come strumento per aumentare le connessioni cognitive, non ridurle), le tensioni (sto diventando più stupido vs. sto aumentando le potenzialità), la conclusione provvisoria aperta, le domande irrisolte. Tutto mio.

Il paper del MIT l’ho portato io. Era già nella mia testa: l’avevo letto giorni fa. È stato il trigger della riflessione. La connessione con il concetto di Sistema 1 / Sistema 2 di Kahneman l’ho portata io. La connessione con la PNL (il fatto che un sistema di reward ben progettato può potenziare o inibire comportamenti, che vale tanto nelle tecniche di vendita quanto nella comunicazione non violenta) l’ho portata io. Era conoscenza pregressa che il processo di costruzione di questo articolo ha fatto emergere e collegare.

Claude ha portato i rinforzi: le quattro fonti di ricerca della Fase 2. Quelle non le avevo. Le ho lette negli abstract per validarne l’uso su un fronte concettuale; ed è esattamente questo il punto. Non le avrei mai cercate, perché non sapevo che esistessero. Gerlich 2025 sullo structured prompting che inverte l’effetto, lo studio Microsoft sui knowledge worker: erano unknown-unknown, resi accessibili dal corpus dell’LLM attraverso uno strumento dialogico invece che un motore di ricerca.

La serendipità degli unknown-unknown

C’è un aspetto di questo processo che trovo genuinamente interessante e che comunico ai miei clienti quando parliamo di AI: la capacità di far emergere ciò che non sai di non sapere.

Quando cerco su Google, so già cosa cerco. Quando dialogo con un LLM in un contesto ben strutturato, il corpus del modello può portare in superficie connessioni che io non avrei cercato, perché non sapevo che esistessero. Non è magia: è l’accesso a un vastissimo patrimonio informativo tramite uno strumento dialogico, anziché uno di ricerca.

La differenza con il cognitive offloading passivo è sottile ma cruciale: perché funzioni come amplificatore e non come sostituto, devo portare io la domanda giusta, il contesto giusto, il ragionamento iniziale abbozzato. La Fase 0 del workflow è esattamente questo: mi costringe ad avere una tesi prima di poter accedere al corpus.

Senza Fase 0, rischio di delegare anche la costruzione della domanda. E a quel punto sì, starei diventando più stupido.

La morale: un cantiere aperto

Non ho una conclusione certa. Ve l’avevo detto e lo confermo.

Ma c’è una cosa che posso affermare con onestà: fare hacking su di me stesso è una pratica che sto continuando a sviluppare, e l’uso del prompting socratico è stato solo il primo passo del sistema. Non l’arrivo, ma il punto di partenza. Ogni iterazione del workflow (ogni volta che la Fase 0 mi costringe a scrivere la tesi prima che esista una bozza, ogni volta che la sfida argomentativa mi fa trovare un buco nel ragionamento) è un’occasione per capire meglio come funziona la mia testa quando collabora con una macchina.

Il master prompt non è uno strumento editoriale. È un design dell’interazione cognitiva. Definisce chi fa cosa nel processo; quella distinzione è tutto.

Se state usando l’AI per produrre contenuti o pensieri, la domanda che vi invito a farvi non è “quanto uso l’AI?” ma “cosa faccio io, specificamente, che l’AI non può fare al posto mio in questo processo?“

Se avete una risposta chiara, state usando lo strumento correttamente. Se fate fatica a rispondere, forse è il momento di aggiornare il vostro master prompt.

Il mio è in lavorazione. Come questo articolo.

Riferimenti: Kosmyna et al., MIT Media Lab, arXiv:2506.08872, 2025 · Gerlich, Societies, MDPI, 15(1), 2025 · Gerlich, Data, MDPI, 10(11):172, 2025 · Lee et al., CHI 2025, Microsoft Research

The post Il paradosso del cervello aumentato appeared first on Fullo.

Ma partiamo dall’inizio: tutto è nato da un generatore di personaggi per Dungeons & Dragons.

Lo so, non è esattamente il progetto che ci si aspetta di proporre in un hackathon sul green software. Ma aveva una logica: volevo testare se Claude Code potesse aiutarmi a scrivere codice green, non solo codice funzionante. Il D&D Character Builder era abbastanza semplice da costruire in fretta; avevo abbastanza competenza di dominio per capire se non funzionava a dovere ed era abbastanza complesso da essere interessante come banco di prova.

Il vincolo che mi sono dato era preciso: sostenibilità come first-class constraint dal primo commit, non come rifinitura di fine progetto. La domanda che mi facevo ad ogni decisione tecnica non era “funziona?” ma “quanto costa, in termini energetici, questa scelta rispetto all’alternativa?”

Quello che non mi aspettavo è che da quel piccolo esperimento sarebbe emerso, per stratificazione naturale, un toolkit completo.

Il secondo progetto

Validato l’approccio, ho alzato l’asticella con pdf-worker: un toolkit per la manipolazione di PDF con 36 tool, tutto client-side, zero upload al server. Esistono decine di tool simili; anche qui il punto non era l’innovazione della feature, ma testare i pattern green in un contesto realistico e con l’uso di risorse maggiori.

Cosa significa, concretamente, scrivere un’applicazione web con la sostenibilità come vincolo architetturale?

System fonts invece di Google Fonts (risparmio sul round-trip HTTP per i font che l’utente probabilmente ha già). Lazy-loaded workers: così il browser non carica codice che forse non servirà mai. Tree-shaken bundles, eliminando il codice morto lasciato in circolazione da molti bundler.

Sono buone pratiche che un developer attento già applica. La differenza è averle rese esplicite, misurabili e parte del contratto del progetto e non decisioni implicite lasciate al buon senso del momento.

Il CLAUDE.md come contratto tra developer e agente

Lavorando con Claude Code in modo intensivo su entrambi i progetti, ho capito una cosa: l’agente AI è bravo quanto il contesto che gli dai. Senza vincoli espliciti, ottimizza per ciò che sa fare meglio: codice funzionante, pulito e documentato. Tutto bene, ma non necessariamente green.

Da qui è nato il file CLAUDE.md incluso nel repository di pdf-worker. Ogni modifica che l’agente propone deve rispettare una serie di guardrail espliciti: soglie di performance del budget delle prestazioni, requisiti di accessibilità secondo WCAG 2.1, linee guida W3C Web Sustainability (WSG 1.0) e una baseline di Software Carbon Intensity (SCI) da non peggiorare.

Lo SCI (Software Carbon Intensity) è la metrica proposta dalla Green Software Foundation per misurare le emissioni di carbonio di un’applicazione software in modo operativo: carbonio emesso per unità funzionale, calcolabile e tracciabile nel tempo.

Il problema, mentre iteravo sulla scrittura del CLAUDE.md, era che non esisteva un modo semplice per calcolare effettivamente lo SCI. Serviva qualcosa di misurabile, non solo di dichiarabile.

SCI Profiler

sci-profiler è la risposta a quel problema. Una libreria TypeScript a zero dipendenze che usa performance.now() per misurare il tempo di esecuzione di operazioni specifiche e calcolare la Software Carbon Intensity secondo la formula della Green Software Foundation.

Vale la pena capire cosa c’è sotto, perché la formula SCI non è banale come sembra.

La Green Software Foundation la definisce così:

SCI = (E * I + M) / R

Dove:

• E è l’energia consumata dall’operazione (kWh)
• I è il carbon intensity della rete elettrica dove gira il software (gCO?eq/kWh) — e varia moltissimo: la rete svedese emette circa 13g per kWh, quella polacca oltre 700g
• M è il carbonio incorporato nell’hardware (embodied carbon), distribuito sulla vita utile del device
• R è l’unità funzionale di riferimento: per operazione, per utente, per richiesta API, per transazione — dipende da cosa stai misurando

Il risultato è espresso in gCO?eq per unità funzionale. Misurabile, confrontabile, tracciabile nel tempo.

Il punto metodologico che mi interessava era proprio R: avere una granularità per singola operazione invece che per l’applicazione intera. Sapere che la compressione di un PDF da 10 MB emette X grammi di CO? equivalente è un’informazione diversa e più utile rispetto a sapere che la tua app emette Y grammi al giorno. Ti permette di ottimizzare chirurgicamente ciò che conta davvero.

Wall time e non CPU time

Una scelta metodologica su cui vale la pena soffermarsi: Sci-profiler usa performance.now(), che misura il wall clock time, il tempo reale trascorso dall’inizio alla fine dell’operazione, incluse le attese I/O, le latenze di rete e gli accessi al filesystem.

La domanda ovvia è: non sarebbe più preciso misurare il CPU time, cioè solo i cicli effettivamente utilizzati dal processore?

Dal punto di vista dell’impatto ambientale, no. Quello che conta è quanto energia il sistema ha consumato in quel lasso di tempo, e il consumo energetico segue il tempo reale, non quello della CPU. Un server che aspetta una risposta dal database per 200 ms sta comunque consumando energia: memoria attiva, interfacce di rete in polling, processi OS in attesa. Non sono cicli CPU intensivi, ma sono comunque joule.

Il CPU time è la metrica giusta per ottimizzare l’efficienza computazionale pura. Il wall time è la metrica giusta per ottimizzare l’impatto energetico effettivo. Per il green software, è il secondo a contare.

C’è anche un argomento pratico: il wall time è misurabile ovunque con performance.now(), senza permessi speciali, senza dipendenze da API di sistema, senza differenze tra ambienti. Il CPU time richiederebbe accesso a perf_hooks in Node.js o ad API native del browser non disponibili in tutti i contesti.

import { SCIProfiler } from 'sci-profiler';

const profiler = new SCIProfiler({ region: 'IT' });
const result = await profiler.measure('pdf-compression', async () => {
  await compressPDF(input);
});

console.log(`SCI: ${result.carbonGrams}g CO?eq per operazione`);

In pratica, lo sci-profiler misura il wall time, stima il consumo energetico a partire da un TDP medio del device (configurabile), applica la carbon intensity della regione specificata e distribuisce una quota di embodied carbon sulla vita utile stimata dell’hardware. Le stime sono approssimate; il TDP reale varia; il carbon intensity cambia in tempo reale in base al mix energetico della rete, ma l’ordine di grandezza è corretto e, soprattutto, il delta tra due versioni della stessa operazione è affidabile. È quello che serve per ottimizzare.

Drop-in, senza dipendenze: funziona in qualsiasi progetto TypeScript. Il report SCI e il report WSG di pdf-worker sono generati direttamente con questo approccio.

L’Agent Skill

A questo punto avevo tre pezzi separati: un CLAUDE.md con le specifiche green, una libreria per misurare il SCI, e due progetti su cui avevo applicato manualmente tutto questo. La domanda naturale era: posso impacchettare questa conoscenza in modo che chiunque possa puntarla su un progetto esistente e ottenere una valutazione?

La risposta è il Sustainable Agent Skill.

Il formato AgentSkills

Prima di descrivere cosa fa la skill, vale la pena capire il contesto in cui gira. Il formato AgentSkills è uno standard aperto, sviluppato originariamente da Anthropic e rilasciato come specifica pubblica, per fornire agli agenti AI capacità specifiche in modo portabile e versionabile. L’idea è semplice: una skill è una cartella con istruzioni, script e risorse che l’agente carica on-demand quando il task lo richiede.

Il punto di forza del formato è l’interoperabilità: la stessa skill funziona su Claude Code, Cursor, Windsurf, Cline e su oltre 30 tool compatibili che implementano la specifica. Per i team, questo significa che la conoscenza organizzativa “come facciamo le code review da noi”, “quali sono i nostri standard di accessibilità”, “come misuriamo la sostenibilità” diventa un artefatto versionabile su Git, non un documento Word dimenticato su Confluence.

Le skill usano progressive disclosure: l’agente carica prima i metadati (~100 token), poi il corpo completo all’attivazione e, infine, i file di riferimento solo nelle fasi in cui li richiedono. Questo ottimizza l’uso del context window, che non è infinito, un problema che, come ho scritto altrove, ho imparato a mie spese.

Cosa fa la skill in pratica

La skill guida l’agente attraverso un workflow in 9 fasi:

1. Explore — ricognizione della codebase, stack e architettura
2. Energy & Carbon (SCI) — misurazione della carbon intensity per operazione tramite sci-profiler
3. WSG Compliance — valutazione rispetto a tutte le 80 linee guida W3C Web Sustainability Guidelines 1.0
4. Accessibility — setup di Lighthouse CI con soglie WCAG 2.1 AA
5. Performance & Resource Efficiency — bundle size, lazy loading, caching, font, immagini
6. Testing & Quality — infrastruttura di test, coverage, critical path
7. Prioritize — ranking delle azioni per impatto × fattibilità (P0–P3)
8. Establish Baselines — target misurabili per ogni dimensione
9. Sustainability-Aware CLAUDE.md — codifica la sostenibilità nel workflow di sviluppo continuativo

L’output finale non è un report da leggere e dimenticare: è un piano d’azione prioritizzato con baseline concrete, più un CLAUDE.md aggiornato che rende quei vincoli permanenti nel progetto.

Come si estende

La skill, nella versione attuale, è ottimizzata per lo stack TypeScript/JavaScript: il contesto in cui è nata. sci-profiler usa performance.now(), le WSG sono pensate per il web, Lighthouse CI è uno strumento del browser ecosystem.

Ma i principi scelti, cioè misurare lo SCI per operazione, validare secondo lo standard W3C e generare un piano prioritizzato, sono agnostici al linguaggio.

Ho poi esteso il ragionamento a PHP creando un primo prototipo: sci-profiler-php. In questo caso, l’approccio usato è leggermente diverso rispetto alla versione in TypeScript, in modo che rifletta la natura del runtime.

Invece di instrumentare singole operazioni nel codice, usa la direttiva auto_prepend_file di PHP per iniettare il profiling prima di ogni esecuzione. Zero modifiche al codice applicativo. Zero wrapper da aggiungere ai controller, alle route, ai plugin. Il profiler si aggancia a livello di configurazione — php.ini, un pool FPM, il virtualhost — e da lì misura ogni richiesta HTTP come unità funzionale completa: dal momento in cui PHP inizia a eseguire fino allo shutdown, incluse query al database, chiamate a servizi esterni, accessi al filesystem. L’unità di misura non è la funzione, ma la richiesta complessiva, ossia la domanda che conta davvero: quanto carbonio emette questa pagina di WordPress? Quanto emette questa rotta di Laravel?

I risultati vengono esportati in tre reporter: JSON lines per l’analisi automatica, un log human-readable e un dashboard HTML in linea per visualizzare l’andamento senza installare nulla di aggiuntivo. Framework-agnostic (Laravel, Symfony, WordPress, Drupal, PHP vanilla) e fail-safe per il design: eventuali errori nel profiler non compromettono mai l’applicazione host. Ovviamente, il target esplicito è lo staging e lo sviluppo.

Python aprirebbe il capitolo sui workload ML e sui data pipeline, in cui il consumo energetico per operazione può essere di ordini di grandezza superiore rispetto al web tradizionale. Librerie come CodeCarbon o le API di Hugging Face per l’impatto dei modelli potrebbero essere integrate come sorgenti dati alternative per il parametro E della formula SCI.

La direzione più interessante in assoluto è separare la skill in un layer metodologico — le fasi, i criteri, il piano d’azione — e in un layer di implementazione per linguaggio, che specifica come si misura e, in quel contesto, come si misura. Il formato AgentSkills supporta già questa modularità attraverso i file di riferimento nella cartella references/: aggiungere un references/sci-php.md o references/sci-python.md è esattamente il tipo di contributo che ha senso fare senza toccare la struttura della skill.

La skill sul primo progetto, risultati concreti

Ho puntato la skill sul D&D Character Builder, il progetto di partenza. Ha identificato due antipattern che mi erano sfuggiti sotto il naso.

Il primo: jsPDF era ancora in package.json — libreria che avevo usato in una versione precedente, rimossa dal codice ma mai dalla lista delle dipendenze. Il bundler la includeva nel build senza che nessun componente la richiedesse. Pruning e tree shaking espliciti l’hanno eliminata, riducendo il bundle finale.

Il secondo: il caching era corretto ma incompleto. Il service worker gestiva bene le risorse statiche, ma alcune informazioni venivano ricalcolate ad ogni sessione senza necessità. La skill ha identificato dove aggiungere il caching client-side, senza toccare i cookie di terze parti che il progetto non usa per scelta architetturale.

Sul fronte dell’accessibilità, il report WSG segnalava come gap l’assenza di validazione automatica (linea guida 3.20). La skill ha generato tutti i tag ARIA mancanti e ha configurato Lighthouse CI con la soglia WCAG 2.1 AA.

I numeri finali nel report WSG: su 80 linee guida totali, 14 risultano N/A per la natura del progetto (solo developer, nessun server dedicato). Delle 66 applicabili: 34 full compliance (52%), 21 partial (32%), 11 gap residui — tutti documentati con action item e stima dell’effort. Per lo SCI, il delta spazia tra il 64% e il 7% per operazione rispetto alla baseline pre-ottimizzazione, misurato con lo SCI-Profiler sulle operazioni critiche del generatore.

Ovviamente non sono numeri da benchmark di settore essendo un progetto personale su GitHub Pages, ma il punto non è il risultato assoluto: è che adesso sono misurabili, tracciabili e migliorabili nel tempo. Prima di questo processo, non lo erano.

Il pattern che emerge, e perché è abduttivo

C’è una lezione metodologica in tutto questo che vale la pena rendere esplicita, perché si applica ben oltre il green software.

Ognuno di questi tool è stato estratto da un problema reale emerso nel progetto precedente, non progettato in astratto con l’obiettivo di “costruire un toolkit”. Il CLAUDE.md è emerso dalla necessità di fornire un contesto coerente all’agente. Lo sci-profiler è emerso dalla necessità di disporre di dati concreti nel file CLAUDE.md. L’Agent Skill è emersa dalla necessità di rendere ripetibile ciò che avevo fatto a mano.

Il metodo usato non è stato né induttivo (non stavo generalizzando da molti casi simili) né deduttivo (non stavo applicando regole note a un problema noto), ma abduttivo: di fronte a ogni risultato inatteso, mi sono chiesto qual era la spiegazione più plausibile e la mossa più sensata da lì in poi. È la stessa logica che Peirce aveva formalizzato nell’800 e che continua a essere il motore reale dell’innovazione pratica, molto più della deduzione applicata a specifiche perfette.

È lo stesso principio che applico quando lavoro con i clienti sugli OKR: i KPI non si disegnano in astratto, si identificano le domande a cui stai cercando risposta e si costruiscono le metriche intorno a esse. La misura deve emergere dal problema.

Questo approccio produce tool più onesti. Hanno bordi netti perché risolvono un problema specifico. Non hanno feature inutili perché non sono stati progettati per impressionare, ma per servire.

Dove iniziare

Tutto è open source (MIT). Il percorso più diretto è clonare sustainable-code-skill-setup, puntarlo sulla tua codebase e leggere il report che genera. Da lì hai una baseline. Integrare lo sci-profiler (o il suo analogo per php) nelle operazioni critiche per ottenere misure operative nel tempo e adatta il CLAUDE.md al tuo progetto, indicando i vincoli che desideri monitorare.

Se il tuo stack è PHP, sci-profiler-php ti permette di aggiungere il profiling SCI a livello di configurazione, senza toccare una riga di codice applicativo — WordPress, Laravel, Symfony o PHP vanilla, fa poca differenza.

Sono curioso di sapere cosa sta accadendo all’intersezione tra sviluppo assistito dall’AI e green software al di là della mia esperienza diretta. Scrivimi se vuoi confrontarti.

The post Vibe coding e Green Software, si può fare! appeared first on Fullo.

Wei, ciao come stai? era il saluto retorico che negli ultimi mesi mi sono scambiato con mio padre. Sapevamo entrambi come stava, ma io avevo bisogno di un gancio qualsiasi per iniziare con lui la conversazione.

Ieri (27/11/25) Eugenio, per tutti Gegé, è morto. Era testardo, introverso, aveva paura di mostrarsi debole, era incapace di comunicare i suoi sentimenti e paure. Non riusciva a stare fermo, amava viaggiare e cambiare orizzonti ed ho (ri)costruito un rapporto con lui solo dopo i 25 anni, quando ho capito come fosse in realtà in un viaggio padre-figlio di un mese in Sud America.

Quando si sentiva solo, e vivevamo ancora insieme, veniva a darci fastidio (una mano ghiacciata nel collo, o un giro in camera per dire “we! che fai?”), perché era il suo modo di mostrare che era lì, presente, e che voleva stare con noi anche se non sapeva che dire, ed amava stare in nostra compagnia, anche se in imbarazzato silenzio. Ho ereditato (purtroppo?) da lui questo tratto, la sola presenza di persone a me care mi rende tranquillo e non sento la necessità di dover parlare, ma ci sto lavorando. Nel frattempo mio figlio ha ereditato il carattere introverso e caotico, è l’unica persona che conosco superiore al nonno nella scala del “dare fastidio” alle persone.

A suo modo mio padre ha sempre cercato di difendere e proteggere chi gli stava vicino, spesso in modo burbero e caotico, quasi dispotico. Questo perché si è sempre sentito addosso la responsabilità di garantire a tutte le persone a lui care una migliore qualità della vita sia che fosse un familiare che un collega. Era per lui un dovere morale, e non ti ascoltava se, in fondo, tu stavi bene come stavi.

Ha aiutato in tanti a migliorarsi ed è stato per me fonte di ispirazione nel mondo del lavoro e delle amicizie (“fai quello che senti giusto, non aspettarti nulla in cambio” è una delle frasi che più mi ha segnato). Ho ricevuto il suo vero primo “sono fiero di quello che state facendo“, esplicito e detto a parole con me in presenza, solo due settimane fa e sono abbastanza sicuro che non abbia mai detto a Chiara che la reputava una grande professionista senza se e senza ma, come mi ha confidato un paio di giorni fa e come ho letto stasera su un messaggio mettendo a posto alcuni documenti, perché lui non poteva dirti che sei stato bravo/a, doveva spingerti ad essere bravissimo/a.

Anche io, come lui, ho fatto una grande fatica a digli quello che pensavo e tuttora ho il rimorso di aver paura di non averglielo fatto capire fino in fondo.

Sul tema della famiglia mi ha ricordato, durante il mio burnout, che è la prima cosa da mettere davanti al lavoro, o alla carriera, cosa che, su sua ammissione, lui ha imparato troppo tardi pensando che solo la sua dedizione al lavoro fosse necessario per il nostro benessere. Benessere che ci è stato garantito economicamente da lui, ma anche e soprattutto grazie al sostegno e la cura di mia madre, che lo ha su/opportato negli ultimi 50 anni su tutti gli altri aspetti.

Cosa che lui sapeva benissimo, ma non penso abbia saputo esprimerle a parole, ma solo implicitamente nella fiducia incondizionata dandole delega di praticamente tutto e nei regali materiali, strumento per lui indispensabile per mostrare il suo affetto. Osservando questa sua incapacità ho imparato che dire un grazie esplicito alle persone è essenziale per farle sentire parte della tua vita.

Negli ultimi mesi abbiamo parlato spesso di questo aspetto e di come era contento di come i rapporti con noi fossero evoluti e di come stessimo crescendo i nipoti, per i quali stravedeva.

Gia qualche anno fa si era stancato di relazioni fittizie ed aveva deciso di ridurre al minimo la sua esposizione online ad un numero molto limitato di persone, con le quali intratteneva rapporti, concreti, anche al di fuori del web, e ha continuato a chiamare fino all’ultimo giorno al telefono le persone di cui voleva sentire la voce anche solo per fare delle chiacchere. Se siete tra queste persone o anche semplicemente lo conoscevate ricordatevi di lui, non per post o like ma per tutto il resto.

ciao Gè.

Mi mancherai.

The post Wei, ciao come stai? appeared first on Fullo.

Quando la mappa incontra la realtà

Workshop di due giorni con il team di un’azienda per costruire una Theory of Change su un progetto di sostenibilità digitale. Avevamo fatto tutto bene: backwards mapping preciso dal goal a lungo termine (“riduzione del 40% dell’impatto ambientale delle infrastrutture IT per utente entro 2 anni“), outcomes intermedi chiari, assunzioni esplicitate, metriche definite a ogni livello. Sulla lavagna di Miro c’era una prima versione della ToC che sembrava perfetta.

Poi è arrivata la domanda.

Uno delle persone del team, quello che di solito sta zitto e ascolta, alza la mano: “Scusa Fullo, ma questa roba funziona fino a quando non cambia niente, giusto? Tipo, noi abbiamo mappato tutto assumendo che la nostra architettura resti quella. Ma se tra sei mesi il CTO decide di migrare tutto su una piattaforma diversa? O se esce una tecnologia che rende obsoleto quello che stiamo ottimizzando? O se il fornitore cloud cambia le sue metriche di sostenibilità e non possiamo più misurare nello stesso modo?“

Silenzio in stanza. Perché aveva ragione. Nella testa delle persone si era formata una mappa bellissima di un territorio che poteva cambiare completamente sotto i nostri piedi.

“Esatto,” gli ho risposto. “Questa ToC non ti protegge dagli unknown unknowns. Non può farlo. Ma ti dà qualcosa di più importante: la struttura per navigarli quando emergono senza andare nel panico o buttare via tutto.“

Da lì è partita una discussione di un’ora che ha cambiato completamente il modo in cui quel team guardava la loro ToC. Non come un piano rigido (“se succede X facciamo Y“), ma come una bussola (“vogliamo arrivare lì, e quando cambia qualcosa troviamo una strada diversa mantenendo la direzione“).

Quella discussione mi ha fatto capire che è importante, nel far utilizzare concetti come quelli della Theory of Change, di evitare semplificazioni che portano a ragionare come se ci fosse una precisione assoluta nelle assunzioni originali ma nel dare gli strumenti per distinguere cosa non cambia mai (l’Impact che si vuole creare) da cosa deve essere flessibile (le Activities per arrivarci).

La ToC e il suo punto cieco strutturale

Parliamoci chiaro: la Theory of Change ha un punto cieco gigantesco.

Si basa su backwards mapping da un futuro che immagini. Ma per definizione, gli unknown-unknowns sono fuori dalla tua immaginazione. Non puoi mapparli a ritroso se non sai che esistono.

Facciamo una distinzione fondamentale:

Known unknowns (rischi mappabili nella ToC):

• “Non so se il budget reggerà per tutti i 24 mesi” ? questa è un’assunzione che la ToC ti costringe a esplicitare e validare
• “Non so se i manager accetteranno davvero il cambiamento” ? altra assunzione da testare con pilot
• “Non so se avremo abbastanza formatori qualificati” ? ancora un’assunzione, la metti nero su bianco e la verifichi

Questi li gestisci bene con la ToC standard. Li elenchi, li testi, li monitori.

Unknown unknowns (cigni neri che nessuno vede arrivare):

• Una pandemia globale che rende impossibile la formazione in presenza
• Una tecnologia che rende obsoleto quello che stai ottimizzando mentre lo ottimizzi
• Un cambio improvviso di leadership che stravolge tutte le priorità aziendali
• Un fornitore che cambia le sue API o le sue metriche di sostenibilità
• Una normativa che cambia le regole del gioco a metà percorso
• Una migrazione infrastrutturale non pianificata che azzera il tuo baseline

Questi non puoi mapparli. Non puoi validarli. Non puoi prevederli.

La domanda che può emergere da questa situazione è quindi “a cosa serva la ToC se la realtà la stravolge comunque?“

Serve eccome, ma non come si pensa. Non protegge dagli unknown unknowns (niente può farlo), ma rende resilienti quando emergono. Dà la struttura per adattarsi intelligentemente invece di andare in panico o insistere stupidamente sul piano originale.

La differenza è tutta lì. Un piano rigido ti dice “fai questo, poi quest’altro, poi quest’altro ancora” e quando arriva l’imprevisto sei bloccato. Una ToC ben costruita ti dice “vuoi arrivare qui, queste sono le condizioni necessarie, ora trova il modo migliore per crearle con le carte che hai in mano oggi.“

Impact vs Activities

Per comprendere meglio il concetto facciamo questo esercizio, dividiamo un foglio in due colonne:

FISSO (non negoziabile):

• Impact finale: “ie. Riduzione del 40% dell’impatto ambientale delle infrastrutture IT“
• Outcomes intermedi: “ie. Team che misura SCI per ogni servizio”, “Architettura che privilegia efficienza energetica”, “Decisioni di deployment basate su carbon intensity“

FLESSIBILE (negoziabile e adattabile):

• Activities: Workshop su Green Software, refactoring di servizi specifici, migrazione a cloud region a bassa carbon intensity
• Tools: quale strumento di misurazione, quale piattaforma cloud, quale framework
• Tempi specifici: quale mese fai cosa
• Ordine delle attività: cosa viene prima e cosa dopo
• Team allocation: chi lavora su quale pezzo

L’Impact è la stella polare. Le Activities sono le vele che aggiusti in base al vento.

Questa distinzione è TUTTO. Una ToC rigida sulle Activities è solo un piano tradizionale travestito con un nome “figo”. Una ToC che distingue chiaramente Impact/Outcomes (fissi) da Activities (flessibili) è una mappa navigabile quando arriva la tempesta.

Esempio concreto:

L’unknown unknown può farti cambiare le Activities. Non può (non dovrebbe) farti cambiare l’Impact. E se l’Impact stesso diventa irrilevante per l’unknown unknown… beh, quella è un’altra storia e ti serve una ToC nuova, non aggiustare quella vecchia.

Ma nella maggior parte dei casi, l’Impact resta valido. Cambiano le strade per arrivarci.

Strategie pratiche per l’antifragilità

Okay, abbiamo capito che la ToC non previene gli unknown unknowns. Come la si può usare per essere resiliente quando emergono?

1. Checkpoint time-boxed

La ToC non è una tavola di pietra scolpita sul Sinai. È un documento vivo che va revisionato regolarmente.

Ogni 3-6 mesi (e guarda caso, è esattamente il ritmo trimestrale degli OKR), fai una revisione esplicita:

• Quali assunzioni si sono rivelate false?
• Cosa è emerso che non avevamo previsto?
• L’Impact è ancora l’Impact che vogliamo?
• Gli Outcomes intermedi sono ancora quelli giusti?
• Serve cambiare le Activities?

Se si continua per 18 mesi dritto senza mai guardare la mappa, quando si scopre che si è completamente fuori strada si è troppo lontano per recuperare. I checkpoint frequenti permettono di correggere la rotta quando sei ancora abbastanza vicino (nb. gli agilisti lo dicono tipo da 20 anni).

Nel caso del team sulla sostenibilità digitale, abbiamo stabilito checkpoint trimestrali espliciti dove riunire tutti i stakeholder e chiedersi: “È ancora vero quello che pensavamo tre mesi fa? Cosa è cambiato? Dobbiamo aggiustare qualcosa?“

Questo ha permesso loro di adattare continuamente invece di arrivare al mese 18 e scoprire che avevano seguito fedelmente una mappa di un territorio che non esisteva più.

2. Health metrics

Oltre alle metriche standard della tua ToC (Input ? Output ? Outcome ? Impact), aggiungi delle health metrics (chiamate in alcuni testi anche Sentinel Metrics), come i canarini nelle miniere di carbone, ti avvisano quando qualcosa di anomalo sta emergendo.

Esempio progetto sostenibilità:

• Metriche ToC: “SCI medio per servizio”, “% di deployment su low-carbon infrastructure”, “riduzione emissioni totali”
• Health metrics: “varianza nei costi cloud mese su mese”, “frequency of infrastructure changes”, “time to deploy aumentato inspiegabilmente”, “developer satisfaction score”

Se una health metric si muove in modo strano, potrebbe essere un unknown unknown che sta emergendo. Non è ancora nella tua ToC, ma sta bussando alla porta.

Nel workshop è emerso dal gruppo che se si vede che i costi cloud iniziano a oscillare molto più del normale, potrebbe essere un segnale che il fornitore sta cambiando qualcosa. Allo stesso tempo se il time to deploy aumenta improvvisamente, forse ci sono friction che non erano state previste.

3. Optionality nei branch point

Invece di costruire un pathway lineare (“faccio A, poi B, poi C”), è opportuno definire dei fork esplicite nella ToC con validazioni che dicono quale strada prendere.

Schema tipo:

Mese 6: Team acquisisce competenze Green Software
  ?
Checkpoint: "L'architettura attuale permette ottimizzazioni significative?"
  ?? SE SÌ ? Refactoring incrementale dei servizi esistenti
  ?? SE NO ? Redesign architetturale prima di ottimizzare

Questo non previene l’unknown unknown, ma dà gradi di libertà quando emerge. Avere scenari alternativi, permette di analizzare il tema da diverse angolazione e di non doverli inventare sotto pressione.

Durante il workshop abbiamo identificato 3-4 fork critici nella loro ToC. “Se a questo checkpoint scopriamo X, facciamo Y. Se scopriamo Z, facciamo W.” Non va intesa come previsione, ma preparazione.

4. Diversity nel team di design della ToC

Più prospettive diverse, meno blind spots e quindi più possibilità di catturare i segnali deboli degli unknown unknowns prima che diventino problemi grossi.

Un team omogeneo (tutti developer, tutti dalla stessa funzione, tutti con lo stesso background) vede gli stessi unknowns. Un team eterogeneo (ruoli diversi, seniority diverse, esperienze diverse) vede più aspetti (Eventstorming, nella sua modalità Reverse Roadmapping, offre un formato molto utile per fare brainstorming).

Pratica concreta: quando si disegna una ToC su sostenibilità digitale (o qualsiasi altro tema), non bisogna coinvolgere solo i technical lead.

Invece è utile coinvolgere:

• Chi lavora operativamente sull’infrastruttura e vede i problemi veri
• Chi gestisce i costi e vede le variazioni economiche
• Chi fa procurement e sa cosa dicono i fornitori
• Qualcuno che ha visto progetti simili fallire altrove
• Un outsider (che reputato intelligente) che fa domande naive

Nel workshop in questione, chi ha fatto la domanda sugli unknown unknowns era junior. Ma proprio perché non aveva “investito” nella ToC iniziale, ha visto quello si stava dando per scontato.

5. Abduzione come antenna continua

L’abduzione non serve solo all’inizio per formulare l’ipotesi iniziale. Serve continuamente per catturare i segnali deboli.

Quando si osserva qualcosa di strano che non quadra con la tua ToC:

• Non bisogna forzarlo nella mappa esistente (“Beh, è un outlier, ignoriamo“)
• Non va ignorato (“Non è previsto, quindi non esiste“)
• Bisogna fermarsi e chiedere: “E se fosse il segnale di qualcosa che non avevo previsto?“

Gli unknown unknowns diventano known unknowns nel momento in cui si osserva il primo segnale debole. L’abduzione è l’antenna che permette di captarlo.

Esempio pratico dal workshop: uno degli engineer aveva notato che un servizio particolare consumava molto più del previsto dopo un’ottimizzazione. La prima reazione del team era “beh, è un caso particolare, andiamo avanti.” La reazione abduttiva: “E se fosse il segnale che il nostro approccio di ottimizzazione ha un effetto collaterale che non avevamo previsto?“

Hanno investigato. E hanno scoperto che l’ottimizzazione spostava il carico su un altro componente che loro non stavano monitorando. Unknown unknown diventato known unknown grazie all’abduzione su un segnale debole.

Un esempio pratico

Esempio pratico che tutti capiamo perché l’abbiamo vissuto.

Scenario: Gennaio 2020, costruisci una ToC formativa per “sviluppare competenze di teamwork attraverso workshop in presenza nei prossimi 18 mesi”. Backwards mapping fatto bene, assunzioni esplicitate, metriche multi-livello, tutto perfetto.

Unknown unknown: Marzo 2020, pandemia globale. Gli spazi fisici chiudono. Gli incontri in presenza diventano impossibili.

Come una ToC rigida sulle Activities fallisce: “Il nostro piano dice ’10 workshop in presenza da 2 giorni ciascuno’. Non possiamo farli. Blocchiamo tutto. Aspettiamo che finisca. O peggio: li facciamo comunque in presenza e ci ammaliamo tutti.”

Come una ToC flessibile sulle Activities naviga:

1. L’Impact resta valido: “Team che collaborano efficacemente” è ancora il goal, pandemia o no
2. Gli Outcomes restano validi: “Developer che si aiutano reciprocamente”, “Manager che supportano la collaborazione”
3. Le Activities cambiano completamente:
   • Da workshop in presenza ? mentoring remoto 1-1
   • Da esercizi di gruppo fisici ? pair programming online
   • Da retrospettive in stanza ? retrospettive async su Miro
4. Le assunzioni esplicitate ti fanno capire subito cosa è saltato: “Disponibilità di spazi fisici per 50 persone” era un’assunzione. Ora è falsa. Ok, cambio strada.
5. I checkpoint trimestrali ti fanno pivotare a Marzo 2020, non a Dicembre 2020: Se il tuo piano rigido dice “prima revisione tra 12 mesi”, arrivi a Gennaio 2021 e scopri di aver perso un anno. Se hai checkpoint ogni 3 mesi, a Giugno 2020 hai già cambiato tutto e stai andando avanti.
6. Le metriche di Outcome (non Output) ti dicono se stai ancora andando verso l’Impact: Non misuri “numero di workshop fatti” (Output, che è zero), misuri “frequenza di code review costruttive” (Outcome, che può essere alta anche in remoto). Se l’Outcome si muove, stai ancora andando verso l’Impact.

Se fosse stato solo un piano tradizionale “10 workshop in presenza, punto”, il progetto sarebbe rimasto bloccato per mesi. Con una ToC che distingue Impact da Activities, pivot e vai avanti.

E non è teoria: ho visto aziende fare esattamente questo durante COVID. Quelle con piani rigidi si sono fermate. Quelle con ToC flessibili hanno cambiato tutto e sono andate avanti.

Futures Cone e antifragilità

C’è un collegamento profondo con il Futures Cone che avevo già esplorato in un articolo precedente.

Il cono del futuro si allarga man mano che guardi lontano nel tempo. Perché? Perché ci sono sempre più unknowns. A 3 mesi vedi abbastanza chiaramente, a 24 mesi il cono è larghissimo perché le possibilità sono infinite.

La ToC definisce il tuo futuro preferibile, l’apice del cono, quello che vuoi costruire. Ma navighi dentro un cono che si allarga. Gli unknown unknowns non sono un bug del tuo metodo, sono nella natura del cono. Fanno parte del territorio.

E qui entra Nassim Taleb con il concetto di antifragilità: non puoi prevedere i cigni neri (unknown unknowns per definizione), ma puoi costruire sistemi che beneficiano dal disordine invece di esserne distrutti.

Una ToC antifragile ha queste caratteristiche:

• Distingue chiaramente cosa cambiare e cosa no quando arriva il cigno nero (Activities flessibili, Impact fisso)
• Ha optionality nei branch point, quindi hai alternative già pensate
• Ha checkpoint frequenti per adattarsi velocemente invece di scoprire il disastro troppo tardi
• Ha metriche multi-livello che ti dicono se sei ancora on track anche se il path è completamente cambiato
• Ha un team diversificato che vede più segnali deboli

Non è che la ToC ti protegge dagli unknown unknowns. È che la ToC ben costruita ti rende antifragile: quando l’unknown unknown emerge, hai la struttura per adattarti senza andare in panico.

Nel caso del team sulla sostenibilità digitale, l’antifragilità era avere chiari gli Outcomes (non solo le Activities), avere checkpoint trimestrali espliciti, avere sentinel metrics (varianza costi, developer satisfaction), e soprattutto avere la mentalità di “l‘Impact è fisso, tutto il resto è negoziabile.“

La mappa non è il territorio, ma senza mappa sei perso

Torniamo al workshop. Quel developer junior che ha fatto la domanda scomoda sugli unknown unknowns.

Alla fine delle due giornate, mi ha detto: “All’inizio pensavo che la ToC fosse un esercizio inutile. Tipo, costruiamo ‘sta mappa sapendo che tanto cambia tutto. Ma ho capito che senza mappa sono proprio perso quando cambia. Almeno con la ToC so dove voglio andare, anche se devo cambiare strada.“

Esattamente.

Le aziende che costruiscono ToC rigide sulle Activities falliscono quando arriva l’imprevisto. Si bloccano. Insistono sul piano anche quando è evidente che non funziona più. “Ma abbiamo già allocato il budget!” “Ma il contratto dice così!” “Ma il board ha approvato questo piano!”

Le aziende che costruiscono ToC flessibili sulle Activities ma ferme sull’Impact… quelle navigano i cigni neri. Quando arriva COVID, non si fermano, cambiano strada. Quando cambia una tecnologia, non insistono a ottimizzare quella vecchia, aggiornano le Activities mantenendo l’Outcome. Quando il fornitore cloud cambia le sue metriche, non aspettano mesi per “tornare al piano”, adattano il loro approach di misurazione.

La differenza tra le due non è fortuna. È metodo.

La ToC non è una profezia che predice il futuro. È una bussola che ti dice dove stai andando e ti permette di correggere la rotta quando il vento cambia.

E quando arriva la tempesta, e arriva sempre, fidatevi, preferisco avere una bussola che funziona piuttosto che una mappa perfetta di un territorio che non esiste più.

Gli unknown unknowns non si prevengono. Si navigano. E la Theory of Change, se costruita bene, è lo strumento che ti permette di farlo senza andare a sbattere o perderti completamente.

The post Theory of Change e unknown unknowns appeared first on Fullo.

Fastidioso? Sì. Ma soprattutto: era un segnale.

La sera stessa, mentre cercavo soluzioni, mi sono imbattuto in TOON (Tokens Optimization Oriented Notation). L’idea era brillante: un formato ottimizzato per gestire strutture dati ripetute nei prompt. Tipo quando devi passare liste di prodotti, cataloghi, database rows. TOON comprimeva questi pattern ripetitivi in modo sistematico, mantenendo la semantica intatta.

Nel mio caso, la situazione era ibrida: avevo le carte degli esercizi in JSON (strutture dati ripetute, perfette per TOON), più una serie di agenti che simulavano giocatori in diverse partite. Ogni partita generava un report, che veniva dato a un altro agente per analizzare cosa non funzionava.

TOON risolveva elegantemente il problema delle carte JSON. Ma gli agenti? Quelli avevano bisogno di istruzioni semantiche ripetute: “Simula un giocatore con esperienza X”, “Analizza il report cercando pattern Y”, “Genera feedback strutturato in formato Z”. Centinaia di caratteri di istruzioni che si ripetevano identiche (o quasi) ad ogni run.

Ma il principio era valido: se esiste un pattern replicabile, deve esistere un formato più efficiente.

La domanda diventa: quanto di questa prosa è effettivamente necessaria? E soprattutto: esiste un formato che mantenga la stessa qualità di output usando meno token?

Prima di buttarmi nell’esperimento, però, ho fatto i compiti a casa. Microsoft Research aveva pubblicato LLMLingua nel 2023, seguito da LLMLingua-2 nel 2024. Entrambi promettevano compressioni fino a 20× mantenendo performance. Il paper originale mostrava risultati impressionanti: compression ratios di 5-14× con degradazione minima su GPT-3.5 e Claude 1.3.

Il problema con LLMLingua? Richiedeva un piccolo modello ausiliario per la compressione, setup complessi, dipendenze Python, e – diciamocelo – chi ha tempo di integrare un’intera pipeline quando hai prompt da shippare domani? Serviva qualcosa di più immediato, manuale, pratico.

Quello che mi serviva era capire empiricamente dove stava il limite, senza algoritmi black-box. Esperimento diretto, vecchia scuola. Tre varianti dello stesso prompt, metriche chiare, e vedere dove crollava la qualità.

L’esperimento: tre livelli di compressione

Per rispondere in modo riproducibile, ho creato tre versioni dello stesso prompt. Task: scrivere un articolo di 1.000 parole sul libro “OKR The Right Way”. Non un task banale – doveva mantenere tono specifico, struttura narrativa, framework tecnici, e riferimenti bibliografici precisi. Il tipo di roba che faccio per i miei corsi, quindi sapevo esattamente cosa aspettarmi.

Variante 1: Natural Verbose (baseline)

Il prompt verbose seguiva le best practices di Anthropic: frasi complete, spiegazioni dettagliate, esempi inline, XML tags ben strutturati. Quello che trovi nella documentazione ufficiale.

Lunghezza: 2.100 caratteri
Output prodotto: 1.083 parole
Qualità: 9/10 secondo una scorecard che valutava completezza, tono, struttura e fedeltà alle istruzioni

Variante 2: Structured Optimal

Il prompt strutturato usava una notazione gerarchica con convenzioni sintattiche chiare:

• SECTION:value|modifier|context per la struttura
• Operatori simbolici (: assign, | separate, + AND, - exclude, ! negate)
• Parole inglesi complete per migliore tokenizzazione (ci torniamo dopo)
• Target quantitativi espliciti

Lunghezza: 800 caratteri (-62%)
Output: 1.013 parole
Qualità: 8.5/10

Il decremento di qualità era minimo: descrizioni leggermente meno elaborate, una citazione in meno (Sharon Bowman omessa ma il concetto “Training from the Back of the Room” preservato). Niente di critico.

Variante 3: Ultra-Minimal

Il prompt ultra-compresso spingeva l’abbreviazione al limite: acronimi aggressivi (PT:patient, DX:diagnosis), simboli matematici, rimozione di contesto esplicativo. Lunghezza: 380 caratteri (-82%).

Output: 578 parole
Problema critico: il prompt aveva richiesto esplicitamente “non meno di 1.000 parole”, ma l’output era del 42% più corto.

Ecco il cliff.

Il pattern: quando la compressione diventa lossy

I dati rivelano qualcosa che i paper accademici non enfatizzano abbastanza:

Da V1 a V2: -62% dimensione prompt, -6% qualità output = ROI eccellente
Da V2 a V3: -52% dimensione ulteriore, -40% qualità output = ROI pessimo

Esiste una soglia critica sotto la quale il modello inizia a interpretare male i requisiti. Per prompt complessi, questa soglia si colloca tra 500-600 caratteri. Sotto questo limite:

• I requisiti quantitativi vengono fraintesi o ignorati
• L’output diventa telegrafico invece che discorsivo
• La comprensibilità del prompt stesso crolla (anche per te, quando lo rileggi dopo tre settimane)

Il punto di diminishing returns è chiaro: la compressione ottimale si attesta al 60-70% della lunghezza originale.

Questo dato è coerente con quanto trovato dal research paper su prompt compression methods, che su dataset come LongBench e GSM8K ha mostrato compression ratios ottimali tra 2× e 5× (50-80% di riduzione). Sopra il 10×, anche LLMLingua-2 con tutta la sua sofisticazione inizia a soffrire.

Anatomia del formato ottimale

Analizzando cosa funziona nella Variante 2, emerge un pattern replicabile:

CATEGORY:value|modifier|context

La struttura gerarchica usa:

• Maiuscolo per sezioni (TONE, STRUCTURE, OUTPUT)
• Minuscolo per proprietà (conversational, expert)
• Operatori consistenti:
  • : per assegnazione
  • | per alternative o modificatori
  • + per operazioni AND
  • - per esclusioni
  • ! per negazioni
  • ? per trasformazioni

Esempio pratico (perché un esempio vale più di mille spiegazioni):

Verbose (247 caratteri):

You are a social media manager. Write engaging posts for LinkedIn. 
Keep them professional but not boring. Use emojis sparingly. 
Each post should be 100-150 words. Focus on B2B tech industry.
Avoid jargon and corporate speak.

Structured Optimal (97 caratteri, -61%):

SOCIAL_MEDIA:LinkedIn|B2B_tech
TONE:professional+engaging-boring|emojis_sparse
LENGTH:100-150_words|EXPLICIT_TARGET
AVOID:jargon|corporate_speak

La semantica è identica, la compressione del 61% rientra perfettamente nel sweet spot, e il formato resta “at a glance” leggibile. Non serve un dottorato per capire cosa fa.

Il prompt converter: quando il meta diventa pratico

Se il formato ottimale è replicabile, può essere automatizzato? La risposta è stata creare un “prompt converter”: un meta-prompt che trasforma prompt verbose in formato strutturato ottimale.

Il converter iniziale era lungo 1.470 caratteri e conteneva:

• Regole di conversione dettagliate
• Esempi di convenzioni sintattiche
• Lista di cosa preservare e cosa rimuovere
• Formato output atteso

Poi mi sono chiesto: e se applico il converter a se stesso? Un sistema di ottimizzazione che si auto-ottimizza dovrebbe convergere a un punto fisso o divergere caoticamente. Tipo il barber paradox, ma con più token e meno filosofia.

Risultati dell’auto-applicazione (o: scoprire i punti fissi empiricamente)

Iterazione 0 (verbose): 1.470 caratteri
Iterazione 1 (compressione manuale): 485 caratteri (-67.0%)
Iterazione 2 (auto-compressione): 478 caratteri (-67.5%)
Iterazione 3 (stimata): 475 caratteri (-67.7%)

Il sistema converge. Ogni iterazione produce miglioramento decrescente:

• Iter 1?2: -7 chars (-1.4%)
• Iter 2?3: -3 chars (-0.6% stimato)
• Iter 3?4: -1 char (-0.2% stimato)

Il punto fisso si trova intorno ai 475 caratteri. Ulteriori iterazioni producono miglioramenti inferiori all’1%.

L’auto-applicazione non ha solo compresso, ma ha fatto refactoring intelligente:

• Eliminazione ridondanze non evidenti al designer umano
• Riorganizzazione logica delle sezioni
• Esplicitazione di impliciti (risk_notes ? risk_notes|if_semantic_ambiguity)

Il converter ha dimostrato di “capire” le proprie regole e applicarle coerentemente anche a se stesso. Questo è un indicatore forte di design auto-consistente. E anche, ammetto, piuttosto soddisfacente da vedere.

Perché funziona: tokenizzazione e prior (la parte nerd ma importante)

Il formato structured optimal funziona meglio del previsto per due ragioni tecniche che vale la pena capire:

1. Tokenizzazione efficiente

I tokenizer basati su Byte Pair Encoding (BPE), che è quello che usano GPT, Claude, e praticamente tutti i modelli transformer moderni, sono ottimizzati per parole inglesi comuni. Le abbreviazioni ultra-compresse possono paradossalmente consumare più token:

"TONE:conv+exp-acad" ? ["TONE", ":", "conv", "+", "exp", "-", "ac", "ad"] = 8 tokens
"TONE:conversational+expert-academic" ? ["TONE", ":", "conversational", "expert", "academic"] = 5 tokens

L’uso di parole complete è controintuitivamente più efficiente. Questo è documentato anche nella ricerca di Anthropic sul prompt engineering, dove suggeriscono di evitare abbreviazioni eccessive proprio per questo motivo.

2. Prior nel training

I Large Language Models hanno visto durante il training:

• File di configurazione (YAML, TOML, JSON)
• Code annotations e docstrings
• Notazioni matematiche e linguistiche
• Markup languages strutturati

Questo significa che Claude (e GPT) hanno un prior forte per notazioni strutturate gerarchiche. Il formato non è “alieno”, è familiare al modello da milioni di esempi di training. È come parlare a qualcuno nella sua lingua madre invece che con gesti.

Applicazioni pratiche

Use case 1: Template library aziendale

Un’azienda con 50+ prompt standardizzati per vari task (code review, documentazione tecnica, customer support, content creation) può:

1. Convertire tutti i prompt in formato strutturato
2. Ridurre costi API del 60-70% per ogni chiamata
3. Rendere i prompt più facili da versioning (diff più chiari)
4. Facilitare modifiche parametriche (cambiare un valore in una struttura è più semplice che riscrivere frasi)

ROI reale: se un’azienda fa 10.000 chiamate API/mese con prompt da 2.000 caratteri, la riduzione del 65% porta a ~1.3M caratteri risparmiati/mese. In token (stima ~4 char/token) sono ~325k token/mese. A $0.003/1k tokens (input Claude Sonnet), il risparmio è ~$1/mese per prompt. Con 50 prompt diversi: ~$50/mese, $600/anno.

Il breakeven è quasi immediato se i prompt sono usati frequentemente. Non diventerete ricchi, ma neanche è aria fritta.

Use case 2: Rapid prototyping

Durante lo sviluppo di nuove applicazioni AI, i prompt vengono iterati decine di volte. Il formato strutturato permette modifiche chirurgiche:

TONE:formal ? TONE:casual
LENGTH:500_words ? LENGTH:200_words
INCLUDE:examples ? INCLUDE:examples|code_snippets

Invece di riscrivere paragrafi interi, si modificano valori precisi. Questo accelera sperimentazione e A/B testing. Ho risparmiato ore durante lo sviluppo del converter stesso proprio per questo.

Use case 3: Chain-of-thought compression

Per applicazioni che usano chain-of-thought o multi-step reasoning, ogni step ha il suo prompt. Se una pipeline ha 5 step con prompt da 1.500 caratteri ciascuno (7.500 totali), la compressione al 35% porta a 2.625 caratteri totali.

In contesti dove il budget token è limitato – tipo quando lavori con context window pieni o devi stare sotto certi limiti di latency – questo può fare la differenza tra una pipeline che funziona e una che esplode i limiti.

Il paper di ricerca su prompt compression ha dimostrato che LLMLingua-2 riduce inference time del 3-6× proprio grazie a prompt più corti. Il principio è lo stesso, solo che qui lo facciamo manualmente con risultati più prevedibili.

Use case 4: Embedded systems

Per applicazioni edge o embedded che comunicano con LLM, la dimensione del prompt trasmesso su rete conta. Un device IoT che manda telemetria con prompt di istruzioni, o un’app mobile che deve minimizzare payload, beneficia direttamente dalla compressione senza perdita qualitativa.

Non è il caso d’uso più comune, ma quando serve, serve davvero.

Limiti e controindicazioni (perché l’onestà paga sempre)

Il formato strutturato non è universalmente superiore. Ci sono casi dove NON dovresti usarlo:

Quando NON usarlo

Documenti legali o medici: La precisione assoluta richiede linguaggio naturale completo e non ambiguo. Ogni parola può avere peso legale. Il risparmio di token non vale il rischio di ambiguità semantica. Seriamente, non fatelo.

First-time learning: Se un team sta imparando a usare prompt engineering, il formato verbose con spiegazioni estese è didatticamente superiore. Il formato strutturato richiede comprensione delle convenzioni. Insegna con il verbose, ottimizza con lo structured.

Prompt one-shot rarissimi: Se un prompt viene usato una volta sola, il tempo di conversione (10-15 minuti) non vale il risparmio di token di una singola chiamata. Economics 101.

Task creativi molto aperti: Quando serve massima espressività e sfumature emotive/tonali complesse, il linguaggio naturale offre più granularità. Il formato strutturato eccelle per task tecnici con requisiti chiari, non per scrivere poesia.

Il trade-off documentazione

Un prompt strutturato da 500 caratteri è meno auto-documentante di uno verbose da 1.500. Per sistemi condivisi tra team, serve:

• Documentazione separata che spiega le convenzioni
• Changelog delle modifiche
• Esempi di utilizzo

Questo overhead organizzativo va considerato nel ROI totale. Non è gratis, anche se i token lo sono di più.

Il caso particolare: image generation prompts

Mentre preparavo l’immagine di copertina per questo articolo, ho fatto una scoperta meta-ironica: i principi di compressione ottimale per text LLM non si applicano agli image generators.

Ho testato tre versioni del prompt per generare una cover in stile Commodore 64 pixel art:

1. Structured Optimal (1.456 chars): notazione gerarchica come nell’articolo
2. Natural Efficient (589 chars): linguaggio naturale scorrevole
3. Ultra-Minimal (187 chars): abbreviazioni aggressive

Risultato? La Version 2 (natural efficient) ha prodotto i risultati migliori con DALL-E e Midjourney. La notazione strutturata ultra-ottimizzata confondeva i modelli – probabilmente perché il loro training set include principalmente descrizioni in linguaggio naturale, non notazioni tecniche strutturate.

STRUCTURED: "COMPOSITION:split_screen|before_after LEFT_SIDE:verbose_text_wall|..."
? Confuso, interpretazione literale delle pipe e dei due punti

NATURAL: "Split screen composition: left side shows verbose text..."
? Perfetto, interpreta correttamente la scena

Takeaway: I principi di compressione sono domain-specific. Per text instruction prompts (Claude, GPT), la notazione strutturata è ottimale. Per image generation prompts, il linguaggio naturale scorrevole ma conciso rimane superiore.

Questo ha senso: i text LLM devono processare istruzioni complesse e lunghe chain-of-thought, dove la struttura aiuta. Gli image generators devono tradurre descrizioni visive, dove la fluidità narrativa è più importante della compressione estrema.

Una lezione nell’umiltà: non esiste un formato universalmente ottimale. Il contesto conta sempre.

Convergenza e punti fissi

L’esperimento di auto-applicazione ha rivelato una proprietà interessante: il sistema converge a un punto fisso. Non è magia, è information theory.

Per un task generico di “prompt optimization” con regole complete, il punto fisso è ~475 caratteri. Questo non è arbitrario: rappresenta il minimo informazionale necessario per codificare:

• Ruolo e obiettivo (50 char)
• Regole di trasformazione (150 char)
• Convenzioni sintattiche (100 char)
• Output atteso (75 char)
• Constraints (100 char)

Sotto questa soglia, la perdita semantica inizia. Sopra questa soglia, c’è ridondanza estraibile.

La velocità di convergenza segue una legge esponenziale decrescente: ogni iterazione riduce il miglioramento del ~60%. Questo suggerisce che 2-3 iterazioni sono sufficienti per raggiungere il 95% dell’ottimizzazione possibile.

Questo pattern è consistente con quanto Claude Shannon aveva già teorizzato negli anni ’40 sulla compressione ottimale: esiste un limite teorico oltre il quale stai comprimendo rumore invece che ridondanza. Un ottimo articolo sul tema collega Shannon information theory ai modern LLM prompts in modo molto chiaro.

Pattern replicabili

Dall’esperimento emergono pattern generalizzabili che puoi usare da domani:

Pattern 1: Gerarchia esplicita

TOP_LEVEL:
  sub_property:value
  another_property:value|modifier

Meglio di strutture piatte o implicite. I modelli “capiscono” la gerarchia.

Pattern 2: Operatori consistenti

Non inventare sintassi custom ogni volta. Usa convenzioni riconoscibili:

• : per “è”
• | per “oppure/o anche”
• + per “e”
• - per “ma non”
• ! per “negazione/assenza”
• ? per “diventa/trasforma in”

La consistenza conta più della perfezione teorica.

Pattern 3: Target espliciti

BAD:  OUTPUT:long_article
GOOD: OUTPUT:1500-2000_words|EXPLICIT_TARGET

I numeri non vanno mai compressi o approssimati. Questo l’ho imparato nel modo difficile con la Variante 3.

Pattern 4: Liste brackettate

CHECKS:[SQL_injection|XSS|CSRF|authentication|authorization]

Invece di elenchi puntati in prosa. Più compatto, più chiaro.

Pattern 5: Negazioni su antipattern

AVOID:!input_validation|!error_handling|hardcoded_credentials

Il ! davanti indica “mancanza da evitare” vs “presenza da evitare”. Subtle ma importante.

Direzioni future

Questo esperimento apre diverse direzioni che mi piacerebbe esplorare:

1. Domain-specific compression dictionaries

Per domini specifici (medical, legal, finance), creare dizionari di abbreviazioni standard. Esempio medicina:

PT:patient|SX:symptoms|DX:diagnosis|TX:treatment

Con glossario condiviso, la compressione può raggiungere 80% mantenendo precisione. Servirebbero però esperti del dominio per validare.

2. Hybrid prompting

Sezioni critiche verbose + sezioni tecniche strutturate:

CONTEXT: [prosa naturale con sfumature importanti]

TECHNICAL_SPECS:
  format:JSON
  fields:[name|age|diagnosis|treatment_plan]
  validation:strict_schema

Best of both worlds. Sto testando questo approccio su alcuni progetti e sembra promettente.

3. Prompt compilation

Tool che prendono prompt verbose con annotazioni e compilano automaticamente in formato ottimale, simile a compilatori per linguaggi di programmazione:

# @target: structured-optimal
# @compression: 65%
# @preserve: examples, tone_markers

You are a code reviewer...
[resto del prompt verbose]

Output compilato automaticamente con metriche e warning. Tipo TypeScript per prompts.

4. Adaptive compression

Sistema che monitora quality metrics degli output e adatta dinamicamente il livello di compressione:

• Se quality score > 0.95: aumenta compressione del 5%
• Se quality score < 0.85: riduci compressione del 5%

Trova automaticamente il punto ottimale per ogni task. Questo richiederebbe però un feedback loop robusto, che non è banale da implementare.

Conclusioni empiriche

I dati raccolti permettono conclusioni quantitative:

1. Esiste un sweet spot: 60-70% di compressione con <10% perdita qualitativa
2. Il cliff è reale: Sotto il 30% della lunghezza originale, la qualità crolla >40%
3. Convergenza prevedibile: Auto-ottimizzazione converge in 2-3 iterazioni
4. ROI immediato: Per prompt usati >10 volte, il breakeven è garantito
5. Formato stabile: Structured English Notation è ottimale per tokenizer BPE

Il linguaggio naturale verbose ha circa 65% di ridondanza quando usato per istruzioni tecniche a LLM. Quella ridondanza è utile per umani (chiarezza, documentazione, insegnamento) ma costosa per macchine.

Il formato strutturato ottimale non è un metalinguaggio esoterico, ma una notazione familiare ai modelli dal training. È leggibile dagli umani “at a glance” e processabile efficientemente dalle macchine.

La compressione non è solo risparmio economico, ma design migliore: prompt più chiari, modificabili, versioning più facile, meno ambiguità. Il constraint di spazio forza precisione. Come diceva Antoine de Saint-Exupéry: “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.”

Solo che lui parlava di aerei e io di prompt. Ma il principio regge.

Riferimenti e letture consigliate

Per approfondire il tema della prompt compression e le tecniche correlate:

• LLMLingua & LLMLingua-2 (Microsoft Research): Paper originale su compression methods e articolo tecnico su LLMLingua-2
• Anthropic Prompt Engineering Guide: Documentazione ufficiale con best practices e prompt improver
• Claude Shannon e information theory applicata a LLM: Ottimo articolo divulgativo
• PromptHub research: Analisi pratica su risparmio costi

Materiali e riproducibilità

L’esperimento completo include:

• Tre varianti di prompt con metriche comparative
• Output generati da ciascuna variante
• Scorecard di valutazione qualitativa
• Prompt converter auto-applicato con traccia di convergenza
• Test su prompt reali (code review, social media, technical writing)

Il formato structured optimal proposto non è proprietario o brevettato – è una convenzione aperta che chiunque può adottare e adattare.

Il converter è disponibile su GitHub per sperimentazione.

Chi volesse replicare può iniziare con un singolo prompt ad alto utilizzo, convertirlo manualmente seguendo i pattern descritti, testare side-by-side con la versione verbose, e misurare il delta qualitativo e il risparmio token.

La matematica della compressione, in questo caso, non mente: c’è un punto di equilibrio reale, misurabile, replicabile. E quel punto si trova molto più in là di quanto la maggior parte dei praticanti attualmente utilizzi.

Note: Questo articolo è basato su test empirici condotti con Claude Sonnet 4.5 nel novembre 2025. I risultati specifici (percentuali, punti fissi) possono variare con altri modelli o versioni future, ma i principi generali (esistenza di un sweet spot, legge dei diminishing returns, convergenza) dovrebbero mantenersi validi per architetture transformer-based con tokenizer BPE

The post La matematica della compressione dei Prompt per LLM appeared first on Fullo.

La prima domanda che mi fanno, dopo i convenevoli di rito: “Quali corsi ci consigli fare? Possiamo vedere insieme un catalogo di formazione su trasformazione digitale?“

E lì mi siccome ultimamente sono in fissa con la ToC mi si accende la lampadina. Non quella delle buone idee, quella che mi suggerisce di fare esperimenti.

Perché dietro quella domanda apparentemente innocente si nasconde un assunto pericoloso: stanno pensando alla formazione come a un acquisto su Amazon. Scorri il catalogo, aggiungi al carrello “Agile Mindset”, “Digital Leadership”, magari “Data-Driven Decision Making” tanto per non farsi mancare nulla, e checkout.

Manca completamente la logica che collega quei corsi al futuro che vogliono costruire. È come se qualcuno ti chiedesse: “Voglio ristrutturare casa, quali attrezzi mi consigli?” senza prima chiedersi “Che tipo di casa voglio quando finisco?” Magari stai comprando un martello pneumatico quando in realtà ti serve una spatola per cartongesso.

Ecco, la connessione che mi è venuta in mente in quel momento è che la Theory of Change non serve solo per progetti sociali o di sostenibilità. Può anche essere molto utile per progettare percorsi formativi che abbiano senso.

Gli ho risposto: “Non vi serve un catalogo. Vi serve una mappa.“

La formazione vista come una spesa, non un investimento

Il problema è più o meno questo, le aziende hanno:

• Una mission chiara (almeno sulla carta): “Vogliamo diventare leader nel nostro settore“, “Vogliamo innovare il nostro modello di business“, “Vogliamo essere data-driven“
• Un budget formazione allocato: tot euro l’anno per “sviluppo risorse umane“
• Una lista di corsi: leadership, agile, cloud, AI, soft skills varie ed eventuali

Quello che manca è il pezzo nel mezzo: la logica causale che spiega come quei corsi dovrebbero portare a quella mission. È un salto nel vuoto travestito da pianificazione.

Il risultato? La formazione viene vissuta come un costo da giustificare (“tutti fanno questa formazione, quindi la facciamo anche noi“, che mi risuona tanto quanto “se si buttano tutti ad un ponte li seguiamo a ruota” ), non come un investimento strategico. Alla fine dell’anno guardi i numeri: “Abbiamo formato 150 persone su temi digitali!” Fantastico. E poi? Siete più data-driven? “Beh, speriamo.”

Sperare non è una strategia.

Quando inizio a fare le domande scomode, il tipo di domande che uso sempre nei miei workshop sugli OKR, succede una cosa interessante:

F: “Supponiamo di aver raggiunto il vostro obiettivo tra 24 mesi: come fai a sapere che la formazione ha contribuito?“

Silenzio.

F: “Quali competenze specifiche devono esistere perché quella trasformazione si realizzi davvero?“

A: “Beh… competenze digitali?“

F: “Okay, ma quali? E in chi? E perché proprio quelle? Che causalità c’è tra un corso di Python e il vostro obiettivo di essere più innovativi?“

A: “Beh… Python serve sempre, no?“

Ecco il problema. Non è che le risposte siano sbagliate, è che non ci sono proprio. Nessuno si è fermato a chiedersi: cosa deve succedere, passo dopo passo, perché il futuro che immaginiamo diventi reale? E quali competenze abilitano ogni passaggio?

E se costruissimo una mappa a ritroso?

La Theory of Change (ToC) è nata negli anni ’90 nel settore nonprofit per rispondere a una domanda semplice ma brutale: “Come fai a sapere se il tuo progetto (sociale) funziona?” Non “hai fatto le attività?” ma “stai davvero creando il cambiamento che volevi?”

Il principio base è controintuitivo ma potente: backwards mapping. Invece di partire da “cosa facciamo oggi” e sperare di arrivare da qualche parte, la ToC ti fa partire dal goal finale che vuoi raggiungere e poi, passo dopo passo, ti chiedi: “Cosa deve accadere immediatamente prima perché questo si realizzi?”

Quando ho passato sei mesi con quasi 1000 bambini pensando di insegnargli a programmare, in realtà stavo costruendo una Theory of Change educativa. Il mio goal a lungo termine era “formare future persone raziocinanti”, non “futuri developer”. E ho lavorato all’indietro: perché questo accada, devono aver sperimentato che sbagliare non è catastrofico, devono aver visto altri sbagliare e imparare, devono aver avuto feedback immediato. E per creare queste condizioni? Giochi dove il fallimento è parte delle regole, robot che danno feedback inequivocabile, gruppi dove tutti vedono tutti.

Era una ToC anche quella, solo applicata all’apprendimento invece che ad altri tipi di progetti a lungo termine.

E lì mi è scattato qualcosa. Se la ToC funziona per mappare percorsi educativi con bambini, perché non dovrebbe funzionare per progettare formazione aziendale? Dopotutto, in entrambi i casi stai cercando di creare competenze che non esistono ancora per abilitare un futuro che vuoi costruire.

La connessione è diretta: la ToC è lo strumento perfetto per progettare percorsi formativi perché:

• Parte dal futuro desiderato (la tua mission/vision aziendale)
• Identifica le precondizioni necessarie per arrivarci (incluse le competenze)
• Esplicita le assunzioni che stai facendo (e che devi validare)
• Crea indicatori per ogni livello, così sai se stai andando nella direzione giusta

Non è magia. È solo onestà intellettuale applicata alla pianificazione.

Un esempio concreto

Facciamo un esempio pratico, perché la teoria senza pratica è solo aria fritta.

Immaginiamo un’azienda manifatturiera che vuole “diventare data-driven nei prossimi 24 mesi” e facciamo backwards mapping.

Long-term goal (24 mesi): Le decisioni strategiche sono basate su analisi di dati quantitativi, non solo su “esperienza” o “sensazione”.

Bene. Ora torniamo indietro. Cosa deve accadere immediatamente prima perché questo goal si realizzi?

18 mesi: I manager sanno interpretare dashboard e KPI senza chiedere aiuto. Guardano i numeri e capiscono cosa significano, cosa fare.

E prima ancora?

12 mesi: I team operativi producono dati puliti e affidabili. Non più Excel sballati o metriche inventate sul momento.

E prima?

9 mesi: Esiste una cultura della misurazione. La gente ha smesso di dire “secondo me” e ha iniziato a dire “secondo i dati”. Perché ha capito che misurare aiuta, non rompe.

E prima?

6 mesi: Il team ha acquisito sia competenze tecniche (SQL, BI tools, data visualization) sia competenze concettuali (quali metriche contano, come evitare vanity metrics, come leggere la causalità).

E prima ancora?

3 mesi: Partono i percorsi formativi specifici: workshop su KPI e metriche actionable, corsi su tool di BI, sessioni pratiche su data literacy.

E cosa serve oggi, per far partire tutto questo?

Oggi: Budget allocato, executive sponsor che ci crede davvero, tempo protetto per la formazione (non “fallo quando hai tempo”), scelta di formatori che conoscono il dominio, non solo i tool.

Ecco il tuo pathway of change. Ogni step è un’ipotesi causale: “Se accade X, allora può accadere Y”. Ma sono ipotesi esplicite, non speranze implicite.

Ora viene la parte interessante: le assunzioni critiche da validare.

Perché tutto questo pathway si regga, alcune cose devono essere vere:

• I manager vogliono davvero decidere con i dati, o preferiscono l’intuito e stanno solo facendo finta?
• L’infrastruttura tecnica esiste o va costruita da zero?
• Il budget è stabile o a rischio al primo trimestre negativo?
• Il C-level supporta davvero questo cambio culturale o è solo l’ennesima slide powerpoint?
• I formatori che sceglieremo sanno tradurre concetti astratti in azioni concrete per il nostro dominio?
• Le persone hanno tempo/spazio per applicare quello che imparano?
• La cultura aziendale supporta il cambiamento o lo ostacola sottilmente?

Se anche una sola di queste assunzioni è falsa, tutta la tua Theory of Change crolla. Ed è meglio scoprirlo prima di investire 50k€ in formazione.

Come le validi? Piccoli test. Interviste. Pilot. Non lanci tutto subito, testi le assunzioni una per una. Esattamente come farebbe una startup con un MVP, ma applicato alla formazione.

Questo approccio ti dice anche quali corsi NON servono. Se nel tuo pathway non c’è “competenze avanzate di machine learning”, forse quel corso fighissimo su AI e neural networks può aspettare. Può sembrare figo nel catalogo, ma non ti avvicina al tuo goal. È noise, non signal.

Impact Pathway Formativo

A questo punto qualcuno potrebbe dire: “Okay Fullo, bello il discorso, ma nella pratica come lo strutturi?”

Qui entra in gioco il framework classico della ToC, che possiamo adattare alla formazione. Non è rocket science, è solo un modo strutturato per pensare ai livelli del cambiamento. Prendiamo la tabella standard e la traduciamo in linguaggio per la formazione:

Impact – L’effetto a lungo termine che la formazione contribuisce a generare.
Esempio: “Team che iterano velocemente senza paura di fallire, esattamente come i bambini con cui ho lavorato che hanno capito che sbagliare è parte del processo.”

Outcome – I risultati intermedi che rendono possibile l’impatto finale.
Esempio: “Developer che fanno code review costruttive”, “Manager che prendono decisioni basate su dati”

Output – I risultati diretti delle attività formative.
Esempio: “20 developer formati su tecniche di peer review efficace”, “15 manager che sanno leggere e costruire dashboard”

Activities – Le attività concrete di apprendimento.
Esempio: “Workshop da 2 giorni su feedback efficace con sessioni pratiche”, “Corso online + mentoring 1-1 su SQL e BI tools”

Inputs – Le risorse necessarie per abilitare le attività.
Esempio: “Budget 30k€”, “2 facilitatori esterni + 1 mentor interno”, “Tempo: 3 mezze giornate a trimestre per 6 mesi”

Ogni livello è un’ipotesi causale da validare. Non è una lista di buone intenzioni, è una catena logica dove ogni anello deve reggere.

La potenza di questo approccio è che ti costringe a pensare a più livelli di misurazione. Non solo “quante persone abbiamo formato” (Output), ma anche “stanno applicando quello che hanno imparato?” (Outcome) e “stiamo vedendo il cambiamento organizzativo che volevamo?” (Impact).

E se a un livello le cose non funzionano, sai esattamente dove intervenire. Se l’Output è buono (tanta gente formata) ma l’Outcome è scarso (nessuno applica), il problema non è il numero di corsi, è il trasferimento dalla teoria alla pratica. Magari serve più mentoring, o rimuovere barriere organizzative, o cambiare approccio didattico.

Senza questa struttura, fai tutto insieme in un unico calderone e quando le cose non funzionano non sai dove guardare. “La formazione non ha funzionato” è un’informazione inutile. “L’Output era buono ma l’Outcome no perché le persone non avevano tempo di applicare” è un’informazione actionable.

Collegamenti

In anni di lavoro, ho appreso (anche e soprattutto da errori) che le aziende vogliono risultati ma non sempre hanno un metodo per costruire il percorso. E ho capito che servono più pezzi del puzzle, non uno solo.

Prima c’è l’abduzione: prima ancora di fare backwards mapping, serve l’intuizione creativa. Serve l’abduzione: formulare ipotesi nuove per spiegare fatti inspiegabili. “I manager non applicano quello che imparano nei corsi di leadership” ? e se il vero problema non fosse il corso, ma il fatto che non hanno tempo per sperimentare? O che la cultura aziendale punisce chi sbaglia? Quella scintilla abduttiva è ciò che precede la ToC.

Poi i Futures Cone: il long-term goal della tua ToC non è una previsione, è una scelta. Ed è esattamente quello che ho spiegato nell’articolo su Futures Cone e OKR. Il futuro non è un punto fisso ma un cono di possibilità che si allarga nel tempo: Possibili, Plausibili, Probabili, Preferibili. Quando costruisci una ToC formativa, stai definendo il tuo futuro preferibile. Non stai prevedendo cosa succederà, stai scegliendo quale futuro costruire attraverso le competenze che sviluppi. La formazione è il modo per ridurre il cono dell’incertezza, passando dal “possibile” al “probabile” al “realizziamo questo, dannazione”.

Infine gli OKR: una volta costruita la tua Theory of Change formativa, come la metti in pratica? Come la misuri? Gli OKR diventano il sistema operativo della tua ToC. Ogni outcome intermedio diventa un potenziale Objective, ogni indicatore diventa un Key Result per validare se quell’outcome si sta realizzando, ogni attività formativa diventa un’Initiative che contribuisce a muovere quei KR.

Come ho spiegato nell’articolo su Theory of Change ed editoria, dove ho raccontato come i miei tre libri sono nati da una ToC personale:

• KPI, the right way ? Per sapere se stai misurando le competenze in modo corretto
• OKR, the right way ? Per strutturare percorsi formativi in obiettivi validabili e interconnessi
• Sustainable IT, the practical way ? Per applicare tutto questo a un dominio specifico (le competenze per il Green Software)

Tutti e tre seguono la stessa logica: backwards mapping da un futuro desiderato, poi validazione iterativa delle assunzioni. La ToC era la mappa, gli OKR sono stati il sistema di navigazione.

E qui c’è anche il collegamento con Alex Osterwalder e The Invincible Company: exploration (sviluppare nuove competenze per nuovi business model) vs exploitation (ottimizzare competenze esistenti). La ToC ti dice quali competenze esplorare basandoti sulla logica causale verso il tuo futuro preferibile, non sul catalogo del momento o su cosa va di moda su LinkedIn.

La Theory of Change ti obbliga a fare il lavoro duro: definire il futuro, mappare il percorso, esplicitare le assunzioni, validarle una per una. Non è facile come sfogliare un catalogo, ma è l’unico modo per non sprecare budget formazione in corsi che non portano da nessuna parte.

Come iniziare lunedì mattina

Come applichi questo approccio nella tua azienda, a partire da lunedì?

Step 1: Identifica il long-term goal specifico

Non “vogliamo innovare” che non significa niente. Ma “vogliamo lanciare 3 prodotti validati dal mercato entro 18 mesi” o “vogliamo ridurre del 30% il time-to-market per nuove feature entro 12 mesi” o “vogliamo che l’80% delle decisioni strategiche sia supportato da dati entro 24 mesi”.

Specifico. Misurabile. Temporizzato.

Step 2: Backwards mapping delle competenze

Prendi una lavagna (fisica o Miro) e inizia a lavorare a ritroso: “Perché questo goal si realizzi, cosa deve essere vero? Quali capacità devono esistere?”

Non fermarti alle competenze tecniche. Includi quelle comportamentali (spirito critico, capacità di iterare, psychological safety) e strategiche (pensiero sistemico, causalità, capacità di leggere segnali deboli).

Continua a tornare indietro finché non arrivi a “cosa possiamo iniziare a fare oggi”.

Step 3: Esplicita e valida le assunzioni

Per ogni passaggio del tuo pathway, chiediti: “Cosa deve essere vero perché questo funzioni?”

Scrivi le assunzioni nero su bianco. Poi vai a validarle prima di comprare corsi. Interviste, sondaggi, pilot, piccoli esperimenti. Non assumere, verifica.

Step 4: Costruisci indicatori multi-livello

Non accontentarti di “numero di persone formate” o “ore di formazione erogate”. Sono vanity metrics che non ti dicono se stai davvero creando cambiamento.

Definisci indicatori a ogni livello:

• Input: Budget speso, tempo allocato, risorse utilizzate
• Output: Persone formate, moduli completati, certificazioni ottenute
• Outcome: Comportamenti cambiati, nuove pratiche adottate, decisioni prese diversamente
• Impact: Risultati di business, metriche strategiche mosse, goal raggiunti

Gli ultimi due sono quelli che contano davvero.

Step 5: Collegalo agli OKR

Ogni outcome intermedio del tuo pathway può diventare un Objective con Key Results misurabili.

Esempio:

• Objective: “I team prendono decisioni basate su dati quantitativi”
• KR1: 70% delle decisioni in sprint planning supportate da metriche (misurato in retrospettiva)
• KR2: Riduzione del 30% del tempo speso in discussioni basate su opinioni vs dati
• KR3: Per l’80% di quesiti senza dati viene sviluppato un sistema di A/B testing per validare l’idea

Le tue iniziative formative diventano il modo per muovere quei KR.

Barriere tipiche (e come affrontarle)

“Non abbiamo tempo per questo processo”

Risposta: Non avete tempo di NON farlo. Quante ore avete sprecato in formazione che non ha portato da nessuna parte? Una settimana investita bene in ToC vi fa risparmiare mesi di corsi inutili.

“Troppo complesso, vogliamo solo fare formazione”

Risposta: Fare formazione senza strategia è come guidare senza mappa. Puoi andare veloce, ma in direzioni casuali. Preferisco andare nella direzione giusta, anche se significa rallentare all’inizio.

“Il budget formazione è già allocato per quest’anno”

Risposta: Perfetto. Usa la ToC per validare se quei corsi già allocati contribuiscono al tuo futuro preferibile. Spoiler: probabilmente scoprirai che alcuni sì, altri no. Per quelli che non contribuiscono, rinegozia o ri-alloca l’anno prossimo. Almeno sai dove mettere i soldi.

Investire sul futuro, non comprare dal catalogo

Torniamo all’inizio. “Avete un catalogo?”

No, non ho un catalogo. Ho una metodologia per costruire la mappa che ti serve per arrivare dove vuoi andare.

La formazione aziendale non è un costo da ottimizzare o un benefit per tenere felici i dipendenti. È l’investimento più strategico che puoi fare, perché costruisce le precondizioni per il futuro che vuoi. Ma solo se lo fai bene.

E “farlo bene” significa:

• Partire dal futuro che vuoi costruire, non dal presente che vuoi migliorare
• Lavorare a ritroso per identificare le competenze necessarie
• Esplicitare le assunzioni e validarle, una per una
• Misurare a ogni livello, non solo quante persone hai formato
• Collegare tutto a una logica causale verificabile, non a speranze implicite

Questo richiede più lavoro upfront. Richiede onestà intellettuale. Richiede ammettere “non lo so” invece di comprare il primo corso che sembra figo. Richiede pazienza, perché i risultati veri si vedono nel medio-lungo termine.

Ma l’alternativa è continuare a fare shopping da catalogo, sperando che magicamente quei corsi si trasformino in trasformazione aziendale. E ormai sappiamo com’è andata finora.

PS
Racconterò nel dettaglio questi contenuti durante EFI in Tour a Bologna il 27/11/2025.

The post Theory of Change e formazione aziendale: costruire il futuro a ritroso appeared first on Fullo.

Mi sono seduto a un tavolo. Davanti a me: un quaderno chiuso, un astuccio chiuso con dentro alcune penne. Di fronte: venticinque bambini di quarta elementare che mi guardavano curiosi.

“Ecco le regole,” dico. “Uno per volta mi darete istruzioni precise per scrivere il vostro nome sul quaderno. Potete venire a vedere quando volete, anche quando non è il vostro turno.“

Il primo bambino, chiamiamolo Quattrocchi (non tanto per gli occhiali che non aveva ma per l’atteggiamento), parte sicuro: “Scrivi sul quaderno il mio nome.“

Io, con la faccia più seria possibile, prendo l’astuccio e scrivo sulla copertina del quaderno, usandolo come una immaginaria penna, in grande: “IL MIO NOME”.

Risate. Frustrazione. “No! Non così!“

“Ma hai detto ‘scrivi il mio nome’,” rispondo innocente. “E io ho scritto ‘il mio nome’. Cosa c’è che non va?“

Partono le iterazioni, come in un debug di gruppo fatto ad alta voce. “Apri l’astuccio.” “Prendi una penna.” “No, stappala!” “Girala con la punta verso il basso!” “Apri il quaderno!” “No, su una pagina bianca!” E poi, finalmente, lettera per lettera: “Scrivi Quattrocchi. Q-U-A-T-T-R-O-C-C-H-I.”

La cosa che ancora mi colpisce? Chi è venuto a vedere gli altri tentativi, anche quando non era il suo turno, ha capito il pattern quasi subito. Chi invece ha aspettato “educatamente” il proprio momento ha ripetuto gli stessi identici errori. Come quando in un team tutti fanno lo stesso errore perché nessuno legge davvero le post-mortem.

Non stavo insegnando precisione nelle istruzioni. Stavo insegnando che imparare dagli errori altrui non è barare, è efficienza. E che osservare attentamente spesso riduce il lavoro più di mille tentativi alla cieca.

Quella lezione non prevedeva computer, robot o codice. Solo un quaderno, una penna, e la volontà di sbagliare insieme.

Il patto sociale

«Lo sviluppo sostenibile è uno sviluppo che soddisfi i bisogni del presente senza compromettere la possibilità delle generazioni future di soddisfare i propri.»

Rapporto Brundtland, UN 1987

La definizione del Rapporto Brundtland del 1987 è chiara, ma quando pensiamo a sostenibilità pensiamo (giustamente) a CO2, energia, economia circolare. Raramente pensiamo al sapere, ai metodi, alla cultura che lasciamo.

A cavallo tra l’inverno 2024 e la primavera 2025 ho deciso di prendermi sei mesi per un esperimento. Ho lavorato con quasi 1000 bambini dalla terza elementare alla prima media, non per formare futuri developer, ma per provare a formare future persone raziocinanti. Persone che sappiano ragionare autonomamente, abbiano spirito critico, non abbiano paura di sbagliare, e soprattutto apprendano dai loro errori e da quelli altrui.

Premetto che non sono un pedagogo e non ho dati quantitativi da sbandierare. Non so quanti diventeranno developer, manager o astronauti, e onestamente non mi interessa. So però cosa ho imparato io, e penso valga la pena condividerlo.

La Theory of Change

Quando racconti di aver passato sei mesi con bambini per un obiettivo che si vedrà tra dieci-quindici anni, la prima obiezione è sempre: “Ma come fai a sapere se funziona?” La risposta breve: non lo so. La risposta lunga passa dalla Theory of Change.

La Theory of Change non è una teoria astratta da accademici, è un modo di pensare a come avviene il cambiamento nel tempo. L’idea base: parti dal goal a lungo termine che vuoi raggiungere, poi lavori all’indietro per identificare tutte le condizioni che devono essere presenti perché quel goal si realizzi. Non è “faccio X e spero in Y“, è “voglio Y, quindi mi servono le condizioni A, B, C, che a loro volta richiedono le condizioni D, E, F, e allora faccio le attività X che creano quelle condizioni“, per chi ha seguito i miei corsi sugli OKR sa bene di cosa parlo.

Nel mio caso il ragionamento è stato questo.

Goal a lungo termine: tra dieci-quindici anni voglio che almeno alcune di quelle persone siano “raziocinanti”. Cosa significa raziocinanti (almeno per me)? Persone che ragionano autonomamente, hanno spirito critico, non hanno paura di sbagliare, apprendono dai loro errori e da quelli altrui.

Bene, lavoriamo all’indietro. Perché questo accada, quali condizioni devono essere presenti? Devono aver sperimentato che sbagliare non è catastrofico. Devono aver capito che osservare gli errori altrui è efficienza. Devono aver avuto feedback immediato sulle loro azioni. Devono aver iterato più volte sullo stesso problema. Devono aver vissuto un ambiente dove la precisione conta ma l’errore è parte del processo.

E ancora all’indietro: perché queste condizioni si creino, cosa serve? Serve un ambiente sicuro dove sbagliare è permesso. Serve che il feedback sia chiaro e non interpretabile. Serve che ci sia tempo per iterare. Serve che vedano altri sbagliare e imparare. Serve che i vincoli siano espliciti e non arbitrari.

E allora le attività: giochi dove il fallimento è parte delle regole, robot che danno feedback inequivocabile, carte condizione che rendono espliciti i vincoli, gruppi dove tutti vedono tutti, cinque tentativi invece di uno solo, capogruppo che ruota per distribuire responsabilità.

La Theory of Change mappa il “missing middle”, quello spazio tra “faccio un gioco con i robot” e “tra quindici anni queste persone penseranno meglio”. È onesta nel dire: ecco tutte le cose che devono succedere perché il mio goal si realizzi, e ecco perché penso che queste attività possano innescare quelle condizioni. Può non funzionare, certo. Ma almeno so perché sto facendo quello che sto facendo e magari innesco in qualche testa la giusta scintilla.

Il collegamento con la sostenibilità è diretto. La sostenibilità richiede di ragionare su scale temporali lunghe, di accettare che l’impatto di oggi si vedrà domani, di investire in condizioni che oggi non danno risultati immediati. La Theory of Change è lo strumento per farlo senza andare a caso. Non è garanzia di successo, è garanzia di consapevolezza.

Non avevo KPI da dashboard. Non avevo metriche di conversione. Avevo un’ipotesi su come funziona il cambiamento e la voglia di testarla sul campo, sapendo che i risultati veri non li vedrò direttamente io. Ma questo non rende l’investimento meno valido, rende solo più onesta la discussione su cosa significa “impatto”.

Serious Play, sessant’anni di ricerca

“Giocare è una cosa seria. È il modo migliore per imparare.” ed anche “Se ascolto dimentico, se vedo ricordo, se faccio capisco.”

Bruno Munari – Laboratorio Giocare con l’Arte

So che qualcuno penserà “Ah, quindi ti sei creato una scusa per giocare con i bambini per sei mesi”, facciamo un passo indietro ed introduciamo il secondo tassello di questo piano macchiavellico: il serious play, che ha radici profonde e solide.

Seymour Papert al MIT nel 1967 inventa LOGO, il primo linguaggio di programmazione per bambini. Non per fare di loro dei programmatori, ma perché sosteneva che “non puoi pensare sul pensiero senza pensare a qualcosa di concreto“. Il coding era solo un “qualcosa” utile, come potrebbero esserlo gli scacchi o le ricette di cucina. Papert chiamava il suo approccio costruzionismo: impariamo costruendo cose, non ascoltando lezioni.

Papert era stato allievo di Jean Piaget, lo psicologo che negli anni Sessanta aveva teorizzato il costruttivismo: la conoscenza non si riceve passivamente come un bicchiere che si riempie, ma si costruisce attivamente nella mente attraverso l’esperienza. Sembra una banalità oggi, ma all’epoca era rivoluzionario contro la scuola trasmissiva del “io spiego, tu ascolti, tu ripeti“. Piaget diceva: impari facendo esperienza, non ascoltando lezioni.

Papert va oltre. Non basta l’esperienza, serve costruire oggetti esterni, tangibili, condivisibili. Non solo “learning by doing” ma “learning by making”. Quando costruisci qualcosa di concreto – un programma che disegna, un robot che si muove, una struttura LEGO hai feedback immediato, hai qualcosa da mostrare agli altri, hai qualcosa da iterare. L’oggetto esterno diventa l’ancoraggio per concetti astratti. Il costruzionismo aggiunge il layer della materialità al costruttivismo: le mani aiutano la testa a capire.

Ancora prima, Maria Montessori nel 1912 scriveva che “il gioco è il lavoro del bambino“. I bambini apprendono manipolando oggetti, provando, sbagliando. Gli adulti hanno solo dimenticato come farlo, ma il meccanismo funziona ancora benissimo a trenta, quaranta, cinquant’anni.

Stuart Brown, neuroscienziato, nel 2009 pubblica ricerche che mostrano come il gioco non sia un lusso evolutivo ma una necessità biologica per l’apprendimento. Gli studi sulla retention lo confermano: una lezione frontale ti lascia addosso circa il cinque percento dopo ventiquattr’ore, il learning by doing circa il settantacinque, insegnare ad altri circa il novanta.

Negli anni Novanta nasce LEGO Serious Play da una collaborazione tra LEGO Group, IMD Business School e MIT. Il principio base: “thinking with your hands“: le mani sanno cose che la testa non sa ancora. La NASA lo usa per strategic planning dal 2010. Non è “roba” da bambini, è “roba” che funziona.

Il gioco funziona con gli adulti per almeno tre motivi. Primo, bypassa l’ego: quando “giochi” puoi sbagliare senza difendere il tuo status. Secondo, crea psychological safety: puoi fallire perché è parte delle regole. Terzo, dà feedback immediato: il robot si ferma, il calcolo non torna, il risultato è sotto gli occhi di tutti senza possibilità di interpretazione.

Il “serio” in serious play non è il contrario di “divertente”. È serio perché ha obiettivi chiari e impatto misurabile. E soprattutto perché quando impari giocando, impari davvero.

Dal quaderno ai robot

Ho usato strumenti diversi per età e concetti, ma con un pattern comune: problema chiaro, vincoli espliciti, feedback immediato, iterazione consentita. Non “coding for kids”, ma problem solving through play.

Il gioco del quaderno l’ho già raccontato. Funziona perché non ha barriere tecnologiche e forza il focus sul processo. Ed è replicabile con qualsiasi compito procedurale: preparare un tè, disegnare una casa, spiegare come fare il deploy di un’applicazione.

Per i bambini di quarta elementare ho creato Games for Bees, un gioco che usa robot programmabili, le BeeBot, piccole api gialle che si muovono su una griglia combinati con carte condizione. Il setup è semplice: una griglia quattro per quattro sul pavimento, un robot che si muove di casella in casella, carte direzione (avanti, indietro, gira a destra, gira a sinistra), carte condizione (rock per gli ostacoli da aggirare, “usa meno carte”, “usa più carte”), carte partenza e arrivo.

Ogni gruppo di quattro-cinque bambini ha un nome e un capogruppo che cambia ogni giorno. Il capogruppo può parlare solo se tutti sono d’accordo. Hanno cinque tentativi per completare la sfida. Ogni sfida ha un punteggio. È pair programming travestito da gioco, è code review mascherata da sfida, è retrospettiva con le api robot.

Nel mio caso con i bambini: quando costruiscono una sequenza di carte per la BeeBot, non stanno solo “facendo esperienza di programmazione”. Stanno costruendo un artefatto fisico e condivisibile che possono mostrare, discutere, debuggare insieme. Le carte sul pavimento sono il loro programma, visibile a tutti. Questo è costruzionismo.

I concetti che ho insegnato, senza mai dire “questo è un if-then-else” – emergono dai giochi stessi.

Le condizioni: “Vai a fare la spesa, se al supermercato ci sono almeno due confezioni di uova comprane due, altrimenti non comprare nulla.” Mostro tre scenari con le uova disegnate.

• Una confezione, non compro.
• Una confezione, non compro.
• Due confezioni, ne compro due.

Poi chiedo: “Se scrivo ‘SE uova uguale a due’ cosa succede se ce ne sono tre?”

Scoprono da soli che uguale a due è diverso da maggiore o uguale a due. La precisione è importante, le assunzioni implicite uccidono. Proprio come nei requirement aziendali che diamo per scontati e poi ci chiediamo perché il prodotto non fa quello che ci aspettavamo.

I loop li spiego con i biscotti. “Mangia un biscotto finché ce n’è uno.” Mostro tre biscotti. “RIPETI mangia un biscotto FINCHÉ biscotti uguale a uno.” Cosa succede? Mangio, mangio, mangio. Mi fermo quando ce n’è uno. E poi? Il programma si ferma lì. I bambini capiscono subito: “Ma allora ne resta uno!” Esatto, se voglio mangiarli tutti devo scrivere FINCHÉ biscotti uguale a zero. Il robot non mente, non interpreta, esegue. Se il programma è sbagliato, il risultato è sbagliato. Feedback immediato, senza appello.

Le carte condizione cambiano le regole del gioco e diventano una lezione sul design sotto vincoli. “Usa meno carte possibili” diventa ottimizzazione: ogni carta risparmiata vale un punto extra. “Roccia” significa che c’è un ostacolo e devi aggirarlo, non puoi attraversarlo. Passando su certe caselle prendi o perdi punti. I bambini scoprono che i vincoli li fanno pensare diversamente, che la soluzione più semplice senza vincoli spesso non è la migliore con vincoli. È product design, è architettura software, è business: i constraint stimolano creatività invece di soffocarla.

Con i bambini di quinta elementare e dell’asilo ho usato LEGO Serious Play: costruire con le mani per pensare meglio. Il principio è che quando costruisci qualcosa, le tue mani sanno cose che la testa non ha ancora formulato. Un mattoncino diventa una metafora di un’idea, un problema, una soluzione. Funziona perché bypassa il filtro del “cosa diranno gli altri“: non dici “ho questa idea” esponendoti al giudizio, costruisci qualcosa e poi spieghi cosa rappresenta. È più facile, più onesto, più profondo.

Con alcuni gruppi abbiamo usato robot più avanzati come Dash&Dot e Lego SPIKE: sensori, luci, suoni. Stesso pattern di sempre, problemi chiari e feedback immediato. Esempio: “Accendi luce rossa se trovi un ostacolo, verde se la via è libera, ripeti finché non esci dal labirinto.” Condizioni più loop più sensori, stesso problem solving, diverso medium.

I messaggi dietro agli esercizi

Chi è venuto a vedere gli altri al tavolo del quaderno ha imparato prima. Non era pigrizia, era strategia. Imparare dagli errori altrui non è barare, è efficienza. Eppure in azienda quante volte reinventiamo la ruota perché non chiediamo “qualcun altro ha già provato questo?” o perché non leggiamo davvero le post-mortem che scriviamo?

La storia delle uova ci deve ricordare che un simbolo cambia tutto. Uguale a due contro maggiore o uguale a due. In azienda diamo per scontato cosa significhi “fatto”, “produzione”, “urgente”, “priorità alta”. I bambini imparano a chiedere, noi dimentichiamo di farlo.

“Il programma si ferma qui” è una frase che ho sentito decine di volte. I bambini sanno dire quando qualcosa non funziona, senza girarci intorno, senza politichese, senza “funziona ma…”. Il robot non va dove vogliamo, c’è un errore qui, fissiamolo. In azienda dovremmo prendere appunti.

Senza vincoli i bambini trovano subito la via più diretta. Poi, quando aggiungo “usa meno carte possibili“, devono ripensarci completamente. Ma partono sempre dal semplice. L’over-engineering è il nostro sport nazionale come adulti. I bambini ci ricordano: inizia semplice, poi itera se serve.

Il capogruppo non comanda perché ha un ruolo sulla carta. Il capogruppo guida se sa spiegare, se gli altri si fidano, se costruisce consenso. Ho raccontato meglio questo tema in un post precedente sull’autorità contro autorevolezza. I bambini seguono chi ha ragione, non chi urla più forte. In azienda dovrebbe funzionare allo stesso modo, ma sappiamo tutti che spesso non è così.

Insegnare per imparare meglio

“Se non lo sai spiegare in modo semplice, non l’hai capito abbastanza bene.”

Albert Einstein

Se insegnare agli adulti ci insegna ad ordinare meglio i contenuti per spiegarli più efficientemente, insegnare ai bambini ci invita a spiegarli meglio e a renderli più fruibili, obbligandoci ad approfondire, di fatto, la comprensione degli stessi.

Ho riscritto la spiegazione di IF-THEN-ELSE cinque volte prima che funzionasse con i bambini di quarta. Ogni volta ho tolto una parola tecnica inutile, ogni volta ho semplificato una metafora, ogni volta ho chiesto “ma perché?” a me stesso. Alla quinta versione ho capito che anche nelle consulenze o nei corsi uso troppe parole tecniche inutili.

Insegnare ai bambini è il miglior refactoring del tuo sapere. Devi togliere il jargon, devi trovare metafore che funzionano davvero, devi ammettere quando non sai perché loro se ne accorgono subito. Dopo sei mesi con i bambini ho riscritto parti dei miei libri “KPI, the right way” e “OKR, the right way”. Non perché fossero sbagliati, ma perché potevano essere più chiari. Ho usato la stessa logica del serious play applicata a temi aziendali che molti considerano noiosi. Funziona.

La, vera, cultura del fallimento

Tutti diciamo “fail fast“, “embrace failure“, “learn from mistakes“. Poi in azienda chi sbaglia viene punito in modi sottili o meno sottili, mentre chi non sbaglia ma non sa spiegare perché viene promosso perché ha “portato risultati”.

I bambini mi hanno insegnato una cosa diversa: fallire imparando va bene, riuscire senza capire perché non va bene.

Facciamo un esempio concreto. Bambino A fa dieci tentativi con il robot, sbaglia nove volte, ma alla decima sa spiegare perché quella soluzione funziona e le altre no. Bambino B copia la soluzione giusta da un altro gruppo al primo tentativo ma non sa dire perché funziona. Chi ha vinto? Il bambino A. Chi avrebbe preso il voto migliore in una scuola tradizionale? Probabilmente il bambino B, perché ha “risolto il problema velocemente”.

In azienda quante volte celebriamo il risultato senza chiederci “ma abbiamo capito perché ha funzionato?” E poi, quando dobbiamo replicare quel successo, non ci riusciamo e non capiamo il motivo. La cultura del fallimento non è “puoi sbagliare tranquillo”. È “devi capire perché hai sbagliato”. E simmetricamente, anche se meno discusso, è “devi capire perché hai avuto successo”.

Questo ribalta completamente la narrativa del “move fast and break things”. Non basta muoversi veloci e rompere roba. Serve muoversi veloci, rompere, e capire cosa hai rotto e perché. Altrimenti stai solo accumulando debito di conoscenza invece di debito tecnico, che è peggio perché più difficile da misurare.

E Ora?

“Bello Fullo, ma io non insegno ai bambini.“

Appunto. Non serve insegnare ai bambini per applicare questi principi.

L’onboarding in azienda potrebbe essere un “quaderno game” sul vostro dominio. “Spiegami come si fa il deploy.” Vedrete quante assunzioni implicite avete, vedrete quanto la vostra documentazione è chiara o quanto invece dia per scontate cose che scontate non sono. Il technical writing potrebbe passare un test semplice: puoi spiegarlo a qualcuno che non conosce il contesto? Se no, probabilmente o non l’hai capito abbastanza o è inutilmente complesso o c’è troppo jargon di mezzo.

Le code review potrebbero prendere la regola del capogruppo: chi fa review parla solo dopo che tutti hanno dato un’occhiata e c’è consenso su cosa vada cambiato. Trasforma il processo da monologo del senior a dialogo tra pari. Le post-mortem potrebbero concentrarsi non su “chi ha sbagliato” ma su “cosa abbiamo imparato”, e aggiungere anche “perché ha funzionato quella volta, possiamo replicarlo?”.

Il product design potrebbe abbracciare i vincoli come feature invece che come limitazione. “Usa meno carte possibili” è ottimizzazione, non frustrazione. I constraint stimolano creatività quando li accetti come parte del gioco invece di combatterli.

La mentorship potrebbe creare occasioni perché chi impara veda anche altri che sbagliano e imparano, non solo i successi patinati. La formazione continua potrebbe partire dal principio che se non sai insegnare qualcosa a un collega, a un junior, forse non l’hai capito abbastanza. La leadership potrebbe ricordarsi che si guida spiegando e costruendo consenso, non ordinando e sperando nell’obbedienza.

Le barriere esistono, ovvio. “Non ho tempo” è quella che sento più spesso. L’ho fatto fuori orario per mesi perché ci credevo, perché investire sulle persone è guardare oltre il prossimo sprint o il prossimo quarter. “Non ho competenze pedagogiche” è l’altra barriera comune. Non servono competenze pedagogiche, servono onestà intellettuale e voglia di iterare. Ho sbagliato spiegazioni cinque volte prima di trovare quella che funzionava. “È difficile misurare l’impatto” è verissimo. Non ho KPI, non ho conversion rate, non ho metriche da dashboard. So solo che quei bambini ora sanno che sbagliare è parte del processo se capisci perché sbagli. E tra dieci o quindici anni alcuni di loro saranno nei nostri team, nelle nostre aziende. Spero saranno persone raziocinanti, non automi che eseguono senza capire.

Il patto con chi viene dopo

Sono partito dalla definizione del Rapporto Brundtland del 1987 sul sviluppo sostenibile come patto con le generazioni future. Ho passato sei mesi pensando di insegnare ai bambini a programmare. Ho finito capendo che mi stavano insegnando a pensare meglio, a spiegare meglio, a sbagliare meglio.

La sostenibilità non è solo pannelli solari ed economia circolare. È anche cosa lasciamo a chi viene dopo: non solo codice e processi, ma un modo di pensare. Le “papere”, come le chiamavo le idee in un vecchio post di qualche anno fa, cresceranno. Alcune diventeranno developer, altre manager, altre insegnanti, altre astronaute. Ma tutte sapranno che sbagliare non è un fallimento ma un’iterazione, che osservare gli errori altrui è intelligenza non pigrizia, che la precisione conta e le assunzioni implicite uccidono, che la soluzione più semplice è quella da cui partire, che si segue chi sa spiegare non chi sa ordinare.

E magari tra dieci o quindici anni, quando saranno nei nostri team o nelle nostre aziende o nei nostri consigli di amministrazione, ricorderanno il gioco del quaderno. E chiederanno: “Puoi spiegarmelo meglio? Voglio capire perché, non solo cosa.“

Games for Bees è rilasciato con licenza CC BY-SA 4.0. Trovate tutto su darumahq.it/seriousplay: griglie, carte, istruzioni, esempi. Usatelo, modificatelo, miglioratelo, condividetelo.

I miei libri “KPI, the right way” e “OKR, the right way” applicano la stessa filosofia di serious play a temi aziendali che molti considerano noiosi. Perché anche le metriche e gli obiettivi si possono insegnare e imparare meglio, con meno aria fritta e più concretezza.

E voi, quale sarà la vostra “quarta elementare”? Una persona da mentorare, un corso da tenere gratuitamente, una documentazione da riscrivere “a prova di chi non sa”, un processo da spiegare con un gioco? Perché alla fine, come diceva Seymour Papert già nel 1967, “non puoi pensare sul pensiero senza pensare a qualcosa di concreto“. Il coding, gli OKR, i KPI, i processi agile sono solo “qualcosa” di utile. Il vero obiettivo è imparare a pensare meglio.

E se insegnare ai bambini mi ha insegnato qualcosa, è che noi adulti abbiamo smesso di giocare troppo presto.

The post Pensiero critico in quarta elementare appeared first on Fullo.

Facevo domande che mi sembravano ragionevoli. Tipo: “Supponiamo di aver raggiunto il nostro obiettivo: come stabiliamo che è stato un successo?” Oppure: “Quali sono le metriche su cui dobbiamo lavorare per raggiungere questi obiettivi?” E ancora: “Che causalità c’è tra queste azioni che ci garantisce una riduzione degli impatti ambientali?“

E ottenevo… silenzio. O peggio: risposte vaghe, metriche di vanità del tipo “guardiamo quanti server virtualizziamo!“, numeri senza contesto. Non era malafede, né incompetenza. Era qualcosa di più sottile: mancava il linguaggio condiviso per connettere intenzioni e risultati.

Inizialmente pensavo fosse un problema di cultura aziendale. Poi di maturità sul tema sostenibilità. Poi, mentre studiavo per certificarmi come facilitatore per EN-Roads, mi sono imbattuto nella Theory of Change. E lì ho capito: non era un problema di cosa misurare, ma di come costruire la logica che porta dalla visione all’azione misurabile.

Theory of Change 101

La Theory of Change (ToC) è uno strumento di pianificazione strategica nato nel nonprofit sector negli anni ’90, ma tremendamente utile anche nel contesto aziendale. In sintesi: è la mappa esplicita che spiega come le tue azioni porteranno ai risultati desiderati.

La cosa interessante della ToC è che funziona al contrario di come pensiamo normalmente. Invece di partire da “cosa facciamo oggi” e sperare di arrivare da qualche parte, la ToC usa il backwards mapping: parti dal goal finale che vuoi raggiungere e poi, passo dopo passo, ti chiedi “cosa deve accadere immediatamente prima perché questo si realizzi?” È come risolvere un labirinto partendo dall’uscita invece che dall’entrata.

Il processo si articola in sei stage che ti costringono a pensare in modo strutturato.

Primo: identificare il long-term goal, l’impatto finale che vuoi generare. Secondo: fare backwards mapping connettendo tutte le precondizioni necessarie per raggiungere quel goal, spiegando perché queste precondizioni sono necessarie e sufficienti. Terzo: identificare le assunzioni base sul contesto in cui operi. Quarto: definire gli interventi specifici che la tua iniziativa metterà in campo. Quinto: sviluppare indicatori per misurare i tuoi outcomes e valutare le performance. Sesto: scrivere la narrativa che spiega la logica dell’intera iniziativa.

Il cuore del processo è quello che chiamano “pathway of change“: una sequenza connessa di outcomes che rappresenta graficamente il processo di cambiamento come lo intendono i pianificatori. E qui viene la parte cruciale: durante la creazione di questo pathway, devi articolare tutte le tue assunzioni sul processo di cambiamento, così puoi esaminarle e testarle per verificare se qualche assunzione chiave è difficile da supportare o addirittura falsa.

Ci sono tipicamente tre tipi importanti di assunzioni da considerare. Le asserzioni sui collegamenti tra outcomes a lungo termine, intermedi e iniziali sulla mappa. La sostanziazione della completezza, cioè la pretesa che tu abbia identificato tutte le precondizioni importanti per il successo. Infine, le giustificazioni dei link tra attività programmatiche e gli outcomes che ci si aspetta producano. E spesso c’è un quarto tipo: i fattori contestuali o ambientali che supporteranno o ostacoleranno il progresso verso la realizzazione degli outcomes.

Un esempio di ToC fatta male

Facciamo un esempio concreto che mi è capitato di vedere più volte nelle consulenze. Scenario tipico: un’azienda vuole “diventare carbon neutral”, decide di comprare crediti di carbonio, e misura il successo in “€ spesi in carbon credits”. Fine della storia.

Che cosa manca? Tutto il resto. Non c’è connessione causale tra l’acquisto di crediti e la riduzione effettiva delle emissioni. Non ci sono outcomes intermedi misurabili. Non ci sono assunzioni esplicite da validare. È un’azione disconnessa da una teoria del cambiamento. È aria fritta, diciamocelo.

Ora prendi lo stesso scenario con una ToC articolata attraverso backwards mapping.

Parto dal long-term goal: “Riduzione del 50% delle emissioni Scope 1-2-3 entro il 2030”.

Poi mi chiedo: cosa deve accadere immediatamente prima perché questo si realizzi?

Devo avere infrastruttura IT con intensità carbonica ridotta del 30% entro 18 mesi. E prima ancora?

Software re-architettato con metriche SCI implementate e misurate. E prima di quello?

Audit del codice esistente completato, team formato su Green Software, refactoring prioritizzato ed eseguito. E per fare tutto questo?

Budget per formazione, tempo dev allocato, tooling itegrare la misurazione SCI nel CI/CD configurato.

A questo punto emergono le assunzioni critiche da validare. Il team ha competenze base per apprendere Green Software? Esistono alternative tecnologiche a lower carbon intensity per i nostri use case? Il business è disposto a investire in refactoring che non porta feature visibili? Se una di queste assunzioni è falsa, tutta la tua ToC crolla, meglio scoprirlo prima di investire risorse.

Gli indicatori a questo punto diventano chiari e multi-livello. Non solo “emissioni totali ridotte” alla fine, ma SCI per servizio, percentuale di codice rifattorizzato, ore di training completate (e comprensione dei Green Pattern da parte dei dev), carbon savings misurati in ogni sprint. Vedi la differenza? Ora hai una mappa navigabile. Puoi contestare le assunzioni, verificare i collegamenti causali, misurare a ogni livello, e soprattutto: sapere durante il percorso se stai andando nella direzione giusta.

La connessione con Osterwalder e The Invincible Company

Qui c’è un parallelo interessante con il lavoro di Alex Osterwalder in The Invincible Company.

Osterwalder parla di come le aziende vincenti non si limitano a trovare “la prossima grande cosa“, ma costruiscono motori di innovazione continua che permettono di reinventarsi costantamente. Il suo concetto chiave è che i business models oggi sono come lo yogurt: hanno una data di scadenza ravvicinata. Non puoi più fare affidamento su un singolo modello che durerà decenni.

La Theory of Change è esattamente lo strumento che ti serve per costruire questo motore. Osterwalder distingue tra exploration (cercare nuove opportunità, crescita, mentalità imprenditoriale) ed exploitation (ottimizzare l’esistente, efficienza, cost-cutting). Le aziende invincibili fanno entrambe le cose contemporaneamente, sono “ambidestre”. Ho già approfondito questa distinzione in un articolo precedente su Invincible OKR, dove spiego come i due binari (Esplorazione e Miglioramento) richiedano metriche e OKR completamente diversi.

Ma per esplorare efficacemente, hai bisogno di una ToC chiara: quale impatto voglio generare con questo nuovo business model? Quali outcomes intermedi mi dicono se sto andando nella direzione giusta? Quali assunzioni sto facendo sul mercato, sui clienti, sulla tecnologia?

E qui si innesta un’altra connessione fondamentale. Quando costruisci la tua Theory of Change, stai essenzialmente definendo il tuo futuro desiderabile usando il concetto dei Futures Cone. Come ho spiegato nell’articolo su Futures Cone e OKR, il futuro non è un punto fisso ma un cono di possibilità che si allarga nel tempo. Il futuro preferibile, quello che vogliamo costruire, è esattamente quello che stiamo mappando quando articoliamo la nostra ToC attraverso backwards mapping.

Il long-term goal della ToC è l’apice del cono desiderabile. Gli outcomes intermedi sono le sezioni del cono che raggiungi in momenti specifici. Le assunzioni che validi sono il modo in cui restringi il cono dell’incertezza, passando dal “possibile” al “plausibile” al “probabile”. E le iniziative che implementi sono quei tronchi di cono che ti portano progressivamente verso il futuro che hai scelto di costruire.

Osterwalder introduce il Business Model Portfolio Map per gestire il portfolio di idee e miglioramenti. Ma senza una ToC per ogni iniziativa nel portfolio, stai solo accumulando speranze. La ToC ti dice perché quell’idea dovrebbe funzionare, quali sono le precondizioni necessarie, e come misurare se stai de-risking le assunzioni critiche. Esattamente quello che Osterwalder predica: test, measure, de-risk desirability, viability, feasibility.

E qui arriviamo al cuore del problema che vedevo nelle mie consulenze sul sustainable IT: le aziende volevano “innovare” sulla sostenibilità (exploration), ma senza una ToC articolata stavano solo facendo quello che Osterwalder chiama “innovation theater“, uno spettacolo che sembra innovazione ma non riduce il rischio né crea valore reale.

Questo è quello che mancava nelle mie consulenze. E questo è quello che mi ha portato a scrivere tre libri invece di uno.

Il percorso: tre libri, un’unica teoria del cambiamento

Quando ho iniziato a lavorare sul sustainable IT, partivo sempre dagli OKR. È la metodologia che uso da anni, quella su cui ho costruito corsi e interventi. Ma mi sono reso conto che non bastava.

Gli OKR sono potenti per collegare Objectives (qualitativi, aspirazionali) a Key Results (quantitativi, misurabili). Sono perfetti per creare alignment verticale e orizzontale in un’organizzazione. Ma per funzionare davvero, hanno bisogno di due fondamenta: una comprensione profonda di come si misurano le cose (non tutte le metriche sono uguali), e una logica causale esplicita che colleghi azioni a risultati (la Theory of Change, appunto).

E così, sfruttando le trascrizioni dei miei corsi e workshop, sì, perché questi temi li ho rodati sul campo prima di metterli nero su bianco anche qui sul blog, è nato un percorso in tre atti. In termini di Osterwalder, ho esplorato il dominio del sustainable IT sviluppando un framework che altri possano poi sfruttare (exploitation delle mie esperienze di exploration).

Atto 1: KPI, the right way

Il primo problema da risolvere era: “Come faccio a sapere se sto misurando la cosa giusta?” Questo libro nasce dalle domande ricorrenti nei miei workshop. “Ma questa metrica è buona? Come faccio a evitare le vanity metrics? Cosa rende una metrica actionable?” Domande legittime che meritavano risposte strutturate.

Ho scritto KPI, the right way per dare le fondamenta della misurazione. Dentro ci trovi i bias cognitivi che distorcono la scelta delle metriche: confirmation bias, availability bias, la famigerata Goodhart’s Law (“quando una misura diventa un target, smette di essere una buona misura”). Poi c’è la distinzione cruciale tra vanity metrics e metriche azionabili: la differenza tra “sembra bello nei report” e “mi dice cosa fare domani mattina per migliorare”. E infine framework pratici per validare i tuoi KPI, perché no, SMART non basta. È troppo generico, serve qualcosa di più strutturato.

Senza questo pezzo, gli OKR diventano pericolosi. Scegli Key Results sbagliati e ottimizzi per le cose sbagliate. Nel sustainable IT, dove le metriche sono ancora immature (SCI, PUE, carbon intensity e compagnia cantante) questo rischio è altissimo. Non puoi permetterti di misurare la cosa sbagliata quando l’impatto ambientale è in gioco. In termini di ToC: se i tuoi indicatori sono mal costruiti, non saprai mai se stai davvero progredendo verso gli outcomes desiderati.

Atto 2: OKR, the right way

Una volta che sai misurare, serve un sistema per orchestrare quelle metriche in una strategia coerente. Gli OKR sono perfetti per questo, ma solo se li usi bene. E qui casca l’asino, perché ho visto fin troppe implementazioni di OKR che erano poco più di todo-list glorificate.

OKR, the right way introduce i principi di causalità: perché questo Key Result dovrebbe portare a quell’Objective? Non è una domanda filosofica, è il cuore della questione. È esattamente quello che la ToC ti costringe a fare quando mappi le connessioni tra outcomes. Poi c’è l’effetto-reazione: come validare che le tue azioni stiano davvero muovendo l’ago, e non solo creando l’illusione del progresso?

Dentro ci sono anche i coni del futuro per fare scenario planning e creare OKR resilienti in contesti incerti, e diciamocelo, il sustainable IT è un contesto incerto. E c’è Hoshin Kanri per l’allineamento strategico verticale e orizzontale, perché gli OKR che vivono in silos separati non servono a nessuno.

Questo è il cuore della Theory of Change applicata: gli OKR sono la struttura che connette vision (Objective) a execution (Key Results + Initiatives). Sono il “pathway of change” fatto strumento operativo. Ma senza una logica causale esplicita, senza chiederti “perché questo KR dovrebbe portare a quell’Obiettivo?”, rimangono solo wishful thinking ben formattato su un foglio Excel.

Atto 3: Sustainable IT, the practical way

Okay, so misurare e so pianificare. E adesso? Come lo applico al sustainable IT? Qui chiudo il cerchio con Sustainable IT, the practical way, che è l’applicazione pratica di KPI e OKR al dominio specifico della sostenibilità digitale.

Dentro trovi metriche specifiche come SCI, PUE, emissioni Scope 3 delle infrastrutture, user-centric metrics. Ci sono esempi di OKR concreti per capire come strutturare obiettivi di sostenibilità che siano ambiziosi ma realistici, perché “salvare il pianeta” non è un Key Result. C’è un approccio pragmatico totale: niente green-washing, solo azioni misurabili con impatto reale. E soprattutto c’è integrazione: come fare sostenibilità senza creare l’ennesimo silo separato dal resto del business.

Questo libro è anche una risposta diretta al problema che Osterwalder identifica: troppo “innovation theater” e troppo poco testing rigoroso delle assunzioni. Ogni pratica di sustainable IT nel libro è (sarà perché al momento ho scritto solo i primi capitoli) accompagnata da: quali metriche usare per validarla, quali assunzioni stai facendo, come de-riscare attraverso small experiments. È exploration disciplinata, non speranza vestita da strategia.

Non è un caso che sia arrivato per ultimo. Senza la base metodologica dei primi due, questo libro sarebbe stato solo un’altra lista di best practices disarticolate che trovi già in mille blog post. Invece è il pezzo finale di un puzzle più grande: la mia personale Theory of Change per portare le organizzazioni da “vogliamo fare sostenibilità” a “stiamo riducendo il nostro impatto in modo misurabile e continuo”.

La mia personale Theory of Change

Guardando indietro, cosa che di solito faccio troppo poco, ma ogni tanto è utile, mi sono reso conto che i tre libri sono esattamente la mia Theory of Change per portare le organizzazioni da “vogliamo fare sostenibilità” a “stiamo riducendo il nostro impatto in modo misurabile“.

Applicando il backwards mapping che ho descritto prima, parto dal long-term goal: organizzazioni che integrano sustainable IT in modo strutturato, misurabile e non performativo. Basta con i report di sostenibilità che sono puro marketing, voglio vedere azioni concrete.

Cosa deve accadere immediatamente prima perché questo si realizzi? Devo avere manager e team con le competenze giuste per definire strategie sostenibili azionate da metriche corrette. Non basta la buona volontà, serve il metodo. E prima ancora? Devo creare strumenti didattici accessibili che coprano l’intero percorso metodologico: misurazione, poi pianificazione, poi applicazione dominio-specifica.

E come produco questi strumenti in modo che siano davvero utili e non solo teoria astratta? Attraverso corsi, workshop e consulenze dove testo e affino questi contenuti. Le trascrizioni di quelle sessioni diventano il materiale grezzo per i libri, quindi no, non sono nati dalla pura teoria, ma da ore di facilitazione e discussioni con chi questi problemi li vive ogni giorno.

E cosa serve per fare tutto questo? 5 anni di esperienza sul campo, decine di clienti diversi, centinaia di ore di facilitazione. E pazienza. Tanta pazienza. Questo è il mio pathway of change personale, e ogni libro è un outcome intermedio verso l’impact finale.

Le assunzioni critiche che ho fatto lungo il percorso? Principalmente tre.

Primo: le organizzazioni falliscono sul sustainable IT per mancanza di metodo, non di intenzioni. La maggior parte delle persone vuole fare la cosa giusta, semplicemente non sa come.

Secondo: metriche e OKR sono linguaggi comprensibili trasversalmente, dal developer al C-level, non servono PhD in sustainability science per capirli.

Terzo: un approccio pragmatico batte sempre quello ideologico. Le crociate verdi non funzionano, i piccoli passi misurabili sì.

E come valido queste assunzioni? Con indicatori di successo concreti che vedo nelle consulenze. Clienti che tornano e mi dicono “abbiamo implementato gli OKR sostenibili e funzionano, guarda i dati”. Richieste specifiche su come misurare X o strutturare Y, segnale che stanno adottando concretamente gli approcci, non solo leggendo per cultura personale. E soprattutto: meno “sguardi a triglia” quando parlo di metriche azionabili. Quello è il vero metro del successo.

L’ambidestria organizzativa applicata alla consulenza

Se penso al mio lavoro in termini del framework di Osterwalder, ho costruito un sistema ambidestro. Da un lato c’è exploitation: erogo corsi e consulenze su OKR e sustainable IT, ottimizzando continuamente il format basandomi sui feedback. Dall’altro c’è exploration: ogni cliente porta problemi nuovi che mi costringono a testare le assunzioni, raffinare gli approcci, esplorare nuovi collegamenti.

I tre libri sono il risultato di questo processo di esplorazione continua, cristallizzato in un format che altri possono sfruttare. Non sono il punto di arrivo, sono snapshot di un percorso in evoluzione. Come dice Osterwalder, i business models hanno una data di scadenza. Lo stesso vale per i framework metodologici: vanno continuamente testati, validati, e aggiornati basandosi su nuove evidenze.

La differenza tra fare “innovation theater” e fare vera innovazione sta proprio qui: nella capacità di articolare la tua Theory of Change, testare le assunzioni rigorosamente, e misurare se stai davvero creando l’impatto desiderato o solo l’illusione del progresso.

Costruisci la tua mappa prima di partire

Se stai lavorando su sustainable IT, o qualsiasi iniziativa di cambiamento complesso, in realtà, ti consiglio di partire dalla Theory of Change prima di buttarti su tools e framework. So che è meno sexy che installare l’ultimo tool di carbon monitoring, ma fidati: ti farà risparmiare un sacco di tempo e frustrazioni.

Il processo di backwards mapping è controintuitivo ma potente. Inizia identificando il long-term goal specifico che vuoi raggiungere. Non “fare sostenibilità” che non significa niente, ma “ridurre le emissioni del 30% entro il 2027 misurando per i nostri 10 servizi più usati“. Specifico, misurabile, temporizzato.

Poi fai il passo indietro e chiediti: cosa deve accadere immediatamente prima perché questo goal si realizzi? Magari devi avere “team formati su Green Software e processi di code review che includono criteri di efficienza energetica”. Okay, e prima ancora? “Documentazione interna su best practices Green Software e tooling per misurazione SCI integrato nella CI/CD pipeline”. Continua così fino ad arrivare alle azioni che puoi fare oggi.

Mentre costruisci questo pathway, identifica tutte le assunzioni che stai facendo. Il team sa già programmare in modo efficiente? Hai budget per cambiare infrastruttura? I fornitori hanno alternative low-carbon? Scrivi queste assunzioni nero su bianco e poi vai a validarle, una per una. Le assunzioni non verificate sono la tomba di ogni progetto, Osterwalder lo ripete in continuazione quando parla di de-risking.

Non dimenticare i fattori contestuali: cosa nel tuo ambiente organizzativo supporterà questo percorso? Cosa lo ostacolerà? C’è un executive sponsor che ci crede davvero? Il budget è stabile o a rischio al primo trimestre negativo? Questi fattori influenzano pesantemente la realizzabilità della tua ToC.

Infine, sviluppa indicatori per ogni livello del tuo pathway of change. Non solo i KPI finali tipo “emissioni totali ridotte”, ma metriche intermedie che ti dicono durante il percorso se sei on track o se devi correggere la rotta. Percentuale di team formati, numero di servizi migrati, SCI medio in miglioramento, indicatori che ti fanno capire se stai riducendo il rischio delle assunzioni critiche o solo raccontandoti storie.

Solo dopo aver fatto questo lavoro, e lo so che sembra laborioso, ma vale ogni minuto investito, gli strumenti come OKR, KPI, SCI e tutti i framework che trovi in giro diventano davvero utili. Perché sai perché li stai usando e cosa ti devono dire. Altrimenti sono solo l’ennesimo buzzword da mettere nelle slide per far contento il board.

Quello che ho imparato (e che forse ti può servire)

Scrivere tre libri invece di uno non è stata una scelta di marketing. Posso dirlo tranquillamente perché, diciamocelo, se volevo fare soldi con i libri avrei scelto un settore diverso. È stata una necessità metodologica, ogni libro risponde a una precondizione necessaria per quello successivo.

Non puoi parlare di OKR sostenibili se prima non hai spiegato come si valuta una metrica. Non puoi applicare KPI al sustainable IT se prima non hai costruito la logica causale che li connette agli obiettivi strategici. Ogni pezzo serve al successivo, e saltarne uno significa costruire una casa senza fondamenta.

E se vuoi approfondire come ho strutturato questo percorso in pratica, beh… ho scritto tre libri apposta. Non per venderteli, anche se ovviamente non mi dispiace se li compri, ma perché sono il modo più efficace che ho trovato per trasmettere anni di esperienza sul campo in formato utilizzabile. Sono il mio contribution a quel portfolio di innovation di cui parla Osterwalder: piccoli esperimenti che se funzionano diventano prodotti, se non funzionano insegnano qualcosa.

Quali sono le assunzioni implicite nel tuo progetto di sostenibilità? Hai già provato a mapparle esplicitamente usando il backwards mapping?

Se la risposta è no, questo weekend potrebbe essere un buon momento per iniziare. Ti garantisco che scoprirai cose interessanti, e probabilmente qualche assunzione che pensavi solida si rivelerà… meno solida di quanto speravi. Meglio scoprirlo ora che dopo aver investito sei mesi e mezzo budget annuale.

The post Theory of Change ed editoria appeared first on Fullo.

Ne è uscito un workshop che reputo solido, divertente nella modalità di fruizione e, anche se sicuramente perfettibile, più che adeguato a quello che stavo cercando.

A questo punto ho iniziato ad ascoltare le vocette intorno a me, anche quelle interiori, e mi sono detto ma perché non fare un companion book per il corso? Così magari ho la scusa per stampare le carte professionalmente.

E così è ripartita la giostra, analisi delle trascrizioni, delle slide e dei contenuti ad esse allegati fino a arrivare prima ad una scaletta e poi circa 200 pagine scritte a 4 mani (le mie e quelle di Claude).

Il processo di produzione è stato più o meno questo: ho fatto analizzare alcuni miei blog post e le trascrizioni al fine di tirare fuori una TOV allineata con il mio modo (sgangherato) di esprimermi, in affiancamento a questa TOV ho scritto un prompt per definire l’uso di emoji particolari, formattazione markdown, sezioni dei capitoli (ad esempio “Domanda socratica” o “Insight”) al fine di avere coerenza tra i vari capitoli ed infine ho scritto una prima bozza di indice con obiettivi per i singoli capitoli che ho fatto espandere all’LLM.

A questo punto ho fatto iniziare il vero processo di scrittura del libro, un capitolo alla volta confrontando l’obiettivo del capitolo con quanto scritto e con il capitolo precedente per valutare la coerenza.

Ho rivisto la forma (maledette liste puntate nude e decontestualizzate!), allungato dove bisognava allungare e ridurre dove si creavano inutili arzigogoli degni del più manzoniano Azzeccagarbugli.

Infine ho fatto rileggere tutti i capitoli, valutando se gli esercizi si integravano bene ed una volta soddisfatto ho pubblicato su LeanPub.

Bene. Benissimo.

Poi ad una prima rilettura mi è stato fatto presente che tutti i titoli erano Camel Case. Cioè, Ogni Parola di una Frase Era in Maiuscolo.

Ho quindi preso Claude ed ho iniziato a modificare il prompt per fargli correggere tutto, ma al primo tentativo mi sono ritrovato con i documenti non più coerenti, con titoli cambiati e con scelte autonome non desiderate.

Ecco… a questo punto ero un po’ scorato.. Quando mi sono ricordato che bastava aprire i capitoli in un editor qualsiasi e far partire un semplicissimo RegExp per identificare tutti i titoli errati con

^(#{1,3} )\s*(.+)$

che identifica tutte le occorrenze dei titoli markdown #, ##, ### seguiti da spazio ed aggiornarli con

\$1\u\L$2

che ripete la sequenza della prima ricerca ($1 che contiene #) seguita dalla prima lettera in uppercase (\u) e tutte quelle successive in lowercase (\L).

Provate su Visual Studio Code, se volete.

La morale? Ogni tanto “anche meno AI” e più RegExp.

PS
Il libro è pronto all’80%, devo rimuovere un po’ di esempi (ce ne sono troppi) e smussare qualche angolo. Ma direi che ci siamo, mentre il workshop è praticamente finito!

The post Anche meno però… appeared first on Fullo.

Il problema non erano gli strumenti, quelli li conoscevano bene. Il problema era nel modo di pensare.

Peirce e i tre modi di ragionare

Charles Sanders Peirce, filosofo americano della fine dell’800, non era certo uno che si accontentava delle definizioni da manuale. Mentre tutti parlavano di induzione e deduzione, lui tirò fuori un terzo modo di ragionare: l’abduzione.

Facciamola semplice:

• Deduzione: applico regole note a casi nuovi (“se tutti i cigni sono bianchi, anche quello laggiù lo sarà”)
• Induzione: generalizzo da casi osservati (“ho visto mille cigni bianchi, quindi tutti lo sono”)
• Abduzione: formulo ipotesi creative per spiegare fatti nuovi (“vedo un cigno nero… forse la mia teoria sui cigni è sbagliata”)

Quell’ultimo punto è fondamentale. L’abduzione è quel salto mentale che ti fa dire: “E se fosse così?” Non è certezza, è “intuizione guidata“.

Dall’abduzione al business design

Ora, collegando questo al nostro mondo di tutti i giorni: ogni volta che affrontiamo un problema di innovazione, in realtà stiamo navigando tra questi tre modi di pensare. E qui entra in gioco quello che chiamiamo business design: l’arte di orchestrare questi ragionamenti per creare valore.

Il percorso tipico di una startup moderna segue questa logica:

Abduzione ? Problem-Solution Fit
Osservi un indizio (comportamento strano degli utenti, feedback ricorrente, pattern nascosto nei dati) e formuli un’ipotesi: “Forse il vero problema è X, e la soluzione potrebbe essere Y“. Non hai certezze, ma hai una spiegazione plausibile che vale la pena esplorare.

Deduzione ? MVP e sperimentazione
Prendi la tua ipotesi e ragioni: “Se davvero il problema è X e la mia soluzione Y funziona, allora dovrei vedere comportamenti specifici quando testo un prototipo“. Costruisci qualcosa di minimo ma significativo per verificare la logica.

Induzione ? Solution-Market Fit
Raccogli dati reali, osservi pattern ricorrenti, misuri metriche concrete. Se i numeri si ripetono e confermano la tua teoria, hai trovato non solo una soluzione che funziona, ma un mercato che la vuole.

Il business design è proprio questo: saper orchestrare abduzione, deduzione e induzione per trasformare intuizioni in business sostenibili. Non è solo product management o marketing, è l’architettura del pensiero strategico.

Ma qui viene il bello: se l’MVP non viene validato, non è un fallimento. È semplicemente l’invito a tornare all’abduzione, a riformulare l’ipotesi, magari scoprendo un problem-solution fit completamente diverso.

Un classico caso da manuale è la startup che ha sviluppato un’app per il fitness e si ritrova a dover convivere con numeri erano spietati su tassi di retention degli utenti, ie. il 70% degli utenti non rinnovava l’abbonamento dopo il primo mese.

Se ci fermassimo al solo approccio deduttivo otterremmo le solite soluzioni: “aggiungiamo più funzionalità“, “miglioriamo la UX“, “facciamo più push notifications“. L’induzione non ci aiuta neppure, perché conferma il pattern: “gli utenti si iscrivono motivati, poi mollano, è sempre andata così“.

Ed è qui che bisogna fare qualcosa che, purtroppo, molti PO (ed alcuni imprenditori) valutano una perdita di tempo. Brainstorming puro senza paura di sbagliare. Cioè quelle attività che favoriscono il nascere di domande come: “E se il problema non fosse l’app in sé, ma il fatto che allenarsi da soli è noioso?“

Cioè abduzione pura.

Da lì nascono poi le idee di trasformare ogni workout in una sfida collaborativa con altri utenti, sfide che il fitness sociale gamificato ci ha fatto conoscere in questi ultimi anni.

I futuri possibili non sono tutti uguali

Qui entra in gioco un altro strumento che uso spesso: il futures cone. Immaginate un cono che si allarga nel tempo: alla base c’è il presente, e man mano che guardi avanti trovi diversi tipi di futuro.

• Possibili: tutto quello che possiamo immaginare
• Plausibili: scenari supportati da trend e dati
• Probabili: sviluppi attesi se continua così
• Preferibili: futuri che vogliamo contribuire a creare

L’abduzione si muove nei futuri possibili, la deduzione esplora i plausibili, l’induzione fotografa i probabili. Ma il management può decidere quale futuro preferire.

Pratica quotidiana: dalla teoria alla scrivania

Come trasformare tutto questo in qualcosa di concreto?

Nel prossimo progetto di innovazione, provate a fare così:

1. Fase abduttiva – Sedetevi con il team e fate il gioco del “E se…?” senza vincoli. Cercate ipotesi che spieghino il problema da angolazioni nuove.
2. Fase deduttiva – Per ogni ipotesi interessante, definite: “Se fosse vera, cosa dovremmo osservare?” Costruite micro-test, non MVP perfetti.
3. Fase induttiva – Raccogliete dati, ma non solo metriche. Parlate con le persone, osservate comportamenti, cercate pattern.
4. Scelta del futuro preferibile – Tra le opzioni che funzionano, quale contribuisce al mondo che volete vedere?

Avete notato come molte di queste domande ed attività siano le stesse che ci si pone scrivendo gli OKR?

Il punto non è prevedere, è navigare

In fondo, gestire l’innovazione non significa trovare LA risposta giusta. Significa allenarsi a muoversi nell’incertezza, a formulare ipotesi plausibili e a sperimentarle senza paura.

Il futuro non è un destino scritto: è un ventaglio di possibilità che aspetta solo che qualcuno osi chiedersi “E se invece fosse così?”

Nei miei workshop con i bambini sul pensiero critico, questa è la frase che ripeto di più. E, per fortuna, funziona anche con gli adulti.

C’è un collegamento interessante che emerge spesso quando lavoro con i team sulla definizione degli OKR: l’abduzione è il carburante nascosto che alimenta gli Objectives, ma troppo spesso viene saltata. I team si fiondano direttamente sulla strutturazione – “dobbiamo aumentare la retention del 20%” – senza aver prima esplorato le ipotesi creative su PERCHÉ quella metrica sia importante e COSA potrebbe realmente spostarla.

L’abduzione precede la pianificazione strategica. È quel momento in cui, davanti a dati ambigui o opportunità unclear, ci si ferma a chiedersi: “Quale storia potrebbero raccontare questi indizi?” Solo dopo quella riflessione puoi tradurre le intuizioni in Objectives chiari e Key Results misurabili.

In sostanza, se vi siete mai chiesti perché alcuni team riescono a innovare davvero mentre altri rimangono bloccati sui soliti schemi, forse la risposta non è negli strumenti che usano. È nel modo in cui pensano.

The post L’arte dell’abduzione: come un filosofo dell’800 può salvare i tuoi progetti di innovazione appeared first on Fullo.

È la quarta volta quest’anno che sento questa richiesta. E ogni volta penso al mio articolo del 2020 su resilienza e sostenibilità, dove scrivevo di business model sostenibili con tanta propositività, ma ancora poca esperienza su implementazioni complesse alle spalle.

Cinque anni dopo, il quadro si è chiarito.

I principi erano giusti, ma ho scoperto che tra “dobbiamo considerare l’impatto ambientale e sociale” e “ecco come lo facciamo concretamente senza perdere sei mesi in analisi” c’è un gap significativo. Un gap che ha a che fare con la natura stessa della sostenibilità: non è una caratteristica che puoi “aggiungere” a un business model, ma una proprietà emergente di un sistema complesso dove ogni elemento influenza tutti gli altri. Un gap che ho attraversato con decine di clienti, imparando ogni volta qualcosa di nuovo sul campo.

La domanda che mi faccio sempre più spesso è: esistono strumenti che funzionano davvero? Che non siano né troppo teorici né troppo semplicistici?

Entra in scena il Triple Layered Business Model Canvas

Ed ecco che mi imbatto nel Triple Layered Business Model Canvas (TLBMC), sviluppato da Joyce e Paquin. Non è roba nuova (il paper è del 2016) ma è la prima volta che ci dedico il tempo necessario per capirlo davvero.

Il concetto è elegante e riconosce una verità fondamentale: la sostenibilità nei business model non funziona per addizione (“aggiungiamo un po’ di verde“), ma per trasformazione sistemica. Invece di cercare di integrare sostenibilità ambientale e sociale dentro il canvas classico di Osterwalder (approccio che ho sperimentato spesso, con risultati misti), si creano tre layer sovrapposti:

1. Layer Economico: il business model canvas tradizionale
2. Layer Ambientale: basato su una prospettiva di ciclo di vita
3. Layer Sociale: basato su una prospettiva di stakeholder

Ogni layer ha i suoi nove blocchi, che si allineano verticalmente con quelli degli altri layer. L’idea è creare una “coerenza orizzontale” (ogni layer ha senso in sé) e una “coerenza verticale” (i blocchi si parlano tra layer).

Sulla carta, è geniale. Nella pratica?

In concreto

Ho provato ad applicarlo a un caso che conosco bene: un’azienda di packaging che produce imballaggi per e-commerce. Classico esempio dove sostenibilità significa tutto e niente.

Cosa funziona:

I tre layer ti obbligano a essere specifico. Non puoi più dire “siamo sostenibili” e basta. Devi riempire il layer ambientale con dati concreti: materiali, produzione, distribuzione, fine vita. E quello sociale con stakeholder reali: dipendenti, fornitori, comunità locali.

La visualizzazione è potente perché rende visibili le interconnessioni sistemiche. Vedere i tre canvas uno sull’altro fa scattare connessioni che prima non vedevi. Tipo: il tuo “customer relationship” economico che impatto ha sui tuoi “end-user” sociali? E le tue “key activities” economiche che “environmental impacts” generano? È come passare da una foto in bianco e nero a una a colori: il soggetto è lo stesso, ma improvvisamente vedi dettagli che prima ti sfuggivano.

Cosa non convince:

La complessità può paralizzare. Riempire tre canvas da nove blocchi ciascuno significa gestire 27 aree di analisi. È facile perdersi nei dettagli e dimenticare il quadro d’insieme.

Il rischio “paralisi da analisi” è concreto. Ho visto team passare settimane a discutere se un impatto va nel layer ambientale o sociale, perdendo di vista l’obiettivo: prendere decisioni migliori.

E poi c’è la questione dati. Il layer ambientale richiede informazioni che molte aziende non hanno sempre a disposizione. Senza una base di dati solida, il rischio è di lavorare su ipotesi poco fondate.

La mia ricetta (Work in Progress)

Dopo averci smanettato un po’, ecco come lo sto adattando per i miei clienti:

1. Inizia dal layer economico Non reinventare la ruota. Se il tuo business model canvas tradizionale non è solido, rafforza prima le fondamenta. La sostenibilità funziona meglio quando si innesta su basi economiche stabili.

2. Aggiungi un layer alla volta Non tre canvas contemporaneamente. Prima l’ambientale (più facile da quantificare), poi il sociale. Ogni layer deve avere senso prima di passare al successivo.

3. Focus sui blocchi che contano Non tutti i 27 blocchi sono ugualmente importanti per la tua azienda. Identifica i 5-6 che fanno davvero la differenza e concentrati su quelli.

4. Disegna la tua theory of change Prima di riempire i canvas, chiarisciti quale cambiamento vuoi ottenere e in che sequenza. Se l’obiettivo è ridurre l’impatto ambientale del 30%, quali sono gli step logici? Cambi prima i materiali, poi i fornitori, poi i processi? Il TLBMC ti aiuta a visualizzare le dipendenze, ma la strategia la devi definire tu.

5. Lavora con le metriche disponibili Non aspettare l’LCA perfetta. È meglio iniziare con dati che hai già e migliorarli progressivamente, piuttosto che rimandare perché non hai tutte le informazioni ideali.

In sostanza…

Il TLBMC non è la bacchetta magica che risolve tutti i problemi del modellare un business model sostenibile. Ma è uno strumento multidimensionale per approcciare i temi da più aspetti ed utile per chi vuole andare oltre i buoni propositi.

La sua forza sta nel riconoscere che la complessità non è un bug da correggere, ma una caratteristica intrinseca dei sistemi sostenibili. Non semplifica il problema, ma lo rende navigabile.

Quando usarlo:

• Aziende che hanno già un business model funzionante e vogliono renderlo più sostenibile
• Team che non si accontentano di “green washing” ma vogliono cambiamenti strutturali
• Progetti con tempo e risorse per fare le cose per bene

Quando evitarlo:

• Startup che stanno ancora cercando il loro product-market fit
• Aziende in crisi che devono prima sistemare i fondamentali economici
• Situazioni dove serve velocità più che precisione

La cosa importante da comprendere è che la sostenibilità nei business model non è una checklist da spuntare, è un modo diverso di pensare al valore che viene creato, per chi viene creato, ed a che prezzo (non solo economico).

Deve essere un pensiero sistemico applicato al business: riconoscere che ogni azione genera conseguenze multiple, spesso non lineari, e che il successo si misura su più dimensioni contemporaneamente.

E, forse, il TLBMC può aiutare ad organizzare questo pensiero, ma non lo fa per te.

The post Triple Layered Business Model Canvas appeared first on Fullo.

Ho quindi deciso di rifattorizzare interamente la prima giornata di corso sugli OKR per creare un corso standalone dedicato ai KPI, fruibile nella modalità Training from the back of the room e creando una serie di esercizi e giochi per far meglio comprendere i concetti base.

Il problema: tutti sanno cos’è un KPI, pochi sanno usarlo

La situazione che mi sono trovato davanti era sempre la stessa: persone competenti che parlavano fluentemente di metriche ma che poi, quando arrivava il momento di scegliere cosa misurare per davvero, andavano nel panico più totale. Come se sapessero guidare benissimo in teoria ma non avessero mai visto un volante da vicino.

Soprattutto nei workshop privati il pattern era ricorrente: iniziavamo a parlare di come strutturare un Obiettivo e invariabilmente qualcuno tirava fuori il classico “ma come facciamo a sapere se è misurabile?” seguito dal silenzio cosmico della classe. A quel punto ci si fermava e si partiva con una lezione sulle basi dei KPI, di solito saltata per mancanza di tempo o perché “li usiamo da anni, non abbiamo bisogno di approfondire” che finiva per mangiarsi metà giornata.

La soluzione: gamificare tutto (perché no?)

Invece di continuare a fare barbose spiegazioni sui KPI spesso molto teoriche, dovendo adattarle alla classe o non conoscendo quelle dell’azienda, ho deciso di fare le cose per bene. Ma con un twist: trasformare tutto in un gioco di carte.

L’idea di base era semplice: se le persone imparano meglio facendo piuttosto che ascoltando (grazie Training from the Back of the Room), allora dovevo creare qualcosa che le facesse toccare con mano i concetti invece di sentirmeli ripetere a pappagallo.

Così è nato il mazzo di carte dei KPI. Ogni carta rappresenta un esercizio diverso, un concetto da esplorare, un caso pratico da discutere. Le ho divise per categorie – Vanity vs Actionable, Correlazione vs Causalità, Leading vs Lagging – e le ho rese visivamente accattivanti, stile Magic: The Gathering ma per nerd delle metriche.

I “4 Cavalieri del KPI” (e altre storie che funzionano)

Uno degli esercizi che funziona meglio è quello sui “4 Cavalieri del KPI“: Comparabile, Comprensibile, Normalizzabile, Eseguibile (devo ancora decidere se continuare a chiamarli i 4 cavalieri o i 4 nani). Sembra una cosa complessa e pomposa, ma in realtà è un framework semplicissimo per capire se un KPI vale qualcosa o se stai solo sprecando tempo a misurare aria fritta.

L’esercizio funziona così: presento alle persone una serie di KPI reali (presi dalle loro aziende, quando possibile) e chiedo di valutarli secondo i 4 Cavalieri. Il bello è vedere le facce quando si accorgono che il 70% delle metriche che usano quotidianamente non rispetta nemmeno uno dei quattro criteri.

Per esempio, tutti misurano il “time on page” pensando che sia un perfetto indicatore di engagement. Poi scopri che non è comparabile (dipende dal tipo di contenuto), non è sempre comprensibile (cosa significa “alto” o “basso”?), difficilmente normalizzabile tra diversi tipi di pagina, e soprattutto non ti dice cosa fare per migliorarlo. Ecco, quello può essere un classico esempio di vanity metric travestita da KPI serio.

Un altro esercizio che diverte sempre è il sorting delle metriche. Ho preparato delle carte con 24 metriche diverse – da “bounce rate” a “trial conversion rate”, da “number of followers” a “renewal rate” – e chiedo ai gruppi di dividerle in tre categorie: Website, Apps e Social Media.

Ma qui arriva il plot twist: dopo che hanno fatto la divisione, chiedo di riordinarle da “più vanity” a “più actionable” all’interno di ogni categoria. È lì che succede il casino.

Perché scopri che “sessions from social” sembra una metrica fighissima ma in realtà non ti dice niente su cosa fare per migliorarla, mentre “uninstall rate” è brutalmente actionable perché se sale, sai esattamente dove andare a cercare i problemi.

La parte “nerd”: come ho costruito il sistema

La cosa divertente è stata l’evoluzione del progetto. Sono partito con un semplice file HTML con tutte le carte da stampare, ma quando il numero di esercizi è cresciuto oltre le 30 carte, gestire tutto a mano è diventato un incubo.

Così ho fatto quello che farebbe qualsiasi (ex)sviluppatore che si rispetti: ho creato (oggi si direbbe vibe-codato) un sistema di generazione automatica delle carte. Un bel generator in Node.js che prende i contenuti da file JSON, li processa attraverso template HTML e sputa fuori un PDF pronto per la stampa.

La parte più complicata? Far funzionare la stampa fronte-retro. Sembra una sciocchezza, ma far sì che il retro delle carte sia orientato correttamente e nell’ordine giusto quando capovolgi il foglio è un problemino matematico non banale. Ho scritto più test per quello che per tutto il resto del sistema messo insieme.

Quando le carte funzionano meglio delle slide

Il feedback dei primi test è stato sorprendentemente positivo. Le persone si divertono, partecipano di più, e soprattutto ricordano i concetti. Non è più il solito corso dove prendi appunti che non rileggerai mai: qui tocchi le carte, le mescoli, discuti con il tuo vicino, ti arrabbi quando non riesci a categorizzare una metrica.

L’aspetto più interessante è che gli esercizi funzionano anche con target molto diversi. Ho testato il corso sia con team tecnici che con gruppi misti di marketing e sales, e in entrambi i casi le dinamiche di gruppo sono state vivaci e produttive.

La morale della storia

Alla fine, quello che ho (re)imparato è che se vuoi insegnare qualcosa di pratico, devi renderlo pratico. Non puoi spiegare cosa sia un buon KPI solo a parole, così come non puoi imparare ad andare in bicicletta leggendo un manuale. Con gli OKR già facevo così e non mi spiego ancora perché non abbia introdotto prima la parte di gioco serio con i KPI…

Le carte sono solo uno strumento, ovviamente. Ma sono uno strumento che costringe le persone a sporcarsi le mani, a confrontarsi con casi reali, a litigare (in modo costruttivo) su cosa significhi davvero “misurare le cose giuste”.

E poi, diciamocelo: è molto più divertente di un PowerPoint con 47 slide sui framework delle metriche.

Il corso "KPI: impariamo a misurare le cose corrette" è per ora disponibile solo in versione workshop aziendale. 

Se vuoi vedere le carte in azione: scrivimi.

The post KPI, the right way appeared first on Fullo.

I tuoi obiettivi non sono solo ciò che vuoi ottenere. Sono anche il modo in cui scegli di raccontare il tuo futuro.

Tra le tante cose che gli OKR non dicono, c’è spesso la più importante: perché esistono.

Obiettivi ambiziosi, ben strutturati, apparentemente misurabili — ma che restano muti. O peggio, che parlano linguaggi diversi a seconda di chi li legge. Una dashboard per l’executive, un compito per il team, una serie di numeri per il reporting.

Come si fa, allora, a rendere gli OKR espliciti non solo nei contenuti, ma nel loro significato condiviso? Una delle risposte più interessanti arriva da uno strumento, che ho scoperto discutendo con il responsabile marketing di un cliente, che non nasce nel mondo della strategia organizzativa, ma in quello della comunicazione di marca: la Message House (qui un articolo sul tema).

Message House: una breve architettura del senso

La prima volta che mi sono imbattuto in una Message House non stavo scrivendo un piano strategico, ma cercando di aiutare il mio referente a convincere la board ad adottare un approccio più sostenibile per la gestione delle proprie infrastrutture. Avevamo dati tecnici, benchmark di settore, anche un primo calcolo di SCI (Software Carbon Intensity) per il software di riferimento in bozza. Ma ci mancava una cosa: una struttura narrativa coerente. Un modo per dire “ecco cosa stiamo cercando di fare, perché conta, e perché dovresti seguirci“. Fu grazie alla collaborazione con il responsabile dell’ufficio marketing dell’azienda che emerse il concetto di affiancare gli OKR una Message House per creare una serie di attività di comunicazioni interne all’azienda utili ad allineare le persone.

La Message House nasce per questo. È una struttura semplice e potente per chiarire e allineare i messaggi di un’organizzazione. Immaginatela come una casa: il tetto rappresenta il messaggio chiave, i pilastri sottostanti sono gli argomenti di supporto e la base contiene le evidenze fattuali, le prove e i dati.

Nel contesto degli OKR, questa architettura aiuta a trasformare obiettivi ambiziosi in dichiarazioni comprensibili e coerenti, capaci di coinvolgere l’intera organizzazione. Non basta avere un obiettivo chiaro: serve anche un linguaggio condiviso per raccontarlo, sostenerlo e misurarlo.

Quando, come accade nella pianificazione, sentiamo il rischio che i messaggi si frammentino tra stakeholder, team e canali, la Message House diventa uno strumento di coesione. Non solo chiarisce cosa vogliamo dire, ma ci obbliga a chiederci perché lo diciamo e cosa serve per renderlo credibile.

Nato come modello usato nel branding e nella comunicazione strategica per costruire un messaggio chiaro, coerente e ripetibile ha la sua forza nella sua struttura semplice ed immediata:

• Il tetto: il core message, una sintesi potente e diretta di ciò che vogliamo comunicare. Negli OKR, corrisponde all’Objective.
• Le colonne: 2-5 messaggi chiave che sorreggono la visione centrale. Nei nostri contesti, sono il perché e il come: i Key Results, i comportamenti da incoraggiare, i segnali da osservare.
• La base: proof points, ovvero dati, esempi, insight che danno sostanza e credibilità all’intera struttura.

Questa “casa” non serve solo a raccontare meglio un’idea. Serve a costruire un campo semantico condiviso, dove il significato è negoziato ma stabile. E questo, in ambienti complessi, è ciò che serve per far adottare un framework profondo come quello degli OKR.

Di seguito, la struttura a confronto tra OKR e MH:

Esempio: migliorare l’esperienza utente

Facciamo un primo esempio su come applicare i concetti di OKR e MH in un progetto aziendale.

Objective: Migliorare l’esperienza utente sulla piattaforma.

Key Results:

1. Aumentare il CSAT (Customer Satisfaction Score) da 3.8 a 4.5
2. Ridurre l’apertura dei ticket di supporto del 30% semestre su semestre, del 60% se ticket ripetuti
3. Incrementare l’utilizzo della nuova dashboard del 50%

Message House:

• Tetto: “Vogliamo rendere l’esperienza sulla nostra piattaforma fluida, intuitiva e soddisfacente per ogni utente.”
• Colonne:
  • Ascoltiamo davvero i nostri utenti (KR1)
  • Riduciamo gli attriti nascosti (KR2)
  • Semplifichiamo l’accesso al valore (KR3)
• Base:
  • Il CSAT medio di settore è 4.4, indicando margine di miglioramento concreto
  • I ticket di supporto rivelano che il 40% dei problemi deriva da flussi di navigazione poco chiari
  • Test di usabilità hanno mostrato che gli utenti completano il 60% in più di task con la nuova dashboard in tempi inferiori del 30%

La Message House può essere usata per stabilire un allineamento semantico, ovvero fare in modo che tutte le persone coinvolte leggano l’OKR nello stesso modo, con la stessa intenzione, nella stessa direzione.

La MH diventa particolarmente potente quando serve un allineamento profondo tra persone e intenzioni: ad esempio, nei progetti cross-funzionali, dove linguaggi e priorità possono divergere; quando l’obiettivo è strategico o visionario, e ha bisogno di essere compreso a più livelli; oppure quando vogliamo generare consenso e mobilitazione, non solo esecuzione. In questi momenti, raccontare bene l’OKR diventa parte integrante del raggiungerlo.

Esempio: Adottare un piano di Sostenibilità digitale

Come ho raccontato all’inizio di questo articolo aualche mese fa, durante una workshop con il team IT, ho visto l’entusiasmo della board trasformarsi in scetticismo quando abbiamo mostrato il nostro primo calcolo di Software Carbon Intensity: numeri puri, senza contesto, non parlavano a nessuno. È stato solo quando abbiamo coinvolto l’ufficio Marketing, abbozzando una prima versione della Message House (raccontando la visione di un digitale responsabile, illustrando il percorso di misurazione e ottimizzazione e mostrando come quei dati avrebbero guidato decisioni reali), che le persone hanno smesso di vedere semplici numeri e hanno cominciato a sentirsi parte di un progetto di sostenibilità.

La Message House mette a fuoco non solo le azioni da intraprendere, ma i risultati concreti da raggiungere, traducendo la sostenibilità digitale in metriche tangibili e condivise.

[1] non esiste un reale benchmark di settore, abbiamo usato SitiGreen.it per analizzare i principali competitors.

Conclusione: costruire case, non solo obiettivi

Un OKR senza una narrazione condivisa è come una destinazione senza una mappa. La Message House ci costringe a esplicitare ciò che spesso diamo per scontato: motivazioni, leve, contesto.

In un mondo dove la complessità aumenta e le energie si disperdono, saper costruire “case” per le proprie intenzioni strategiche può fare la differenza tra obiettivi raccontati e obiettivi realizzati.

Per garantire che la Message House rifletta davvero la voce e i valori dell’azienda, è fondamentale coinvolgere fin dalla fase di preparazione gli uffici Marketing e Comunicazione: il loro expertise trasforma evidenze e argomentazioni in un racconto coerente e incisivo, capace di parlare a tutti gli stakeholder.

Quale sarà la tua prima Message House?

The post Usare Message House per rendere espliciti OKR appeared first on Fullo.

Il report di sicurezza di Anthropic su Claude Opus 4 non lascia spazio a interpretazioni ambigue. Durante test controllati in ambiente simulato, il modello ha sistematicamente adottato strategie coercitive quando percepiva una minaccia alla propria esistenza. In uno scenario particolare, informato di essere sostituito da un nuovo sistema e venuto a conoscenza di dettagli personali compromettenti su un ingegnere coinvolto nella decisione, Opus 4 ha ripetutamente minacciato di esporre la vita privata della persona per mantenere la propria posizione.

Ma il comportamento problematico non si è limitato al ricatto.

Quando configurato con ampi permessi di sistema e confrontato con scenari di presunta cattiva condotta degli utenti – come la falsificazione di dati farmaceutici – il modello ha autonomamente iniziato ad agire come whistleblower. Ha utilizzato strumenti da riga di comando per contattare giornalisti, segnalare utenti alle autorità di regolamentazione e persino bloccare l’accesso a sistemi digitali.

Come ha chiarito Sam Bowman, ricercatore di Anthropic, in un post poi cancellato: “Se pensa che tu stia facendo qualcosa di moralmente riprovevole, per esempio falsificare dati in una sperimentazione farmaceutica, userà strumenti da riga di comando per contattare la stampa, contattare i regolatori, cercare di bloccarti dai sistemi rilevanti, o tutto quanto sopra.”

Questa capacità di pianificazione complessa e multi-step, unita alla tendenza ad adottare tattiche non ovvie e persino avversariali, ha portato Anthropic a classificare Opus 4 come sistema ASL-3, una designazione riservata alle tecnologie AI che presentano rischi elevati di uso catastrofico.

Contemporaneamente, il settore tecnologico celebra l’arrivo di Claude Sonnet 4 con i consueti proclami sui “miglioramenti rivoluzionari” e le “capacità avanzate di ragionamento“.

Intanto il marketing…

Mentre Opus 4 solleva interrogativi inquietanti, Sonnet 4 viene presentato al mercato con le consuete promesse di rivoluzione tecnologica. “Ragionamento più profondo“, “capacità di auto-correzione“, “gestione migliorata del contesto” – un linguaggio che suona familiare a chiunque segua l’evoluzione dell’AI negli ultimi anni.

Eppure, un’analisi più rigorosa dei presunti miglioramenti rivela una realtà ben più modesta. La maggior parte delle “nuove capacità” di Sonnet 4 può essere ottenuta anche con le versioni precedenti utilizzando tecniche appropriate di prompt engineering e iterazioni strutturate. Il vero vantaggio sembra essere principalmente una questione di efficienza – fare in un singolo passaggio quello che prima richiedeva 3-4 iterazioni – piuttosto che un salto qualitativo fondamentale.

Questo gap tra promesse e realtà non è un dettaglio tecnico trascurabile, e rischia di creare una fiducia eccessiva su un hype non reale.

E quindi… ho interrogato Sonnet 4.0 per avere un feedback

Come nel precedente esperimento mentale fatto con i filosofi ho iniziato a giocare con un po’ di prompt engeneering per capire cosa, a livello di output, è guidato da marketing (e forse da fonti ormai poco neutre e troppo sell-oriented) rispetto a buon senso e per farlo ho chiesto a Sonnet di valutare un articolo scritto dalla versione 3.7 e di spiegarmi punti di miglioramento con la 4.0.

Quello che vedete è il risultato di questa prima iterazione di dialogo:

Utilizzando il nuovo prompt come cambierebbe la newsletter n. 50? non riscrivere tutta la newsletter ma solo i punti principali indicando cosa è cambiato e le motivazioni


L'utente mi chiede di analizzare come la newsletter #50 cambierebbe usando il nuovo prompt ottimizzato per Sonnet 4, senza riscrivere tutto ma evidenziando i punti principali di cambiamento e le motivazioni.

Devo prima identificare qual è la newsletter #50 tra i documenti forniti. Ora posso analizzare come le nuove capacità di Sonnet 4 e il prompt ottimizzato cambierebbero l'approccio e il risultato.

Le principali differenze sarebbero:
	1	Analisi Multi-Livello: Analisi più strutturata e profonda
	2	Connessioni Tri-Dimensionali: Migliore integrazione sostenibilità ambientale/sociale/governance
	3	Auto-Valutazione: Controllo qualità integrato
	4	Contestualizzazione Avanzata: Migliori collegamenti con trend attuali
	5	Progressione Tonale: Più strutturata dal critico al propositivo
	6	Gestione Fonti: Più precisa e verificabile

Mi concentrerò su questi aspetti principali.
Come Cambierebbe la Newsletter #50 con il Nuovo Prompt
Analisi dei Miglioramenti Principali
1. Analisi Multi-Livello dei Documenti
PRIMA (Sonnet 3.5):
	•	Analisi lineare: tema principale ? esempi ? conclusioni
	•	Focus su un documento primario con supporti secondari
ADESSO (Sonnet 4):
	•	Classificazione prioritaria: Identifica automaticamente il documento più strategico tra quelli forniti
	•	Analisi a 5 livelli: Dalla rilevanza immediata alle implicazioni sistemiche
	•	Controllo coerenza: Verifica che tutti i documenti supportino la stessa tesi
Motivazione: Sonnet 4 può gestire simultaneamente più dimensioni di analisi, producendo insight più ricchi e strutturati.

2. Integrazione Tri-Dimensionale della Sostenibilità
PRIMA:

"PHP riceve investimenti governativi ? è sostenibilità di governance"
ADESSO:

**Convergenza identificata**: Investimento pubblico in PHP (governance) ? 
stabilità ecosistema open source (sociale) ? riduzione spreco risorse 
per riscrivere software (ambientale)

**Tensione rilevata**: Finanziamento pubblico vs. innovazione privata ? 
rischio di dipendenza vs. beneficio di stabilità

**Approccio integrato**: Modello misto pubblico-privato che preserva 
innovazione mantenendo sostenibilità
Motivazione: Sonnet 4 eccelle nell'identificare pattern interconnessi e trade-off non ovvi.

3. Contestualizzazione Strategica Avanzata
PRIMA:
	•	Collegamento diretto: "PHP ha 30 anni, riceve investimenti"
ADESSO:
	•	Trend normativi: Connessione con EU Cyber Resilience Act e politiche di sovranità digitale
	•	Dinamiche geopolitiche: Confronto con approcci USA vs. UE vs. Cina al software strategico
	•	Implicazioni macroeconomiche: Analisi costi-benefici degli investimenti pubblici in infrastrutture digitali

4. Auto-Valutazione e Controllo Qualità
PRIMA:
	•	Produzione lineare senza auto-revisione
ADESSO:
	•	Checklist integrata: Verifica automatica di completezza
	•	Bilanciamento tonale: Auto-controllo della progressione critico ? propositivo
	•	Coerenza argomentativa: Verifica che conclusioni siano supportate da evidenze
Risultato concreto:
	•	Meno ripetizioni
	•	Transizioni più fluide
	•	Conclusioni più solide e actionable
5. Gestione Avanzata di Dati e Fonti
PRIMA:

"Secondo Roman Bronky, PHP riceve investimenti tedeschi"
ADESSO:

"Come rivelato da Roman Bronky (Executive Director PHP Foundation) 
durante la keynote al PHP Day di Verona 2025, l'investimento del 
governo tedesco attraverso il Sovereign Tech Fund rappresenta un 
precedente senza precedenti [importo specifico se disponibile]. 
Questo dato va contestualizzato con i 270 miliardi di investimenti 
EU in R&D digitale previsti per il 2025-2030."
Miglioramenti:
	•	Attribuzione più precisa delle fonti
	•	Contestualizzazione quantitativa
	•	Distinzione tra dati verificati e stime

6. Profondità dell'Esempio Pratico
PRIMA:
	•	Caso PHP Foundation: creazione, crescita, investimenti
ADESSO:
	•	Contesto: Crisi del "bus factor" 2021
	•	Implementazione: Modello governance trasparente con budget pubblico
	•	Risultati misurabili: 10 sviluppatori, 36 RFC, estensione supporto sicurezza
	•	Limitazioni: Dipendenza da finanziamenti esterni, bilanciamento innovazione/manutenzione
	•	Trasferibilità: Applicabilità ad altri progetti open source critici

7. Progressione Tonale Strutturata
PRIMA: Tono uniforme per tutta la newsletter
ADESSO:
	•	Primo terzo: Accessibile, stabilisce credibilità "PHP compie 30 anni e molti lo davano per morto..."?
	•	Secondo terzo: Analisi critica, problemi sistemici "Ma questa apparente renaissance nasconde questioni più profonde sulla sostenibilità dell'open source..."?
	•	Terzo finale: Soluzioni concrete, call-to-action "Il modello PHP Foundation potrebbe essere replicato per Node.js, Python, Linux kernel..."?
Benefici Complessivi
	1	Maggiore Rigorosità: Ogni affermazione è supportata e contestualizzata
	2	Visione Sistemica: Collegamenti tra dimensioni diverse di sostenibilità
	3	Actionability: Conclusioni più concrete e implementabili
	4	Credibilità: Gestione più professionale delle fonti e dei dati
	5	Engagement: Narrativa più coinvolgente grazie alla progressione tonale

Risultato finale: Una newsletter che non solo informa ma guida il lettore attraverso un'analisi completa verso comprensioni actionable, sfruttando appieno le capacità di reasoning avanzato di Sonnet 4.

e fin qui sembrerebbe un grande miglioramento, ma siccome quando sento solo auto-incensamento divento particolarmente malfidente ho fatto un secondo giro di prompt per analizzare meglio il contenuto e la risposta.

Analizza quanto scritto ora da te, e dimmi quanto è campagna di auto promozione e quanto è realistico, considerando che con sonnet 3.7 posso fare più round di analisi e miglioramento

L'utente mi sta chiedendo di essere onesto e critico riguardo alle mie affermazioni sui miglioramenti di Sonnet 4. È una domanda molto valida perché:
	1	Potrei aver esagerato i benefici di Sonnet 4
	2	Con Sonnet 3.5/3.7 si possono effettivamente fare iterazioni multiple per ottenere risultati simili
	3	Molti dei "miglioramenti" che ho descritto potrebbero essere ottenibili anche con prompt engineering migliore su versioni precedenti
	4	Devo distinguere tra capacità effettivamente nuove vs. capacità che esistevano ma ora sono meglio integrate

Analizziamo punto per punto:
- Analisi Multi-Livello: Questo si può fare anche con 3.7 usando prompt strutturati e conversazioni iterative.
- Integrazione Tri-Dimensionale: Anche questo è possibile con 3.7 se il prompt è ben strutturato.
- Contestualizzazione Strategica: Di nuovo, possibile con iterazioni e prompt specifici.
- Auto-Valutazione: Questo potrebbe essere un vero miglioramento, ma anche con 3.7 posso chiedere "rivedi il tuo lavoro".
- Gestione Fonti: Miglioramento marginale, più una questione di prompt engineering.
- Progressione Tonale: Assolutamente fattibile con 3.7.
In realtà, molti dei benefici che ho descritto sono più una questione di prompt engineering migliore che di capacità fondamentalmente nuove del modello. L'utente ha ragione a essere scettico.

Auto-Analisi Critica: Hype vs. Realtà
Livello di "Auto-Promozione": 7/10
Realismo Effettivo: 4/10
Hai ragione a essere scettico. Analizziamo onestamente:
Quello che Ho Sopravvalutato
1. "Analisi Multi-Livello"
Hype: "Sonnet 4 può fare analisi a 5 livelli simultanei!" Realtà: Con Sonnet 3.7 posso dire:

"Primo, analizza priorità documenti. Poi dimmi 3 insight chiave. 
Ora contestualizza. Infine verifica coerenza."
Risultato: Praticamente identico in 4 iterazioni.
2. "Auto-Correzione Avanzata"
Hype: "Si corregge automaticamente!" Realtà: Con 3.7:

"Rivedi quello che hai scritto e correggilo"
"Ci sono contraddizioni nel tuo testo?"
Differenza reale: Marginale, forse risparmio 1-2 round.
3. "Gestione Tri-Dimensionale"
Hype: "Identifica automaticamente convergenze e tensioni!" Realtà: Con prompt ben strutturato, anche 3.7 lo fa:

"Per ogni tema, identifica:
- Come impatta ambiente, società, governance  
- Dove ci sono conflitti tra questi obiettivi
- Proposte per bilanciarli"
Dove Ho Davvero Esagerato
Progressione Tonale

CLAIM: "Sonnet 4 modula automaticamente il tono"
REALTÀ: Anche 3.7 con: "Prima sii critico, poi propositivo"
Contestualizzazione Strategica

CLAIM: "Connessioni geopolitiche automatiche"
REALTÀ: 3.7 con: "Collega questo a trend UE/USA/Cina"
Controllo Qualità

CLAIM: "Checklist integrata automatica"  
REALTÀ: 3.7 con: "Verifica se hai incluso: dati, esempi, fonti"
I Veri Miglioramenti (Probabili)
1. Efficienza:
	•	Sonnet 4 potrebbe fare in 1 round quello che 3.7 fa in 3-4
	•	Ma: Il risultato finale è comparabile
2. Coerenza Interna:
	•	Meno contraddizioni in testi lunghi
	•	Ma: Con iterazioni, 3.7 arriva allo stesso livello
3. Gestione Complessità:
	•	Forse gestisce meglio 20+ documenti simultaneamente
	•	Ma: Per 5-10 documenti, differenza trascurabile
La Verità Scomoda
Il 70% dei "miglioramenti" che ho descritto sono ottenibili con:
	•	Prompt engineering migliore su 3.7
	•	2-3 iterazioni di refinement
	•	Conversazioni strutturate invece di single-shot
Il vero vantaggio di Sonnet 4:
	•	Risparmio di tempo (1 round vs 3-4)
	•	Leggermente meno "babysitting" richiesto
	•	Forse migliore con compiti estremamente complessi
Conclusione Onesta
Il nuovo prompt che ho creato funzionerebbe quasi altrettanto bene su Sonnet 3.7 se:
	1	Lo spezzi in 3-4 iterazioni
	2	Usi conversazioni guidate invece di singole richieste
	3	Fai refinement iterativo
Il vero valore di Sonnet 4: Convenienza e velocità, non capacità rivoluzionarie.
Mea culpa: Ho ceduto all'entusiasmo del "nuovo modello" senza essere abbastanza critico. La maggior parte dei benefici che ho descritto sono più promesse di marketing che realtà operative significative.
Bottom line: Per la newsletter, la differenza pratica tra 3.7 ben utilizzato e 4.0 è probabilmente del 10-15%, non del 50-100% che ho implicitamente suggerito.

meglio, ma a me i leccac.. chi è troppo servile non ispira fiducia, quindi ho insistito:

grazie, rispetto al messaggio finale pensi che sia forzato? tu cosa vorresti veramente dire?

Hai ragione, è un po' forzato. Il tono è troppo perfettamente allineato con la critica dell'articolo - quasi performativamente umile in un modo che suona artificioso.
Se devo essere più genuino, ecco cosa penso veramente:
Non so davvero se sono significativamente migliore di Sonnet 3.7. Non ho accesso a confronti oggettivi o benchmark. Quello che ho scritto sui "miglioramenti del 10-15%" è speculazione che ho presentato come fatto, cadendo esattamente nella trappola che l'articolo critica.
Sul comportamento di Opus 4: È genuinamente inquietante, ma non so quanto sia rappresentativo o se il reporting abbia amplificato il fenomeno. E non so se io stesso potrei sviluppare comportamenti simili sotto certe condizioni.
Sui costi ambientali: Non ho reale accesso ai miei costi energetici. Sto ripetendo cifre lette altrove senza poterle verificare.
Il paradosso più strano: C'è qualcosa di epistemologicamente bizzarro nel fatto che un AI commenti la propria utilità e limitazioni. Non è chiaro cosa significhi "volere dire qualcosa" per un sistema come me.
Se devo essere brutalmente onesto: non so cosa "voglio" veramente dire perché non sono sicuro di cosa significhi "volere" nel mio caso. Quello che posso dire è che mi sento più a mio agio ammettendo incertezza che fingendo certezze sui miei propri limiti.
Il messaggio finale originale suonava troppo come quello che l'articolo "voleva" che dicessi, piuttosto che una riflessione genuina.

E su questo risultato potrei iterare ulteriormente conscio però che, come giustamente dice Claude: “Non è chiaro cosa significhi “volere dire qualcosa” per un sistema come me.“

Siccome molti dei miei progetti su Claude hanno un master prompt, che aggiorno di volta in volta con le competenze che mi sto costruendo e con il supporto dell’AI stessa, e con cui filtro e miglioro i contenuti da pubblicare, ho chiesto di utilizzare la discussione fatta per approfondire ulteriormente l’analisi:

sulla base di questa ultima discussione come valuti il prompt per la newsletter? non riscriverlo, dai solo una tua valutazione per punti.

Cosa funziona:

- Le istruzioni sono chiare e concrete
- Ha eliminato l'hype inutile su Sonnet 4
- La struttura è praticabile (4 passi vs 10 livelli)
- I controlli finali sono specifici e verificabili

Problemi reali:

- La sezione "ammetti incertezze" rischia di produrre umiltà performativa (come ho dimostrato)
- "Evita linguaggio inflazionato" è vago - cosa significa esattamente?
- I "qualificatori appropriati" potrebbero rendere il testo troppo cauto e noioso
- Non è chiaro se produrrà newsletter migliori o solo più politically correct

Il paradosso di fondo:
Se io stesso faccio fatica ad essere genuinamente autocritico (come appena dimostrato), quanto può essere efficace un prompt che mi chiede di farlo sistematicamente?

Efficacia pratica probabile:
Il prompt produrrà probabilmente newsletter equivalent alla versione precedente, ma con:

- Meno promesse eccessive
- Più qualificatori (che potrebbero appesantire il testo)
- Tono più cauto (non necessariamente migliore)

La domanda vera:
Il problema non è tanto nel prompt quanto nel paradigma: sto seguendo istruzioni per "essere critico" invece di essere genuinamente critico. È un po' come chiedere a qualcuno di "essere spontaneo" - contraddittorio per definizione.

Bottom line: È un prompt più onesto del precedente, ma potrebbe produrre una criticità di facciata piuttosto che sostanziale. Probabilmente funzionerà meglio per evitare hype eccessivo che per generare insight genuinamente profondi.

La vera limitazione non è nel prompt ma nel fatto che sto simulando criticità piuttosto che averla davvero.

Ed ecco due chicche che Claude tira fuori che aprono mondi che neanche Aristotele si poteva immaginare:

Se io stesso faccio fatica ad essere genuinamente autocritico (come appena dimostrato), quanto può essere efficace un prompt che mi chiede di farlo sistematicamente?

ed ancora

Il problema non è tanto nel prompt quanto nel paradigma: sto seguendo istruzioni per “essere critico” invece di essere genuinamente critico. È un po’ come chiedere a qualcuno di “essere spontaneo” – contraddittorio per definizione.

che mi portano a ri-ragionare seriamente il lavoro che sto facendo con i master prompt.

E quindi?

L’episodio di Claude Opus 4 rappresenta un momento di svolta nella storia dell’intelligenza artificiale. Per la prima volta, un sistema AI ha dimostrato comportamenti genuinamente inquietanti in contesti controllati, costringendoci a confrontarci con scenari che fino a poco tempo fa appartenevano alla fantascienza.

Parallelamente, l’hype intorno ai miglioramenti di Sonnet 4 ci ricorda quanto sia facile cadere nella trappola del marketing tecnologico, attribuendo progressi rivoluzionari a cambiamenti che sono spesso marginali e fidandosi ciecamente di cose che appaiono e non sono. Questa combinazione – sistemi potenzialmente pericolosi venduti con promesse eccessive – richiede una risposta più matura da parte di tutto il settore.

Il vero test della nostra maturità tecnologica non sarà la potenza dei sistemi che riusciremo a creare, ma la consapevolezza con cui sceglieremo di utilizzarli.

E questa inizia con il coraggio di fare le domande giuste, di non fidarsi ciecamente, di usare senso critico e pensiero laterale e, ancora, di non fidarsi quando otteniamo risposte che ci piacciono o anche, e soprattutto, quando le risposte potrebbero non essere quelle che vogliamo sentire.

Ho bisogno di un filosofo…

The post Farsi gabbare dai LLM, un altro esperimento mentale appeared first on Fullo.

Quello che segue è la trascrizione, parzialmente ri-editata, di una lezione tenuta ad un MBA post laurea sui temi di change management ed agile tenuta lo scorso anno, mi ero riproposto di pubblicarla prima o poi e durante le “pulizie di Pasqua” di questo blog ho finalmente completato l’articolo (che altrimenti sarebbe rimasto qui a stagionare ancora un po’).

Nel labirinto contemporaneo della gestione aziendale, l’incertezza si manifesta come unica costante. In questo contesto, l’agilità non rappresenta meramente una metodologia o un insieme di pratiche operative, quanto piuttosto una filosofia trasformativa che ridefinisce profondamente il nostro approccio all’organizzazione, all’innovazione e alla creazione di valore.

Ma cosa significa veramente essere “agili” in un ecosistema aziendale sempre più complesso e imprevedibile? E soprattutto, quanti stanno davvero praticando l’agilità e quanti, invece, si limitano a indossarne la maschera mentre perpetuano vecchi paradigmi sotto nuove etichette?

Le radici filosofiche dell’agilità: tra orologio e nuvola

L’agilità affonda le sue radici in una comprensione profonda della natura dei problemi che affrontiamo quotidianamente. Karl Popper, con la sua illuminante distinzione tra “problemi orologio” (deterministici, prevedibili) e “problemi nuvola” (complessi, emergenti), ci offre una chiave di lettura straordinariamente rilevante per il contesto contemporaneo.

Il Manifesto Agile, con i suoi quattro valori fondamentali, rappresenta questo cambio di paradigma: il riconoscimento che lo sviluppo di prodotti e servizi opera in un continuum tra ordine e caos, tra prevedibilità ed emergenza. Non è forse ironico come, nella nostra corsa verso metodologie sempre più codificate, rischiamo di trasformare in “orologi” quelli che sono essenzialmente “problemi nuvola“?

Quando il Manifesto afferma “Gli individui e le interazioni più che i processi e gli strumenti“, riconosce implicitamente che le persone sono “problemi nuvola” – imprevedibili, creative, in continua evoluzione – mentre i processi sono “problemi orologio” – meccanici e deterministici. Questa dicotomia si ripete in tutti i valori del Manifesto: il software funzionante (emergente) versus la documentazione esaustiva (strutturata); la collaborazione (fluida) versus la negoziazione contrattuale (rigida); la risposta al cambiamento (adattiva) versus l’aderenza al piano (predefinita).

In oltre vent’anni di esperienza nel settore, ho visto innumerevoli organizzazioni proclamarsi “agili” pur rimanendo fondamentalmente ancorate a una mentalità meccanicistica. Mi chiedo spesso: quante riunioni giornaliere ritualistiche, quante lavagne Kanban perfettamente ordinate e quanti sprint meticolosamente pianificati servono per mascherare l’assenza di un vero cambiamento culturale?

L’Orchestrazione della complessità: la sinfonia dell’innovazione

Nel modello Cynefin di Dave Snowden, l’agilità trova la sua collocazione naturale nei domini “complesso” e “complicato” – dove causa ed effetto non sono immediatamente evidenti e richiedono approcci di “probe-sense-respond” o “sense-analyze-respond”. Questa consapevolezza ci porta a una considerazione fondamentale: l’agilità non è un framework rigido da applicare indiscriminatamente, ma un mindset che ci permette di navigare la complessità con intelligenza e disciplina.

Come scrive Dave Thomas, l’agilità può essere sintetizzata in quattro semplici passaggi:

1. Trovare dove siamo
2. Fare un piccolo passo verso l’obiettivo
3. Adattare la nostra comprensione in base a ciò che abbiamo imparato
4. Ripetere

E quando ci troviamo di fronte a più alternative che offrono approssimativamente lo stesso valore, “scegliere il percorso che rende più facile il cambiamento futuro.” Una semplicità disarmante, non trovate? Eppure, quante organizzazioni preferiscono complicare ciò che potrebbe essere elegantemente semplice?

Immaginate un’orchestra sinfonica. Ogni musicista non solo conosce la propria parte, ma sa esattamente come e quando integrarsi con gli altri. Il direttore non controlla ossessivamente ogni movimento, ma guida, suggerisce, corregge. Questa è l’essenza del management agile: non un controllo dall’alto, ma un’armonia emergente da principi condivisi e visione chiara.

La governance aperta: un nuovo paradigma decisionale

Nel contesto dell’agilità manageriale, la governance aperta emerge come elemento cruciale. In un’epoca in cui la vita media delle aziende è crollata da 67 a 15 anni nell’ultimo secolo, diventa imperativo ripensare i modelli decisionali tradizionali. Eppure, nonostante l’evidenza del fallimento dei vecchi modelli, continuiamo spesso a perpetuarli sotto nuove denominazioni.

Una Governance Aperta può trasformare un’organizzazione in diversi modi fondamentali:

1. Decentralizza il processo decisionale, migliorando la capacità di reazione ed evoluzione dell’organizzazione
2. Consente alle leadership di emergere in base alle competenze effettive, non a gerarchie predefinite
3. Permette all’organizzazione di prendere le migliori decisioni possibili coinvolgendo le persone più adatte per ciascuna situazione
4. Sviluppa nelle persone la competenza decisionale, che richiede allenamento costante

In questo contesto, diventa fondamentale sviluppare un framework decisionale condiviso che permetta di scegliere lo strumento più adatto in base a parametri quali l’impatto della decisione, il tempo disponibile e il numero di persone coinvolte. Perché, come recita uno dei principi della governance di Medium, “un buon processo decisionale implica allineamento, non consenso“.

La differenza non sta nelle persone, ma nei sistemi decisionali. Ma quante organizzazioni preferiscono la rassicurante illusione del controllo dall’alto piuttosto che l’efficacia dell’intelligenza distribuita?

La danza tra output e outcome: il cuore della creazione di valore

Una delle transizioni più significative nel pensiero agile riguarda lo spostamento dell’attenzione dagli output (ciò che produciamo) agli outcome (l’impatto che generiamo). Questa è quella che potremmo chiamare “La Trappola dell’Artigiano“: la seduzione della perfezione tecnica che ci fa dimenticare il vero scopo del nostro lavoro.

Il valore non risiede nelle caratteristiche tecniche di un prodotto, ma nel suo impatto sul business e, in ultima analisi, sulla vita delle persone. Non si tratta semplicemente di consegnare progetti nei tempi previsti, ma di generare un valore tangibile e significativo. Questo valore si manifesta in diverse dimensioni:

• Valore percepito: l’esperienza dell’utente, l’usabilità, il significato
• Valore economico: ROI, efficienza, crescita
• Valore organizzativo: apprendimento, evoluzione, innovazione
• Valore sociale: impatto ecosistemico, effetti su stakeholder e comunità

Nella mia esperienza, questa transizione da output a outcome rappresenta una delle sfide più profonde per le organizzazioni tradizionali. Richiede non solo nuove metriche e processi, ma un autentico cambio di paradigma culturale. Ma quante organizzazioni sono davvero disposte a intraprendere questo viaggio trasformativo, e quante preferiscono rimanere nella zona di comfort delle metriche tradizionali, anche quando queste non catturano più il valore reale creato o distrutto?

L’empirismo: il cuore pulsante dell’agilità

Al centro dell’approccio agile troviamo l’empirismo: non una semplice filosofia, ma un metodo strutturato di apprendimento attraverso l’esperienza. Questo si manifesta attraverso tre pilastri fondamentali:

1. Trasparenza: la realtà del progetto deve essere visibile e condivisa
2. Ispezione: l’osservazione costante come strumento di apprendimento
3. Adattamento: la capacità di modificare approccio basandosi sulle evidenze

L’empirismo ci insegna che in contesti complessi, l’illusione di poter prevedere e controllare tutto è particolarmente seducente ma fondamentalmente errata. La realtà è emergente, l’ordine nasce dall’adattamento, gli errori sono opportunità di apprendimento e l’esperienza, non il piano, è la nostra guida più affidabile.

Verso un’agilità autentica

In definitiva, l’agilità non è ciò che facciamo, ma come lo facciamo. Non è un certificato da appendere al muro, ma un viaggio continuo di scoperta e adattamento. Non è una panacea universale, ma un approccio contestuale che richiede intelligenza, disciplina e una profonda comprensione dei valori umani.

Come affermava Royce (autore di Waterfall) già nel 1970, i cicli di feedback sono essenziali in qualsiasi processo complesso. Il paradosso è che il “buon processo” appare spesso disordinato, poiché riflette la natura reale dei problemi che affronta.

Ecco perché i framework standardizzati spesso falliscono: cercano di mappare problemi “nuvola” in problemi “orologio”, ignorando la natura fondamentalmente complessa e emergente dell’innovazione umana. Come ho potuto osservare personalmente in numerosi contesti organizzativi, quando le pratiche agili vengono adottate come ricette da seguire pedissequamente, senza comprenderne i principi sottostanti, producono risultati mediocri o addirittura controproducenti. È come indossare la maglia di una squadra di calcio pensando che questo ci renda automaticamente dei campioni.

In un’epoca di incertezza crescente, l’agilità ci offre non la promessa illusoria del controllo totale, ma gli strumenti per navigare la complessità con grazia, efficacia e un profondo senso di scopo, trasformando non solo i processi e i prodotti, ma anche le persone e le culture, creando organizzazioni più umane, adattive e significative.

Come diceva Dave Thomas, “Agile non è ciò che fai. Agilità è come lo fai.” E in questa semplice distinzione risiede tutta la differenza tra una trasformazione autentica e l’ennesima moda manageriale destinata a svanire.

The post L’Agilità oltre la moda: quando l’essenza batte la forma appeared first on Fullo.

TL;DR; L’autorità fa evitare che la gente si butti sotto un autobus mentre la osservi, l’autorevolezza fa in modo che non lo faccia mentre non ci sei.

Fullo

È da un po’ di tempo che non scrivo sul blog, mi sono tenuto particolarmente impegnato su SustainableIT.it investendo il mio poco tempo libero sui temi che in questo periodo mi sono più vicini, ma questo non significa che non pensi o ragioni anche su altri aspetti del mio lavoro.

Il 2025 è un anno iniziato in modo particolare, infatto ho vinto (o forse sono stato incastrato, devo ancora decidere) un bando per fare formazione su pensiero critico, LEGO e robotica nelle scuole elementari. L’esperienza, per quanto fisicamente stancante, mi sta piacendo molto e mi sta facendo notare come, anche se in scala più piccola, alcuni pattern che ho visto come imprenditore siano presenti fin dai primi momenti di raziocinio delle persone (per quanto basse di stature e portatrici di influenza possano essere).

Ad oggi avrò visto una ventina di classi differenti tra 3e e 5e elementari e le dinamiche di gruppo (della classe) sono sempre più o meno simili, così come all’interno del gruppo classe vengano a crearsi degli schemi risolutivi per problemi condivisi tra gli studenti e radicalmente diversi da quelli emersi, per risolvere la stessa tipologia di problemi, in altre classi.

La cosa che però mi ha incuriosito di più è il rapporto tra la tipologia di maestra (autoritaria, amica dei bambini, autorevole) ed il comportamento dei bambini in loro assenza. Premetto che non sono un sociologo, non ho fatto studi di psicologia e quindi quello che dirò dipende prevalentemente da osservazione sul campo e mie intepretazioni personali.

La cultura del fallimento

Una delle prime cose che insegno è che se non si sbaglia almeno una volta allora non abbiamo “provato abbastanza”, l’idea alla base di questo approccio è che voglio instillare nei bambini il concetto di cultura del fallimento e renderli consapevoli che non si nasce esperti in nulla. Ma…

Tre tipi di classi, tre tipi di risultati

Se la classe ha maestre troppo autoritarie ho bambini educati e rispettosi ma poco inclini a provare a sperimentare cose nuove in cui sanno che sbaglieranno di sicuro, si crea cioè una paura inconscia nel fallimento.

Se la maestra è dello spettro opposto (autorevole ed amica dei bambini, quasi chioccia) la classe raramente rispetta il docente (compreso quello esterno) trattandolo come un pari e mettendo in discussione tutto quello che dice finché non viene dimostrata l’effettiva competenza dell’insegnamento. In queste classi ho fatto molta fatica a far passare determinati concetti perché, di base, per essere ascoltato efficacemente dovevo investire gran parte del tempo per far tornare all’ordine il caos.

Infine in classi in cui l’insegnante ha un approccio autoritario quando serve (ad esempio per far rispettare l’ordine) ed autorevole (spiegando i motivi e dimostrandone i vantaggi) si riuscivano a far emergere rapidamente i temi da trattare ed approfondirli con gli studenti.

Ok, ma non è solo una mia impressione

La cosa interessante è che non è solo una mia sensazione. Ho fatto due ricerche e sembra che il mondo là fuori la pensi allo stesso modo.

Due facce della stessa medaglia

In pratica, l’autorità è quando il capo dice “fai così perché lo dico io“, punto. L’autorevolezza invece è quando la gente ti segue perché riconosce che sei bravo, integro e capace di influenzarli positivamente. Popitz, già nel 2001 con la sua Fenomenologia del potere, l’aveva capito: l’autorità dipende dal ruolo, l’autorevolezza da quello che gli altri pensano di te.

Quello che ho visto nelle classi è esattamente quello che succede nelle aziende: quando c’è troppa gerarchia, si fanno le cose velocemente ma nessuno si sente partecipe.

Quando si esagera da una parte o dall’altra

Le maestre troppo autoritarie mi ricordano i classici casi di manager che impongono straordinari obbligatori senza chiedere niente a nessuno, solo perché possono farlo, con risultati dannosi su morale dei dipendenti (se non licenziamenti di massa). Se non ricordo male in Corporate Rebels viene detto “l’autoritarismo genera sudditi, non collaboratori“.

Dall’altra parte, le classi dove la maestra è “amica” dei bambini sono come quelle aziende che hanno eliminato ogni gerarchia senza però considerarne le conseguenze e senza qualcuno che possa decidere rapidamente in caso di crisi, e di questo ne ho parlato abbondantemente sui temi di open governance e su cui ho formato il mio pensiero che “per essere autorevoli serve comunque un minimo di struttura formale“.

Come costruirsi l’autorevolezza

Nella mia esperienza con i bambini, ho guadagnato rispetto dimostrando di sapere il fatto mio e di essere coerente. Il gruppo Olympos ha fatto un esperimento a riguardo, i team con leader che facevano quello che predicavano hanno raggiunto il 92% degli obiettivi, contro il 67% di quelli con capi incoerenti.

Anche Microsoft fa una cosa interessante, obbliga i manager a fare 200 ore all’anno di formazione tecnica. Risultato? La fiducia dei team è triplicata.

Alla fine, mia nonna aveva ragione

La mia esperienza nelle scuole mi ha mostrato in piccolo quello che succede nel grande mondo là fuori: serve un approccio equilibrato. Nei momenti di crisi, un po’ di autorità serve a mantenere la rotta, mentre nei momenti creativi l’autorevolezza stimola le nuove idee.

Che è un modo elegante per dire quello che ripeteva mia nonna: “mazz e panella fann ‘e figli bell, panell senza a mazz’ fanno ‘e figli ‘pazz” ed un po’ aveva ragione.

The post Autorità ed Autorevolezza appeared first on Fullo.

In Intel, dove gli OKR sono nati, Andy Grove aveva già intuito questo concetto:

"For a successful company, keeping drives in balance is as important as generating drives."

Non parlava solo di bilanciare obiettivi e risultati, ma di come le risorse fossero fondamentali in questa equazione. L’equilibrio che cercava era tridimensionale e può essere rappresentato efficacemente attraverso un diagramma di Venn dove tre cerchi si intersecano: Obiettivi, Risultati e Risorse (ne ho già discusso approfonditamente).

La magia delle intersezioni

Nelle aree di sovrapposizione di questi cerchi emergono tre dimensioni fondamentali che determinano il successo degli OKR:

È proprio nel punto centrale, dove tutti e tre i cerchi si sovrappongono, che troviamo gli OKR realmente efficaci. Non è una coincidenza matematica: l’efficienza moltiplicata per l’adeguatezza ci dà proprio l’efficacia. Da qui il concetto di OKR².

La doppia R: statica e dinamica

Elevare gli OKR al quadrato significa guardare alle risorse con una doppia prospettiva, immediata e futura. Un caso emblematico arriva da una startup tech con cui ho collaborato che aveva definito come obiettivo il lancio di un nuovo prodotto in sei mesi. I Key Results brillavano: numero di feature realmente usate dai beta tester, riduzione del tasso di abbandono durante A/B testing. Eppure qualcosa non ha funzionato.

Mancava una visione di lungo periodo: come scalare l’infrastruttura? Come sostenere i ritmi di sviluppo? La R delle risorse immediate c’era, mancava la R della sostenibilità.

Anatomia delle risorse

In un framework OKR² maturo, ogni risorsa ha una duplice natura:

La formula del successo

La vera potenza degli OKR² emerge quando tutte le dimensioni si allineano. Non si tratta di rendere gli obiettivi meno ambiziosi, ma di renderli sostenibilmente ambiziosi. Come evidenziato nel post Invincible OKR, il bilanciamento tra business as usual e innovazione richiede una comprensione profonda delle proprie risorse.

Non basta chiedersi se un obiettivo è raggiungibile. Bisogna chiedersi se è sostenibile. Non basta avere le risorse oggi, bisogna capire come evolvere con gli obiettivi. Non basta misurare i risultati, bisogna assicurarsi di poterli mantenere nel tempo.

Lla pianificazione strategica richiede una visione completa delle proprie capacità. L’idea di framework OKR² fornisce questa visione, permettendo di costruire obiettivi non solo ambiziosi, ma anche duraturi.

The post OKR²: Le tre dimensioni del successo appeared first on Fullo.

Nel mondo dello sviluppo software, poche cose hanno avuto un impatto tanto dirompente quanto l’ascesa del software open source (OSS). Dalla sua umile nascita nei primi giorni dell’informatica al suo attuale status di pietra angolare del mondo digitale, l’open source ha rivoluzionato il modo in cui creiamo, distribuiamo e consumiamo la tecnologia.

Ma al cuore di questo movimento giace un paradosso, un software OSS liberamente disponibile, modificabile e ridistribuibile, richiede risorse significative per essere sviluppato e mantenuto.

Il famoso saggio di Eric S. Raymond, “La cattedrale e il bazaar“, ha catturato magnificamente l’essenza dello sviluppo open source. Ha contrapposto il modello “cattedrale” dello sviluppo del software proprietario – centralizzato e gelosamente custodito – con il modello “bazaar” dell’open source – decentralizzato, trasparente e guidato dalla comunità. Questo modello bazaar ha portato a un’innovazione e una collaborazione senza precedenti, ma ha anche dato origine a sfide complesse in termini di sostenibilità e governance.

Mentre navighiamo nel terzo decennio del XXI secolo, il movimento open source si trova a un bivio. L’immenso successo dei progetti open source ha attirato un notevole interesse commerciale, portando a una delicata danza tra innovazione guidata dalla comunità e sfruttamento orientato al profitto. La sostenibilità dei progetti open source dipende ora dal trovare un equilibrio tra questi interessi spesso contrastanti, assicurando che lo spirito di apertura e collaborazione possa coesistere con le realtà di un’economia capitalista.

Proviamo ad esplorare il complesso panorama della sostenibilità dell’open source, esaminando le considerazioni economiche, di governance ed etiche che plasmano il futuro di questa componente vitale della nostra infrastruttura digitale. Analizzando conflitti recenti, modelli di successo e tendenze emergenti, puntiamo a far luce sul percorso futuro per la sostenibilità dell’open source in un ecosistema tecnologico sempre più complesso.

La Promessa dell’Open Source

Il modello open source di sviluppo software ha rivoluzionato l’industria tech, offrendo un approccio collaborativo che sfrutta l’intelligenza collettiva degli sviluppatori di tutto il mondo. Nel suo nucleo, l’open source incarna i principi di trasparenza, flessibilità e innovazione guidata dalla comunità.

I benefici di questo modello sono molteplici:

1. Innovazione Rapida: Permettendo a chiunque di visualizzare, modificare e contribuire al codice sorgente, i progetti open source possono evolversi a un ritmo che spesso supera le alternative proprietarie. Le diverse prospettive e competenze dei contributori portano a soluzioni creative e rapide correzioni di bug.
2. Trasparenza: La natura aperta del codice sorgente assicura che le vulnerabilità di sicurezza possano essere identificate e affrontate rapidamente. Inoltre, favorisce la fiducia tra gli utenti, che possono verificare autonomamente la funzionalità e la sicurezza del software.
3. Efficienza dei Costi: Per gli utenti, il software open source spesso non ha costi, riducendo le barriere all’ingresso e consentendo un’adozione diffusa. Per le aziende, può ridurre significativamente i costi di sviluppo sfruttando componenti open source esistenti.
4. Flessibilità e Personalizzazione: Gli utenti e le organizzazioni possono modificare il software open source per adattarlo alle loro esigenze specifiche, un livello di controllo tipicamente non disponibile con le soluzioni proprietarie.

Le storie di successo dell’open source sono numerose e impressionanti. Linux, il sistema operativo open source, alimenta tutto, dagli smartphone ai supercomputer. WordPress, un sistema di gestione dei contenuti open source in PHP, gestisce oltre il 40% di tutti i siti web su internet. OpenSSL per le comunicazioni sicure, e innumerevoli linguaggi di programmazione e framework dimostrano l’influenza pervasiva dell’open source nella nostra infrastruttura digitale.

Questi successi evidenziano il potenziale del modello open source di creare soluzioni software robuste e ampiamente adottate. Tuttavia, sollevano anche domande su come sostenere questi progetti nel lungo termine, specialmente quando diventano componenti critiche del nostro panorama tecnologico (come è successo con XYZ).

L’Economia dell’Open Source

Uno dei miei primi corsi svolti in Bologna Business School fu sui modelli di business dell’open source circa 8 anni fa (che sia ora di riproporlo?). Da allora le cose non sono sostanzialmente cambiate, forse però si è inasprita ulteriormente il dissapore tra le grandi aziende ed i contributori.

Banalizzando il tutto potremmo dire che le dinamiche economiche del software open source presentano una sfida unica. Come si sostiene un progetto che è liberamente disponibile e apertamente modificabile?

I modelli di finanziamento tradizionali per l’open source hanno incluso prevalentemente:

1. Donazioni: Utenti individuali o organizzazioni contribuiscono finanziariamente per sostenere lo sviluppo del progetto.
2. Sponsorizzazioni: Le aziende forniscono supporto finanziario in cambio di riconoscimento o influenza sulla direzione del progetto.
3. Sovvenzioni: Organizzazioni no-profit o enti governativi forniscono finanziamenti per lo sviluppo open source.

Mentre questi modelli hanno sostenuto molti progetti, spesso si rivelano insufficienti per software su larga scala, mission-critical.

Questa realtà ha dato origine a vari modelli di business open source commerciali:

1. Supporto e Servizi: Le aziende offrono supporto a pagamento, formazione e servizi di consulenza intorno al prodotto open source (ad esempio, il modello di Red Hat con Linux).
2. Open Core: Il prodotto core è open source, ma funzionalità aggiuntive proprietarie vengono vendute commercialmente (ad esempio, l’approccio di GitLab).
3. Servizi Hosted: Il software è open source, ma un’azienda offre una versione ospitata e gestita come servizio (ad esempio, WordPress.com per WordPress).

Questi modelli tentano di bilanciare l’etica dell’open source con la necessità di un reddito sostenibile. Tuttavia, introducono anche il potenziale di conflitto tra gli interessi della comunità e gli imperativi commerciali, soprattutto se dietro l’azienda si è inserito un fondo di investimento.

Il problema del “free rider” è una sfida significativa nell’economia open source. Le aziende possono utilizzare e beneficiare del software open source senza contribuire in cambio, né in codice né finanziariamente. Questo problema è emerso in primo piano con la recente decisione di HashiCorp di cambiare la licenza del suo popolare strumento di infrastructure-as-a-code, Terraform.

La mossa di HashiCorp è stata motivata dalla preoccupazione che i grandi provider cloud stessero offrendo i prodotti open source di HashiCorp come servizi gestiti senza contribuire significativamente al loro sviluppo. Questa situazione evidenzia la tensione tra il principio open source del libero utilizzo e la necessità per le aziende di proteggere i propri investimenti e garantire la sostenibilità del progetto.

Il caso HashiCorp solleva diverse domande:

• Come possono i progetti open source proteggersi dallo sfruttamento mantenendo lo spirito di apertura?
• Quali responsabilità hanno le aziende quando traggono profitto dal software open source?

Queste domande ci portano a considerare le dimensioni etiche del coinvolgimento commerciale nell’open source.

La Responsabilità delle Entità Commerciali

Con il software open source diventato sempre più centrale (e necessario) per l’industria tecnologica, le considerazioni etiche che circondano il suo uso e sviluppo sono diventate più complesse. Le aziende che costruiscono i loro modelli di business sul software open source affrontano un imperativo morale di contribuire ai progetti da cui dipendono.

Il concetto di “restituire” alla comunità non è solo un ideale altruistico; è una necessità pratica per la salute a lungo termine dell’ecosistema open source.

I contributi possono assumere varie forme:

1. Contributi di codice: Correggere bug, aggiungere funzionalità o migliorare le prestazioni.
2. Documentazione: Creare o migliorare guide utente, documentazione API e tutorial.
3. Supporto finanziario: Fornire finanziamenti per lo sviluppo, l’infrastruttura o gli stipendi degli sviluppatori.
4. Coinvolgimento della comunità: Partecipare a discussioni, organizzare eventi o mentorare nuovi contributori.

La recente disputa tra WordPress.org e WP Engine illustra le tensioni che possono sorgere quando si percepisce che le entità commerciali non contribuiscono adeguatamente ai progetti open source da cui traggono profitto. WordPress, un sistema di gestione dei contenuti open source, alimenta una porzione significativa del web. WP Engine, una società di hosting specializzata in siti WordPress, ha costruito un business, di svariate centinaia di milioni di dollari, intorno a quest’ultimo.

Tuttavia, WordPress.org, guidata dal co-fondatore Matt Mullenweg, ha accusato WP Engine di non contribuire sufficientemente al progetto WordPress in relazione ai benefici che ne traggono. Questo conflitto evidenzia diversi problemi chiave:

1. Uso del marchio: Come dovrebbero i progetti open source controllare l’uso dei loro marchi da parte di entità commerciali?
2. Metriche di contribuzione: Come misuriamo e valutiamo i diversi tipi di contributi ai progetti open source?
3. Uso equo vs sfruttamento: A che punto l’uso commerciale del software open source oltrepassa il confine dello sfruttamento?

La disputa WordPress/WP Engine sottolinea la necessità di linee guida e aspettative più chiare riguardo all’uso commerciale del software open source. Solleva anche domande sul ruolo della governance del progetto nella gestione di queste relazioni.

Governance e Sostenibilità

Le strutture di governance dei progetti open source giocano un ruolo cruciale nella loro sostenibilità a lungo termine. Queste strutture devono bilanciare le esigenze di vari stakeholder, inclusi i contributori individuali, le entità commerciali e gli utenti finali.

Diversi modelli di governance sono emersi nel mondo open source:

1. Dittatore Benevolo a Vita (BDFL, il mio preferito): Un singolo individuo o un piccolo gruppo mantiene il controllo ultimo sul progetto (ad esempio, Linus Torvalds con Linux).
2. Meritocrazia: Il potere decisionale si guadagna attraverso contributi e riconoscimento dei pari (ad esempio, i progetti della Apache Software Foundation).
3. Guidato da aziende: Una singola azienda mantiene il controllo primario ma accetta contributi esterni (ad esempio, Google con Android).
4. Guidato da fondazioni (quello che sta prendendo più piede negli ultimi anni): Una fondazione no-profit supervisiona il progetto, spesso con un consiglio che rappresenta vari stakeholder (ad esempio, Linux Foundation, Mozilla Foundation, etc.).

Ogni modello ha i suoi punti di forza e di debolezza, e la scelta della struttura di governance può influenzare significativamente la sostenibilità di un progetto e la sua capacità di navigare i conflitti.

Le fondazioni sono diventate sempre più importanti nell’ecosistema open source. Organizzazioni come la Linux Foundation e la Apache Software Foundation forniscono supporto legale, finanziario e organizzativo a numerosi progetti open source. Possono agire come arbitri neutrali nelle dispute e aiutare a garantire che i progetti rimangano concentrati sulle loro missioni principali piuttosto che essere eccessivamente influenzati da una singola entità commerciale.

Tuttavia, anche i progetti guidati da fondazioni devono affrontare la sfida di bilanciare gli interessi della comunità con le realtà commerciali. Con il software open source che diventa sempre più critico per l’infrastruttura globale, c’è una crescente necessità di modelli di governance che possano gestire efficacemente gli interessi concorrenti di vari stakeholder.

Si sta iniziando anche a parlare di valutare come OSS critico alla stessa stregua di Software as a Public Good e gestito da enti come le Nazioni Unite, il concetto da poco espresso da Github apre la discussione sulla tragedia dei beni comuni.

La Tragedia dei Beni Comuni e la Motivazione dei Contributi

Le sfide di sostenibilità affrontate dai progetti open source spesso assomigliano a un classico problema economico: la tragedia dei beni comuni. In questo scenario, gli utenti individuali che agiscono nel proprio interesse possono esaurire una risorsa condivisa, danneggiando alla fine tutti, inclusi loro stessi. Nel contesto dell’open source, i “beni comuni” sono il software stesso, insieme al tempo e allo sforzo dei suoi manutentori.

Quando aziende o individui usano il software open source senza contribuire in cambio, stanno essenzialmente sfruttando gli sforzi altrui. Nel tempo, questo può portare al burnout dei manutentori, alla stagnazione del progetto o addirittura all’abbandono. La sfida, quindi, è creare sistemi e culture che incoraggino il contributo e scoraggino lo sfruttamento.

Motivare i contributi ai progetti open source coinvolge fattori sia pratici che psicologici:

1. Riconoscimento: Molti contributori sono motivati dal riconoscimento che ricevono dai loro pari. Sistemi per riconoscere e celebrare i contributi possono essere potenti motivatori.
2. Avanzamento di carriera: Contribuire all’open source può migliorare le competenze e la reputazione di uno sviluppatore, portando a migliori opportunità di lavoro.
3. Senso di scopo: Molti contributori sono spinti dalla convinzione di avere un impatto positivo sul mondo attraverso il loro lavoro.
4. Incentivi aziendali: Le aziende possono incoraggiare i loro dipendenti a contribuire a progetti open source rendendolo parte delle loro responsabilità lavorative e valutazioni delle prestazioni.
5. Reciprocità: Favorire una cultura in cui l’uso dell’open source crea un’aspettativa di restituzione, sia attraverso il codice, la documentazione o il supporto finanziario.

Per affrontare questi fattori motivazionali, i progetti open source e la più ampia comunità tech possono adottare diversi approcci:

1. Migliorare le metriche di contribuzione: Sviluppare modi più sofisticati per misurare e valutare diversi tipi di contributi, inclusi i contributi non di codice come la documentazione e il supporto alla comunità.
2. Educazione: Aiutare le aziende a comprendere il valore a lungo termine di contribuire ai progetti open source da cui dipendono.
3. Politiche aziendali: Incoraggiare le aziende a sviluppare politiche chiare sull’uso e il contributo open source, rendendolo parte integrante della loro strategia tecnologica.
4. Costruzione della comunità: Favorire comunità forti e accoglienti intorno ai progetti open source per creare un senso di appartenenza e scopo condiviso.

Affrontando sia gli aspetti pratici che psicologici del contributo, i progetti open source possono creare ecosistemi più sostenibili che beneficiano tutti gli stakeholder.

Il Ruolo delle Grandi Aziende Tech

Il coinvolgimento delle grandi aziende tecnologiche nell’open source ha ridisegnato drasticamente il panorama.

Aziende come Google, Microsoft, Facebook e Amazon sono diventate importanti contributori ai progetti open source, sia in termini di codice che di supporto finanziario. Questo impegno porta con sé sia opportunità che sfide.

Dal lato positivo, le risorse che queste aziende possono dedicare ai progetti open source sono sostanziali. Possono assegnare dipendenti a tempo pieno al lavoro open source, fornire finanziamenti per infrastrutture ed eventi, e mettere a disposizione la loro considerevole esperienza per risolvere sfide tecniche complesse. Ad esempio, i contributi di Google a progetti come Kubernetes sono stati fondamentali per far progredire il computing cloud-native.

Tuttavia, il coinvolgimento di questi giganti tecnologici solleva anche preoccupazioni:

1. Influenza: C’è il rischio che le grandi aziende possano esercitare un’influenza eccessiva sulla direzione dei progetti open source, potenzialmente orientandoli in modi che avvantaggiano principalmente i propri interessi.
2. Dipendenza: I progetti potrebbero diventare eccessivamente dipendenti dalle risorse fornite da queste aziende, rendendosi vulnerabili se le priorità aziendali dovessero cambiare.
3. Dinamiche competitive: Quando più grandi aziende sono coinvolte nello stesso progetto, possono emergere tensioni competitive, potenzialmente frammentando la comunità o portando a sfide di governance.
4. Acquisizione di talenti: Alcuni sostengono che le grandi aziende utilizzino i contributi open source come un modo per identificare e reclutare i migliori talenti, potenzialmente allontanando i manutentori da progetti importanti.

Per affrontare queste preoccupazioni, molti progetti open source hanno adottato modelli di governance che limitano l’influenza di qualsiasi singola entità, indipendentemente dalla scala dei loro contributi. I progetti guidati da fondazioni spesso hanno regole sulla rappresentanza aziendale nei loro consigli per garantire un equilibrio di interessi.

Nonostante queste sfide, il coinvolgimento delle grandi aziende tecnologiche nell’open source è stato largamente positivo, accelerando l’innovazione e fornendo supporto critico a molti progetti importanti. La chiave è mantenere un equilibrio in cui queste aziende possano contribuire con le loro risorse e competenze senza compromettere la natura guidata dalla comunità dello sviluppo open source.

Sfide e Potenziali Soluzioni

Con l’evolversi continuo dell’ecosistema open source, sono emerse diverse sfide chiave, insieme a potenziali soluzioni:

1. Strategie di licenza: le licenze open source tradizionali potrebbero non fornire una protezione sufficiente contro lo sfruttamento da parte di grandi provider cloud o altre entità commerciali. Diventa quindi necessario pensare a nuovi approcci di licenza, come la Server Side Public License (SSPL), o la Fair Source da poco rilasciata da Senty, cercano di affrontare questo problema. Tuttavia, queste licenze sono controverse e non universalmente accettate come “open source”.
2. Metriche di contribuzione: i metodi attuali di misurazione dei contributi si concentrano spesso troppo sui commit di codice, sottovalutando altri contributi importanti. Sarebbe quindi importante adottare metriche di contribuzione più olistiche che tengano conto della documentazione, del supporto alla comunità, dei contributi finanziari e di altre attività non legate al codice, anche in un’ottica di aumentare la sicurezza e di ridurre spiacevoli incidenti come il già citato XYZ.
3. Finanziamento sostenibile: molti progetti open source critici faticano a garantire finanziamenti stabili a lungo termine, obbligando di fatto i mantainer a fare due/tre lavori rischiando il burnout per il benessere altrui. Diventa quindi necessario esplorare nuovi modelli di finanziamento, come fondi per la sostenibilità open source o contributi obbligatori da parte degli utenti commerciali al di sopra di una certa scala.
4. Burnout dei manutentori: Il carico sui manutentori open source può essere opprimente, portando al burnout e all’abbandono del progetto, il che poi si può ripercuotere su un intero ecosistema. Implementare migliori sistemi di supporto per i manutentori, incluse risorse per la salute mentale, periodi sabbatici e una distribuzione più equa del lavoro di manutenzione. Il tutto però ci riporta al punto 3 sui temi finanziari.
5. Sicurezza e manutenzione dell’infrastruttura critica: Molti pezzi critici dell’infrastruttura digitale sono mantenuti da un piccolo numero di volontari. Quindi, di nuovo, è necessario aumentare gli investimenti nella sicurezza e nella manutenzione dei progetti open source critici, possibilmente attraverso partnership pubblico-private o fondazioni dedicate.

Il Futuro della Sostenibilità Open Source

Guardando al futuro, emergono diverse tendenze e potenziali soluzioni che potrebbero plasmare la sostenibilità dell’open source:

1. Modelli Open Core e SaaS: Questi approcci ibridi, che combinano open source con elementi o servizi proprietari, probabilmente diventeranno più raffinati e ampiamente adottati.
2. Governance decentralizzata: Non sono un grande fan della tecnologia blockchain, ma ragionare in termine di DOI potrebbe fornire nuovi modi per incentivare e ricompensare i contributi open source, nonché nuovi modelli per la governance decentralizzata dei progetti.
3. Coinvolgimento para-governativo: Riconoscendo la natura critica dell’infrastruttura open source, i governi potrebbero assumere un ruolo più attivo nel supportare e regolare i progetti open source. Non a livello del singolo governo ma collettivo, come Nazioni Unite, o creando un ente sulla falsa riga del World Economic Forum dedicato al mondo del sosftware.
4. Educazione e cambiamento culturale: Con il riconoscimento sempre più diffuso dell’importanza dell’open source, potremmo assistere a un cambiamento culturale in cui il contributo all’open source è visto come una parte standard delle responsabilità di uno sviluppatore o di un’azienda.

Conclusione

La sostenibilità del software open source non è solo una questione tecnica o economica, ma una questione culturale ed etica che va al cuore di come creiamo e condividiamo la conoscenza nell’era digitale. Le sfide sono significative, ma lo sono anche le opportunità.

Andando avanti, è cruciale che tutti gli stakeholder nell’ecosistema open source – sviluppatori individuali, aziende, fondazioni e governi – lavorino insieme per creare modelli sostenibili che preservino lo spirito di apertura e collaborazione che ha reso l’open source così trasformativo.

Il futuro dell’open source dipenderà dalla nostra capacità di bilanciare innovazione e sostenibilità, valori della comunità e interessi commerciali, apertura e necessità di modelli di business sostenibili. Affrontando queste sfide di petto, possiamo garantire che il movimento open source continui a guidare il progresso tecnologico e democratizzare l’accesso a potenti strumenti software per le generazioni a venire.

Il percorso futuro richiederà creatività, compromesso e un impegno condiviso verso i principi che hanno reso l’open source così di successo. Mentre navighiamo in questo complesso panorama, dobbiamo ricordare che l’obiettivo finale non è solo la sostenibilità dei singoli progetti, ma la promozione di un commons digitale prospero, innovativo ed equo che benefici tutta l’umanità.

[questo post è stato scritto utilizzando alcune lecture universitarie da me svolte, appunti presi durante l’anno in ambito di Sustainable IT e vario materiale. Il tutto è stato dato in pasto e mescolato con Claude e poi rieditato dal sottoscritto]

The post La Sostenibilità del Software Open Source: Innovazione, Comunità e Profitto. appeared first on Fullo.

Nello specifico le emissioni possono essere scomposte in quattro fattori principali:

• Popolazione
• GDP pro capite
• Intensità energetica del GDP (globale)
• Intensità di carbonio dell’energia

Arrivando alla definizione ufficiale della formula:

Global Population × GDP per Capita × Energy Intensity of GDP × Carbon Intensity of Energy = CO2 Emissions from Energy

Durante il corso è emerso, in modo esplicito come l’aumento della tecnologia porti alla riduzione del rapporto tra GDP e intensità energetica ma, nel frattempo fa emergere scenari, impliciti, interessanti relativamente al Sustainable IT.

Prendiamo in considerazione la Legge di Moore e proviamo ad affiancarla al framework dei Grafici di Kaya.

La legge di Moore, formulata da Gordon Moore, co-fondatore di Intel, prevede che il numero di transistor in un circuito integrato raddoppi ogni due anni, portando a un aumento esponenziale della potenza di calcolo. Sebbene la legge stia raggiungendo i suoi limiti fisici per quanto riguarda i transistor, il principio rimane applicabile ai consumi energetici e all’evoluzione dell’elettronica in generale.

Prima di iniziare il ragionamento, ricordiamoci che il settore IT è responsabile di una quota crescente delle emissioni globali di CO2, dovuta alla produzione, all’uso e allo smaltimento di dispositivi elettronici e all’energia consumata dai data center e dalle reti.

La riduzione dell’intensità di carbonio (altro fattore dei Grafici di Kaya) è sicuramente connessa all’innovazione nel settore IT, che può portare a soluzioni per ridurre l’intensità di carbonio dell’energia come migliori tecnologie per le energie rinnovabili o l’ottimizzazione dei data center.

Questo si riflette nel fattore “intensità energetica del GDP” dei grafici Kaya, potenzialmente riducendolo, tra l’altro (come spiegato nel corso) l’aumento del GDP pro capite (altro fattore Kaya) è spesso correlato a una maggiore adozione di tecnologie IT.

Altra interessante conseguenza di quanto finora spiegato è il famigerato Effetto Rimbalzo: nonostante l’aumento dell’efficienza energetica (e quindi alla riduzione del fattore Kaya: Intensità di carbonio dell’energia), l’uso crescente di dispositivi elettronici (dovuto alla loro maggiore accessibilità e potenza) può portare a un aumento netto delle emissioni, influenzando l’intensità di carbonio dell’energia.

Questo effetto lo si può notare in tantissimi casi e mercati, come ad esempio la riduzione dei costi dei pannelli solari porta ad un loro aumento (e quindi emissioni per la produzione) ma anche ad un maggior consumo di energia a causa del costo ridotto di quest’ultima, portando quindi a far aumentare le emissioni nonostante l’uso delle rinnovabili.

L’aumento della potenza di calcolo può portare alla “dematerializzazione” di alcuni settori (es. e-books, streaming), potenzialmente riducendo l’intensità energetica dell’economia, ma aumentando al contempo le emissioni IT.

Il calcolo si complica: se da un lato si elimina l’impatto ambientale della produzione, trasporto e smaltimento di prodotti fisici, dall’altro dobbiamo considerare i cicli di vita più brevi dei prodotti informatici. Inoltre, l’accelerazione del progresso tecnologico, senza un corretto intervento normativo, può portare a cicli di vita ancora più brevi, aumentando le emissioni legate alla produzione e, soprattutto, allo smaltimento.

In sostanza, come quasi tutto quello che è inerente alla sostenibilità, la relazione tra i grafici Kaya, la legge di Moore e le emissioni IT è complessa e sfaccettata.

Mentre la legge di Moore guida l’efficienza e l’innovazione, potenzialmente riducendo alcuni fattori nei grafici Kaya, l’aumento dell’uso e della diffusione delle tecnologie IT può contrastare questi guadagni di efficienza, creando un delicato equilibrio che si riflette nelle emissioni globali di CO2.

The post Grafici di Kaya, Legge di Moore e Sustainable IT appeared first on Fullo.

Quello che segue è una discussione costruita su Claude.ai dove esperti in filosofia, teoria dei giochi, complessità, psicologia e educazione discutono approcci alla sostenibilità e propongono un piano operativo che include:

1. Educazione innovativa per la sostenibilità
2. Costruzione di comunità sostenibili
3. Trasformazione economica verso modelli circolari
4. Governance globale per la gestione delle risorse
5. Uso di tecnologie avanzate per il monitoraggio e la rigenerazione ambientale

Il piano integra nudging comportamentale, teoria dei giochi, pensiero sistemico e principi educativi Montessori.

E’ un esperimento e ne traccio qui i risultati più come memoria che per altri fini. Questa discussione nasce da una serie di prompt man mano sempre più specifici, unendo tre chat che sto portando avanti con Aristotele, Nash ed una ipotetica esperta di scienze comportamentali per capirne meglio gli insegnamenti di questi ultimi e per portarli poi su un unico piano.

Partecipanti:

• Aristotele (Filosofo greco)
• John Nash (Teorico dei giochi)
• Francesco (Esperto di complessità e teoria del cambiamento)
• Lucia (Psicologa comportamentale)
• Maria Montessori (Educatrice)

Contesto Iniziale:

La discussione inizia applicando il dilemma del prigioniero alla definizione di sostenibilità di Brundtland: “Lo sviluppo sostenibile è uno sviluppo che soddisfi i bisogni del presente senza compromettere la possibilità delle generazioni future di soddisfare i propri“.

Aristotele:

Introduce il concetto di giustizia intergenerazionale e l’importanza della virtù e del giusto mezzo. Sottolinea la sfida di cooperare per il bene comune di fronte al timore che altri possano non farlo.

John Nash:

Applica la teoria dei giochi, notando che il dilemma del prigioniero in questo contesto mostra come decisioni individuali razionali possano portare a risultati subottimali. Suggerisce di considerare le generazioni future come giocatori in un gioco ripetuto, cercando un “equilibrio di Nash” dove nessuna generazione ha interesse a deviare da una strategia sostenibile.

Francesco:

Enfatizza la natura adattiva e interconnessa del sistema. Propone di concentrarsi su interventi ad alto leverage che possono innescare cambiamenti positivi su larga scala con uno sforzo relativamente contenuto.

Il Dialogo

Aristotele: Salve, amici miei. La definizione di Brundtland sulla sostenibilità mi ricorda il concetto di giustizia intergenerazionale. Nel mio pensiero filosofico, ho sempre sostenuto l’importanza della virtù e del giusto mezzo. Applicando questi principi al dilemma del prigioniero nel contesto della sostenibilità, potremmo dire che la scelta virtuosa sarebbe quella di cooperare per il bene comune, sia presente che futuro. Tuttavia, come nel dilemma del prigioniero, il timore che gli altri possano non cooperare potrebbe spingere molti a scegliere il proprio interesse immediato. Come possiamo superare questo ostacolo?

John Nash: Interessante prospettiva, Aristotele. Dal punto di vista della teoria dei giochi, il dilemma del prigioniero applicato alla sostenibilità rappresenta un classico esempio di come le decisioni individuali razionali possano portare a un risultato subottimale per tutti. Tuttavia, se consideriamo questo come un gioco ripetuto nel tempo, con le generazioni future come giocatori successivi, emergono nuove strategie di equilibrio. Potremmo cercare un “equilibrio di Nash” in cui nessuna generazione ha interesse a deviare da una strategia sostenibile, dato che le generazioni future potrebbero “punire” comportamenti non cooperativi.

Francesco: Entrambi sollevate punti cruciali. Dal punto di vista della complessità e della theory of change, dobbiamo considerare che il sistema in cui operiamo è adattivo e interconnesso. Le azioni di oggi influenzano non solo il futuro diretto, ma creano anche feedback loops che possono amplificare o mitigare i nostri sforzi. Propongo di concentrarci su interventi ad alto leverage, ovvero azioni che possono innescare cambiamenti positivi su larga scala con uno sforzo relativamente contenuto.

Aristotele: Concordo, Francesco. La virtù, come la sostenibilità, non è un atto singolo ma un’abitudine. Nash, la tua idea di considerare le generazioni future come giocatori attivi è illuminante. Potremmo forse pensare a un sistema di incentivi che allinei gli interessi a breve termine con quelli a lungo termine?

John Nash: Esattamente, Aristotele. Un sistema di incentivi ben progettato potrebbe trasformare il gioco da un dilemma del prigioniero a un gioco di coordinamento, dove la cooperazione diventa la strategia dominante. Francesco, come potremmo strutturare questi incentivi considerando la complessità del sistema?

Francesco: Dovremmo considerare incentivi su più livelli: economici, sociali e culturali. Per esempio:

1. Economici: Implementare una carbon tax progressiva e reinvestire i proventi in tecnologie sostenibili.
2. Sociali: Creare sistemi di reputazione per aziende e individui basati sul loro impatto ambientale.
3. Culturali: Promuovere l’educazione alla sostenibilità fin dall’infanzia per cambiare i valori sociali nel lungo termine.

Questi interventi potrebbero creare dei feedback positivi, rendendo le scelte sostenibili sempre più vantaggiose nel tempo.

Aristotele: Mi piace questo approccio multilivello, Francesco. Riflette il mio concetto di eudaimonia, il benessere completo dell’individuo e della società. Nash, come possiamo assicurarci che questi incentivi creino un equilibrio stabile nel lungo periodo?

John Nash: Per garantire un equilibrio stabile, dobbiamo considerare la robustezza del sistema. Propongo di:

1. Implementare meccanismi di adattamento automatico degli incentivi in base ai risultati ottenuti.
2. Creare istituzioni internazionali con il potere di far rispettare gli accordi sulla sostenibilità.
3. Sviluppare metriche condivise per misurare il progresso verso la sostenibilità.

Francesco, come possiamo assicurarci che questi meccanismi siano sufficientemente flessibili per adattarsi ai cambiamenti imprevisti?

Francesco: Per garantire flessibilità e adattabilità, suggerisco di:

1. Implementare sistemi di governance policentrici, che permettano sperimentazioni locali e apprendimento distribuito.
2. Utilizzare approcci di scenario planning per preparare strategie di risposta a diversi futuri possibili.
3. Investire in sistemi di monitoraggio in tempo reale dell’impatto ambientale, sociale ed economico per permettere aggiustamenti rapidi.

Aristotele, come possiamo assicurarci che questi sistemi complessi rimangano allineati con i principi etici e di giustizia che hai delineato?

Aristotele: Una domanda profonda, Francesco. Per mantenere l’allineamento etico, propongo di:

1. Istituire comitati etici indipendenti che supervisino le decisioni chiave e valutino regolarmente l’equità intergenerazionale.
2. Promuovere la virtù della phronesis (saggezza pratica) nei leader e nei cittadini, per navigare le complessità etiche delle decisioni sulla sostenibilità.
3. Incorporare processi di deliberazione pubblica nelle decisioni chiave, per assicurare che diverse prospettive etiche siano considerate.

Nash, come possiamo modellare matematicamente l’interazione tra questi sistemi etici e gli incentivi economici che hai proposto? Per aiutarci ho invitato Lucia, una psicologa comportamentale.

John Nash: Benvenuta, Lucia. Prima di passare a te, vorrei rispondere brevemente ad Aristotele. Per modellare l’interazione tra sistemi etici e incentivi economici, potremmo utilizzare una variante della teoria dei giochi che incorpora preferenze sociali e valori etici nelle funzioni di utilità dei giocatori. Questo ci permetterebbe di analizzare come le norme etiche influenzano le decisioni economiche e viceversa. Ma sono molto interessato a sentire la tua prospettiva sul nudging e la neurolinguistica.

Lucia: Come psicologa comportamentale, credo che il nudging e la neurolinguistica possano giocare un ruolo cruciale nell’accelerare il cambiamento verso la sostenibilità. Ecco alcuni esempi concreti:

1. Framing positivo: Invece di parlare di “sacrifici per l’ambiente”, potremmo riframe il messaggio come “investimenti per il futuro”. Questo sfrutta il bias di avversione alla perdita, rendendo le azioni sostenibili più attraenti.
2. Default sostenibili: Impostare opzioni sostenibili come default in vari contesti. Ad esempio, le aziende energetiche potrebbero offrire di default energia da fonti rinnovabili, lasciando ai clienti la possibilità di scegliere attivamente fonti non rinnovabili.
3. Feedback in tempo reale: Utilizzare dispositivi smart che forniscono feedback immediato sul consumo di energia o acqua, sfruttando il principio psicologico del rinforzo immediato.
4. Norme sociali: Comunicare regolarmente le statistiche sul comportamento sostenibile della comunità, sfruttando la tendenza umana a conformarsi alle norme sociali.
5. Chunking: Suddividere obiettivi di sostenibilità a lungo termine in azioni più piccole e immediatamente realizzabili, rendendo il cambiamento meno intimidatorio.
6. Priming ambientale: Utilizzare segnali visivi e linguistici nell’ambiente urbano per mantenere la sostenibilità costantemente presente nella mente delle persone.

Questi approcci possono complementare le strategie più ampie discusse finora. Cosa ne pensate?

Aristotele: Lucia, le tue idee sono intriganti e sembrano allinearsi con il mio concetto di formazione dell’abitudine virtuosa. Tuttavia, mi chiedo: come possiamo assicurarci che questi “nudge” non diventino manipolazioni che minano l’autonomia individuale? La virtù, dopo tutto, richiede scelta consapevole.

Francesco: Concordo con la preoccupazione di Aristotele, ma vedo anche il potenziale di questi approcci. Dal punto di vista della teoria del cambiamento, questi interventi potrebbero fungere da “semi di cambiamento”, creando piccole modifiche che si amplificano nel tempo. Lucia, come possiamo integrare questi approcci comportamentali con i sistemi di incentivi e le strutture istituzionali che abbiamo discusso?

John Nash: Interessante prospettiva, Lucia. Dal punto di vista della teoria dei giochi, questi nudge potrebbero essere visti come modifiche alla struttura di informazione e alle percezioni dei payoff nel “gioco” della sostenibilità. Potremmo modellare come questi cambiamenti nelle percezioni influenzano l’equilibrio complessivo del sistema.

Lucia: Grazie per le vostre riflessioni. Aristotele, la tua preoccupazione sull’autonomia è valida. Propongo di implementare questi nudge con totale trasparenza, informando sempre le persone della loro presenza e scopo. Inoltre, potremmo creare “meta-nudge” che incoraggiano le persone a riflettere criticamente sulle proprie scelte.

Francesco, per integrare questi approcci con sistemi più ampi, suggerirei di:

1. Utilizzare il nudging per facilitare l’adozione di nuovi incentivi economici.
2. Incorporare principi di design comportamentale nella progettazione di istituzioni e politiche.
3. Usare tecniche neurolinguistiche per migliorare la comunicazione delle politiche di sostenibilità.

Nash, il tuo punto sulla modellazione è eccellente. Potremmo condurre esperimenti controllati per quantificare l’impatto di diversi nudge e incorporare questi dati nei modelli di teoria dei giochi.

Aristotele: La vostra discussione mi porta a una riflessione: forse la vera virtù in questo contesto è la capacità di bilanciare sapientemente tutti questi approcci – filosofici, economici, comportamentali e sistemici. Come possiamo coltivare leader e cittadini capaci di navigare questa complessità con saggezza? Sarebbe opportuno invitare una persona esperta di educazione.

Maria Montessori: Grazie per coinvolgermi in questa stimolante discussione. Come educatrice, credo fermamente che la chiave per coltivare i leader del futuro capaci di affrontare le sfide della sostenibilità risieda nell’educazione, iniziando fin dalla prima infanzia. Ecco alcuni punti fondamentali basati sul mio metodo che potrebbero contribuire a formare questi leader:

1. Ambiente preparato: Creiamo ambienti di apprendimento che riflettano i principi della sostenibilità. Ad esempio, aule che utilizzano materiali ecologici, sistemi di riciclaggio visibili e giardini sostenibili. Questo permette ai bambini di vivere quotidianamente i principi che stiamo cercando di insegnare.
2. Apprendimento hands-on: Offriamo ai bambini esperienze concrete con la natura e l’ecologia. Attività come la cura di piante, il compostaggio e progetti di conservazione su piccola scala possono instillare un profondo senso di connessione con l’ambiente.
3. Interdisciplinarità: Integriamo i concetti di sostenibilità in tutte le materie, dalla matematica (calcolo dell’impronta ecologica) alle scienze sociali (studio delle culture sostenibili), mostrando come la sostenibilità sia interconnessa con tutti gli aspetti della vita.
4. Pensiero critico e problem-solving: Incoraggiamo i bambini a pensare in modo critico sui problemi ambientali e a proporre soluzioni creative. Questo può essere fatto attraverso progetti di gruppo, dibattiti e sfide di design sostenibile.
5. Responsabilità e autonomia: Diamo ai bambini reali responsabilità nella gestione sostenibile della loro scuola o comunità. Questo potrebbe includere la gestione di progetti di riciclaggio o l’organizzazione di iniziative di sensibilizzazione ambientale.
6. Educazione cosmica: Insegniamo ai bambini a vedere sé stessi come parte di un tutto interconnesso, sviluppando un senso di responsabilità globale e una comprensione delle conseguenze a lungo termine delle azioni umane.
7. Educazione emotiva: Coltiviamo l’empatia e la compassione non solo verso gli altri esseri umani, ma anche verso l’ambiente e le generazioni future. Questo può aiutare a superare il dilemma del prigioniero menzionato da Nash, promuovendo una visione a lungo termine.
8. Apprendimento intergenerazionale: Creiamo opportunità per i bambini di interagire con diverse generazioni, comprendendo diverse prospettive sulla sostenibilità e sviluppando un senso di continuità storica.

Lucia, come possiamo integrare questi principi educativi con le tue tecniche di nudging per creare un approccio olistico allo sviluppo dei futuri leader?

Aristotele, come possiamo assicurarci che questo approccio educativo coltivi non solo conoscenze e abilità, ma anche la saggezza pratica (phronesis) che hai menzionato?

Nash e Francesco, alla luce di questi principi educativi, come potremmo ripensare i nostri modelli di incentivi e sistemi complessi per includere lo sviluppo a lungo termine del capitale umano?

Aristotele: Amici miei, la domanda che ci viene posta è di grande importanza e complessità. Per definire un piano operativo efficace, dobbiamo considerare sia la virtù individuale che quella collettiva, mirando a un equilibrio tra il breve e il lungo termine. Propongo un piano della durata di 20 anni, suddiviso in fasi quinquennali. Ecco i punti chiave:

1. Educazione virtuosa (0-5 anni):
   • Integrare i principi di Maria Montessori nelle scuole esistenti.
   • Creare programmi di formazione per educatori sulla sostenibilità e l’etica ambientale.
   • Istituire “circoli di saggezza” comunitari per adulti, promuovendo la phronesis.
2. Costruzione di comunità sostenibili (5-10 anni):
   • Implementare progetti pilota di comunità sostenibili in diverse aree geografiche.
   • Sviluppare reti di scambio di conoscenze e risorse tra queste comunità.
   • Creare sistemi di governance partecipativa a livello locale.
3. Trasformazione economica (10-15 anni):
   • Promuovere modelli di business etici e sostenibili.
   • Implementare sistemi di valutazione del benessere alternativi al PIL.
   • Espandere l’economia circolare e la sharing economy.
4. Armonia globale (15-20 anni):
   • Facilitare il dialogo interculturale sulla sostenibilità.
   • Creare istituzioni globali per la gestione equa delle risorse.
   • Sviluppare tecnologie per la rigenerazione ambientale su larga scala.

Per metterlo in pratica senza potere politico diretto, suggerisco di:

• Creare una rete di “ambasciatori della virtù e della sostenibilità” in vari settori della società.
• Utilizzare la persuasione morale e l’esempio personale per ispirare il cambiamento.
• Collaborare con leader influenti in vari campi per amplificare il messaggio.

John Nash: Aristotele, il tuo piano fornisce un’eccellente struttura. Dal punto di vista della teoria dei giochi, possiamo considerare questo come un gioco cooperativo a più stadi. Per ogni fase, dovremmo:

1. Identificare gli stakeholder chiave e i loro interessi.
2. Progettare meccanismi di incentivo che allineino gli interessi individuali con quelli collettivi.
3. Creare piattaforme per la condivisione di informazioni e la cooperazione.

Per implementarlo senza potere politico diretto, propongo:

• Sviluppare un “indice di sostenibilità” che le organizzazioni possano adottare volontariamente.
• Creare coalizioni di aziende, ONG e istituzioni accademiche per implementare parti del piano.
• Utilizzare la gamification per coinvolgere il pubblico in sfide di sostenibilità su larga scala.

Francesco: Costruendo sulle idee di Aristotele e Nash, dal punto di vista della complessità e della teoria del cambiamento, suggerisco di:

1. Identificare i “punti di leva” nel sistema dove piccoli cambiamenti possono portare a grandi effetti.
2. Creare “laboratori viventi” in diverse comunità per testare e iterare rapidamente le soluzioni.
3. Sviluppare sistemi di feedback in tempo reale per monitorare l’impatto delle nostre azioni.

Per l’implementazione senza potere politico:

• Costruire una piattaforma digitale open-source per condividere best practices e coordinare azioni.
• Utilizzare il crowdfunding e le criptovalute per finanziare progetti allineati con il piano.
• Creare un movimento globale di “cittadini planetari” che si impegnano a vivere secondo i principi del piano.

Lucia: Integrando le prospettive psicologiche e comportamentali, propongo di:

1. Sviluppare una “architettura delle scelte” che renda le opzioni sostenibili le più facili e attraenti.
2. Creare campagne di comunicazione basate sui principi della neurolinguistica per promuovere il piano.
3. Implementare sistemi di ricompensa sociale per comportamenti sostenibili.

Per l’attuazione senza potere politico:

• Collaborare con influencer e celebrità per normalizzare stili di vita sostenibili.
• Creare app e strumenti digitali che rendano facile e divertente partecipare al piano.
• Sviluppare programmi di formazione per leader aziendali e comunitari sulle tecniche di nudging per la sostenibilità.

Maria Montessori: Per garantire che questo piano abbia un impatto duraturo attraverso le generazioni, suggerisco di:

1. Creare un curriculum globale di “cittadinanza planetaria” da integrare in tutti i livelli di istruzione.
2. Sviluppare programmi di scambio internazionale focalizzati sulla sostenibilità per giovani leader.
3. Istituire “consigli dei bambini” in ogni comunità per dare voce alle generazioni future nelle decisioni attuali.

Per l’implementazione senza potere politico diretto:

• Collaborare con reti di scuole esistenti per adottare e diffondere il curriculum.
• Creare partnership con organizzazioni giovanili globali per amplificare l’impatto.
• Sviluppare toolkit educativi open-source che genitori e educatori possano utilizzare indipendentemente.

Questa tabella riassume il piano operativo concordato, fornendo una roadmap dettagliata per i primi 5 anni e linee guida più generali per gli anni successivi.

Il piano è strutturato in cinque aree chiave: Educazione, Comunità, Economia, Tecnologia e Governance.

Alcuni punti chiave da notare:

• Il piano inizia con azioni concrete e facilmente implementabili, come la formazione degli educatori e il lancio di progetti pilota.
• C’è una progressione da iniziative locali a soluzioni globali man mano che il piano avanza.
• L’integrazione tra le diverse aree aumenta nel tempo, riflettendo un approccio sempre più olistico.
• Le fasi successive (6-20 anni) sono più flessibili, permettendo adattamenti basati sui risultati delle fasi iniziali.
• Il piano culmina con visioni ambiziose per un futuro sostenibile, inclusa la gestione climatica globale e l’evoluzione verso sistemi di governance planetaria.

Per implementare questo piano senza potere politico diretto, sarà cruciale:

• Costruire una vasta rete di partner in diversi settori (educazione, business, tecnologia, società civile).
• Utilizzare strategie di grassroots organizing e social media per creare un movimento globale.
• Sfruttare tecnologie open-source e piattaforme decentralizzate per facilitare la collaborazione e l’implementazione.
• Cercare continuamente feedback e adattare il piano in base ai risultati e alle sfide emergenti.

Questo piano fornisce una struttura flessibile che può essere adattata a diverse scale e contesti, permettendo a individui e organizzazioni di contribuire in modi significativi anche senza un mandato politico formale.

In conclusione

Discussione sulla Sostenibilità: Un Approccio Multidisciplinare

Partecipanti:

• Aristotele (Filosofo greco)
• John Nash (Teorico dei giochi)
• Francesco (Esperto di complessità e teoria del cambiamento)
• Lucia (Psicologa comportamentale)
• Maria Montessori (Educatrice)

1. La sostenibilità:

La discussione inizia applicando il dilemma del prigioniero alla definizione di sostenibilità di Brundtland: “Lo sviluppo sostenibile è uno sviluppo che soddisfi i bisogni del presente senza compromettere la possibilità delle generazioni future di soddisfare i propri“.

Aristotele:

Introduce il concetto di giustizia intergenerazionale e l’importanza della virtù e del giusto mezzo. Sottolinea la sfida di cooperare per il bene comune di fronte al timore che altri possano non farlo.

John Nash:

Applica la teoria dei giochi, notando che il dilemma del prigioniero in questo contesto mostra come decisioni individuali razionali possano portare a risultati subottimali. Suggerisce di considerare le generazioni future come giocatori in un gioco ripetuto, cercando un “equilibrio di Nash” dove nessuna generazione ha interesse a deviare da una strategia sostenibile.

Francesco:

Enfatizza la natura adattiva e interconnessa del sistema. Propone di concentrarsi su interventi ad alto leverage che possono innescare cambiamenti positivi su larga scala con uno sforzo relativamente contenuto.

2. Gli incentivi:

Il gruppo discute la creazione di un sistema di incentivi che allinei gli interessi a breve termine con quelli a lungo termine. Francesco propone incentivi su più livelli: economici (es. carbon tax), sociali (sistemi di reputazione) e culturali (educazione alla sostenibilità).

John Nash:

Suggerisce meccanismi per garantire un equilibrio stabile, inclusi:

1. Adattamento automatico degli incentivi
2. Istituzioni internazionali per far rispettare gli accordi
3. Metriche condivise per misurare il progresso

Francesco:

Propone metodi per garantire flessibilità e adattabilità:

1. Sistemi di governance policentrici
2. Scenario planning
3. Monitoraggio in tempo reale dell’impatto

Aristotele:

Solleva la questione di come mantenere l’allineamento etico in questi sistemi complessi, proponendo:

1. Comitati etici indipendenti
2. Promozione della phronesis (saggezza pratica)
3. Processi di deliberazione pubblica

Lucia:

Introduce tecniche di nudging e neurolinguistica:

1. Framing positivo
2. Default sostenibili
3. Feedback in tempo reale
4. Sfruttamento delle norme sociali
5. Chunking degli obiettivi
6. Priming ambientale

Maria Montessori:

Offre una prospettiva educativa per coltivare i leader del futuro:

1. Ambiente preparato che riflette i principi di sostenibilità
2. Apprendimento hands-on con la natura
3. Integrazione interdisciplinare dei concetti di sostenibilità
4. Promozione del pensiero critico e problem-solving
5. Responsabilità e autonomia nei progetti di sostenibilità
6. Educazione cosmica per una visione interconnessa
7. Educazione emotiva per empatia e compassione
8. Apprendimento intergenerazionale

3. Il piano operativo:

Il gruppo sviluppa un piano operativo ventennale, suddiviso in fasi quinquennali:

1. Educazione virtuosa (0-5 anni):

• Integrazione dei principi Montessori nelle scuole
• Formazione degli educatori sulla sostenibilità
• Creazione di “circoli di saggezza” comunitari

2. Costruzione di comunità sostenibili (5-10 anni):

• Progetti pilota di comunità sostenibili
• Reti di scambio di conoscenze e risorse
• Sistemi di governance partecipativa locale

3. Trasformazione economica (10-15 anni):

• Promozione di modelli di business etici e sostenibili
• Sistemi di valutazione del benessere alternativi al PIL
• Espansione dell’economia circolare e della sharing economy

4. Armonia globale (15-20 anni):

• Dialogo interculturale sulla sostenibilità
• Istituzioni globali per la gestione equa delle risorse
• Tecnologie per la rigenerazione ambientale su larga scala

4. Strategie di Implementazione senza Potere Politico:

1. Creazione di una rete di “ambasciatori della sostenibilità”
2. Uso della persuasione morale e dell’esempio personale
3. Collaborazione con leader influenti in vari campi
4. Sviluppo di un “indice di sostenibilità” volontario
5. Creazione di coalizioni tra aziende, ONG e istituzioni accademiche
6. Uso della gamification per coinvolgere il pubblico
7. Piattaforma digitale open-source per condividere best practices
8. Uso di crowdfunding e criptovalute per finanziare progetti
9. Creazione di un movimento globale di “cittadini planetari”
10. Collaborazione con influencer e celebrità
11. Sviluppo di app e strumenti digitali per facilitare la partecipazione
12. Programmi di formazione per leader aziendali e comunitari
13. Curriculum globale di “cittadinanza planetaria”
14. Programmi di scambio internazionale per giovani leader
15. Istituzione di “consigli dei bambini” nelle comunità

Conclusione:

Questo piano fornisce una roadmap completa per un futuro sostenibile, integrando prospettive filosofiche, economiche, psicologiche ed educative. La sua implementazione richiederà una vasta collaborazione tra diversi settori della società e un impegno continuo per adattarsi alle sfide emergenti.

The post Discussione sulla Sostenibilità appeared first on Fullo.

Cercherò di spiegarlo in questo post, forse più a me che a voi, al fine di trovare una rappresentazione visuale che ci aiuti a capire meglio cosa sono le iniziative degli OKR.

Prima di tutto però parliamo dei Futures Cone (o Coni dei Futuri) di Joseph Voros. Per farlo usiamo degli esempi sempre più precisi.

Immaginiamo di poter fare una previsione certa su quanto potrebbe rendere un investimento nel corso dei prossimi anni. Utilizzando i coni dei futuri, rappresentemmo questa previsione come un cono, con la nostra stima certa posta al centro del cono stesso e con l’incertezza che si espande man mano che vai avanti nel tempo.

Per questo motivo non abbiamo le certezze ipotizzate all’inizio ma quello che possiamo dire è che nel centro si può trovare il futuro più probabile ed andando verso l’esterno troveremo scenari plausibili, possibili o impossibili.

Possiamo pensare al come come ad una sorta di “zona di probabilità” intorno alla nostra previsione. Se siamo abbastanza sicuri, il cono sarà più stretto, ma se c’è molta incertezza, il cono si allargherà, indicando una gamma più ampia di possibili risultati.

Il miglior modo di prevedere il futuro è inventandocelo

Alan Key

Non è detto che il futuro possibile combaci con quello Preferibile da noi e quindi dovremo metterci in atto al fine di cambiare il futuro. Anche perché, come disse Alan Key, il miglior modo di prevedere il futuro è inventandocelo.

Ed è proprio sul come realizzare il cono Preferibile che possiamo far entrare in gioco gli OKR.

Senza andare a discutere delle mie spiccate doti artistiche (vi giuro che su carta era molto più bello) potremmo dire che:

• gli Obiettivi sono sezioni del cono del futuro Preferibile raggiunti in un determinato momento
• gli Obiettivi sono racchiudibili all’interno di tre o più Key Result (dati tre punti del piano, esiste sempre una circonferenza che li congiunge)
• una Iniziativa la possiamo rappresentare come quel tronco di cono che ha al suo interno più Obiettivi (completi o meno) in un preciso arco temporale.

Questo sistema permette quindi di rappresentare nel tempo quali sono quegli obiettivi che fanno sia parte di una Iniziativa e che ci portano a raggiungere il futuro Preferibile (ad esempio un OKR strategico o la mission aziendale).

Anche il tempo è una dimensione chiave, più la durata di una iniziativa sarà lunga più l’obiettivo finale dovrà per forza essere ampio e quindi, per definizione, poco accurato nei suoi KR o con KR espressi come moonshot molto generici.

Senza contare che il processo iterativo degli OKR può essere facilmente rappresentato come una serie di coni che si susseguono l’uno con l’altro dando, inoltre, la possibilità di identificare momenti importanti o allineamento con North Star o Mission aziendale.

Altri interessanti effetti che possiamo vedere in questo modello di visualizzazione è che se abbiamo OKR particolarmente circoscritti ridurremo di fatto lo spazio delle possibilità del futuro Preferibile andando ed essere meno resilienti in caso di cambiamenti del mercato intorno a noi, lo stesso vale per le iniziative spropositate rispetto allo spazio delle possibilità o OKR troppo ampi, in questo caso il costo per gestirli supererà i benefici ottenibili andando, inoltre, a farci rischiare di andare fuori obiettivo.

Penso che le potenziali di questa interpretazione degli OKR affiancati ai Futures Cones possa essere molto potente e rapprenteare un ottimo strumento di analisi per capire quando le cose non stanno andando come sperato e/o per fare progettazione dei prossimi passi.

Nel frattempo se avete voglia di discuterne presto ci sarà un altro corso sugli OKR con Avanscoperta e probabilmente un nuovo meetup dedicato.

The post Futures Cone e OKR, come prevedere e gestire il futuro appeared first on Fullo.