L'alternativa alle roadmap

Ho sempre trovato fantastica la seguente citazione del Generale George Patton:

"Non dire alle persone come fare qualcosa. Di' loro cosa fare e ti sorprenderanno con la loro inventiva".

Purtroppo le roadmap fanno proprio ciò di cui il Generale avverte

Le roadmap dicono ai team cosa fare e come farlo. Normalmente questo avviene sotto forma di liste prioritizzate di feature o progetti, che qualcuno crede davvero risolverà il problema (anche se il problema spesso non è ancora chiaro o non è stato realmente compreso).

Se sulla tua roadmap c'è qualcosa come "aggiungere PayPal come metodo di pagamento aggiuntivo", è perché credi che ci siano clienti che non possono pagare con gli altri tuoi metodi di pagamento? O ha a che fare con i pagamenti internazionali? O forse qualcuno pensa che sarebbe uno svantaggio competitivo non offrire questa opzione?

Ho già sottolineato in diversi articoli che considero le product roadmap classiche come la fonte di molto spreco nei team di prodotto. L'articolo Prodotti falliti tratta questo tema e in Scomode verità dello sviluppo prodotto approfondisco questo concetto.

Poiché il problema delle roadmap riceve sempre più attenzione, ultimamente mi è stato chiesto più spesso di parlare dell'alternativa alle roadmap.

Un argomento vasto

In questo articolo vorrei provare a farlo. È un grande tema, che ha a che fare anche con argomenti come cultura di prodotto, empowerment e autonomia. Di solito mi serve almeno un'ora per spiegare tutto questo di persona, ma spero di riuscire a riassumere l'essenza qui.

Prima di lanciarci sull'alternativa alle roadmap, dobbiamo chiarire che le roadmap sono state utilizzate per così tanto tempo perché soddisfano due esigenze ben precise – e queste esigenze non spariranno semplicemente.

1) La dirigenza vuole assicurarsi che i team lavorino prima sugli item di maggior valore per l'azienda.

2) Poiché devono gestire un'azienda, ci sono situazioni in cui hanno bisogno di scadenze concrete e impegni – e con le roadmap possono registrare e tracciare questi impegni.

Affinché un'alternativa alle roadmap classiche possa essere accettata nelle aziende, questi due punti devono essere affrontati almeno altrettanto bene.

Le roadmap hanno le loro radici nel vecchio modello centralizzato command-and-control. Alcuni stakeholder tengono una riunione – di solito trimestralmente – per riflettere sulle priorità e i progetti dei team per il trimestre successivo.

Al contrario, nel modello del team di prodotto i team dovrebbero poter scoprire da soli come risolvere i rispettivi problemi di business di cui devono occuparsi.

Ma per questo non basta avere semplicemente bravi collaboratori. Il team ha bisogno del contesto necessario. I membri del team devono aver interiorizzato dove esattamente l'azienda vuole andare e devono aver compreso cosa il loro team deve contribuire a questo obiettivo superiore.

Per tornare al Generale Patton:

Come forse già sai, anche l'esercito lavora con il concetto di team autonomi. Questi team (Squad) sono mantenuti intenzionalmente piccoli e sono per lo più autonomi, tengono sempre d'occhio le intenzioni comuni, ma possono decidere da soli cosa ritengono sia il modo migliore per risolvere un determinato problema.

Queste intenzioni comuni sono il contesto che ho appena menzionato. "Attraverso le intenzioni vengono formulati con precisione gli obiettivi e le intenzioni superiori... Intenzioni chiare portano ad attività mirate nelle forze armate. Esprimono ciò che il comandante vuole raggiungere e perché, e generano nelle forze armate un senso di appartenenza. Normalmente vengono espresse attraverso possibili impatti, obiettivi e risultati desiderati... Intenzioni realmente ben formulate sono comprensibili per i subordinati anche senza una grande quantità di dettagli aggiuntivi."

Le aziende tecnologiche hanno diverse possibilità per fornire questo contesto o queste intenzioni. Tuttavia, io sostengo due componenti ben precise:

La visione del prodotto: descrive la visione olistica di ciò che l'organizzazione nel suo insieme sta cercando di raggiungere.

