Come creare un documento sui requisiti del prodotto (PRD)

La creazione di un ottimo prodotto richiede molte ricerche e una pianificazione completa. Ma da dove puoi iniziare? Spesso i product manager iniziano con un PRD.

A product requirements document defines the product you are about to build: It outlines the product's purpose, its features, functionalities, and behavior.

Next, you share the PRD with (and seek input from) stakeholders - business and technical teams who will help build, launch or market your product.

Once all stakeholders are aligned, the PRD serves as a compass, providing clear direction toward a product's purpose while creating a shared understanding among business and technical teams.

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. Ecco alcune cose da tenere a mente:

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).

Anche i requisiti Agile dipendono da una conoscenza del cliente che è condivisa tra owner di prodotto, designer e team di sviluppo. La conoscenza condivisa e l'empatia nei confronti dei clienti di destinazione permettono agli owner di prodotto di trovare risorse che non sapevano di avere.

che possono concentrarsi sui requisiti di livello superiore e lasciare i dettagli dell'implementazione al team di sviluppo, che è perfettamente attrezzato per occuparsene grazie, anche in questo caso, a questa base di conoscenze condivise. (Boom).

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 o accedi 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 dei colloqui con i clienti

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

Ok: hai parlato di una serie di storie utente con l'ingegnere e il designer. C'è stato uno scambio di messaggi, avete tenuto alcune sessioni di pianificazione e concluso che ci sono alcune altre dimensioni da considerare per la funzione 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?

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 Arriva subito al punto. Informa senza annoiare.

3. Background e valore strategicoPerché lo stiamo facendo? In che modo si inserisce negli obiettivi generali dell'azienda?

4. Presupposti

Elenca i possibili presupposti tecnici, aziendali o degli utenti.

5. User story

Elenco o link alle user story coinvolte. Collega anche i 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.

Ecco un documento completo sui requisiti del prodotto che abbiamo creato utilizzando Confluence. Ricorda che nessun requisito del prodotto è mai uguale all'altro. Usa questo esempio per capire i diversi elementi che dovrebbero essere inclusi nel PRD, ma tieni sempre presente che non si tratta dell'unica soluzione possibile.

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" interessanti

I diagrammi realizzati con strumenti come Visio, Gliffy o Balsamiq comunicano meglio i problemi al 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 da solo: 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.

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.

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 il processo di sviluppo più trasparente, perché è facile vedere lo stato di ogni elemento di lavoro; questo consente all'owner di prodotto e ai team a valle, come quello 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 funzioni.