Presentazione del backlog di prodotto

Una volta chiariti i risultati attesi, i membri del team possono riunirsi e mettere a punto la strategia per realizzare le idee di prodotto che li aiuteranno a ottenerli. Da un punto di vista pragmatico, il primo passo che puoi fare verso tali obiettivi è adottare un backlog di prodotto.

Nel nostro lavoro, abbiamo incontrato molti team di prodotto che utilizzano un unico backlog di Jira per acquisire tutto: richieste di funzionalità, opportunità grandi e piccole, task e sottotask, bug e ticket urgenti e idee sulla strada che il prodotto può prendere dopo.

Inevitabilmente, ci hanno raccontato la stessa storia. Il backlog cresce in maniera incontrollata, con un elenco di ticket in continuo aumento, e diventa fonte di ansia. Questi backlog disorganizzati e opprimenti non supportano la definizione delle priorità a nessun livello, dai cambiamenti tattici ai nuovi investimenti di grande portata.

I team hanno finito per spostare queste discussioni nei fogli di calcolo, ma ogni volta si ripeteva la stessa storia. Le informazioni andavano perse, le decisioni non venivano registrate e le risorse erano allocate in tempi stretti, in base all'istinto o a opinioni dominanti.

Ma c'è una soluzione migliore: un backlog di prodotto progettato attorno ai risultati, distinto dal backlog di consegna per il lavoro quotidiano.

Cos'è un backlog di prodotto?

Il backlog di prodotto è il luogo in cui le idee vengono create, ordinate in base alla priorità, condivise in roadmap e collegate a risultati e obiettivi. Il backlog contiene tutte le idee, le informazioni, le opportunità e le soluzioni sui prodotti ed è sotto la responsabilità del team di prodotto. Non è tanto un luogo in cui pianificare task specifici da eseguire, ma è dedicato alla discussione sugli ambiti in cui investire e sui motivi per farlo. Gli stakeholder di tutta l'azienda possono essere invitati a far parte di questo backlog, a collaborare su priorità e roadmap e a discutere dell'avanzamento generale delle iniziative di prodotto in corso.

Pensa al backlog di prodotto come a una casa che il team di prodotto condivide con i collaboratori di tutta l'azienda. È uno spazio designato per tutto ciò che team e collaboratori vogliono monitorare, da idee vaghe a opportunità concrete, e perfezionare nel tempo in base ad apprendimenti, feedback dei clienti e cambiamento degli obiettivi generali.

Backlog di prodotto e backlog di consegna a confronto

Il backlog di prodotto è diverso dal backlog di consegna, perché ognuno ha uno scopo specifico. 

Il backlog di consegna serve a gestire il lavoro di consegna, creare piani di consegna e monitorare l'avanzamento. Contiene la suddivisione del lavoro (epic, story, task e sottotask) per capire come rispettare gli impegni ed è sotto la responsabilità del team di ingegneri. Qui l'intero team si riunisce e collabora per discutere dei problemi di consegna: sequenziamento, dipendenze, capacità, milestone tecniche.

Naturalmente i backlog di prodotto e consegna sono strettamente collegati. Il lavoro nel backlog di consegna porta a formulare idee nel backlog di prodotto, che a loro volta sono collegate ai risultati desiderati. In questo modo, leader, manager e sviluppatori possono ottenere una panoramica di come il team sta lavorando per raggiungere i risultati man mano che il lavoro procede attraverso cicli di esplorazione e consegna.

Diversamente da quanto avviene nel backlog di prodotto, tutti gli elementi del backlog di consegna sono intesi come piani concreti, da completare alla fine. Il backlog di prodotto serve invece per l'ideazione, il brainstorming e la pianificazione. Alcune idee di prodotto non avranno mai la priorità e finiranno nelle roadmap, come è giusto che sia.  

Separando i problemi generali relativi ai prodotti dalla pianificazione e dal monitoraggio delle consegne, i team possono stabilire le priorità in modo più efficace, collegare il lavoro ai risultati ed evitare backlog fuori controllo che cercano di accontentare tutti.

Backlog di prodotto e backlog di consegna a confronto
Il collegamento tra i backlog di prodotto e di consegna e la relazione con i diversi team dell'azienda.

Backlog di prodotto

Backlog di consegna

A cosa serve?

