Finde die Lücken deines PRD, bevor es die Prüfer tun
5 Min. Lesezeit
Die meisten PRDs gehen nach einem Durchlesen durch die Person raus, die sie geschrieben hat. Das fängt Tippfehler ab, aber selten die Lücke, die in den Kommentaren jedes Dokuments, das du verschickst, dieselbe Rückfrage hervorruft, weil du die Antwort schon kennst und über die Stelle hinweglist, an der sie fehlt. Ein PM, der den Kontext einer Funktion zwei Wochen lang im Kopf getragen hat, liest ein PRD dazu völlig anders als ein Entwickler, der das Dokument zum ersten Mal kalt öffnet.
Achtung
Ein Durchlesen durch den Autor prüft, ob das Dokument für jemanden Sinn ergibt, der die Funktion schon kennt. Es prüft nicht, ob es für jemanden Sinn ergibt, der sie nicht kennt, und das ist der tatsächliche Prüfer.
Das PRD, das dein eigenes Durchlesen übersteht, ist das, das du am wenigsten beurteilen kannst.
Warum dieselbe Frage in der Prüfung immer wieder auftaucht
Du hast das Dokument mit dem vollen Kontext schon im Kopf geschrieben, sodass eine Lücke in den Anforderungen für dich nicht als Lücke wirkt, sondern als selbstverständlich. Der Prüfer hat diesen Kontext nicht, sodass dieselbe Art Frage, ein unbehandelter Randfall, eine unausgesprochene Annahme, Dokument für Dokument wieder auftaucht. Haben drei deiner letzten fünf PRDs denselben Kommentar bekommen, wie sich die Funktion für einen bestimmten Nutzertyp verhalten soll, ist das kein Pech, sondern ein Muster in der Art, wie du den Umfang schreibst.
Nimm ein PRD für eine Massenexport-Funktion, das genau festlegt, was für einen Standardnutzer passiert, der bis zu 10.000 Zeilen exportiert. Es sagt nicht, was bei 100.000 Zeilen passiert oder bei einem Nutzer im Gratistarif mit Exportgrenzen, weil der Autor die ganze Zeit des Schreibens an den Normalfall dachte. Ein Entwickler, der das Dokument aufgreift, hat keine Möglichkeit, diese Antworten abzuleiten, und der entstehende Kommentarstrang, „was passiert oberhalb der Zeilengrenze?“, ist dieselbe Frage, die auch bei den letzten drei PRDs aufgekommen wäre, hätte jemand daran gedacht nachzuprüfen.
Vorher: das PRD schreiben, einmal lesen, entscheiden, dass es klar ist, zur Prüfung senden.
Nachher: es Claude mit dem tatsächlichen Kontext der Funktion geben, konkret fragen, ob der Umfang klar ist und welche Randfälle fehlen, und beheben, was es findet, bevor ein Prüfer fragen muss.
Ein Vorgehen, ein PRD vor der Prüfung zu testen
- 1
Gib Claude den tatsächlichen Entwurf und den echten Kontext
Füge Problemstellung und Anforderungen so ein, wie sie geschrieben sind, keine Zusammenfassung, zusammen mit der Angabe, für wen diese Funktion ist. Ein PRD für ein internes Admin-Werkzeug braucht eine andere Randfallabdeckung als eines für eine öffentliche Funktion, und derselbe fehlende Randfall zählt mehr oder weniger, je nachdem, wer betroffen ist.
- 2
Frag konkret, ob der Umfang klar ist
Ein vages „ergibt das Sinn“ bekommt eine vage Antwort. Frag direkt, ob jemand ohne Vorkontext allein aus dem Dokument sagen könnte, was im Umfang ist und was nicht, denn das ist der eigentliche Test, dem sich ein Entwickler stellt, der das Dokument kalt aufgreift.
- 3
Bitte um fehlende Randfälle, nicht um allgemeine Kritik
Verlange die konkreten Randfälle, die die Anforderungen nicht behandeln, kein offenes Feedback. Ein fehlender Randfall ist konkret und behebbar; „das könnte klarer sein“ ist es nicht.
- 4
Behebe die Lücken, bevor jemand anderes das Dokument sieht
Aktualisiere den Anforderungsabschnitt direkt anhand dessen, was Claude markiert hat. Die Fassung, die ein Prüfer sieht, sollte die Fragen schon widerspiegeln, die du sonst in den Kommentaren bekämst, sodass die Prüfzeit in echte Meinungsverschiedenheiten statt in grundlegende Klärungen fließt.
Hier sind die Problemstellung und der Anforderungsabschnitt meines PRD für eine Massenexport-Funktion. Sag mir ehrlich, ob der Umfang klar ist, und markiere jeden Randfall, den ich nicht behandelt habe.
”Bei einer Funktion mit einer bestimmten technischen Einschränkung, die du schon kennst, einem Ratenlimit, einer Datengrößenobergrenze, einer Berechtigungsgrenze, lohnt es sich, Claude diese direkt zu nennen, damit die Randfallprüfung im echten System statt in generischen Vermutungen verankert ist.
Unser Exportsystem hat auf Infrastrukturebene ein hartes Limit von 500.000 Zeilen, das in diesem PRD nirgends erwähnt wird. Welche Randfälle rund um Zeilengrenzen sollten die Anforderungen angesichts dieser Einschränkung ausdrücklich behandeln?
”
In Claude Tutorial
Ein Dokument gegen einen Leser ohne deinen Kontext zu testen ist übertragbar.
Zu prüfen, ob etwas für jemanden ohne deinen Hintergrund Sinn ergibt, statt deinem eigenen Durchlesen zu trauen, gilt weit über PRDs hinaus. Die App hat dazu eine vollständige Lektion, mit Übungen, die für jedes Dokument gelten, das du schreibst, damit jemand anderes danach handelt.
Wenn die Lücken immer aus demselben Abschnitt kommen
Tauchen Randfälle immer im selben Teil deiner PRDs auf, lohnt es sich, das als Muster zu bemerken, statt jedes Mal von vorn zu korrigieren. Eine wiederkehrende Lücke etwa im Berechtigungsabschnitt bedeutet meist, dass dieser Abschnitt eine feste Checkliste braucht, nicht noch eine einmalige Prüfung. Dieselbe Art von Lücke dreimal einzeln zu beheben ist ein Zeichen, dass sich die zugrunde liegende Gewohnheit ändern muss, nicht nur das aktuelle Dokument.
Tipp
Bitte Claude, die Lücken dieses PRD mit denen deiner letzten Dokumente zu vergleichen, falls du sie hast. Ein Muster über mehrere PRDs ist ein stärkeres Signal als die Randfälle eines Dokuments, und es zeigt dir, wo du eine wiederverwendbare Checkliste bauen solltest.
Das ist das dritte PRD in Folge, bei dem Prüfer nach dem Umgang mit Berechtigungen gefragt haben. Hier ist der Berechtigungsabschnitt dieses Entwurfs. Was fehlt, und was müsste eine feste Checkliste für diesen Abschnitt künftig abdecken?
”Gibt es eine solche Checkliste, lohnt es sich, den jeweiligen Abschnitt jedes neuen PRD vor der ersten Prüfung dagegen laufen zu lassen, statt sich darauf zu verlassen, dass das Gedächtnis jedes Mal dieselbe wiederkehrende Lücke fängt.
Hier ist die Berechtigungs-Checkliste, die wir letztes Mal gebaut haben, und hier der Berechtigungsabschnitt eines neuen PRD. Prüfe ihn gegen die Checkliste und markiere alles, was die Checkliste abdeckt und dieser Entwurf noch nicht hat.
”Weiterlesen
- Ein PRD aus einer einzeiligen Funktionsanfrage schreiben: die Struktur von Anfang an richtig aufsetzen, vor dem Durchgang aus Prüfen und Beheben, den dieser Artikel behandelt.
- Support-Tickets in priorisierte Themen verwandeln: woher die Randfälle, die ein PRD abdecken muss, oft überhaupt stammen.
- Erste Schritte mit Claude: die zugrunde liegenden Gewohnheiten, Kontext, Iteration, Präzision, auf denen dieser ganze Ablauf aufbaut.