Produktanforderungsdokumente – kurz und knapp

Niemand verfasst gerne umfangreiche, extrem detaillierte Dokumente zu Produktanforderungen. Und die Wenigsten verwenden diese gerne.

Dan Radigan Dan Radigan
Themen durchsuchen

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.

Agile Produktanforderungsdokumente | Atlassian Agile Coach

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.

Das Zusammentragen von Anforderungen in einer agilen Welt

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.

Gemeinsamer Informationsstand aller Teams

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 Feedback direkt vom Kunden hören, statt sich auf die Notizen 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 Kundentypen sollte eine Teamaufgabe sein. Jedes Teammitglied bringt einzigartige Sichtweisen und Einblicke ein und sollte verstehen, wie die Kundentypen die Produktentwicklung beeinflussen.
  • Auch die Einschätzung von Vorgängen und die Backlog-Pflege sollten Teamaufgaben sein. Auf diese Weise kann sichergestellt werden, dass alle auf demselben Stand sind und verstehen, warum der Produktinhaber Prioritäten für bestimmte Aufgaben festgelegt hat.

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

Erstelle zur Dokumentierung der Erkenntnisse deiner Kunden eine Vorlage für Kundeninterviews. Befolge unser Tutorial zum Führen wertvoller Kundeninterviews:

Anti-Pattern, die vermieden werden sollten
  • Vor Beginn der eigentlichen Entwicklungsarbeit ist das gesamte Projekt bereits bis ins kleinste Detail festgelegt.
  • Bevor die Arbeit überhaupt beginnen kann, sind ein gründlicher Review und ein strenges Abzeichnen von allen Teams erforderlich.
  • Designer und Entwickler wissen nicht, wann Anforderungen aktualisiert wurden.
  • Anforderungen werden gar nicht erst aktualisiert, weil sie ja bereits von allen abgezeichnet wurden (siehe oben).
  • Der Produktinhaber entwickelt Anforderungen ohne Einbeziehung des Teams.

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?

Klare Anforderungen mit einem einseitigen Dashboard

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? Im Zeitplan, gefährdet, verzögert, zurückgestellt usw.
  • Angestrebtes Release: Für wann ist die Auslieferung geplant?
Agile Anforderungen | Atlassian Agile Coach

2. Team- und Unternehmensziele 
Komme direkt zum Punkt. 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?

Agile Produktanforderungen | Atlassian Agile Coach

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.

Agile Anforderungen: Storys | Atlassian Agile Coach

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.

Profitipp:

Das Agile Manifest erinnert uns daran, dass wir flexibel in Bezug auf die Entwicklung von Anforderungen sein können. Einige Teams nutzen User-Story-Zuordnungsübungen, um Probleme und Lösungen zu ermitteln. Manchmal besucht das gesamte Produkttrio (Produktinhaber, Entwickler und Designer) einen Kunden und sucht dann mittels Brainstorming nach Lösungen für ein bestimmtes Problem, das der Kunde erwähnt hat.

 

Unabhängig davon, wie Anforderungen ausgearbeitet werden, sollte das Team diese als eine der vielen Mittel für die Definition und Kommunikation von Kundenproblemen betrachten. In unserem Abschnitt zum agilen Design erfährst du, wie Produktinhaber Keynote und PowerPoint verwenden, um Modelle realer Erfahrungen als Anforderungen zu erstellen. 

Beispiel für ein einseitiges Produktanforderungsdokument

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.

Beispiel eines agilen Produktanforderungsdokuments | Atlassian Agile Coach
Produktanforderungsdokument | Atlassian Agile Coach

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

Nach dem Einloggen wählst du das Muster für Produktanforderungen und befolgst das unten stehende Tutorial, das dich durch die Erstellung des Dokuments leitet:

Die wichtigsten Punkte bei diesem Einseiten-Prinzip:

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 Software 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 Software 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.

Herausforderungen

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.

Jetzt geht es an die Arbeit!

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 in der Vorgangsverfolgung des Entwicklerteams zu verknüpfen. Dadurch wird der Entwicklungsprozess transparenter: Der Status der einzelnen Aufgaben ist leicht zu erkennen und Produktinhaber und nachfolgende Teams, beispielsweise aus den Bereichen Marketing und Support, können fundierte Entscheidungen treffen.

Profitipp:

Verzichte auf das Nachverfolgen von User Storys, die auf Projektanforderungen basieren und auf Fehlern in verschiedenen Systemen. Das Verwalten von Aufgaben in zwei unterschiedlichen Systemen ist unzweckmäßig und enorm zeitaufwendig.

Denke daran, bei der Weiterentwicklung der Anforderungen für ein Projekt agil zu bleiben. Es ist in Ordnung, User Storys zu ändern, wenn 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.