TL;DR: Durante un workshop per costruire una ToC su sostenibilità digitale, mi è stata fatta una domanda molto intelligente: “E se cambia tutto?” La risposta non è nella precisione del piano, ma nel distinguere cosa non cambia mai (l’Impact) da cosa deve essere flessibile (tutto il resto). Gli unknown unknowns non si prevengono, si navigano.
Qualche settimana fa mi arriva una chiamata. Un’azienda in quella fase dove si è cresciuti abbastanza da avere problemi seri ma non abbastanza da avere le risorse per risolverli bene. Mi chiedono supporto per “scegliere i contenuti formativi giusti per un processo di trasformazione aziendale nel medio-lungo termine.“
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.
Qualche settimana fa, durante un workshop con una startup che voleva portare innovazione nel proprio prodotto, mi sono trovato davanti alla solita scena: team brillante, slide perfette sul product-market fit, roadmap dettagliata. Tutto corretto, tutto logico. Eppure mancava qualcosa. Quella scintilla che trasforma un’idea in qualcosa che funziona davvero.
Il problema non erano gli strumenti, quelli li conoscevano bene. Il problema era nel modo di pensare.
Settimana scorsa mi è capitato di nuovo. Un’azienda manifatturiera mi contatta: “Francesco, dobbiamo rendere sostenibile il nostro business model. Ci serve qualcosa di concreto, non i soliti powerpoint sulla responsabilità sociale o progetti per piantare gli alberi.“
È 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.
Volevo scrivere questo articolo da un po’ di tempo, e l’occasione me l’ha data la recente discussione tra Matt Mullenweg e WP Engine.
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.
Come possiamo utilizzare i Coni dei Futuri per rappresentare Obiettivi, Risultati Chiave e Iniziative della nostra azienda?
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.
Ogni volta che svolgo un corso sugli OKR la prima giornata è interamente dedicata a cosa significa misurare e creare dei KPI. Nonostante l’attenzione di tutti sia verso la stesura degli OKR perfetti fin da subito, penso che una incompleta, o nulla, comprensione di cosa significhi misurare e come si costruiscano delle metriche utili sia alla base dell’insuccesso di molte transizione all’uso dello strumento.
In questo articolo, esploreremo la differenza tra KPIs leading, lagging, reporting e metriche esplorative, analizzando esempi pratici per una comprensione più approfondita.
Ho comprato questo libro di impulso mentre terminavo la lettura di Impact! un po’ per curiosità ed un po’ perché avevo voglia di leggere di qualcosa inerente a come il mondo italiano vede il nuovo ruolo del Circular Economy Manager (CEM) o del Business Designer orientato alla Sostenibilità, e lo ho divorato in pochi giorni.
Nel complesso, nonostante una piccola delusione (per una mia aspettativa non corrisposta), il libro ha tanti ottimi spunti, abbastanza da consigliarvi di leggerlo…
Le aziende cercano costantemente metodi efficaci per pianificare e raggiungere i risultati desiderati. Non è un mistero che apprezzi particolarmente gli OKR, questo però non mi impedisce di usare anche altre metodologie affiancandole o indipendenti al fine di trovare una quadra rispetto allo stile dell’azienda con cui lavoro. Una delle metodologie che più apprezzo usare è Hoshin Kanri, un sistema di pianificazione strategica originario dal Giappone ma che nasce dall’influenza di W. Edwards Deming nel dopoguerra.
Dobbiamo capire che la sostenibilità del software va oltre le best practices della Green Software Foundation!
La Green Software Foundation ci ha fornito preziose linee guida, come l’indice SCI (Software Carbon Intensity), per misurare l’impatto ambientale del software. Tuttavia, la sostenibilità del software non si limita solo a questo aspetto. Perché un software sia veramente sostenibile, occorre considerare anche altri fattori cruciali.
