Come creare un documento sui requisiti del prodotto (PRD)

PUNTI CHIAVE

• Un PRD (documento sui requisiti di prodotto, dall'inglese Product Requirements Document) definisce lo scopo, le funzionalità e il comportamento di un prodotto, allineando gli stakeholder e orientando lo sviluppo.

• I PRD Agile si concentrano sulla comprensione condivisa, sulle esigenze dei clienti e sulla flessibilità, evitando specifiche eccessivamente dettagliate.

• Dei PRD efficaci includono obiettivi, presupposti, user story, design ed elementi fuori ambito chiari, che promuovono la collaborazione e l'adattabilità.

• Collabora con il tuo team per creare e aggiornare regolarmente un PRD conciso, garantendo chiarezza e allineamento durante tutto il progetto.

Per creare un prodotto di successo, si inizia con una direzione definita e un allineamento chiaro. È qui che entra in gioco il documento sui requisiti del prodotto (PRD).

Un PRD delinea le caratteristiche essenziali, gli obiettivi e le funzionalità di un prodotto e funge da roadmap del prodotto che permette ai team di trasformare le idee in realtà. Questo è un passaggio cruciale per qualsiasi product manager che deve allineare i team, gli stakeholder e gli obiettivi generali.

In questo articolo, analizzeremo cos'è un documento sui requisiti del prodotto, perché è importante e come getta le basi per uno sviluppo efficace del prodotto.

Cos'è un documento sui requisiti del prodotto?

Un documento sui requisiti del prodotto (PRD) definisce il prodotto che si sta per creare: ne delinea lo scopo, le caratteristiche, le funzionalità e il comportamento.

Definisce lo scopo, le principali funzionalità del prodotto, le esigenze degli utenti e i criteri di successo, fornendo un'unica origine di riferimento per i team interfunzionali.

Documentando chiaramente i requisiti e le aspettative, un PRD garantisce che tutti, dai progettisti agli sviluppatori agli stakeholder, rimangano allineati durante l'intero processo di sviluppo del prodotto.

Documento sui requisiti del prodotto per il lavoro Agile

Che aspetto ha il processo di raccolta dei requisiti in un mondo Agile? Sembra complicato, anzi lo è. Ma non preoccuparti.

In Atlassian, sappiamo tutto sulla creazione di PRD in un ambiente Agile. I requisiti Agile sono i migliori alleati dell'owner di prodotto.

Gli owner di prodotto che non utilizzano i requisiti Agile si ritrovano a dover specificare ogni dettaglio per rilasciare il software giusto (e poi incrociano le dita sperando di aver specificato gli elementi giusti). D'altra parte, i requisiti Agile dipendono anche da una comprensione condivisa del cliente.

Queste conoscenze vengono condivise tra owner di prodotto, progettista e team di sviluppo. Le conoscenze condivise e l'empatia nei confronti dei clienti di destinazione permettono agli owner di prodotto di trovare risorse che non sapevano di avere.

Possono concentrarsi sui requisiti di livello superiore e lasciare i dettagli dell'implementazione al team di sviluppo, che è perfettamente attrezzato per occuparsene grazie a questa base di conoscenze condivise.

Suggerimenti per creare un documento sui requisiti del prodotto efficace

Se sei entusiasta dell'idea di avere conoscenze condivise, ma non sai come crearle, prova alcuni di questi suggerimenti:

• Quando conduci i colloqui con i clienti, includi un membro dei team di progettazione e sviluppo in modo che possano ascoltare direttamente il cliente invece di fare affidamento sulle note dell'owner di prodotto. Ciò darà loro anche la possibilità di approfondire quando l'argomento è fresco nella mente del cliente.

• Rendi lo sviluppo e l'utilizzo di clienti tipo un impegno dell'intero team. Ogni membro del team ha prospettive e informazioni approfondite uniche e deve capire in che modo gli utenti tipo influenzano lo sviluppo del prodotto.

• Trasforma anche la valutazione dei ticket e il backlog grooming in uno sport di squadra. Sono ottime opportunità per assicurarsi che tutti siano sulla stessa lunghezza d'onda e capire perché l'owner di prodotto ha stabilito le varie priorità di lavoro.

Vuoi provare? Registrati a Confluence.

Crea un modello di colloquio con i clienti per documentare le informazioni approfondite raccolte su questi ultimi. Segui il nostro tutorial per iniziare a condurre utili colloqui con i clienti:

• Crea pagine approfondite di colloqui con i clienti

• Trasforma le informazioni in approfondimenti con la piramide del colloquio con il cliente

Hai parlato di una serie di user story con l'ingegnere e il progettista. C'è stato uno scambio di messaggi, avete tenuto alcune sessioni di pianificazione e avete concluso che ci sono alcuni altri aspetti da considerare per la funzionalità su cui state lavorando.

Devi rimpolpare alcune supposizioni, riflettere più a fondo su come tutto ciò si adatti al quadro generale e tenere traccia di tutte le domande aperte a cui devi rispondere. E poi?

Cosa dovrebbe includere un PRD?

Quando si scrive un documento sui requisiti, è utile utilizzare un modello coerente a livello di team in modo che tutti possano seguire e fornire il proprio feedback. In Atlassian, utilizziamo Confluence per creare requisiti di prodotto con il modello di documento sui requisiti del prodotto.

Abbiamo scoperto che la sezione seguente fornisce contesto "sufficiente" per comprendere i requisiti di un progetto e il suo impatto sugli utenti:

1. Definire le specifiche del progetto

Ti consigliamo di includere indicazioni di alto livello nella parte superiore della pagina come segue:

• Partecipanti: chi è coinvolto? Includi l'owner di prodotto, il team, gli stakeholder

• Stato: qual è lo stato attuale del programma? Rispondente all'obiettivo, a rischio, ritardato, differito ecc.

• Rilascio di destinazione: quando è previsto il rilascio?

2. Obiettivi del team e obiettivi aziendali

Vai subito al dunque. Informa senza annoiare. Avere il software giusto per fornire i dettagli degli obiettivi in una vista facile da leggere è utile per tutte le persone coinvolte.

Gli obiettivi aziendali devono essere chiari e diretti, ma anche sufficientemente informativi da allineare gli stakeholder. Non dare ad altri l'opportunità di fare supposizioni.

3. Contesto e valore strategico

La sezione con le informazioni sul background spiega la motivazione dietro al prodotto o alla funzionalità e come il prodotto o la funzionalità si allinea con gli obiettivi aziendali di più ampia portata. Fornisce il contesto per spiegare perché il progetto è importante e quali problemi mira a risolvere.

Informazioni dettagliate sull'allineamento strategico garantiscono che tutti comprendano come questo lavoro supporta la vision e le priorità dell'organizzazione. Questa chiarezza aiuta i team a mantenere la concentrazione sulla fornitura di valore che conta.

4. Presupposti

Questa sezione delinea tutte le ipotesi che il team sta facendo riguardo alla tecnologia, alle esigenze aziendali o al comportamento degli utenti. Una chiara definizione delle ipotesi aiuta a identificare i potenziali rischi e le aree che potrebbero richiedere una convalida.

Garantisce inoltre che tutti siano consapevoli dei fattori che influiscono sulle decisioni e sulla pianificazione. Rivedendo queste ipotesi durante l'intero corso del progetto, i team possono adattarsi man mano che emergono nuove informazioni.

5. User story

Elenca o collega le user story interessate. Collega anche colloqui con i clienti e includi gli screenshot di ciò che hai visto. Fornisci dettagli sufficienti per creare una story completa e includi le metriche di successo.

6. Interazione e design con l'utente

Dopo che il team ha arricchito la soluzione per ogni user story, collega le esplorazioni di progettazione e i wireframe alla pagina.

7. Domande

Man mano che il team comprende i problemi da risolvere spesso sorgono delle domande. Crea una tabella di "cose da decidere o su cui svolgere ricerche" per tenere traccia di questi elementi.

8. Cosa non stiamo facendo

Mantieni il team concentrato sul lavoro da svolgere evidenziando in modo chiaro ciò che non sta facendo. Segnala gli elementi che al momento sono esterni all'ambito, ma che potrebbero essere presi in considerazione in un secondo momento.

Vantaggi di un documento sui requisiti del prodotto ben scritto

Come concetto da tenere a mente dalla lettura di questo blog, cerca di comprendere il "perché" e non il "cosa", poiché il "perché" ti aiuterà a esplorare le soluzioni migliori per il tuo team.

Ecco i vantaggi e le sfide che abbiamo riscontrato con l'approccio della dashboard di una pagina:

1. Una pagina, un'unica fonte

Mantieni la semplicità. Il documento sui requisiti del prodotto diventa la "pagina di destinazione" per tutto ciò che riguarda l'insieme di problemi all'interno di un determinato epic.

Avere un punto di riferimento centrale consente ai membri del team di risparmiare tempo per accedere a queste informazioni e offre loro una panoramica sintetica.

2. Agilità extra

Una delle cose fantastiche dell'utilizzo di una semplice pagina per la collaborazione (rispetto a uno strumento di gestione dei requisiti dedicato) è che puoi agire in modo Agile riguardo alla documentazione. Non devi seguire lo stesso formato ogni volta: fai ciò che ti serve, quando ti serve e procedi in modo Agile. Cambia ogni volta che serve.

3. Contesto e dettagli sufficienti

Spesso dimentichiamo quanto possa essere potente un semplice link. Incorporiamo molti link nei nostri documenti sui requisiti del prodotto: aiutano a estrarre la complessità e a divulgare progressivamente le informazioni al lettore secondo necessità.

Il collegamento di risorse dettagliate può includere elementi come:

• Colloqui con i clienti per informazioni di background, convalida o ulteriore contesto relativo alla funzionalità

• Pagine o blog in cui sono state proposte idee simili

• Discussioni o documentazione tecnica e diagrammi già esistenti

• Video delle demo dei prodotti o altri contenuti correlati provenienti da fonti esterne

4. Story live

Una volta che le story sono state abbozzate e inserite come ticket in Jira, effettuiamo il collegamento ad esse nella nostra pagina (e automaticamente viene creato anche un collegamento dai ticket alla pagina).

La sincronizzazione bidirezionale tra Confluence e Jira consente di vedere automaticamente lo stato attuale di ogni ticket direttamente nella pagina dei requisiti.

5. Saggezza collettiva

L'acquisizione dei requisiti di prodotto in Confluence consente ai membri di team diversi di contribuire e fornire suggerimenti. È impressionante vedere quante volte un membro di un altro team è intervenuto nella conversazione con un commento fornendo ottimi feedback, suggerimenti o nozioni apprese da progetti simili.

In questo modo, le organizzazioni di grandi dimensioni possono avere l'impressione di essere un piccolo team.

6. "Extra" coinvolgenti

I diagrammi creati con strumenti come le lavagne Confluence comunicano meglio i problemi al tuo team. Puoi anche incorporare immagini, video e contenuti dinamici esterni.

7. Collaborazione

L'aspetto più importante di tutto questo è riuscire a coinvolgere tutti. Non scrivere mai un documento sui requisiti del prodotto per conto tuo: dovresti sempre collaborare con uno sviluppatore per scriverlo insieme. Condividi la pagina con il team e ricevi il feedback.

Commenta, fai domande, incoraggia gli altri a contribuire con pensieri e idee. Questo è particolarmente importante per i team distribuiti che spesso non hanno la possibilità di discutere dei progetti di persona.

Le sfide dei documenti sui requisiti del prodotto

Ogni approccio ha i suoi aspetti negativi. Di seguito sono riportate due sfide principali che abbiamo affrontato e osservato anche dal punto di vista dei clienti:

1. La documentazione può diventare obsoleta

Cosa succede quando implementi una story, ricevi un feedback e modifichi la soluzione di conseguenza? Qualcuno torna indietro ad aggiornare la pagina dei requisiti con l'implementazione finale?

Questa è una sfida che riguarda qualsiasi tipo di documentazione ed è sempre utile chiedersi se valga la pena fare compromessi di questo tipo. Parla con il tuo team su cosa faresti in uno scenario come questo.

2. Mancanza di partecipazione

"Cosa posso fare per incoraggiare le persone a lasciare un commento?", "Come posso incoraggiare le persone a scrivere più specifiche e story sulla nostra intranet?"

Questa è una bella gatta da pelare e si riduce a varie tecniche di adozione wiki all'interno dell'organizzazione. Ci sono molte risorse che puoi usare in questa situazione. Potrebbero esserci in gioco anche questioni culturali più profonde.

Inizia a lavorare sul tuo PRD con Jira e Confluence

Quando i requisiti sono agili, l'owner di prodotto ha più tempo per capire e stare al passo con il mercato. E mantenere i requisiti esplicativi ma succinti consente al team di sviluppo di utilizzare qualsiasi implementazione si adatti meglio all'architettura e allo stack tecnologico.

Una volta che i requisiti di un progetto sono stati ragionevolmente ben preparati, consigliamo di collegare le user story nella sezione 5 sopra alle story corrispondenti nello strumento di monitoraggio dei ticket del team di sviluppo.

Ciò rende più trasparente il processo di sviluppo, perché permette di vedere facilmente lo stato di ogni elemento di lavoro; questo consente all'owner di prodotto e ai team a valle, come quelli di marketing e di assistenza, di prendere decisioni più informate.

Ricorda: occorre essere Agile nell'evoluzione dei requisiti di un progetto. Non è un problema cambiare le user story man mano che il team crea, rilascia e riceve feedback. Mantieni sempre alta l'asticella della qualità e una sana cultura di progettazione, anche se ciò significa rilasciare meno funzionalità.