Cos'è un documento sui requisiti del prodotto?

Immagina di essere uno chef di un ristorante di alto livello. Una sera arriva un cliente molto importante (diciamo Meryl Streep) e chiede della pasta, ma non dà altri dettagli. Tu vai nel panico. Il sudore comincia ad accumularsi sotto la tua toque blanche. Se deludete Meryl Streep, sarete senza lavoro. Ma nessuno ti dirà che tipo di pasta vuole.

Questo scenario immaginario illustra perché un documento sui requisiti di prodotto è così importante: è scritto dal product manager e dettaglia ciò che deve essere costruito, per chi è, e come beneficia l’utente finale. È la differenza tra l’essere detto di cucinare la pasta e l’essere detto di fare gli spaghetti alla bolognese.

Scopri quali altri benefici puoi trarre dalla creazione di un documento dei requisiti di prodotto e scopri come iniziare.

Cos’è un PRD?

Un documento dei requisiti di prodotto definisce completamente lo scopo di un prodotto o di una funzionalità e spiega cosa il prodotto dovrebbe includere. Senza questo importantissimo documento, il tuo team è quasi certo di fallire perché non ha idea di cosa sarà considerato una build di successo.

Un PRD mantiene tutti sulla stessa pagina: Nessuno dovrebbe avere domande su cos’è il prodotto o su cosa dovrebbe ottenere dopo aver letto il PRD. Stabilisce obiettivi e linee guida molto chiare per un prodotto e mostra come le caratteristiche di un prodotto soddisfano i bisogni dell’utente.

Cosa non è un PRD?

Non c’è nessuna vergogna nel confondere un PRD con un BRD – ci sono troppi acronimi nel mondo. Ma un PRD è sicuramente diverso da altri documenti con cui potresti avere più familiarità.

Documento sui requisiti di business (BRD)

Un documento sui requisiti di business posiziona il prodotto nel contesto della vostra organizzazione nel suo complesso. Descrive ciò che un nuovo prodotto dovrebbe fare e dettaglia i bisogni e le aspettative dell’utente, la ragione per cui questa soluzione è necessaria, e qualsiasi vincolo che potrebbe influenzare un deployment di successo. Non entra nelle specifiche del prodotto o di come dovrebbe apparire o agire.

Documento sui requisiti del software (SRD)

Un documento sui requisiti del software entra nei dettagli del software che alimenta il vostro prodotto. Include dettagli su interfacce, requisiti di sicurezza, capacità funzionali, livelli di performance e informazioni correlate. Questi documenti sono destinati a sviluppatori, tester, ingegneri e clienti.

Perché avete bisogno di un documento sui requisiti del prodotto

Il PRD è la visione del prodotto. Senza una visione, cosa c’è da lavorare?

I documenti dei requisiti di prodotto mostrano anche come gli obiettivi del prodotto saranno raggiunti con diversi aspetti del prodotto. Questo documento sarà usato da vari team nella vostra azienda per aiutare a descrivere il prodotto agli stakeholder, aiuterà il vostro team di vendita ad essere in grado di presentare il prodotto in modo convincente in modo da poterlo vendere e diventare ricco, e i vostri designer sapranno come dovrebbe apparire e agire. È essenzialmente un progetto per il vostro prodotto.

Allora avete bisogno di un PRD? Assolutamente sì. Proprio come un produttore di automobili ha bisogno di un progetto per un’auto prima di iniziare a costruirla.

Cosa dovrebbe essere incluso nel tuo PRD

Perché questo documento toccherà i team di progettazione, supporto, vendite, marketing e ingegneria, ci sono alcuni elementi che sono standard da includere.

Obiettivo chiave

L’obiettivo chiave dovrebbe spiegare per chi state costruendo il prodotto, quali sono i punti critici del cliente che sperate di risolvere e come questo prodotto si inserisce nei vostri obiettivi e nella vostra visione come azienda. Questa sezione potrebbe anche includere potenziali casi d’uso.

Prima di iniziare a creare il vostro documento PRD, è importante che raccogliate la voce del cliente. Immaginate di iniziare a costruire un prodotto senza fare alcuna ricerca sui clienti e di scoprire che i vostri clienti volevano che non assomigliasse affatto a un’app per social media. Vi state organizzando per costruire un prodotto che riempia un bisogno, quindi avete bisogno di sapere quali sono questi bisogni. Una volta che avete capito cosa vogliono i vostri clienti, potete spiegare come il vostro obiettivo chiave per il prodotto soddisfa questi desideri.

Data di rilascio desiderata

