PRD (voll)

Eine vollständige PRD ist für eine komplexe, riskante oder teamübergreifende Initiative gerechtfertigt, bei der der Verlust des Kontexts teurer ist als die Erstellung eines Dokuments. Füllen Sie die Abschnitte nach Bedarf aus und notieren Sie das Unbekannte ausdrücklich; das Volumen des Textes gleicht die schwachen Hinweise auf das Problem oder das Fehlen des Eigentümers der Lösung nicht aus.

Was ist PRD?

Kurzbeschreibung

PRD ist ein strukturiertes Dokument, das erklärt, welches Produkt hergestellt werden soll, warum, für wen und welche Parameter es haben soll. Es wird von Entwicklern, Designern, Testern, Geschäfts- und anderen Teams gelesen.

Anwendungsbeispiel

Das Team startet einen neuen Onboarding-Prozess im Mobile Banking. Ohne PRD werden verschiedene Abteilungen die Aufgabe auf ihre eigene Weise sehen, wobei Zeitpläne und Ziele verschwimmen. Nachdem wir uns auf PRD geeinigt hatten, einigten sich alle auf eine Beschreibung und eine Reihe von Anforderungen: Was der Benutzer sieht, was auf dem Server passiert, wie man den Erfolg zählt, welche Einschränkungen bei Tech-Schulden.

Die Grundstruktur der PRD

Universalform

1. Beschreibung der Aufgabe
2. Produktziele (Produktziele)
3. Benutzerszenarien (User Stories/Flows)
4. Grundlegende Anforderungen (Funktionale Anforderungen)
5. Einschränkungen und nicht eingeschlossene Anforderungen (außerhalb des Anwendungsbereichs)
6. Erfolgsmetriken (Success Metrics)
7. Technische und nicht-funktionale Anforderungen
8. Validierungs- und Annahmekriterien
9. Anpassung und Risiko

Beispiel: Short Template

1. Problem: Das Ausfüllen von langen Profilen verhindert, dass Benutzer schnell beginnen.
2. Ziel ist es, die durchschnittliche Füllzeit um 30% zu reduzieren.
3. Szenarien: Ein neuer Benutzer registriert sich und beendet sofort das Onboarding.
4. Anforderungen: automatisches Ausfüllen des Formulars, Unterstützung für Mobilgeräte, Integration mit Backend.
5. Out of Scope: Profil-Redesign, Multi-Account.
6. Metriken: Zeit von der Registrierung bis zur ersten Aktion.
7. Technischer: API v2-Unterstützung, WCAG-Verfügbarkeit.
8. Kriterien: Der Benutzer schließt den Prozess in weniger als 2 Minuten ab.
9. Risiken: Integration mit einem veralteten CRM

Vergleich von Short und Full PRD

Die Vollversion fügt Details hinzu: Was zu testen ist, Links zu Layouts, spezifische APIs, Zeitplan und Beschreibung von Edge Cases. Die Kurzform eignet sich für Verbesserungen innerhalb eines kleinen Teams. Voll ist erforderlich, um große Projekte zu starten, wenn mehrere Abteilungen beteiligt sind.

Anforderungen, die nicht fehlen dürfen

Funktionale vs. nicht-funktionale Anforderungen

Funktional beschreibt, was das Produkt auf der Ebene der Funktion macht. Nicht funktional – wie genau es das macht (Geschwindigkeit, Sicherheit, UX, Geräteunterstützung).

Beispiel

Anforderung: Der Speicher-Button sollte bei schlechtem Internet funktionieren. Dies ist nicht funktional: Sie müssen das Stabilitätsniveau und beispielsweise die Reaktion der Schnittstelle auf einen Fehler beschreiben.

Einschränkungen (außerhalb des Anwendungsbereichs)

Ohne die Out of Scope-Bezeichnung fügen Entwickler häufig zusätzliche Aufgaben hinzu oder schlagen implizite Erweiterungen vor. Beschreiben Sie klar, was in diesem Feature oder Release nicht getan wird.

