So erstellst du ein Produktanforderungsdokument (Product Requirements Document, PRD)

Zusammenfassung: Ein Produktanforderungsdokument definiert die Anforderungen an ein bestimmtes Produkt. Dazu gehören Zweck, Features, Funktionen und Verhalten des Produkts. Das Dokument dient geschäftlichen und technischen Teams als Leitfaden für die Entwicklung, Veröffentlichung und Vermarktung des Produkts.

Ein gutes Produkt lässt sich nur mit umfangreicher Forschung und Planung erstellen. Aber wo fängst du am besten an? Produktmanager beginnen oft mit einem Produktanforderungsdokument (Product Requirements Document, PRD).

Ein Produktanforderungsdokument definiert das Produkt, das du erstellen möchtest. Es skizziert den Zweck des Produkts, seine Features, Funktionen sowie sein Verhalten.

Anschließend teilst du das Produktanforderungsdokument mit den Stakeholdern (und holst Input von ihnen ein). Zu den Stakeholdern zählen sowohl die Business- als auch die technischen Teams, die an der Erstellung, Einführung und Vermarktung des Produkts beteiligt sind.

Nachdem nun alle Stakeholder auf dem Laufenden sind, dient das Produktanforderungsdokument als eine Art Kompass, der eine klare Richtung zum Zweck des Produkts vorgibt und dafür sorgt, dass Business- und technische Teams immer auf demselben Stand sind.

Wie verläuft das Zusammentragen von Anforderungen in einer agilen Umgebung? Hört sich kompliziert an – und ist es auch. Aber keine Sorge. Wir bei Atlassian kennen uns mit der Erstellung von Produktanforderungsdokumenten in einer agilen Umgebung bestens aus. Folgende Punkte solltest du berücksichtigen:

Agile Anforderungen sind der beste Freund des Product Owners. Product Owner, die keine agilen Anforderungen verwenden, verzetteln sich in der Spezifizierung aller Details, um die richtige Software auszuliefern (und müssen dann die Daumen drücken, dass sie die richtigen Dinge spezifiziert haben). Agile Anforderungen basieren dagegen auf einem gemeinsamen Verständnis für den Kunden, das vom Product Owner, Designer und Entwicklerteam geteilt wird. Dieses gemeinsame Verständnis und die Empathie für den Zielkunden setzt eine verborgene Bandbreite an Aktivitäten für Product Owner frei. Sie können sich auf allgemeinere Anforderungen konzentrieren und die Implementierungsdetails dem Entwicklerteam überlassen, das perfekt dafür ausgestattet ist – auch aufgrund dieses gemeinsamen Verständnisses. (Tada!)

Wenn dir die Idee des gemeinsamen Verständnisses gefällt, du aber keine Ahnung hast, wie du dieses erreichst, probiere einige der folgenden Tipps aus:

• Ermögliche es jeweils einem Mitglied des Design- und des Entwicklerteams, dich zu Kundengesprächen zu begleiten. Auf diese Weise können sie direkt mit dem Kunden kommunizieren, statt sich auf die Hinweise des Product Owners verlassen zu müssen. Du hast so außerdem die Möglichkeit, dem Kunden wichtige Fragen zu stellen, solange das Thema noch aktuell ist.
• Das Entwickeln und Nutzen von Kundenrollen sollte eine Teamaufgabe sein. Jedes Teammitglied bringt einzigartige Sichtweisen und Einblicke ein und sollte verstehen, wie die Rollen die Produktentwicklung beeinflussen.
• Auch die Einschätzung von Vorgängen und die Backlog-Pflege sollten Teamaufgaben sein. Dies sind großartige Möglichkeiten, um sicherzustellen, dass alle auf demselben Stand sind und verstehen, warum der Produktinhaber Prioritäten für bestimmte Aufgaben festgelegt hat.

Möchtest du das Ganze mal ausprobieren? Registriere dich oder logge dich in Confluence ein >>

Erstelle zur Dokumentation des Kundenfeedbacks eine Vorlage für ein Kundeninterview. Befolge unser Tutorial zur Durchführung wertvoller Kundeninterviews:

• Erstellen von aufschlussreichen Seiten für Kundeninterviews
• Verwandle mit der Pyramide für Kundeninterviews Informationen in aufschlussreiche Erkenntnisse.

Gut, du hast eine Reihe von User Storys mit deinem Entwickler und Designer besprochen. Ihr habt hin und her diskutiert, einige Whiteboard-Sitzungen abgehalten und beschlossen, dass ihr einige weitere Dimensionen in Bezug auf das Feature bedenken müsst, an dem ihr gerade arbeitet. Ihr solltet einige Hypothesen ausarbeiten, gründlicher darüber nachdenken, wie alles in das allgemeine Schema passt, und alle offenen Fragen nachverfolgen, die beantwortet werden müssen. Und jetzt?

