Produktanforderungsdokumente – kurz und knapp

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

Dan Radigan Dan Radigan

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

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. (Tada!)

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 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 Product Owner 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 Dokumentierung der Erkenntnisse deiner Kunden eine Vorlage für Kundeninterviews. Befolge unser Tutorial zum Führen wertvoller Kundeninterviews:

Anti-Pattern, die vermieden werden sollten
  • Das gesamte Projekt ist bereits bis in das kleinste Detail festgelegt, bevor die Entwicklungsarbeit beginnt.
  • 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 Product Owner 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

When writing a requirements document, it's helpful to use a consistent template across the team so everyone can follow along and give feedback. At Atlassian, we use Confluence to create product requirements with the product requirements document template. We've found that the section below provides "just enough" context to understand a project's requirements and its impact on users:

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?
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 Elemente 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.

Pro Tip:

Das Agile Manifesto 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 (Product Owner, 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 Product Owner Keynote und PowerPoint verwenden, um Mockups 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, es ist aber nicht die einzig wahre Methode zur Erstellung eines solchen. 

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

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

Nach dem Einloggen wählst du den Product Requirements Blueprint 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 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 agil in Bezug auf deine Dokumentation vorgehen kannst! Du musst nicht jedes Mal dasselbe Format verwenden, sondern kannst jederzeit nach Bedarf und agil vorgehen. Kürze und ändere nach Bedarf.

3. Gerade genügend Kontext und Detail
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 Issues in Jira Software eingegeben wurden, verknüpfen wir sie mit unserer Seite (die praktischerweise ebenfalls einen Link von den Issues zurück zu der Seite erstellt). Diese wechselseitige Synchronisierung zwischen Confluence und Jira Software sorgt dafür, dass wir den aktuellen Status von jedem Issue automatisch direkt auf der Anforderungsseite sehen.

5. Kollektive Weisheit
Beim Erfassen von Produktanforderungen erleichtert Confluence anderen Personen in 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 eine aus ähnlichen Projekten gelernte Lektion bietet. Damit 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. Eine 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 Szenario tun würdet.

2.
"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 der Akzeptanz verschiedener 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 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.

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.