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.

A product requirements document defines the product you are about to build: It outlines the product's purpose, its features, functionalities, and behavior.

Next, you share the PRD with (and seek input from) stakeholders - business and technical teams who will help build, launch or market your product.

Once all stakeholders are aligned, the PRD serves as a compass, providing clear direction toward a product's purpose while creating a shared understanding among business and technical teams.

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:

• Aufschlussreiche Seiten mit Kundeninterviews erstellen

• 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. Projektdetails definieren

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 AusrichtungWarum 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 sehe das auch bei vielen Kunden. 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 sind schwierige Aufgaben, die vor allem mit verschiedenen Wiki-Techniken in deinem Unternehmen zu tun haben. 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.