Beim Formulieren von Anforderungen ist es hilfreich, im gesamten Team eine konsistente Vorlage zu verwenden, damit jeder den Angaben problemlos folgen und Feedback geben kann. Bei Atlassian nutzen wir in Confluence zum Erstellen von Produktanforderungen die Vorlage für ein Produktanforderungsdokument. Wir haben festgestellt, dass der unten stehende Abschnitt "gerade genug" Kontext zum Verständnis der Anforderungen eines Projekts und dessen Auswirkungen auf Benutzer bietet:

1. Definieren der Projektdetails
Wir empfehlen, direkt am Seitenanfang allgemeine Anweisungen zu folgenden Punkten bereitzustellen:

• Teilnehmer: Wer ist am Projekt beteiligt? Hier kannst du den Product Owner, das Team und die Stakeholder aufführen.
• Stand: Wie ist der aktuelle Stand des Programms? Nach Planung, gefährdet, verzögert, zurückgestellt usw.
• Angestrebtes Release: Für wann ist die Auslieferung geplant?

2. Team- und Unternehmensziele
Komme direkt zur Sache. Stelle Informationen bereit und sieh von möglicherweise langweiligen Ausführungen ab.

3. Hintergrund und strategische Ausrichtung
Warum machen wir das? Inwiefern passt die Vorgehensweise zu den allgemeinen Unternehmenszielen?

4. Annahmen
Liste mögliche Annahmen in Bezug auf Technik, Unternehmen oder Benutzer auf.

5. User Storys
Liste oder verlinke die verwendeten User Storys. Verlinke darüber hinaus Kundeninterviews und füge Screenshots von Inhalten ein, die du dir bereits angesehen hast. Stelle genügend Details für eine umfassende Story bereit und gib auch Erfolgsmetriken an.

6. Benutzerinteraktion und Design
Verlinke die Seite mit Designuntersuchungen und Wireframes, sobald das Team für jede User Story eine Lösung ausgearbeitet hat.

7. Fragen
Wenn das Team die zu lösenden Probleme versteht, kommen oft Fragen auf. Erstelle eine Tabelle der "Dinge, die wir entscheiden oder recherchieren müssen", um diese Punkte nachzuverfolgen.

8. Was wir nicht tun
Sorge dafür, dass sich das Team auf die vorliegende Arbeit konzentriert, indem du klar darlegst, welche Aufgaben nicht erledigt werden sollen. Weise darauf hin, welche Aufgaben nicht zum aktuellen Arbeitsumfang gehören, zu einem späteren Zeitpunkt aber möglicherweise berücksichtigt werden müssen.

Hier haben wir ein komplett ausgearbeitetes Produktanforderungsdokument, das wir mit Confluence erstellt haben. Beachte dabei, dass es bei allen Produktanforderungen Unterschiede gibt. An diesem Beispiel kannst du die verschiedenen Elemente sehen, die in deinem Produktanforderungsdokument enthalten sein sollten. Das ist aber nicht die einzig wahre Methode zur Erstellung eines solchen Dokuments.

Wenn dieser Blog dir irgendwelche Erkenntnisse bringen soll, musst du das "Warum" verstehen, nicht das "Was" – denn das "Warum" hilft dir zu erkennen, was für dein Team am besten ist. Hier sind die Vorteile und Herausforderungen, die wir beim einseitigen Dashboard-Ansatz beobachtet haben:

1. Eine Seite, eine Quelle
Halte alles so einfach wie möglich. Das Produktanforderungsdokument wird zur "Startseite" für alles, was mit den Problemen in einem bestimmten Epic zusammenhängt. Eine zentrale Informationsquelle spart deinen Teammitgliedern Zeit beim Zugriff auf Informationen und verschafft ihnen einen guten Überblick.

2. Zusätzliche Agilität
Einer der großen Vorteile bei der Verwendung einer einfachen Seite für die Zusammenarbeit (im Gegensatz zu einem dedizierten Tool für das Anforderungsmanagement) ist, dass du in Bezug auf deine Dokumentation agil vorgehen kannst! Du musst nicht jedes Mal dasselbe Format verwenden, sondern kannst jederzeit nach Bedarf und agil vorgehen. Kürze und ändere, wenn nötig.

3. Gerade genügend Kontext und Details
Wir vergessen oft, wie wirkungsvoll ein einfacher Link sein kann. Wir betten eine Menge Links in unsere Produktanforderungsdokumente ein. Damit wird die Komplexität verringert und der Leser kann Informationen nach Bedarf sukzessive abrufen. Links zu ausführlichen Ressourcen können Folgendes umfassen:

