Conquista il team con una Roadmap agile

Quanto è importante strutturare correttamente la Roadmap del proprio progetto, per monitorare, prevedere, ma anche comunicare con chiarezza con il team? Moltissimo.
Noi di GetConnected per esempio abbiamo sviluppato un Add-on Atlassian per aiutare proprio i Project Manager a costruire roadmap migliori e integrate tra Confluence e JIRA, Live Roadmap.

Grazie a questo incisivo e puntuale articolo, la nostra seconda puntata del Blog Atlassian sul Product Management Agile, sarà facile capire l’importanza di alcuni must-haves della progettazione e come attuarli, per ottenere un teamwork migliore.

La presentazione di una roadmap può essere un argomento spinoso sia per gli sviluppatori che per i Product Manager: mentre questi hanno lavorato duramente per ottenere una visione, tutto ciò che gli altri vedono è l’ignoto che si abbatte sul loro lavoro.

Io stesso (Martin Suntinger, NdT) ho sperimentato queste tensioni quando lavoravo come sviluppatore e spesso mi trovavo in disaccordo con le roadmap messe insieme dai Product Manager. Non comprendevo pienamente il motivo di determinate scelte, e spesso ciò che mi ritrovavo a pensare al termine dei meeting di pianificazione era: “Beh, questo non ha senso per me, ma se lo dicono loro…” o peggio “Dovremo cavarcela da soli e fare sembrare che ciò che facciamo combaci con questa roadmap”.

Potresti obiettare che il problema non è certo una novità, e avresti ragione. In quanto sviluppatore, ho sempre avuto un’opinione forte su quale fosse la cosa giusta da fare. Ma ora che sono diventato un Product Manager, comprendo i motivi di questi dis-allineamenti, e quali insegnamenti trarne fuori per fare centro alla prossima presentazione di una roadmap. Dopo tutto, se il team tecnico comprende e condivide il quadro generale, le decisioni di progettazione e implementazione quotidiane saranno fatte con il giusto contesto e otterrai il prodotto immaginato.

1. Prediligi la sostanza ai paroloni

Mentre parole d’ordine come “big data analytics”, “learning machines” o “iniziative di Internet of Things (IoT)” possono essere efficaci sul piano business come punti di ancoraggio di alto livello, queste non sono di alcuna utilità ai team tecnici. Gli ingegneri devono sapere esattamente cosa stanno costruendo, come il prodotto si lega a prodotti concorrenti, con che modalità sarà consegnato e chi lo userà alla fine, e con quale scopo.

Impostare temi di livello macro è un’ottima cosa per la strutturazione di roadmap e contesto, ma assicurati di non fermarti lì e di avere delle buone risposte per tutto ciò che sta dietro ad ogni elemento di alto livello. Ad esempio, se hai chiamato un tema “servizi intelligenti”, assicurati di scomporre il tutto in iniziative chiave ed epics necessari alla realizzazione del tema stesso.

2. Fornisci il giusto contesto

I team tecnici necessitano di conoscere il contesto del perché hai pianificato la costruzione di qualcosa attraverso una roadmap. Nessun team tecnico ti dirà mai “Dimmi solo cosa ti serve e te lo faccio”. Al contrario, gli ingegneri vogliono vedere da dove scaturisce la richiesta di una feature.

Lascia che siano i dati a parlare e a raccontate una storia convincente dalla prospettiva degli Users. Fai il ricorso ad alcune user personas, e parla di altre alternative che hai già scartato e perché. Per aiutare l’intero team a comprendere la tua roadmap, il “perché” conta tanto quanto il “cosa”.

3. Fa attenzione al commitment

Se una feature non sembra ben pensata o realistica, ma è ancora in roadmap, dovrebbe scattare un campanello d’allarme. Non dare mai l’impressione al tuo team tecnico che questi debbano costruire qualcosa soltanto perché tu l’hai promesso a qualcuno. Il che potrebbe essere un impegno preso con un cliente o una richiesta del Management. Quindi sii saggio quando si parla di impegnarsi. E anche quando hai delle forti pressioni dietro di te relativamente alla richiesta di una particolare modifica, assicurati di trasmettere la giusta logica anche al team.

4. Realizza piani realistici

Una visione è una cosa buona, ma è ancora meglio se tutti si sentono in grado di poterla effettivamente realizzare. Il piano non deve essere preciso, ma se la prima cosa che il tuo Responsabile di Sviluppo vede osservando la roadmap è un gran collo di bottiglia: per esempio, se la roadmap appare centrata sui temi di design ma tu hai un solo designer, allora questi ti contesterà per tutto il resto della tua presentazione.

Assicurati di fare una verifica di fattibilità e su diversi scenari multipli. Devi avere risposte, un chiaro piano d’azione e una definita consapevolezza di “come ciò può esser realizzato”, prima di richiedere l’impegno degli altri.

