Erfolgreiche Releases beginnen mit einem Produktanforderungsdokument (PRD), das diese fünf Schritte enthält:
- Definieren Sie den Zweck des Produkts.
- Brechen Sie den Zweck in Features herunter.
- Setzen Sie die Ziele für die Release-Kriterien fest.
- Bestimmen Sie den Zeitplan.
- Stellen Sie sicher, dass die Stakeholder das Dokument überprüfen.
Wir werden im Folgenden auf jeden dieser Schritte eingehen. Lesen Sie weiter oder springen Sie zu dem gewünschten Abschnitt:
- Was ist ein PRD (Produktanforderungsdokument) Excel
- Was ist ein agiles Anforderungsdokument?
- Wie schreibt man ein PRD (Produktanforderungsdokument)
- PRD-Vorlage: Ein Beispiel für ein Produktanforderungsdokument
- Ein PRD und Rückverfolgbarkeit
Was ist ein Produktanforderungsdokument (PRD)?
Ein PRD (Produktanforderungsdokument) umreißt die Anforderungen an das, was Sie bauen werden, damit die Leute wissen, was das fertige Produkt tun soll.
Ein PRD ist der beste Freund eines Produktmanagers. Es stellt die Weichen für das Release. Und es stellt sicher, dass Sie das liefern, was die Kunden wollen – pünktlich.
Jeder Stakeholder, der mit dem Release zu tun hat – Entwickler, Tester, Projektmanager – sollte wissen, was im PRD steht.
PRDs enthalten typischerweise die folgenden Elemente:
- Zweck – Für wen es ist und warum Sie es bauen.
- Features – Was Sie bauen werden.
- Release Criteria – Ziele für das Release (z.B., Funktionalität).
- Timeline – Ein grobes Zeitfenster für das Release.
Was ist mit einem agilen Anforderungsdokument?
Dokumentation ist typischerweise das Gegenteil von Agile. Aber auch agile Entwicklungsteams profitieren vom Einsatz von PRDs.
In der agilen Entwicklung werden User Stories anstelle von traditionellen Anforderungen erstellt. Ein agiles Anforderungsdokument sammelt also User Stories, die für ein Release wichtig sind.
Es deckt immer noch die gleichen Elemente ab – Zweck, Funktionen, Release-Kriterien, Zeitplan. Aber ein agiles Anforderungsdokument tut dies typischerweise in einem Task Board oder einem interaktiven Dokument und nicht in einem statischen Dokument.
Ein PRD muss schließlich kein Roman sein. Sie können das Wesentliche eines Produktreleases in einem One-Pager abdecken – und dafür sorgen, dass Ihr Entwicklungsteam auf dem agilen Kurs bleibt.
👉🏼 LESEN: Wie man einen Agile-Hybrid in einer regulierten Branche durchführt >>
Wie man ein PRD (Produktanforderungsdokument) schreibt
Ein effektives PRD zu schreiben ist wichtig.
Auch wenn Sie mit dem Schreiben des eigentlichen Dokuments beauftragt sind, sollte es eine gemeinschaftliche Arbeit sein. Sie werden mit mehreren Stakeholdern in der Entwicklung zusammenarbeiten. Dies stellt sicher, dass alle auf der gleichen Seite über die Ziele der Produktfreigabe sind. Und es stellt sicher, dass das, was Sie entwickeln, ein Kundenbedürfnis erfüllt – und rechtzeitig fertiggestellt werden kann.
Erinnern Sie sich: Das übergeordnete Ziel eines PRDs ist es, zu definieren, was Sie bauen werden – nicht wie Sie es bauen werden.
Hier sind fünf Schritte, um ein effektives PRD für ein erfolgreiches Produktrelease zu schreiben.
Definieren Sie den Zweck des Produkts
Jeder in der Entwicklung muss sich über den Zweck des Produkts im Klaren sein. Der Zweck muss die Funktionen bestimmen.
Der Zweck sollte umreißen:
- Welche Probleme das Produkt löst.
- Wer das Produkt nutzen wird.
- Warum es wichtig ist.
Jeder Stakeholder sollte dem Zweck zustimmen – und sich dessen bewusst sein, während die Entwicklung voranschreitet.
Break the Purpose Down Into Features
Ihr nächster Schritt ist die Bestimmung der Feature-Anforderungen für das Release. Jede Funktion sollte den Gesamtzweck Ihres Produkts unterstützen.
Eine bewährte Methode zum Festlegen von Funktionsanforderungen ist es, zunächst Themen und Initiativen zu definieren.
Ein Thema richtet die Organisation über Jahre hinweg aus.
Ein paar Beispiele für ein Thema könnten sein:
- API
- Performance
- Mobile
Themen können sich über mehrere Jahre und Release-Zyklen erstrecken.
Initiativen werden verwendet, um die Entwicklungsbemühungen auf ein Thema auszurichten. Und Initiativen stellen sicher, dass Sie wissen, dass die Dinge in die richtige Richtung gehen. Eine Initiative kann sich über mehrere Themen erstrecken, z. B. die Integration von Funktionen für API, Performance und Mobile.
Von dort aus lässt sich eine Initiative in Funktionsanforderungen aufschlüsseln.
▶️ WATCH: Von der Planung eines Themas zum Setzen von Anforderungen >>
Setzen Sie die Ziele für die Release-Kriterien
Das Setzen der richtigen Ziele für die Release-Kriterien hilft Ihnen, den Zweck der Produktfreigabe zu erreichen.
Ihre Ziele sollten sein:
- Einfach zu verstehen.
- Aktionsfähig.
- Erreichbar.
- Messbar.
Die Freigabekriterien sollten fünf Bereiche abdecken.
Funktionalität
Sie müssen die Mindestfunktionalität definieren, die Sie benötigen, um das Produkt freigeben zu können. Ein Beispiel ist die Definition von Anforderungen, die für die Freigabe kritisch sind.
Benutzbarkeit
Sie müssen sicherstellen, dass das Produkt einfach zu benutzen ist. Ein Beispiel ist die Festlegung des Umfangs von Benutzertests – und was Sie mit den Ergebnissen tun werden.
Zuverlässigkeit
Sie müssen sicherstellen, dass Ihr Produkt zuverlässig ist. Ein Beispiel ist die Sicherstellung, dass es sich von einem Systemausfall erholen kann.
Leistung
Sie müssen eine Basislinie für die Leistung festlegen. Ein Beispiel ist die Bestimmung, wie schnell Ihr Produkt geladen werden muss.
Supportfähigkeit
Sie müssen festlegen, dass das Release unterstützt werden kann. Ein Beispiel ist die Sicherstellung, dass es von den Anwendern installiert und konfiguriert werden kann.
Bestimmen Sie den Zeitplan
Jedes Produkt-Release braucht ein Ziel-Release-Datum – auch wenn es nur eine grobe Schätzung ist.
Dies sollte Ihnen Flexibilität geben, um sich an eine Änderung der Prioritäten anzupassen. Es sollte aber auch den schleichenden Umfang einschränken, indem es begrenzt, wie viele Funktionen die Beteiligten hinzufügen können.
Die Verwaltung des Freigabeprozesses – und das Einhalten des angestrebten Freigabedatums – kann knifflig sein.
▶️WATCH: How to Fix Your Release Process >>
Make Sure Stakeholders Review It
Wenn Sie ein PRD erstellen, ist es wichtig, dass wichtige Stakeholder das Dokument prüfen.
Das kann knifflig sein, wenn Sie ein Anforderungsdokument in Microsoft Word verwalten.
Es ist eine bewährte Praxis, eine zentrale Lösung zu haben, mit der Sie Anforderungsprüfungen online verwalten können. Dann können Sie sicherstellen, dass jeder die aktuellste Version des Dokuments sieht. Und Sie können zurückgehen und verfolgen, wie sich Dinge geändert haben.
Es ist auch wichtig, dass jeder, der an der Entwicklung des Produkts beteiligt ist, weiß, was im PRD steht. Es sollte mit jedem geteilt werden, von den Entwicklern über die Tester bis hin zu den Managern.
📑 GET WHITE PAPER: 9 Tipps zum Schreiben nützlicher Anforderungen >>
PRD-Vorlage: Ein Beispiel für ein Produktanforderungsdokument
Viele Teams verwenden Microsoft Word, um PRDs zu erstellen und zu verwalten.
Hier ist ein Beispiel für ein Produktanforderungsdokument in Microsoft Word:
Ein PRD auf dem neuesten Stand zu halten ist in einem Tool wie Microsoft Word schwierig. Es ist schwer, die Genauigkeit zu gewährleisten, wenn die Anforderungen nur an einer Stelle verfolgt werden – weit weg vom Rest der Entwicklung. Es ist eine Herausforderung, dafür zu sorgen, dass jeder Zugriff auf die neueste Version hat. Es ist schwieriger, zusammenzuarbeiten. Und es ist praktisch unmöglich, agil zu arbeiten.
Deshalb verwenden viele Entwicklungsteams Anforderungsmanagement-Software, um ein PRD zu erstellen. Es bringt sie weg von Informationssilos. Die Anforderungen sind immer aktuell. Und es kann von jedem Entwicklungsteam verwendet werden, unabhängig davon, ob es einem Wasserfall- oder einem agilen Entwicklungsprozess folgt.
Hier ist ein Beispiel für das gleiche PRD in Helix ALM:
Ein agiles Anforderungsdokument kann auch in einem Task Board erstellt werden. So haben Sie auf einen Blick den Status der Anforderungen im Blick.
In diesem Kanban-Board sehen Sie beispielsweise, wie User Stories (Anforderungen) überprüft und umgesetzt werden.
Wenn Sie in Sprints entwickeln (wie die meisten Agile Teams), können Sie Helix ALM verwenden, um den Fortschritt jedes Sprints zu überwachen. Sie sehen, welche User Stories implementiert und validiert wurden.
Ein PRD und Rückverfolgbarkeit
Das Schreiben eines PRD ist nur ein Schritt zu einer effizienten Entwicklung und einem besseren Release-Prozess. Erfolgreiche Releases hängen auch von gründlichen Tests und einer schnellen Fehlerbehebung ab.
Es ist also eine Best Practice, ein Tool – wie Helix ALM – zu haben, mit dem Sie User Stories (oder Anforderungen), Tests und Probleme alle an der gleichen Stelle verfolgen können. Dann können Sie Ihr PRD sogar verwenden, um die Testabdeckung sicherzustellen, indem Sie Testfälle aus User Stories erstellen. Und Sie können die Ergebnisse bis zur Fehlerbehebung verfolgen.
✏️ Lernen Sie 6 Übungen, um die Nachvollziehbarkeit zu stärken >>
In Helix ALM wird dies durch eine Nachvollziehbarkeitsmatrix (die automatisch vom Tool generiert wird) erreicht: