Écrire un PRD que les développeurs lisent réellement, avec Claude comme éditeur
Les développeurs ignorent les PRD qui se lisent comme des essais. Une structure serrée et Claude en tant que rédacteur sévère ont permis l'ouverture du mien.
Mes premiers PRD sont revenus avec « pouvez-vous simplement dire quoi construire ». J'ai donc arrêté d'écrire des documents et commencé à rédiger des spécifications qu'un ingénieur fatigué tolérerait. Le travail de Claude est de couper, pas d'inventer.
La structure d'abord : une ligne sur le problème, une ligne sur l'utilisateur, une courte liste de ce que signifie « fait » et les cas extrêmes que les développeurs ont réellement rencontrés. Pas de roman de fond. S'il a besoin d'un paragraphe de contexte, il appartient à un fil de discussion lié.
Rédigez-le simplement, puis collez-le à Claude avec une instruction : "supprimez chaque phrase qu'un développeur peut déduire et signalez toute exigence sans test d'acceptation". Cette seule invite tue les peluches qui rendent les PRD désactivables.
Ensuite j'ajoute les tests d'acceptation que Claude a signalés comme manquants. Une exigence sans test est une opinion. Les développeurs lisent les spécifications qu'ils peuvent vérifier ; ils écument le reste.
L'habitude qui a tout changé : j'écris le PRD en supposant que le lecteur a le contexte et n'a pas de patience. Claude m'aide à tenir cette ligne en supprimant la prose de courtoisie.
Claude (claude.ai)
Idéal pour : la rédaction longue, l'édition et le raisonnement par la structure.
Principales fonctionnalités : mode document, contexte long, artefacts pour les brouillons, édition soignée.
Forfait gratuit : un niveau gratuit avec des limites quotidiennes.
Tarification : Pro environ 20 $ par mois pour une utilisation plus élevée.
Avantages : fort en taille et en restructuration, reste bref.
Inconvénients : cela adoucira un point brutal à moins que vous ne le lui disiez pas.
Mon verdict : j'écris les os, Claude enlève le gras, je rajoute les cases de bord. Le document qui en résulte est suffisamment court pour être lu et suffisamment spécifique pour être construit.
Questions fréquemment posées :
Q : Claude devrait-il rédiger le PRD à partir de zéro ?
R : J’écris la structure ; Claude édite. La génération complète s’écarte de ce dont l’équipe a réellement besoin.
Q : Dans quelle mesure est-il trop court ?
R : Si un développeur peut le construire et le tester à partir de la documentation, c'est suffisamment long. Le rembourrage est généralement plus long.
Q : Ai-je besoin de tests d’acceptation pour chaque ligne ?
R : Oui, pour tout ce qu'une personne chargée de l'assurance qualité vérifiera. Des exigences vagues deviennent ensuite des reproches.