Wer im Anforderungsmanagement "groß" geworden ist, wundert sich bisweilen über die sehr unterschiedlichen Auslegungsarten seiner neuen Rolle "Product Owner" in agilen Projekten.
Product Owner kompilieren aus dem Bedarf ihrer Anspruchsgruppen Anforderungen und kommunizieren sie in geeigneten Formen an das Entwicklungsteam. Insofern muss ein Product Owner mindestens zwei Sprachen sprechen:
- Die seiner Anspruchsgruppen, z. B. Geschäftsprozesse oder Produktfunktionen.
- Die der Softwareentwickler und Architekten. z. B. funktionale und nicht-funktionale Anforderungen
Ein Product Owner muss nicht alles wissen, aber er muss alles Wichtige in Erfahrung bringen und Klärungspunkte erkennen können. Wer muss was wann wissen und wann klären diesen Punkt - nicht unnötig früh, nicht zu spät?
Es entstehen zwei Kommunikationsrichtungen: eine von oben nach unten, die die Vorgaben und Richtungen festlegt. Und eine von unten nach oben, die die Machbarkeiten prüft und Einwände kommuniziert. In der Mitte entsteht das sinnvoll Machbare.
Da ich beide Welten kenne - Unternehmenssoftware und Steuergeräte- würde ich sagen, die Welt der Unternehmenssoftware ist hier weiter als die der Steuergeräte. Mit Ökonomen und Informatikern kommt man schnell in ein methodisches Fahrwasser und legt erst einmal einen sinnvollen Arbeitsfluss fest. Mit Steuergeräteingenieuren geht es oft sehr schnell in Richtung technischer Details - ohne die Perspektiven anderer Gruppen -zum Beispiel Anwender- einzunehmen. Damit meine ich nicht, dass Usecases unter den Tisch fallen. Sondern dass man glaubt, diese selbst ohne Rücksprachen festlegen zu können.
Ich bin jedes mal sehr dankbar, wenn es im Projekt einen guten, erfahrenen Systemarchitekten gibt. Mit ihm kann ein Product Owner "über alles reden". Am besten sitzt man mit ihm oder ihr Tür an Tür oder im selben Raum.
Ingenieure bestätigen einander gerne und suchen selbst für sich die Bestätigung ihres Expertenwissens. Das gilt auch für solche, die sich agil nennen. Ein Product Owner schätzt Experten, braucht aber keine Domänen, die nach außen nicht gut kommunizieren. Dieses Risiko besteht oft in Steuergeräteprojekten, aber man bedenke, dass auch sehr alte Softwaresysteme in Unternehmen und Verwaltungen von Programmierern mit Ingenieursmentalität geschrieben wurden. Hier lauert eine Fußangel und Falle nach der anderen. Auch Verunsicherungsangriffe auf den Anforderungsmanager oder Product Owner lauern hier. Es kostet viel Kraft, aber Ausdauer und Durchhaltevermögen werden am Ende (ca. 1 Jahr) belohnt. Obwohl ich das weiß, kostet es auch mich immer wieder Überwindung, mich nicht irre machen zu lassen. Weil ich mich ja nicht abschotten will, sondern mich bewusst dem Kommunikationsstrom aussetze. Und mit Annahmen arbeite. Und erst einmal Vertrauen bei den Meinen aufbauen muss. Die vielleicht selbst anfällig für diese Expertenkultur sind.
Somit komme ich zu dem Schluss, dass ein Product Owner auch das benötigt was früher im positiven Sinn unter Beratungsmentalität lief: Sensibilität, Hellhörigkeit, plus innerer Kompass plus dickes Fell.
Die meisten Anforderungsprofile an Product Owner stimmen deshalb m. E. nicht. Sie sind zu einseitig auf technische Expertisen ausgelegt.
Ich sehe hierin auch einen tief sitzenden Grund dafür, warum deutsche Startups nicht so erfolgreich sind, wie z. B. US-amerikanische. Es fehlt die Perspektive des Produktmanagers, der aus Endkundensicht Anforderungen beschreibt und priorisiert.
Keine Kommentare:
Kommentar veröffentlichen