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.

La creazione di un prodotto di successo richiede una grande quantità di ricerche e una pianificazione completa. Ma da dove iniziare? I product manager spesso iniziano dal 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:

Ti consigliamo di includere le istruzioni 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?

Vai subito al dunque. Informa senza annoiare.

Perché abbiamo deciso di procedere in questo modo? In che modo si inserisce negli obiettivi generali dell'azienda?

Elenca le eventuali supposizioni di natura tecnica o aziendale o relative agli utenti che stai facendo.

Elenca le user story associate o inserisci un link verso di esse. Inserisci anche link ai colloqui con i clienti e includi screenshot di ciò che hai visto. Fornisci dettagli sufficienti per creare una story completa e includi le metriche di successo.

Dopo che il team ha sviluppato la soluzione adatta a ogni user story, collega le idee di design e i wireframe alla pagina.

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.

Mantieni il team concentrato sul lavoro da svolgere evidenziando in modo chiaro ciò su cui non state lavorando. 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:

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 di disporre di una panoramica sintetica.

Uno degli aspetti più positivi dell'uso di una semplice pagina per collaborare (rispetto a uno strumento di gestione dei requisiti dedicato) è che puoi gestire agilmente la documentazione. Non devi seguire lo stesso formato ogni volta: fai ciò che ti serve quando ti serve, sii agile. Taglia e cambia in base alla necessità.

Spesso dimentichiamo quanto possa essere potente un semplice link. Incorporiamo molti link nei nostri documenti sui requisiti del prodotto: aiutano a ridurre la complessità e a comunicare progressivamente le informazioni al lettore secondo le sue 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

Vedo che anche molti clienti lo fanno. Una volta che le story sono state abbozzate e inserite come ticket in Jira, possiamo inserire un link verso di esse nella pagina (il 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.

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 occasioni in cui un membro di un altro team è intervenuto nella conversazione con un commento condividendo feedback illuminanti, suggerimenti o insegnamenti tratti da progetti simili. In questo modo, le organizzazioni di grandi dimensioni possono avere l'impressione di essere un solo team.

I diagrammi realizzati con strumenti come Visio, Gliffy o Balsamiq comunicano meglio i problemi al team. È anche possibile incorporare immagini esterne, video e contenuti dinamici.

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:

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? Questo è un problema che riguarda qualsiasi tipo di documentazione ed è sempre utile chiedersi se valga la pena fare compromessi di questo tipo. Discuti con il team di quello che faresti in uno scenario come questo.

"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?" Questo è un problema serio, e la sua soluzione si traduce nell'adozione di varie tecniche 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.