Probabilmente avrete più date di rilascio per vari componenti o iterazioni del prodotto, specialmente se state usando la metodologia agile. Nel tuo PRD, dettaglierai le scadenze per i componenti chiave del progetto. Una volta che questo è definito, i project manager possono iniziare a costruire scope e timeline e poi metterli in sprint.

Caratteristiche del prodotto

Definire le caratteristiche del prodotto in modo che la gente sappia cosa costruire. Riferendosi ai vostri obiettivi chiave, questa sezione dovrebbe dettagliare lo scopo di ogni caratteristica e quale problema spera di risolvere.

Per esempio, diciamo che state facendo un’applicazione marketplace per la vendita e l’acquisto di vestiti – volete incorporare tutto il divertimento dei social media con l’eccitazione di ottenere bei vestiti a meno. Nel vostro PRD, avrete quindi la descrizione di come sarà il vostro home feed e mostrerete come soddisfa il requisito di sentirsi come il coinvolgimento dei social media. Potresti anche avere una descrizione del post di un articolo con il prezzo originale contrapposto al prezzo “in vendita” e dimostrare che soddisfa il requisito di segnare vestiti cool per meno soldi. In questo modo, ogni caratteristica ha uno scopo calcolato.

Dovreste anche essere in grado di dettagliare come l’utente interagirà con l’app: Avrà uno scroll infinito, ci sarà una funzione fotocamera incorporata, e ci sarà un modo per bloccare facilmente gli utenti problematici? Tutto questo dovrebbe essere definito nel vostro PRD.

Il vostro documento sui requisiti di prodotto dovrebbe anche includere criteri di rilascio, obiettivi che dovete raggiungere prima di rilasciare il prodotto. Creare criteri di rilascio intorno a:

Funzionalità minima
Usabilità, misurata attraverso i test degli utenti
Affidabilità
Performance e velocità
Supporto

Considera strumenti come l’albero critico della qualità per collegare le esigenze dei clienti con i requisiti del prodotto.

Per saperne di più

Flusso dell’utente e design

Il design è, ovviamente, visivo. È qui che vorrete incorporare wireframe di pagine e mockup di design per aiutare gli altri a vedere ciò che state immaginando per il look and feel del sito.

annotato wireframe della pagina di login o di iscrizione — Annotated Login or Sign-up Page Wireframe (Clicca sull’immagine per modificarla online)

esempio wireflow app bancaria — Bank App Wireflow Esempio (Clicca sull’immagine per modificarla online)

Metriche di performance

Se non hai stabilito come saranno determinate le performance del tuo prodotto, non c’è modo di sapere se è un successo o un fallimento. Il tuo prodotto dovrebbe avere un feature tracker in atto che determina quali caratteristiche del tuo prodotto sono usate più spesso per aiutare a valutare quali componenti del tuo prodotto hanno più successo. Questo tipo di monitoraggio ti aiuta a migliorare il tuo prodotto in futuro. Gli indicatori di performance potrebbero includere la frequenza con cui ogni caratteristica viene utilizzata, quanto tempo i vostri utenti passano ad interagire con le caratteristiche, come gli utenti navigano nei flussi di lavoro, ecc.

Quantificare il successo di ogni caratteristica. Per esempio, potreste dire “Crediamo che la nostra integrazione Apple Pay sarà usata dal 40% degli utenti”. Da quel punto in poi, avete un modo numerico per determinare se avevate ragione o meno e se la funzione è stata un successo.

Utilizza un’ipotesi per ciascuna delle tue caratteristiche, compresa un’ipotesi quantificabile che può essere rivista dopo il lancio per determinare il successo o il margine di miglioramento. Potreste scoprire che alcune funzioni possono essere abbandonate del tutto.

Lavoro futuro previsto

Le analisi di cui sopra possono aiutare a determinare i miglioramenti futuri. Ma potreste anche avere idee su come volete che il prodotto si evolva nel tempo. Questo lavoro futuro dovrebbe avere ancora in mente i bisogni dei clienti. In questa sezione, è importante mantenere le vostre idee ad alto livello – potete diventare più granulari in futuro.

Fortunatamente, ci sono modelli di documenti sui requisiti di prodotto che tolgono le congetture dal processo. Crea un modello dalle informazioni che ti abbiamo fornito e personalizzalo in base alle esigenze della tua azienda.

Lucidchart è ottimo per creare wireframe, mockup, strutture di scomposizione del lavoro, timeline e altre immagini che ti aiutano a spiegare i requisiti del prodotto. E possono essere facilmente aggiunti al tuo PRD usando le nostre integrazioni con G Suite, Microsoft Office, Atlassian e altre piattaforme. Iscriviti oggi stesso per un account gratuito.

Vedi perché Lucidchart è uno spazio di lavoro ideale per creare wireframes e spiegare i requisiti di prodotto.