Häufige Fehler in PRD und wie man sie vermeidet

Wortlautnebel

Sätze wie Effizienz zu verbessern oder es bequem zu machen, geben Entwicklern oder Designern keine Ahnung, was zu erreichen ist. Schreiben Sie immer mit überprüfbaren Kriterien: Was ** bedeutet ** effektiv, wie ** messen ** das Ergebnis.

Fehlen von Metriken

PRD ohne Metriken verwandelt sich in eine Postkarte über Gefühle. Hinzufügen von Objektmetriken: Skriptausführungsrate, Benutzerprozentsatz, Fehler, Konvertierung, NPS - was nach dem Release gemessen werden kann.

Vergessene Kommunikation

Die unkoordinierte PRD reduziert nicht die Risiken, sondern erhöht sie: Designer arbeiten an einem Layout, Tester an einem anderen, Entwickler Code aus dem Speicher. Überprüfen Sie, ob das Dokument von den wichtigsten Interessengruppen vereinbart wurde.

Checkliste für PRD-Kontrolle

Fragen zum Selbsttest

1. Ist der Zweck und der Grund der Aufgabe definiert?
2. Gibt es konsistente Nutzerszenarien?
3. Sind die Anforderungen auf der für die Entwicklung und Erprobung erforderlichen Ebene klar beschrieben?
4. Gibt es Kriterien für eine erfolgreiche Akzeptanz?
5. Gibt es Einschränkungen oder Bereiche, die nicht abgedeckt sind?
6. Sind die Erfolgsmetriken klar und wo können die Daten überprüft werden?
7. Ist PRD zwischen den Teams vereinbart: Design, Virgin, QA, Business?

Beispiel für die Verwendung einer Checkliste

Bevor das Team den neuen Analytics-Bereich des B2B-Produkts startete, durchlief das Team eine Sieben-Punkte-Liste. Es stellte sich heraus, dass sie keine Erfolgsmetriken definiert haben - am Ende fügten sie das Tracking der notwendigen Benutzeraktionen hinzu, um die Hypothese der Vorteile zu validieren.

Wo man sich Beispiele und Vorlagen anschaut

• Atlassian Product Requirements ist eine kostenlose visuelle Vorlage in Confluence mit Kommentaren aus den Abschnitten
• Miro PRD Template – interaktives Kollaborationsboard
• Produktkoalition: Anatomie einer großen PRD
• Roman Pichler: Sample PRD – Englisch, mit Fokus auf agile

FAQ: Häufig gestellte Fragen

Was ist das Standard-PRD-Format? Es gibt keinen einheitlichen Standard, aber die Grundblöcke stimmen bei den meisten großen Projekten überein: Ziele, Anforderungen, Szenarien, Akzeptanzkriterien, Metriken, außerhalb des Umfangs, Risiken.

Was ist der Unterschied zwischen PRD und BRD? Das Business Requirements Document (BRD) erfasst die Mission und die Vorteile des Unternehmens, während die PRD detailliert beschreibt, was mit einem Fokus auf das Produkt und den Benutzer erstellt werden muss.

Wer schreibt PRD? Am häufigsten PM oder PO, aber überprüfen und finalisieren Sie mit dem Entwicklungsteam, Design, QA und Business Stakeholder.

**Muss ich für jedes neue Feature eine vollständige PRD erstellen? Nein, für schnelle Fixes. Bei großen Änderungen, neuen Modulen oder kundenspezifischen Lösungen, ja.

**Was passiert, wenn sich die Anforderungen häufig ändern? Machen Sie eine PRD-Versionierung und notieren Sie, welche Änderungen wann stattgefunden haben. Dies wird dem Team helfen, den Kontext im Auge zu behalten und das Dokument schneller zu aktualisieren.

*PrD ist immer der Text? Nein, man kann Diagramme, Prototypen, Tabellen verwenden – die Hauptsache ist, dass das Team sich wohl fühlte, mit den Anforderungen zu arbeiten und es keine unterschiedlichen Interpretationen gab.