Cogli le lacune del tuo PRD prima dei revisori
6 min di lettura
La maggior parte dei PRD parte dopo una sola rilettura da parte di chi li ha scritti. Questo coglie i refusi, ma raramente la lacuna che fa porre la stessa domanda di chiarimento nei commenti di ogni documento che invii, perché conosci già la risposta e leggi oltre dove manca. Un PM che ha portato il contesto di una funzionalità in testa per due settimane legge un PRD su di essa in modo completamente diverso da un ingegnere che apre il documento a freddo per la prima volta.
Attenzione
Una rilettura dell'autore controlla se il documento ha senso per chi conosce già la funzionalità. Non controlla se ha senso per chi non la conosce, che è il revisore vero.
Il PRD che sopravvive alla tua stessa rilettura è quello che sei meno qualificato a giudicare.
Perché la stessa domanda continua a comparire in revisione
Hai scritto il documento con tutto il contesto già in testa, quindi una lacuna nei requisiti non ti sembra una lacuna, ti sembra ovvia. Il revisore non ha quel contesto, quindi lo stesso tipo di domanda, un caso limite non gestito, un presupposto non dichiarato, riemerge documento dopo documento. Se tre dei tuoi ultimi cinque PRD hanno ricevuto lo stesso commento che chiede come la funzionalità debba comportarsi per un tipo specifico di utente, non è sfortuna, è uno schema nel modo in cui scrivi l'ambito.
Prendi un PRD per una funzionalità di esportazione in blocco che specifica esattamente cosa accade per un utente standard che esporta fino a 10.000 righe. Non dice cosa accade a 100.000 righe, né per un utente con un piano gratuito con limiti di esportazione, perché l'autore pensava al caso comune per tutto il tempo in cui scriveva. Un ingegnere che riprende il documento non ha modo di dedurre quelle risposte, e il thread di commenti risultante, “cosa succede oltre il limite di righe?”, è la stessa domanda che sarebbe emersa anche negli ultimi tre PRD, se qualcuno avesse pensato di controllare.
Prima: scrivere il PRD, leggerlo una volta, decidere che è chiaro, inviarlo in revisione.
Dopo: consegnarlo a Claude con il vero contesto della funzionalità, chiedere specificamente se l'ambito sia chiaro e quali casi limite manchino, e correggere ciò che trova prima che un revisore debba chiedere.
Un procedimento per testare un PRD prima della revisione
- 1
Dai a Claude la bozza vera e il contesto reale
Incolla la dichiarazione del problema e i requisiti come scritti, non un riassunto, insieme a chi sia il destinatario di questa funzionalità. Un PRD per uno strumento amministrativo interno richiede una copertura dei casi limite diversa da quella di una funzionalità rivolta al pubblico, e lo stesso caso limite mancante conta più o meno a seconda di chi è interessato.
- 2
Chiedi specificamente se l'ambito è chiaro
Un vago “ha senso?” riceve una risposta vaga. Chiedi direttamente se qualcuno senza alcun contesto precedente potrebbe dire cosa è nell'ambito e cosa no dal solo documento, che è il vero test che affronterà un ingegnere che riprende il documento a freddo.
- 3
Chiedi i casi limite mancanti, non una critica generale
Chiedi i casi limite specifici che i requisiti non affrontano, non un feedback aperto. Un caso limite mancante è concreto e correggibile; “questo potrebbe essere più chiaro” no.
- 4
Correggi le lacune prima che qualcun altro veda il documento
Aggiorna direttamente la sezione dei requisiti con ciò che Claude ha segnalato. La versione che un revisore vede deve già riflettere le domande che altrimenti riceveresti nei commenti, così il tempo di revisione va a veri disaccordi invece che a chiarimenti di base.
Ecco la dichiarazione del problema e la sezione dei requisiti del mio PRD per una funzionalità di esportazione in blocco. Dimmi onestamente se l'ambito è chiaro e segnala qualsiasi caso limite che non ho affrontato.
”Per una funzionalità con un vincolo tecnico specifico che già conosci, un limite di frequenza, un tetto alla dimensione dei dati, un confine di permessi, vale la pena dirlo direttamente a Claude perché il controllo dei casi limite si basi sul sistema reale anziché su congetture generiche.
Il nostro sistema di esportazione ha un limite rigido di 500.000 righe a livello di infrastruttura, che non è menzionato da nessuna parte in questo PRD. Dato questo vincolo, quali casi limite attorno ai limiti di righe dovrebbero essere affrontati esplicitamente dai requisiti?
”
Dentro Claude Tutorial
Testare un documento contro un lettore che non ha il tuo contesto è trasferibile.
Controllare se qualcosa ha senso per chi non ha il tuo background, invece di fidarsi della tua stessa rilettura, vale ben oltre i PRD. L'app ha una lezione completa al riguardo, con esercizi che si applicano a qualsiasi documento che scrivi perché qualcun altro agisca.
Quando le lacune vengono sempre dalla stessa sezione
Se i casi limite continuano a emergere nella stessa parte dei tuoi PRD, vale la pena notarlo come uno schema, non correggere ogni volta da capo. Una lacuna ricorrente, per esempio, nella sezione dei permessi di solito significa che quella sezione ha bisogno di una checklist permanente, non di un'altra revisione una tantum. Correggere la stessa categoria di lacuna tre volte separate è un segno che l'abitudine di fondo deve cambiare, non solo il documento attuale.
Consiglio
Chiedi a Claude di confrontare le lacune di questo PRD con quelle degli ultimi documenti, se li hai. Uno schema su più PRD è un segnale più forte dei casi limite di un solo documento, e ti dice dove costruire una checklist riutilizzabile.
Questo è il terzo PRD di fila in cui i revisori hanno chiesto della gestione dei permessi. Ecco la sezione dei permessi di questa bozza. Cosa manca e cosa dovrebbe coprire d'ora in poi una checklist permanente per questa sezione?
”Una volta che una checklist del genere esiste, vale la pena far passare la sezione pertinente di ogni nuovo PRD attraverso di essa prima della prima revisione, invece di affidarsi alla memoria per cogliere ogni volta la stessa lacuna ricorrente.
Ecco la checklist dei permessi che abbiamo costruito l'ultima volta e ecco la sezione dei permessi di un nuovo PRD. Controllala contro la checklist e segnala tutto ciò che la checklist copre e che questa bozza ancora non ha.
”Continua a leggere
- Scrivere un PRD a partire da una richiesta di funzionalità di una riga: impostare bene la struttura fin dall'inizio, prima del giro di revisione e correzione che questo articolo tratta.
- Trasformare i ticket di assistenza in temi prioritizzati: da dove spesso vengono, in primo luogo, i casi limite che un PRD deve coprire.
- Iniziare con Claude: le abitudini di fondo, contesto, iterazione, specificità, su cui si regge tutto questo processo.