Gli obiettivi aziendali: descrivono gli obiettivi aziendali specifici e prioritizzati per ogni singolo team di prodotto.

Esistono diversi sistemi e metodologie per gestire questi obiettivi aziendali. Il mio preferito al momento è il sistema OKR (Objectives and Key Results).

L'idea in sé è piuttosto semplice: di' ai membri del team cosa devono raggiungere e come verranno misurati i risultati. Poi lascia che il team decida da solo cosa ritiene essere il modo migliore per risolvere i rispettivi problemi.

Supponi, ad esempio, che il tuo prodotto richieda attualmente 30 giorni per il processo di onboarding di nuovi clienti. Per poter scalare efficacemente, questo deve essere ridotto a 3 ore o meno. Questo sarebbe quindi un buon esempio di obiettivo per uno o più team di prodotto: "Ridurre drasticamente il tempo necessario perché un cliente sia operativo." Uno dei risultati chiave potrebbe essere: "Tempo medio di onboarding inferiore a 3 ore."

Anche se il concetto degli obiettivi di team sembra piuttosto semplice, ci sono molte possibilità per istituzionalizzarlo nei team di prodotto e nelle organizzazioni, e possono volerci alcuni trimestri prima che l'organizzazione goda dei benefici di questo concetto.

Ci sono alcune scoperte sulla visione del prodotto e soprattutto sulla buona applicazione del sistema OKR che metterò al centro dei prossimi articoli. Nel frattempo, puoi già dare un'occhiata al materiale di Christina Wodtke.

Questo contesto è quindi molto importante – ovvero la visione del prodotto e gli obiettivi del team.

All'inizio ho sottolineato che dobbiamo considerare i due principali motivi per le buone vecchie roadmap. Il primo era il desiderio di lavorare prima sugli item di maggior valore per l'azienda. È sperabilmente chiaro che il management si occupa di questa esigenza fornendo gli obiettivi specifici per l'organizzazione e la loro prioritizzazione. La differenza, però, è che ora prioritizzano l'importanza dei risultati di business invece del valore soggettivo dei feature.

Il secondo motivo era la necessità di commitment, a cui rispondiamo con il concetto di commitment ad alta integrità. Questo si riferisce a situazioni in cui abbiamo effettivamente bisogno di un commitment per una data o un risultato specifico.

Questo approccio ha diversi vantaggi:

In primo luogo, i team sono molto più motivati quando possono decidere autonomamente quale ritengono essere la migliore soluzione al problema.

In secondo luogo, il team non può semplicemente cavarsela consegnando un feature o progetto desiderato; il feature deve anche funzionare effettivamente (il che viene misurato attraverso i Key Results). In caso contrario, il team deve provare un approccio diverso per risolvere il problema.

In terzo luogo – indipendentemente da dove venga l'idea per una soluzione – molto spesso il primo approccio non funziona e, invece di negarlo, con questo modello se ne è molto consapevoli.

Tutto ruota più attorno all'outcome invece che all'output – ovvero ottenere un risultato significativo, invece di raggiungere semplicemente un qualsiasi obiettivo.

Spesso chiedo ai team di guardare all'anno passato e di valutarsi in base al tasso di successo della loro roadmap, in termini di quanti item corrispondessero effettivamente agli obiettivi aziendali. Se lo fai e non sei orgoglioso di ciò che scopri, spero che prenderai in considerazione questa alternativa. Assicurati che la tua organizzazione di prodotto disponga di una visione del prodotto convincente. Assicurati che ogni team di prodotto abbia obiettivi aziendali chiaramente definiti e prioritizzati. Assicurati che tutti i commitment necessari siano commitment ad alta integrità.
E ora dai potere ai tuoi team di prodotto, affinché possano decidere autonomamente quali soluzioni ritengono più adatte a determinati problemi di business, e guarda quanti dei tuoi team ti sorprenderanno con i loro risultati.

Questo testo proviene dal blog di Marty Cagan ed è stato tradotto in italiano.

Seminario Product Owner

=> Visita ora un Seminario Product Owner di Agile Academy.

Il Product Backlog

=> Leggi di più sul Product Backlog nel dizionario agile.

Il ruolo del Product Owner

=> Scopri di più sul ruolo del Product Owner.