PRD è l’acronimo di Product Requirement Document: è il documento in divenire che rappresenta lo status e gli obiettivi del prodotto. Un buon esempio di PRD deve fornire risposte chiare sugli aspetti chiave dello sviluppo del prodotto, nonché spiegare perché stiamo investendo risorse in questa iniziativa.
Tipicamente, un PRD include:
- Status e informazioni sul documento in sè
- Obiettivo del prodotto e contesto: quali sono gli user problem che vengono risolti e qual è il target del prodotto.
- Funzionalità e soluzione high-level: quali sono le feature essenziali del prodotto e in che modo rispondono ai problemi precedentemente delineati. Qual è la priorità relativa delle funzionalità.
- Definizione di done: quali criteri devono essere soddisfatti affinché il prodotto possa essere rilasciato. Ad esempio, quali sono le funzionalità essenziali, quali test di usabilità devono essere superati, quale livello di performance deve essere garantito.
- Rischi e limitazioni: ad esempio finestre temporali, limiti nelle risorse a disposizione, dipendenze critiche.
- Fasi di implementazione e rilascio: definizione dei milestone principali del progetto.
- Registro (log) delle decisioni: documentazione delle decisioni più importanti inerenti il prodotto e prese nel corso delle varie revisioni.
Quando occorre un PRD e quando se ne può fare a meno
I PRD sono una buona pratica per iniziative che richiedono molto allineamento tra varie parti. Sono inoltre utili per progetti che si protraggono per un arco temporale particolarmente lungo: dunque, dove è particolarmente utile tenere traccia dei cambiamenti.
Per iniziative più modeste, il PRD può essere sostituito da altra documentazione – ad esempio un’epic esaustiva dal punto di vista dei requisiti e che contenga rimandi ad altra documentazione per aspetti quali customer problem, rischi o fasi di rilascio.
Spesso preferisco utilizzare un documento più snello che contenga informazioni sul contesto, il customer problem, l’impatto e la soluzione. Ciò detto, saper organizzare un PRD può tornare utile nella pratica; la struttura può inoltre essere adattata in preparazione di altra documentazione, più adatta all’effettiva dimensione del progetto.
Un esempio di PRD
A titolo esemplificativo immaginerò di essere il PM responsabile per un software che permette agli utenti di arricchire le pagine prodotto dei loro e-commerce. L’esempio è del tutto fittizzio e l’utilità o meno del prodotto in questione non è, naturalmente, tema di questa guida.
Il software immaginario da cui parto consente di avere due macro-livelli di utenti: amministratori e gestori dei contenuti. Gli amministratori possono assegnare a ciascun creatore sia le aree delle pagine prodotto sia le categorie di prodotto da loro modificabili. Tuttavia, questa gestione avviene esclusivamente da terminale o tramite la modifica diretta di file di configurazione. Il PRD che introdurrò descrive un’iniziativa volta a creare un pannello di amministrazione all’interno del software.
Status e informazioni sul documento
Inizialmente voglio fornire al lettore le informazioni base sul documento in sè e dare contesto alla lettura. Partendo dagli essenziali:
Ovviamente, il titolo del documento deve essere inequivocabile. Nel pannello ho aggiunto informazioni utili a chiunque debba consultare il PRD. Innanzitutto, la data dell’ultima modifica e l’attuale stato: quest’ultimo ci dice se il processo di revisione è ancora in corso, se il documento è approvato, è una bozza, è stato sostituito (superseded) da uno più attuale, eccetera.
Elencare autore, collaboratori e revisori serve a sapere chi sono le persone a cui fare riferimento per qualsiasi necessità collegata all’iniziativa. In generale, anche in piccole realtà, è buon uso tenere traccia di chi ha lavorato a un determinato progetto – soprattutto per riferimenti futuri.
Infine, i documenti rilevanti possono aggiungere ulteriore contesto alla lettura. In questo caso, ho collegato una press release dove precedentemente si era descritto il prodotto dal punto di vista del cliente (scriveremo in futuro di questa pratica), oltre a un’ulteriore PRD che descrive un’iniziativa collegata (potrebbe, ad esempio, trattarsi di un’iniziativa che ha delle dipendenze tecniche o funzionali rispetto a quella qui descritta).
Ho visto documentazione in cui, per arrivare subito al dunque, il glossario è tralasciato o nascosto tra gli allegati. Trovo invece utile disambiguare da subito i termini necessari. Il glossario non serve tanto a chiarire vocaboli che il lettore non conosce, quanto a spcificare l’uso che faremo dei vocaboli all’interno del documento. Nel nostro esempio, è essenziale capire inequivocabilmente cosa si intende con l’uso dei termini clienti, creatori e amministratori – e chiarirlo prima che vengano utilizzati.
Presentazione dell’iniziativa: contesto e obiettivi
In un paragrafo, spiegare sinteticamente qual è il problema o l’opportunità che l’iniziativa circoscrive, e perché è importante. Come da esempio, una volta delineato in breve il problema e descritte le conseguenze, è sufficiente rimandare a materiali di approfondimento che mostrino da dove derivano gli insight. Potrebbe anche essere necessario aggiungere, eventualmente come paragrafo a sé stante, una descrizione dell’audience del prodotto.
Chiarito l’obiettivo dell’iniziativa, passo a quantificare l’opportunità.
Innanzitutto ho descritto in due punti quello che considero la “definizione di successo”: invece di descriverlo qualitativamente, indico due chiari KPI e l’impatto quantitativo che mi aspetto per entrambi. Anche in questo caso, mi limito a rimandare ai materiali che mostrano da dove derivino le stime.
I KPI indicati riflettono, almeno in parte, l’auspicabile miglioramento nell’esperienza dell’utente. Nel paragrafo di chiusura, invece, rendo esplicito qual è l’impatto per il business: in questo caso, liberare delle risorse che possono essere destinate a compiti a maggior valore aggiunto.
Soluzione e requisiti
Definito il problema, si può passare a descrivere la soluzione. Trovo sia un buon uso iniziare da una descrizione di alto livello e – se vi è pericolo di confusione – esplicitare quali aspetti non sono invece parte dell’iniziativa in corso.
Si può elaborare ulteriormente sull’out of scope negli allegati, se necessario. L’importante è che eventuali ambiguità vengano risolte. Per quanto riguarda la descrizione delle interazioni degli utenti, i design, le architetture di sistema, possono essere inserite insieme alla soluzione, in un paragrafo dedicato o in allegato. Per facilitare la leggibilità, solitamente preferisco includerle con la soluzione solo se essenziali per disambiguare qualche aspetto fondamentale.
Passo dunque alle funzionalità.
La struttura suggerita nell’esempio non è l’unica, ma contiene le informazioni essenziali:
- Un collegamento al ticket o altra fonte che gli sviluppatori possano usare per tracciare il progredire dell’implementazione, e per ricevere le specifiche dettagliate.
- Un titolo e una descrizione, possibilmente in forma di user story.
- Una priorità: il livello di granularità può essere diverso, tuttavia ritengo importante che siano evidenziate le funzionalità fondamentali per il rilascio del prodotto. Assegnare correttamente le priorità serve anche a prendere decisioni importanti qualora il tempo si rivelasse insufficiente per poter implementare tutte le funzioni.
Esplicitare le incertezze: supposizioni, rischi e dipendenze
I rischi legati allo sviluppo di un prodotto possono essere di vari tipi (in inglese): possono essere rischi per il business (ad esempio, il primo elemento nell’elenco qui sotto), possono essere di usabilità (secondo elemento), o di fattibilità (terzo elemento). Ogni rischio va stimato nel potenziale impatto; inoltre, per ciascuno si dovrebbe documentare quel che è pianificato in termini di mitigazione.
Un quarto tipo di rischio di cui parla Marty Cagan è il value risk, ossia se i clienti compreranno il prodotto o decideranno di utilizzarlo: fermo restando che i prodotti possono non andare come si desidera, questo tipo di rischi non dovrebbero apparire in un PRD. Se avete buone ragioni per pensare che vi sia un value risk, è allora il caso di tornare alla fase di discovery e rivalutare l’opportunità.
Inoltre, è lecito che vi siano degli aspetti che non è stato possibile validare con le informazioni o le risorse a disposizione. Non è ottimale, ma è la realtà. Una buona strategia per evitare che tali supposizioni creino danni “incontrollati” è renderle esplicite, così da poterle monitorare.
Piano di rilascio
In una PRD, il piano di rilascio non deve necessariamente essere dettagliato:
Le finestre temporali possono essere vaghe (se il prodotto lo consente) e servono per lo più a fornire un orientamento per gestire risorse o dipendenze.
Il piano può essere utile a chi dovrà portare il prodotto sul mercato (marketing e vendite), ma ha anche un valore a sé stante per lo sviluppo del prodotto: ad esempio, le varie iterazioni offrono spazio per iterare sulle funzionalità già implementate in base ai riscontri degli utenti.
Documentare le decisioni
Non è una prassi né tanto meno un obbligo, ma un log delle decisioni ha una sua importanza pratica e strategica.
Da un punto di vista pratico, può far risparmiare tempo, evitando di ridiscutere temi già stati affrontati in passato. Può inoltre aiutare a ricostruire la catena di decisioni in quelle tante situazioni in cui, all’improvviso, non si è più sicuri del perché una certa funzionalità sia stata lasciata in disparte, o il piano di rilascio sia stato cambiato.
L’importanza strategica ha a che fare con la gestione degli stakeholder. A tutti è capitato di avere a che fare con colleghi il cui ego è tale da voler dar voce ad ogni costo alle critiche, ragionate o meno che siano: il dover documentare ogni decisione e richiesta, così come il dover mettere un nome dietro a tali decisioni, rende le persone più accountable (responsabili) e aiuta nel gestire gli stakeholder più difficili.
Allegati (con moderazione)
Di regola, per decidere se qualcosa vada in allegato o nella parte principale del documento mi chiedo: è possibile, per chi legge, prendere delle decisioni sulla scorta dei materiali forniti fino a questo punto?
Se la risposta è no, le informazioni o risorse mancanti vanno nel corpo del documento. Altrimenti diventano allegati.
Esempi tipici di allegati sono user flow, architettura di sistema, mockup e design, wireframe e interazioni degli utenti.
Buone pratiche e buon senso
Come ogni tipo di documentazione, il PRD deve svolgere una funzione chiara e deve essere predisposto in tale ottica: ad esempio, sarebbe controproducente documentare in 20 pagine un piccolo cambiamento a una funzione secondaria del nostro prodotto. Ciò detto, il tempo speso a creare un buon PRD (e il tempo speso a rifinirlo nei vari processi di revisione) è da considerarsi un investimento che permetterà di risparmiare tempo in (dis)allineamento nel futuro.
Non esiste la “formula magica del PRD” e quello proposto nell’esempio non è che una possibile forma. Ad esempio, molti PRD includono l’audience a cui è destinato il prodotto per mezzo di user persona, così da chiarire il collegamento tra i bisogni dell’utente e la soluzione. Per prodotti complessi con una base utente ampia e varia, potrebbe essere più importante rispetto ad altri paragrafi.
Può anche essere utile separare le funzionalità dai requisiti non funzionali: questi ultimi sono le parti del sistema che non sono collegate in maniera diretta alle sue funzionalità, dunque a ciò che l’utente esperisce. Ad esempio il modo in cui vengono immagazzinati i dati, i tempi di risposta richiesti, la sicurezza nella trasmissione dei dati, la conformità legale, eccetera.
Il nostro esempio non voleva essere esauriente, quanto chiaro. Se l’hai trovato utile, qui puoi scaricare un template da adattare alle tue necessità.