In cosa dovremmo investire? Perché?

Come ci riusciamo?

In cosa consiste?

Idee di prodotto, problemi degli utenti, opportunità, soluzioni, ipotesi

Suddivisione del lavoro: epic, story, task, sottotask e bug

Chi ne è responsabile?

Product manager

Owner di prodotto, leder del team di ingegneri, project/program manager

Chi partecipa

Il team di prodotto principale: product manager, ingegneri, designer, altri team di prodotto dell'azienda

Team che lavorano a contatto con i clienti (vendita, assistenza, di successo dei clienti, solution engineering, sul campo)

Leadership

Stakeholder aziendali

Il team di prodotto principale:

Product manager, ingegneri, designer

Leadership ingegneristica

Assegnazione delle priorità basata su

Obiettivi, valore aziendale

Feedback e informazioni dei clienti

Analisi del prodotto e dati

Fattibilità tecnica

Dipendenze

Capacità del team

Urgenza operativa (ad esempio bug e problemi di affidabilità)

Vantaggi di un backlog di prodotto

L'utilizzo di backlog separati per prodotti e consegne offre molti vantaggi:

  • È uno spazio sicuro in cui il team di prodotto può discutere di potenziali idee, oltre che dei dati disponibili, senza preoccuparsi di quanto siano realizzabili o definite. 

  • Riunisce tutte le discussioni sui prodotti, in modo che i team possano acquisire conoscenze nel tempo senza dover effettuare ricerche in numerosi fogli di calcolo.

  • Crea un'origine di riferimento condivisa e una comprensione comune delle priorità dei prodotti. Questo risolve un problema comune che i team di prodotto si trovano ad affrontare: il processo decisionale basato sull'istinto o sulle opinioni dominanti di clienti e stakeholder. 

  • Crea trasparenza nelle discussioni sulla definizione delle priorità, portando tutti i membri dell'azienda a condividere le stesse opinioni. Questo elimina molti attriti durante la collaborazione con stakeholder e team rivolti ai clienti.

  • È legato al lavoro di consegna, quindi le roadmap non diventano obsolete e sono sempre precise in quanto tengono conto dei vincoli di consegna.

Come organizzare il backlog di prodotto

Idee, opportunità, problemi, soluzioni: il team di prodotto deve decidere cosa inserire nel backlog di prodotto tenendo in considerazione a cosa sta cercando di dare priorità e rappresentando il suo modo di pensare le priorità e gli investimenti legati ai prodotti.

Il backlog di esplorazione
Il modo in cui i diversi gruppi di stakeholder interagiscono con il backlog di prodotto.

È molto importante che il team di prodotto controlli i contenuti del backlog di prodotto e la struttura utilizzata per classificare le idee e definirne la priorità, altrimenti si rischia di ottenere la disorganizzazione che si stava proprio cercando di evitare.

Per controllare il backlog, è necessario invitare stakeholder interni solo con modalità predefinite per contribuire, anziché con privilegi diretti di creazione e modifica degli elementi. Ad esempio, questi collaboratori potrebbero aggiungere commenti, votare le idee o taggare il cliente che ha richiesto una funzionalità.

Le diverse categorie di collaboratori a un backlog di prodotto
Le diverse categorie di collaboratori a un backlog di prodotto.

Di seguito sono riportati due framework consigliati per strutturare un backlog di prodotto: macigni, sassi e ciottoli ed elenchi lunghi, medi e brevi. Ti consigliamo di organizzare il backlog di prodotto in base a questi tre bucket e a queste attività.

In Jira Product Discovery, questo viene fatto configurando visualizzazioni specifiche per mostrare le idee giuste e scegliendo i campi da visualizzare per facilitare la discussione (selezione, valutazione) e invitare alla collaborazione (approfondimenti, voti, commenti, reazioni).

Macigni, sassi e ciottoli

Molti team di prodotto hanno un solo tipo di oggetto: "idea", ma il backlog può contenere elementi di diverse forme, dimensioni e livelli di granularità, da nuove grandi scommesse a piccoli miglioramenti dei prodotti. 

Una pratica comune consiste nello strutturare un backlog con tre categorie di elementi: 

  • Macigni: grandi investimenti, opportunità strategiche e nuove grandi scommesse

  • Rocce: investimenti medi e miglioramenti sostanziali dei prodotti che portano ai risultati

  • Ciottoli: piccoli investimenti, come risoluzione di piccoli bug e ticket nell'esperienza utente