5. Pensa in grande, ma resta coi piedi per terra

Devi essere consapevole di dove si trovino oggi il prodotto e le capacità del team, rispetto a dove vorresti che fossero. E’ fantastico avanzare verso nuovi terreni, che potrebbero richiedere nuove competenze per il team o di discostarsi dalla tecnologia attuale, ma non basta annotare le aspirazioni di dove vorresti trovarti di qui a un anno. Piuttosto, pensa a come arrivarci realisticamente. Acquisire talento richiede tempo, adottare nuove tecnologie pure, e abbandonare i prodotti esistenti richiede impegni precisi e un piano di transizione.

6. Costruisci un business case

Business Case? Proprio così, anche ai team tecnici interessano i business case. Forse non nella stessa misura del Senior Management, ma ad un team tecnico interessa capire perché qualcosa è rilevante per il business, se produce risultati reali e come questi verranno misurati. Tieni allineato il tuo team. Tutti hanno interesse per il successo aziendale nel suo complesso, e ciò può essere un’ottima fonte di feedback e di raccolta di nuove idee.

Inoltre, una piena consapevolezza sull’impatto di business, e una visibilità sui risultati effettivi stimola la motivazione; guidare i risultati è molto più stimolante del limitarsi a sviluppare e rilasciare una feature.

7. Bilancia aspetti noiosi con quelli motivanti

Gli ingegneri vogliono costruire prodotti unici e innovativi, di cui essere orgogliosi. Se si tratta della stessa vecchia storia già raccontata da altri, ciò può essere demotivante. Assicurati di fare ricerche per essere sicuro che la tua storia sia tanto innovativa quanto credi. La mancanza di innovazione può essere demoralizzante per gli sviluppatori, ma ancora peggiore sarà il suo impatto sul business.

Detto ciò, la roadmap finirà sempre con l’apparire come un mix tra interessantissime nuove feature, e aspetti non troppo eccitanti a livello tecnico che comunque vanno svolti. Basta che ti assicuri che anche gli aspetti banali appaiano motivanti sulla tua roadmap.

8. Pensa oltre l’MVP e la Versione 1

Creare un MVP (Minimum Viable Product) e poi una Versione 1.0 è un conto, ma ci sono anche una gran varietà di aspetti di cui tenere conto a rilascio effettuato: azioni operative, supporto, richiesta di nuove feature da parte degli utenti, miglioramenti continui, e nuove versioni di altri prodotti e/o di piattaforme integrate. Una rapida riflessione su sfide e ostacoli che potrebbero verificarsi a rilascio eseguito, porterà facilmente alla luce tutti questi aspetti, e gli ingegneri saranno grati che queste dimensioni non siano state ignorate. Da alcune stime emerge addirittura che lo sforzo iniziale nel costruire una nuova feature varia da 1/2 a solo 1/3 dello sforzo totale: il risultato è cioè più costoso della costruzione iniziale, e un insieme di “piccole cose” diventano molto costose a lungo andare.

9. Sii pronto a parare i colpi

Le stime sono una cosa positiva. Danno una guida, e sono costruiti sulla base della migliore conoscenza di un Product Manager ad ogni dato momento nel tempo. Nonostante ciò, diverse ipotesi alla base delle stime possono finire per rivelarsi sbagliate al momento dell’implementazione o definizione del progetto. Assicurati di costruire e presentare una roadmap che sia flessibile ai cambiamenti.

10. Sii aperto e onesto

L’obiettivo di una roadmap è di fornire una guida. Non è un piano dettagliato d’esecuzione e tutti i membri del team di sviluppo lo sanno bene. Non c’è bisogno di farla apparire come qualcosa che non è. Quindi, se non possiedi ancora tutti i dettagli su un determinato topic, sii onesto. Condividi cosa sai, quali sono le intenzioni, le domande ancora aperte e i rischi maggiori che devono essere ancora individuati. Evidenzia le aree che necessitano di ulteriore sperimentazione e ricerca, per inquadrare al meglio il “cosa”. L’importante è ricordarsi di includere questo tempo per la sperimentazione all’interno della pianificazione.

In conclusione?
Il tuo team necessita di una roadmap che dipinga chiaramente il quadro generale, ma che non trascuri la realtà. Il team necessita inoltre una roadmap che sia motivante, e che abbia abbastanza dettagli per dare indicazioni agli sviluppatori circa il da farsi nei prossimi 1-2 sprint, sentendosi sicuri che saranno in grado di ottenere grandi risultati che avranno un reale impatto per il business.

Come scegliere un tool e integrarlo per le vostre roadmap? Richiedete una call gratuita di 30′ con un nostro esperto

Articolo Originale: https://www.atlassian.com/agile/tips-for-presenting-product-roadmaps

di Martin Suntinger, Principal Product Manager per Portfolio for JIRA | traduzione di Davide Schillaci