Perchè non è così importante andare veloci?

Nello sviluppo software, ma anche in altri ambiti..

Nel 2009 hanno fatto uno studio dentro Microsoft, per analizzare quanto i progetti e le iniziative digitali partite con lo scopo di migliorare qualche numero, fossero effettivamente riuscite ad avere l’effetto sperato.
Si scoprì che solo un terzo delle iniziative muoveva i numeri nella direzione sperata, un terzo non cambiava le cose in maniera statisticamente significativa ed un terzo addirittura peggiorava le cose.

Ora magari puoi pensare che a Microsoft non erano molto abili (erano pur sempre gli anni di Windows Vista e di Ballmer come CEO), ma non ho ancora trovato uno studio in cui la percentuale di iniziative che hanno effetti positivi sia almeno il 50%. Questo vuol dire che probabilmente anche nella tua azienda e nel tuo lavoro, almeno metà delle iniziative digitali che partono sono destinate ad avere un effetto nullo o negativo. Brutto eh?

Ho anche una bella notizia però, quella che io chiamo “la fondamentale asimmetria dello sviluppo software”, la possibilità di successo delle iniziative è completamente scollegata dalla loro dimensione. Ovvero puoi avere progetti giganti che non portano a niente, ma anche piccole modifiche che hanno impatti enormi.

Facciamo un passo indietro però, ed analizziamo come viene comunemente ottimizzata la creazione di prodotti digitali. Il punto più costoso in termini di tempo della creazione di un prodotto è spesso la programmazione, quindi l’impegno è tutto nell’ottimizzazione dello sviluppo.
Che è un po’ come cercare di arrivare prima ad una meta che non conosciamo correndo tantissimo, ma senza guardare la cartina. Uno sforzo ammirevole, ma forse non ben indirizzato.

“Velocità di motoscafo” Benedetta Cappa (1923)

E quindi? Come si può ottimizzare il processo di creazione ed evoluzione di un prodotto per renderlo più efficace?

Ora probabilmente hai un qualche tipo di riunione regolare in cui si parla dell’andamento degli sviluppi del prodotto, a che punto siamo, quanto ci manca che problemi ci sono... Pensa se a quella riunione il focus fosse invece su che impatto stanno avendo le cose che abbiamo sviluppato, se ci sono iniziative da amplificare o altre da chiudere o addirittura funzionalità da eliminare perchè stanno peggiorando le cose al posto che migliorarle… probabilmente cambierebbero molte cose nel modo di lavorare del tuo team.

Ultimamente il mio lavoro è un po’ questa cosa qua, aiutare i team a lavorare focalizzandosi sui risultati (outcomes) più che sulle attività (outputs), più sulla direzione che sulla velocità.

Hai già sperimentato modalità simili di lavoro? Come ti sei trovato? Hai esperienze da condividere?

A tra due settimane!

PS. Se sei curioso c’è un mio talk del 2018 dagli amici di Crafted Software in cui parlo di un’esperienza concreta di creazione di un prodotto basata sui risultati.