Requisiti di prodotto: come scrivere un PRD dalle interviste
Trasforma le interviste in un documento dei requisiti: problema, scenari, vincoli, perimetro della versione e criteri di verifica. Con modello ed esempio.
Chiedere un pulsante lascia aperto il problema
Un cliente dice «Aggiungete un pulsante di esportazione». Non chiarisce chi usa il file, cosa deve contenere o cosa succede dopo. Il documento dei requisiti di prodotto, o PRD, allinea il team sulla richiesta e sui confini del risultato.
Qui si parla di un breve documento per una funzionalità. Architettura, contratti e requisiti tecnici aziendali conservano il proprio ruolo. Il PRD rende verificabile il problema prima di scegliere l’implementazione.
Dalla richiesta dell’utente ai requisiti
Torna all’ultimo caso reale
Chiedi quando è servita l’esportazione, cosa ha fatto la persona al suo posto, quali dati ha trasferito e dove ha avuto difficoltà. Segna esempio e conseguenze nella trascrizione. «È scomodo» va spiegato prima di verificare un miglioramento.
Descrivi lo scenario prima di scegliere l’interfaccia
Registra chi avvia l’azione, con quali dati e quale risultato attende. Pulsante, email e report automatico sono opzioni. Esamina necessità e vincoli prima di trasformare il primo suggerimento in requisito.
Definisci il perimetro della versione
Indica cosa rientra nell’attività e cosa resta deliberatamente fuori. Elenca a parte accessi, campi e casi senza risultati. Concorda come misurare velocità o volume prima di imporre requisiti.
Formula la verifica
Descrivi per ogni requisito un risultato osservabile e dati di esempio. Collega la prova al problema. Se un punto non è confermato, registralo come domanda aperta con il responsabile e la data entro cui decidere.
Esportare un elenco di richieste chiuse
L’esempio è fittizio. Nomi, condizioni e risultati servono a spiegare il metodo.
Ogni venerdì copio a mano le richieste chiuse in un foglio. Al responsabile servono oggetto, data di chiusura e assegnatario. La conversazione non serve.
Occorre condividere dati specifici di un periodo. L’intervista non richiede l’intero archivio, gli allegati o tutto il testo delle conversazioni.
Esempio di criterio: scelto un periodo, l’export contiene le richieste chiuse in quel periodo e solo i campi concordati. Chiarisci a parte come trattare le date ai confini.
| Elemento del PRD | Esempio compilato | Stato |
|---|---|---|
| Utente | Responsabile dell’assistenza | Confermato nell’intervista |
| Campi | Oggetto, data di chiusura, assegnatario | Verificare con il destinatario |
| Fuori dal perimetro della versione | Conversazioni e allegati | Da concordare |
| Domanda aperta | Quale fuso orario definisce i limiti del periodo? | Serve una risposta |
Modello PRD per una funzionalità
Collega ogni requisito a un’osservazione. Una fonte può sostenere più punti. L’accordo va comunque confermato.
Nome e versione della funzionalità: Problema dell’utente: Caso concreto dell’intervista: Utente e contesto: Scenario principale: Risultato atteso: Dati e vincoli: Dentro e fuori dal perimetro: Criteri di verifica: Ipotesi e domande aperte: Fonti e riferimenti temporali: Chi ha approvato e quando:
Si possono verificare i requisiti senza l’autore?
- Ogni requisito spiega quale problema risolve.
- Il risultato verificabile è distinto dall’implementazione.
- Il perimetro della versione è esplicito.
- Le domande aperte sono indicate.
Entriamo nei dettagli
Si può scrivere un PRD solo dai desideri del committente?
Una bozza è possibile. Verifica scenari e vincoli reali. Un desiderio descrive una soluzione possibile e può lasciare implicito il problema dell’utente futuro.
Quanto deve essere lungo il documento?
Deve chiarire scenario, perimetro, vincoli e verifica. Per una piccola funzionalità, un testo breve con esempi è spesso più pratico di una descrizione lunga degli obiettivi generali.