È meglio creare aree separate per queste categorie nel backlog di prodotto e pensare a bilanciare gli investimenti tra le tre, riservando budget e spazio della roadmap a ognuna. Senza questo tipo di intenzionalità è difficile assegnare le priorità, soprattutto per quanto riguarda i ciottoli. Una nuova grande scommessa è entusiasmante, ma i piccoli miglioramenti hanno un effetto negativo aggravato sull'esperienza utente. 

Ulteriori informazioni su questo framework sono disponibili nella sezione Idee.

Roadmap JPD
Una visualizzazione dei macigni.
Una visualizzazione dei ciottoli
Una visualizzazione dei ciottoli.

Elenchi lunghi, medi e brevi

Un altro modo semplice e pragmatico per strutturare un backlog di prodotto viene da Brent Johnson, uno dei primi ad adottare Jira Product Discovery, che ha descritto il lavoro sui prodotti come lavorare costantemente con 3 bucket: elenco lungo, elenco medio ed elenco breve.

Il team di prodotto trae le sue idee dagli elenchi lungo, medio e breve del backlog di prodotto, invitando gli stakeholder di tutta l'azienda a collaborare.

Il modo in cui i diversi gruppi di stakeholder contribuiscono agli elenchi lunghi, medi e brevi
Il modo in cui i diversi gruppi di stakeholder contribuiscono agli elenchi lunghi, medi e brevi.
  • L'elenco lungo contiene tutto: idee non definite, problemi, opportunità o soluzioni e può includere più di 200 idee. 

    • È curato dal team di prodotto, che usa la conoscenza del mercato, le preoccupazioni strategiche e operative e le esigenze di clienti e aziende per trasformarlo in un elenco medio.

  • L'elenco medio è una preselezione delle possibili priorità, cioè opportunità interessanti in cui il team potrebbe legittimamente investire. 10-20 delle oltre 200 idee di un elenco lungo possono arrivare all'elenco medio.

    • Sono le idee che sembrano buone perché sono importanti dal punto di vista strategico, emergono spesso nelle discussioni con i clienti o hanno un forte potenziale per soddisfare gli utenti. Occorre assegnare loro la priorità inserendole in un elenco breve, in genere con il contributo dei diversi stakeholder dell'azienda. 

  • L'elenco breve è fondamentalmente la roadmap del prodotto, cioè le idee che il team di prodotto si è impegnato ad approfondire. Questi task mettono in atto opportunità, problemi o soluzioni per iniziare a creare un'esperienza di prodotto o migliorarne una esistente. 

    • Il team esamina regolarmente questo elenco in base a ciò che apprende e si impegna a tenerlo aggiornato. È l'elenco su cui il resto dell'azienda può aspettarsi aggiornamenti più regolari.

Un backlog di prodotto, organizzato per contenere le richieste dei clienti.
Un backlog di prodotto, organizzato per contenere le richieste dei clienti.

Come creare un backlog di prodotto in Jira Product Discovery

Abbiamo progettato Jira Product Discovery come un luogo in cui i team di prodotto possono raccogliere le proprie idee, collaborare per svilupparle e stabilire le priorità. In Jira Product Discovery, puoi creare uno o più backlog di prodotto, chiamati "Discovery Project". 

In genere, l'opzione migliore è includere chi lavora insieme ogni giorno in un unico progetto (come ad esempio una o più squadre). Detto ciò, molti clienti di Jira Product Discovery ospitano diversi team e prodotti nello stesso progetto. Ciò è particolarmente utile quando è richiesto un livello di collaborazione elevato tra i vari team.

Ecco una demo su come fare:

Con il piano premium di Jira Product Discovery, puoi visualizzare idee provenienti da più progetti in un unico luogo, creando viste che mostrano idee provenienti da progetti diversi e il quadro generale dei programmi di prodotto di un'organizzazione.

E poi?

Nelle ultime due sezioni di questo manuale, spiegheremo nel dettaglio come utilizzare un backlog di prodotto per:

Forniremo esempi di come facciamo tutto ciò nel team di Jira Product Discovery, utilizzando Jira Product Discovery e altri prodotti.