Schlanke Anforderungs- und Business-Analyse-Skills für agile Produktverantwortliche (Product Owners)
Kürzlich wurde ich gefragt: „Was sind die wichtigsten Business-Analyse-Fähigkeiten oder -Techniken, die Product Owner benötigen? Meine erste Antwort war: „Die meisten – wenn nicht alle“. Aber dann sind mir ein paar eingefallen, auf die ich wirklich nicht verzichten möchte.
Vorausgesetzt, der Product Owner ist Teil eines erfahrenen Agile-Teams, das auch über Kenntnisse in der betreffenden Branche verfügt, sind hier meine 7 wichtigsten Kompetenzen im Bereich der schlanken Geschäftsanalyse mit einer Begründung, warum ich sie ausgewählt habe:
Minimal erforderliche Skills für Product Owners
FREE BA VIDEOS
Leicht verständliche kurze Videos die verschiedene Business Analyse Techniken beschreiben.
1. Ermittlung von Problemen und Opportunitäten im Geschäftsbereich
Für mich ist dies ein klarer Fall, weil ich glaube, dass JEDER in einer modernen Organisation davon profitieren würde, neue Wege zu lernen, um Möglichkeiten und Probleme zu erkennen. Viele Menschen verbringen viel zu viel Zeit damit, über Probleme zu sprechen, die in Wirklichkeit Symptome der zugrunde liegenden Probleme sind. Solide Kompetenzen in der Problemanalyse sind fast immer (selbst in einer persönlichen Situation, wie ich bezeugen kann) eine Grundvoraussetzung für eine gute Entscheidungsfindung.
Beispieltechnik: Problem Analysis Uncovers Business Requirements
2. Brainstorming kreativer Lösungen und Strategien
Natürlich ist das Erkennen von Problemen und Opportunitäten sehr wichtig, aber es wäre irgendwie schön, wenn der Produktverantwortliche tatsächlich herausfinden könnte, wie er die Sachlage beheben oder ausnutzen könnte. Genauso offensichtlich ist, dass er/sie bei der Definition der Lösung keinen Alleingang machen muss, was zur nächsten Fähigkeit führt.
3. Effektive Moderation von Arbeitsgruppen, um Lösungen, User Stories und Anforderungen zu definieren
Kollaboration ist die Grundlage der Produktivität bei schlanker und agiler Arbeit. Eine Gruppe dazu zu bringen, qualitativ hochwertige Resultate zu erzielen, ist eine Fähigkeit, die einen mittelmäßigen Product Owner in einen Superstar verwandelt. Unser Wörterbuch definiert „moderieren“ als: „eine Handlung oder einen Prozess leichter zu machen“. Meines Erachtens wird jeder, der in der Lage ist, eine Aufgabe leicht oder leichter zu machen, mit einer Gruppe weit mehr erreichen, als diese für möglich hält.
Beispieltechnik: How to Run Requirements Workshops (aka JAD/R)
4. Evaluierung alternativer Lösungen und Strategien zur Ermittlung der vielversprechendsten Optionen
Die erste Lösung oder Strategie, die einem in den Sinn kommt, ist nicht immer die beste. Tatsächlich beinhaltet das gesamte Konzept der Agilen Entwicklung die ständige Verbesserung eines Produkts, um den Wert, den es dem Kunden bietet, zu steigern. Bei der Wahl einer Vorgehensweise kann der Produktverantwortliche potenzielle Alternativen vergleichen und diejenige auswählen, die am ehesten Erfolg verspricht.
5. Priorisieren von Funktionen, um das Mindestprodukt (Minimum Viable Product - MVP) oder die Minimalfunktionalität (Minimum Viable Feature - MVF) für ein bestimmtes Release zu definieren
Die richtige Prioritätensetzung ist für den Erfolg einer schlanken und agilen Entwicklung unerlässlich. Ohne Prioritäten wird jede Arbeit chaotisch und kontraproduktiv sein. Es gibt eine Reihe von Priorisierungstechniken für die Auswahl der Stories, Features usw., die im nächsten Release enthalten sein werden. Meiner Meinung nach ist es für den Product Owner wichtig, mehrere zu kennen, da keine Priorisierungstechnik für jede Sachlage funktioniert. Wählen Sie die beste aus und ignorieren Sie den Rest.
Beispieltechnik 1: Using Cynefin to Prioritize and Analyze Features, User Stories, and Functional Requirements
Beispieltechnik 2: Prioritize Your User Stories, Features, Non-functional Requirements or Other Backlog Items
6. Darstellung der ausgewählten Lösung und Strategie in überprüfbare Funktionen, Stories oder NFR
Die Hauptaufgabe des Product Owners ist es, zu kommunizieren, was das agile Team liefern muss, damit das kommende Release erfolgreich sein kann. Natürlich raten wir davon ab, auf antiquierte Dokumentationsgewohnheiten zurückzugreifen und viktorianische Romane zu schreiben, die niemand liest.
Der Product Owner muss jedoch einen Weg finden, das gewünschte Ergebnis so auszudrücken, dass die Entwickler es mit hoher Wahrscheinlichkeit erfolgreich umsetzen können. User Stories, Epics, Feature-Listen, Beispiele oder Szenarien und all die anderen wunderbaren schlanken Werkzeuge zur Business-Analyse funktionieren gut, wenn sie richtig verstanden und implementiert werden. Der Product Owner muss auch wissen, wie detailliert er/sie die Anforderungen beschreiben muss, um dem agilen Team voraus zu sein, ohne Zeit damit zu verschwenden, an Dingen zu arbeiten, die es nie bis zur Entwicklung schaffen.
Beispieltechnik: An Overview of Lean/Agile Business Analysis Techniques
7. Prüfen, dass die implementierte Lösung oder Strategie den versprochenen Kundennutzen bringt
Am Ende muss jemand das Ergebnis der Entwicklung validieren und bewerten. Dies setzt voraus, dass die ausgewählten Funktionen, Features, User Stories, NFR, etc. den notwendigen Qualitätsanforderungen entsprechen. Akzeptanztests und die Fähigkeit, Beispiele oder Szenarien aus dem wirklichen Leben zu erfassen und auszuführen, geben dem agilen Team und der Business-Community die Gewissheit, dass die neue Funktionalität oder das neue System ihre Anforderungen abdeckt.
Beispieltechnik: Acceptance Test Driven Development (ATDD) and BDD for the Business Analyst
Lean und Agile
Lernen Sie, die neuesten Praktiken der Business-Analyse anzuwenden, um die schlanke und agile Software-Entwicklungswelt optimal zu unterstützen.
Eine praktikable Alternative: Fachexpertenteam PLUS Business-Analyst
Wenn das agile Team weniger erfahren ist, müssen die Fähigkeiten des Product Owners kompensieren. Die gute Nachricht ist, dass er/sie keinen „Alleingang“ machen muss. Es spricht absolut nichts dagegen, ein Team auf der Geschäftsseite aufzubauen, dem auch Business-Analysten angehören, um die erforderlichen Fähigkeiten zu gewährleisten.
In den meisten Sachlagen könnte das eine bessere Alternative sein, denn ein Vollzeit Product Owner zu sein, ist nichts für schwache Nerven. Da er/sie mit mehreren Produkten und verschiedenen agilen Teams arbeitet, benötigt er/sie möglicherweise die meisten – wenn nicht sogar alle – Business-Analysetechniken. Natürlich setzt diese Alternative voraus, dass der Produktverantwortliche in der Lage ist, zu erkennen, wann er welche Technik einsetzen sollte – und warum.
Rückblickend war meine ursprüngliche Antwort „Die meisten, wenn nicht alle“ vielleicht doch die beste. Das spart sicherlich Zeit und nutzt die vorhandenen Fähigkeiten derer, die den Business-Analyse-Hut tragen. Hört sich nach einer Win-Win-Situation für diejenigen an, die sich für die schlanke Business-Analyse als Beruf entschieden haben.