• Kundengespräche als Hintergrund, Validierung oder weiteren Kontext für das Feature
• Seiten oder Blogs mit Vorschlägen ähnlicher Ideen
• Vorherige Gespräche oder technische Dokumentation und Diagramme
• Videos von Produktdemos oder andere zugehörige Inhalte aus externen Quellen

4. Lebendige Storys
Ich habe gesehen, dass viele Kunden dies ebenso handhaben. Sobald die Storys grob umrissen sind und als Vorgänge in Jira eingegeben wurden, verknüpfen wir sie mit unserer Seite (die praktischerweise ebenfalls einen Link von den Vorgängen zurück zu der Seite erstellt). Diese wechselseitige Synchronisierung zwischen Confluence und Jira sorgt dafür, dass wir den aktuellen Status sämtlicher Vorgänge automatisch direkt auf der Anforderungsseite sehen.

5. Kollektive Weisheit
Beim Erfassen von Produktanforderungen erleichtert es Confluence anderen Personen aus verschiedenen Teams, einen Beitrag zu leisten und Vorschläge zu machen. Ich war immer wieder überrascht, wie oft jemand aus einem anderen Team einen Kommentar in das Gespräch einbringt, der großartiges Feedback, einen Vorschlag oder Erfahrungen aus ähnlichen Projekten liefert. Dadurch kann sich ein großes Unternehmen wie ein kleines Team anfühlen.

6. Einsatz von "Zubehör"
Mithilfe von Diagrammen, die mit Tools wie Visio, Gliffy oder Balsamiq erstellt werden, kannst du Probleme besser an dein Team weitergeben. Du kannst außerdem externe Bilder, Videos und dynamische Inhalte einbetten.

7. Zusammenarbeit!
Der wichtigste Aspekt bei all dem ist, alle Beteiligten einzubeziehen. Verfasse ein Produktanforderungsdokument niemals allein, sondern beziehe immer einen Entwickler mit ein. Teile die Seite mit deinem Team und lass dir Feedback geben. Kommentiere, stelle Fragen und fordere die anderen auf, ihre Gedanken und Ideen beizutragen. Das ist besonders wichtig für verteilte Teams, die nicht oft die Gelegenheit haben, Projekte persönlich zu besprechen.

Jeder Ansatz hat seine Nachteile. Hier sind zwei der größten Herausforderungen, die wir selbst beobachtet und auch von Kunden erfahren haben:

1. Dokumentation kann veralten
Was passiert, wenn du eine Story implementierst, Feedback erhältst und dann die Lösung änderst? Gibt es jemanden, der die Anforderungsseite nach der letzten Implementierung aktualisiert? Das ist eine Herausforderung für jede Art von Dokumentation und du solltest immer hinterfragen, ob sich solche Kompromisse lohnen. Sprich mit deinem Team darüber, was ihr in einem solchen Fall tun würdet.

2. Mangelnde Beteiligung
"Was kann ich tun, damit andere Kommentare abgeben?", "Wie kann ich andere ermutigen, mehr Spezifikationen und Storys im Intranet zu veröffentlichen?" Das ist eine harte Nuss und hat vor allem mit verschiedenen Wiki-Techniken in deinem Unternehmen zu tun. Es gibt viele Ressourcen, die dir hier helfen können. Möglicherweise spielen auch tiefer gehende kulturelle Probleme eine Rolle.

Wenn Anforderungen geschickt formuliert sind, hat der Produkteigentümer mehr Zeit, den Markt zu verstehen und mit ihm Schritt zu halten. Wenn sie zudem informativ, dabei aber kurz und knapp gehalten sind, kann das Entwicklerteam sie auf die Weise implementieren, die am besten zur Architektur und zum Technologie-Stack passt.

Sobald die Anforderungen eines Projekts einigermaßen ausgereift sind, empfehlen wir, die User Storys in Abschnitt 5 oben mit den entsprechenden Storys im Issue Tracker des Entwicklerteams zu verknüpfen. Dadurch wird der Entwicklungsprozess transparenter: Der Status der einzelnen Aufgaben ist leicht zu erkennen und Product Owner und nachfolgende Teams, beispielsweise aus den Bereichen Marketing und Support, können fundierte Entscheidungen treffen.

Denke daran, bei der Weiterentwicklung der Anforderungen für ein Projekt agil zu bleiben. Es ist in Ordnung, User Storys zu ändern, während das Team entwickelt, ausliefert und Feedback erhält. Achte immer darauf, einen hohen Qualitätsanspruch und eine passende Entwicklungskultur zu bewahren – auch wenn das bedeutet, weniger Features auszuliefern.