Un template PRD in Markdown:copialo e compilalo.

Il template

Copialo in un nuovo file e sostituisci tutto ciò che è tra parentesi angolari. Elimina una sezione solo se sei sicuro che non serva, e scrivi "nessuno" invece di lasciarla vuota, così chi legge capisce che è stata considerata.

# PRD: <Feature name>

Status: Draft | In review | Approved
Owner: <name>
Last updated: <date>

## 1. Problem
Who has the problem, what it is, and what it costs them today.
One short paragraph. No solution here.

## 2. Goals
- <Outcome 1, measurable>
- <Outcome 2, measurable>

## 3. Non-goals
Things this work will NOT do, so nobody builds them by accident.
- <Not in scope 1>
- <Not in scope 2>

## 4. Users and scenarios
- As a <role>, I want <action>, so that <benefit>.
- As a <role>, I want <action>, so that <benefit>.

## 5. Requirements
Number each one so it can be referenced in plans and tests.
- R1. The system must <behavior>.
- R2. The system must <behavior>.
- R3. The system should <optional behavior>.

## 6. Acceptance criteria
- [ ] R1: Given <state>, when <action>, then <result>.
- [ ] R2: Given <state>, when <action>, then <result>.

## 7. Edge cases and errors
- <Empty state>
- <Invalid input>
- <Network or permission failure>

## 8. Data and interfaces
- Data stored or changed: <fields, formats, migrations>
- APIs or screens affected: <names>

## 9. Success metrics
- <Metric>: from <baseline> to <target> by <date>.

## 10. Rollout and rollback
- Release plan: <flag, staged, all at once>
- How to turn it off if it goes wrong: <step>

## 11. Open questions
- [ ] <Question> (owner: <name>)

## 12. Context for the agent
Files to read first: <paths>. Constraints: <stack, style, limits>.

Perché è scritto così

Un PRD per un agente AI ha lo stesso compito di uno per una persona, con meno spazio per le congetture. Una persona ti chiede in corridoio cosa intendevi. Un agente colma il vuoto con la sua ipotesi migliore e va avanti.

• I non-obiettivi sono la protezione più economica contro lo scope creep. Gli agenti aggiungono extra "utili" se non gli dici di non farlo.
• I requisiti numerati (R1, R2) permettono a un piano, a un test e a un commento di revisione di puntare alla stessa cosa.
• I criteri di accettazione come caselle di una lista di attività diventano una lista di cose da fare che si può spuntare. Vedi le liste di attività Markdown per la sintassi.
• I casi limite sono il punto in cui il codice generato fallisce per primo: dati vuoti, input errato, connessione persa.
• Il rollback ti costringe a pensare a come annullare la modifica prima di rilasciarla.

Come compilarlo

1. Scrivi il problema senza la soluzione

   Se non riesci a descrivere il problema senza nominare una funzione, la funzione è un'ipotesi. Di' chi è coinvolto e cosa succede oggi.

2. Rendi misurabile ogni obiettivo

   "Checkout più veloce" è un desiderio. "Checkout mediano sotto i 30 secondi" è un obiettivo.

3. Scrivi i requisiti come comportamento

   "Il sistema deve mostrare un errore quando il file supera i 10 MB" si può testare. "Buona gestione degli errori" no.

4. Abbina un criterio a ogni requisito

   Usa il formato dato, quando, allora (Given, when, then). Se non riesci a scrivere il controllo, il requisito è vago.

5. Chiudi con le domande aperte

   Indica il responsabile di ciascuna. Un agente deve fargliele, non deciderle.

I diagrammi aiutano per flussi e stati; un blocco Mermaid nel file è facile da modificare. Vedi la sintassi dei diagrammi di flusso Mermaid.

Passare il PRD a un agente AI

Indica all'agente il file invece di incollarlo: "Leggi docs/prd/export.md e proponi un piano; non scrivere ancora codice." Chiedi prima un piano, verificalo con i requisiti numerati, poi lascia che costruisca. Un PRD, un piano e una lista di attività sono di solito tre file separati. Il PRD dice cosa e perché, il piano dice come, e le attività sono i passaggi.

Tieni le regole valide per tutto il progetto (comandi, stile, cartelle) fuori dal PRD e in CLAUDE.md o AGENTS.md, così il PRD contiene solo ciò che è specifico di questa funzione.

Errori comuni

• Una soluzione travestita da problema. "Ci serve un menu a tendina" non è un problema.
• Nessun non-obiettivo. Tutto ciò che sta intorno entra nell'ambito.
• Requisiti che non possono fallire. Se nessun test potrebbe mai farlo fallire, non dice nulla.
• Un PRD che nessuno rilegge. Aggiorna lo stato e le domande aperte man mano.
• Dieci pagine per una piccola modifica. Una funzione da un giorno di lavoro richiede mezza pagina.

I product manager possono leggere e rivedere i PRD in DotMD come documenti renderizzati, con commenti sul passaggio esatto. La lettura è gratuita; vedi i prezzi per modifica e revisioni.

Domande sui template PRD in Markdown

Altre domande