Come creare un documento sui requisiti del prodotto (PRD)

Riepilogo: il documento sui requisiti del prodotto (PRD) definisce i requisiti di un particolare prodotto, inclusi lo scopo, le funzioni, la funzionalità e il comportamento del prodotto. Serve come guida per i team aziendali e tecnici per aiutarli a creare, lanciare o commercializzare il prodotto.

Building a great product requires tons of research and comprehensive planning. But where do you start? Product managers often start with a product requirements document (PRD).

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

Successivamente, condividi il PRD con gli stakeholder, chiedendo loro anche di dare un contributo, e con i team aziendali e tecnici che ti aiuteranno a creare, lanciare o commercializzare il prodotto.

Una volta che tutti gli stakeholder sono allineati, il PRD funge da bussola, fornendo una chiara direzione verso lo scopo di un prodotto e creando una base di conoscenze condivise tra i team aziendali e tecnici.

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). I requisiti Agile, invece, dipendono da una conoscenza del cliente che è condivisa tra l'owner di prodotto, il designer e il team di sviluppo. La conoscenza condivisa e l'empatia nei confronti del cliente target dà vita a larghezze di banda nascoste per gli owner di prodotto, 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.
• Rendi anche la valutazione dei ticket e il backlog grooming uno sport di squadra. Queste sono ottime opportunità per assicurarsi che tutti siano sulla stessa lunghezza d'onda e capire perché l'owner di prodotto ha stabilito una certa priorità per le attività da svolgere.

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
Consigliamo di includere indicazioni generali 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 strategico
Perché 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. Storie utente
Elenca o crea collegamenti alle storie utente 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 con l'utente e progettazione
Dopo che il team ha arricchito la soluzione per ogni storia utente, collega le esplorazioni di progettazione e i wireframe alla pagina.

7. Domande
Via via che comprende i problemi da risolvere, spesso il team ha 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 gli elementi esclusi dal lavoro. 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, una sola fonte
Non complicare le cose. 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 godere di agilità riguardo alla documentazione. Non devi seguire lo stesso formato ogni volta: fai ciò che ti serve, quando ti serve e muoviti con agilità. Taglia e cambia in base alla necessità.

3. La quantità giusta di contesto e dettagli
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 dinamiche
Vedo che anche molti clienti le usano. Una volta che le story sono state abbozzate e inserite come ticket in Jira, ci colleghiamo ad esse nella nostra pagina (che, opportunamente, crea anche un collegamento dai ticket alla pagina). La sincronizzazione bidirezionale tra Confluence e Jira ci consente di vedere automaticamente lo stato attuale di ogni ticket direttamente dalla 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. Sono rimasto stupito dal numero di volte in cui 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 solo team.

6. Utilizzare degli "extra"
I diagrammi realizzati con strumenti come Visio, Gliffy o Balsamiq comunicano meglio i problemi al team. Puoi anche incorporare immagini esterne, video e contenuti dinamici.

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 si implementa una story, si riceve un feedback e si modifica la soluzione di conseguenza? Qualcuno torna indietro e aggiorna 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 rete 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 storie utente 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: è facile vedere lo stato di ogni elemento di lavoro, il che 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 agili nell'evoluzione dei requisiti di un progetto. Non è un problema cambiare le storie utente man mano che il team crea, rilascia e riceve feedback. Mantieni sempre alta la barra della qualità e una sana cultura di progettazione , anche se ciò significa rilasciare meno funzioni.