Riepilogo: la roadmap di prodotto è un piano d'azione che descrive l'evoluzione di un prodotto o una soluzione nel tempo. I team di prodotto utilizzano le roadmap per delineare le funzionalità future del prodotto e quando verranno rilasciate nuove funzioni. Se utilizzata nello sviluppo Agile, una roadmap fornisce contesto cruciale per il lavoro quotidiano del team e dovrebbe rispondere ai cambiamenti nel panorama competitivo.
L'idea che lo sviluppo Agile ignori la pianificazione a lungo termine potrebbe essere il più grande mito dopo il mostro di Loch Ness. La roadmap è tanto importante per un team Agile quanto per un team Waterfall perché fornisce un contesto per il lavoro quotidiano del team ed è in grado di adattarsi ai cambiamenti del panorama concorrenziale. Ma a differenza di un certo leggendario mostro acquatico scozzese, una roadmap Agile ben fatta è facile da trovare e facile da capire.
Che cos'è una roadmap di prodotto Agile?
La roadmap di prodotto è un piano d'azione che descrive l'evoluzione di un prodotto o una soluzione nel tempo. I team di prodotto utilizzano le roadmap per delineare le funzionalità future del prodotto e quando verranno rilasciate nuove funzioni. Se utilizzata nello sviluppo Agile, la roadmap fornisce contesto cruciale per il lavoro quotidiano del team, la vision futura e dovrebbe rispondere ai cambiamenti nel panorama competitivo. Più team Agile possono condividere un'unica roadmap di prodotto, oppure ogni team può avere la propria.
Creazione della roadmap
Per creare una roadmap, i team di prodotto prendono in considerazione le traiettorie di mercato, gli obiettivi aziendali, i feedback e le informazioni dei clienti e i vincoli di progettazione. Una volta che questi fattori sono stati ragionevolmente ben compresi, vengono espressi in una roadmap sotto forma di iniziative e timeline. Di seguito è riportata una roadmap molto semplice creata per un team di prodotto. In generale, è meglio che le roadmap dei prodotti si attengano a periodi di tempo più lunghi, come mesi o trimestri, piuttosto che impegnarsi a rispettare date specifiche. Per far sì che le conversazioni sull'assegnazione siano incentrate sugli obiettivi e le strategia, anziché sulle timeline, puoi anche provare ad associare Now (Ora), Next (In seguito) e Later (Successivamente) alle iniziative.
Condivisione della roadmap
Una volta creata, la roadmap deve essere condivisa con l'intero team di prodotto e i team dirigenziali e di distribuzione, in modo che tutti comprendano la vision e la direzione da seguire. In molte organizzazioni, gli owner di prodotto creano le loro roadmap in PowerPoint e fogli di calcolo, quindi inviano le slide e i fogli di calcolo al team tramite e-mail. Sebbene sia mossa da buone intenzioni, questa strategia è viziata fin dall'inizio. Ogni membro del team ha la propria copia della roadmap e tenere tutti aggiornati quando e se la roadmap cambia è a dir poco dispendioso in termini di tempo.
Quindi, come possono i team di prodotto tenere l'organizzazione informata al meglio? Semplice.
La maggior parte degli strumenti di collaborazione creati per questo scopo invierà automaticamente una notifica a tutti i partecipanti a un progetto per informarli che la roadmap è cambiata.
Quando aggiungi un'iniziativa alla roadmap, tieni presente le seguenti domande:
Prima di parlare di soluzioni di previsione dinamica, parliamo dei passaggi da seguire per creare un piano Agile a lungo termine usando la metafora della costruzione di una casa:
- Quali sono le priorità relative di ciascuna iniziativa?
- Che impatto avrà ogni iniziativa sugli obiettivi di prodotto e aziendali?
- Quanto impegno è richiesto per ogni iniziativa?
- Esistono informazioni e dati sufficienti per sostenere il perseguimento di un'iniziativa?
- Quando intendiamo lavorare a ciascuna iniziativa?
- Ci sono date particolari che il team deve rispettare?
- Quali sono le dipendenze, sia interne che da altri team, del programma?
- Quali team stanno lavorando a ciascuna iniziativa?
- I team attuali hanno disponibilità nelle loro programmazioni e capacità sufficiente?
- Possiamo mantenere stabili gli attuali team Agile?
- Se la risposta è no...
- Come verranno riorganizzati i team?
- Stiamo tenendo conto della formazione dei team appena creati sulla timeline del progetto?
- Come verranno riorganizzati i team?
- Se la risposta è no...
Utilizzo della roadmap
È importante ricollegare il lavoro finale del team alla roadmap del prodotto in modo da ottenere il "contesto" completo di cui si parla sopra. Un modo collaudato per farlo è quello di tracciare le idee di prodotto a cui hai assegnato la priorità nella tua mappa dei prodotti, quindi suddividerle in epic, requisiti e storie utente nella tua roadmap finale. Spesso ciascuna idea avrà un epic corrispondente che deve essere suddiviso in task più piccoli. Collegare le idee sulla tua roadmap di prodotto con epic della tua roadmap finale offre agli ingegneri il contesto alla base di iniziative prioritarie, come il feedback e la ricerca degli utenti, a portata di mano. Inoltre, rende più facile per i team di prodotto e sviluppo prendere insieme decisioni a breve termine che non compromettano il lavoro futuro.
Supponiamo, ad esempio, di implementare un'ampia funzione di profilo utente sul nostro sito Web. Se scopriamo che i nostri clienti non interagiscono con la funzione, dovremmo continuare a investire in quest'ultima? Forse sì, forse no. Dobbiamo capire perché il coinvolgimento è basso prima di prendere questa decisione. Quindi, invece di andare avanti, potremmo decidere di implementare alcuni test A/B nella speranza di ottenere qualche idea sul basso tasso di coinvolgimento, che potrebbe indicarci una direzione che sarebbe stata molto più difficile (o impossibile) se fossimo semplicemente andati avanti aggiungendo altri fronzoli.
La capacità di fare un passo indietro e fare ricerche prima di prendere una decisione cruciale è l'essenza delle roadmap Agile. E idealmente, il processo di discovery di informazioni e dati è il passo iniziale che fai prima di decidere di attuare qualsiasi decisione. Le roadmap offrono al team la possibilità di evolvere le funzioni man mano che apprende ulteriori informazioni su un prodotto e sul mercato.
- La pianificazione futura è completamente ignorata: stiamo agendo in modo avventato.
- Il "resto dell'azienda" è tenuto all'oscuro delle attività del team.
- La roadmap viene aggiornata continuamente (o mai).
- I requisiti dettagliati stanno appesantendo la roadmap.
Evoluzione della roadmap
I progetti Waterfall richiedono un enorme investimento iniziale. Di conseguenza, i membri del team si affezionano alla roadmap e rinunciano a prendere la decisione giusta perché è troppo doloroso annullare il lavoro che hanno fatto: un "peccato" umano, se mai ce ne fosse uno.
Da parte sua, lo sviluppo Agile comporta tre rischi diversi:
- Il team potrebbe perdere fiducia nella capacità della leadership di prendere decisioni strategiche se la roadmap viene aggiornata troppo frequentemente.
- Il prodotto potrebbe arrivare troppo tardi sul mercato e perdere la domanda repressa se la roadmap non viene aggiornata abbastanza frequentemente.
- Gli sforzi a lungo termine possono sembrare "troppo grandi e impegnativi" per iterazioni più brevi. Il team sovracompensa suddividendo il lavoro in granularità estremamente fine e finisce per concentrarsi troppo sui risultati a breve termine.
Per contrastare il "girare a vuoto", la mancanza di originalità e gli atteggiamenti miopi, mantieni la roadmap uniformemente focalizzata su tattiche a breve termine e obiettivi strategici a lungo termine. Un ottimo modo per farlo è rivedere trimestralmente le roadmap, adeguarle alle necessità e condividerle. Questa procedura funziona bene in organizzazioni di qualsiasi dimensione, ma ricorda: una singola roadmap può estendersi a più team Agile, quindi ispeziona, adatta e comunica di conseguenza.
Continua a leggere la guida Agile Coach per considerazioni speciali rivolte ai team più grandi che gestiscono portfolio Agile con roadmap che coinvolgono diversi team. Puoi anche provare a creare gratuitamente la tua roadmap in Jira Product Discovery, creata per i team di prodotto.