Entdecken Sie Millionen von E-Books, Hörbüchern und vieles mehr mit einer kostenlosen Testversion

Nur $11.99/Monat nach der Testphase. Jederzeit kündbar.

Product Ownership meistern: Produkte erfolgreich entwickeln
Product Ownership meistern: Produkte erfolgreich entwickeln
Product Ownership meistern: Produkte erfolgreich entwickeln
eBook442 Seiten3 Stunden

Product Ownership meistern: Produkte erfolgreich entwickeln

Bewertung: 0 von 5 Sternen

()

Vorschau lesen

Über dieses E-Book

Der Leitfaden für Product Owner
  • Den gesamten Produktlebenszyklus aktiv gestalten
  • Komplexe Probleme und Produkte in den Griff bekommen
  • Mit umfangreicher Methodensammlung samt Tipps und Tricks, um den eigenen Werkzeugkoffer erweitern

Product Owner stehen jeden Tag vor der Herausforderung, Produkte Wirklichkeit werden zu lassen. Sie sind stets auf der Suche nach dem Wert für ihre Kunden und müssen dabei Dinge wie Stakeholder, Unternehmenspolitik und Kundinnen unter einen Hut bringen. Product Ownership meistern zeigt auf, warum heutiges Produktmanagement nicht nur kompliziert, sondern komplex ist und gibt Hilfestellungen, wie Product Owner die Komplexität meistern können – von der ersten Produktidee bis zur Produktablöse den gesamten Lebenszyklus entlang.

SpracheDeutsch
Herausgeberdpunkt.verlag
Erscheinungsdatum13. Sept. 2022
ISBN9783969108093
Product Ownership meistern: Produkte erfolgreich entwickeln

Ähnlich wie Product Ownership meistern

Ähnliche E-Books

Projektmanagement für Sie

Mehr anzeigen

Ähnliche Artikel

Rezensionen für Product Ownership meistern

Bewertung: 0 von 5 Sternen
0 Bewertungen

0 Bewertungen0 Rezensionen

Wie hat es Ihnen gefallen?

Zum Bewerten, tippen

Die Rezension muss mindestens 10 Wörter umfassen

    Buchvorschau

    Product Ownership meistern - Frank Düsterbeck

    1Einleitung

    Wir arbeiten in unserem Alltag mit vielen Product Ownern aus unterschiedlichen Branchen und Unternehmensgrößen zusammen. Dabei beobachten wir, dass diese auf ganz unterschiedliche Probleme stoßen und ihrer Verantwortung rund um ihr Produkt oft nicht gerecht werden können. Einige der Product Owner kennen die Entwickler kaum, sind nur bei wenigen Meetings dabei und dadurch viel zu weit von ihrem Team entfernt. Andere wiederum sind durch äußeren Druck getrieben und dadurch unfokussiert oder haben keinen direkten Zugriff auf die diversen Stakeholder und werden von diesen als willfährige Anforderungsübersetzer wahrgenommen. Wieder andere Product Owner wurden von ihren Vorgesetzten überhaupt nicht bevollmächtigt, Produktentscheidungen treffen zu dürfen. Sie werden beispielsweise bei Priorisierungen oder Portfolio- und Roadmap-Entscheidungen immer wieder überstimmt – sie ownen das Produkt gar nicht.

    Fast allen Product Ownern gemeinsam ist, dass sie unter Lieferdruck stehen, nur einen begrenzten Teil ihres ganzen PO-Werkzeugkastens nutzen können, teilweise zu stark auf den Nutzer fokussieren und dabei andere Stakeholder-Interessen außer Acht lassen.

    Wir beide sind auf vielen Konferenzen mit Vorträgen zu diesen Themen vertreten und hatten auf den Rückfahrten viel Zeit, über diese Beobachtungen sowie die Fragen und das Feedback zu unseren Vorträgen zu diskutieren. Die Probleme der Zielgruppe Product Owner sind uns also sehr bewusst. Daraus entstand die Idee, den Product Ownern dieser Welt nicht nur punktuell, in unseren eigenen Produktentwicklungen, unseren Beratungsmandaten oder auf Veranstaltungen zu helfen, sondern unsere Erfahrungen breiter zu streuen und dieses Buch als eine Lösung für diese Probleme zu schreiben.

    Der richtige Start war aber trotzdem ein wenig schleppend. Monatelang haben wir immer wieder gesagt, dass wir ja dieses Buch endlich angehen wollen. Im März 2021 haben wir das Produkt Buch aber dann wirklich in Angriff genommen. Ab Juni 2021 war der dpunkt.verlag und damit unsere großartige Lektorin Melanie Andrisek mit an Bord. Dadurch hat das Ganze noch mal ordentlich Fahrt aufgenommen, und die Produktentwicklung kam endlich voran.

    Wir freuen uns sehr, dir mit diesem Buch das notwendige Hintergrundwissen und die verschiedenen Methoden, Techniken und Artefakte vorzustellen, damit du neue wertvolle Lösungsideen für deine Probleme als Product Owner erhalten und Product Ownership wirklich meistern kannst.

    1.1Wie dieses Buch aufgebaut ist

    Dieses Buch besteht aus drei Teilen:

    Teil I: Die Herausforderungen des Product Owners

    Dieses Kapitel gibt dir das notwendige Hintergrundwissen, deine Herausforderungen als Product Owner besser zu verstehen. Es bildet die Basis für die später vorgestellten Methoden, Techniken und Artefakte, mit denen du ein wertvolles Produkt herstellen kannst. Das Kapitel erläutert dir, auf welche Herausforderungen du bei komplexer Softwareentwicklung triffst. Jedes Produkt durchläuft im Laufe seiner Entwicklung einen Lebenszyklus. Je nachdem, wo in diesem Zyklus sich dein Produkt befindet, ändert sich dein Arbeitsschwerpunkt als PO. Diese Schwerpunkte nennen wir Fokusthemen und stellen sie in diesem Kapitel genauer vor. Diese Fokusthemen sind auch die Basis für die Sortierung der Methoden und Artefakte.

    Teil II: Die Verantwortlichkeiten des Product Owners

    In diesem Kapitel gehen wir genauer darauf ein, was deine Verantwortlichkeiten als PO sind. Wie das Zusammenspiel mit dem Scrum Master und den Entwicklern funktioniert und welche Besonderheiten es bei großen Produkten und im Dienstleistungsumfeld gibt. Außerdem ist ein Produkt immer Teil eines Portfolios und steht nicht im luftleeren Raum.

    Teil III: Methoden und Artefakte sortiert nach Fokusthema

    In diesen Kapiteln zeigen wir dir Methoden und Artefakte, die dich als PO dabei unterstützen, Product Ownership zu meistern. Diese sind sortiert nach den Fokusthemen, und ein durchgängiges Praxisbeispiel hilft dir beim Verstehen.

    1.2Wie dieses Buch zu lesen ist

    Wir empfehlen, Teil I und Teil II des Buches linear zu lesen, weil diese die Grundlage erläutern, um die folgenden Methoden und Artefakte korrekt umzusetzen. Methoden können dich dabei unterstützen, ans Ziel zu kommen, aber viel wichtiger sind das richtige Hintergrundwissen und ein grundlegendes Verständnis für komplexe Problemstellung. Die Methoden und Artefakte kannst du je nach Bedarf linear oder punktuell lesen.

    1.3Webseite

    Wir nennen in diesem Buch viele Methoden und Artefakte, die dir als Product Owner das Leben erleichtern. Viele Medien und Helferlein, die wir in unserem Buch vorstellen, kannst du für den Einsatz in deiner eigenen Produktentwicklung von unserer Webseite herunterladen:

    https://www.product-ownership-meistern.de/medien/

    1.4Gendersprache

    Bei vielen Begriffen haben wir die geschlechtsneutrale Schreibweise genutzt. Aufgrund der Lesbarkeit haben wir uns an einigen Stellen für das generische Maskulinum entschieden. Selbstverständlich meinen wir aber alle Geschlechter gleichermaßen.

    1.5Danke!

    An dieser Stelle ein großes Dankeschön an unsere Lektorin Melanie Andrisek, die uns mit ihrer beharrlichen und humorvollen Kritik und Impulsen immer vorangebracht hat. Außerdem möchten wir folgenden Personen für ihr Review und ihr fundiertes Feedback danken: Ulf Mewe, Lars Einemann, Stefan Roock, Arne Schröder, Roman Pichler und Arne Limburg. Vielen lieben Dank für eure Zeit, die ihr investiert habt, damit wir ein hoffentlich wertvolles Produkt für Product Owner erstellen konnten.

    Wie wir feststellen mussten, bedeutet so ein Buch doch einiges mehr an Arbeit als ursprünglich gedacht – es ist eben ein komplexes Vorhaben. Daher an dieser Stelle ein Danke an unsere Familien, die diesen Zeitinvest mitgetragen haben.

    Teil I

    2Die Herausforderungen des Product Owners

    Der Product Owner ist, neben den Developern (wir verwenden im Folgenden den Begriff Entwickler) und dem Scrum Master, eine der drei spezifischen Ergebnisverantwortlichkeiten im Scrum-Team, die innerhalb des Scrum Guide von Sutherland und Schwaber beschrieben werden [Schwaber]. Das Scrum-Team als solches ist ergebnisverantwortlich, in jedem Sprint ein wertvolles, nützliches Produktinkrement zu schaffen. Die spezifische Ergebnisverantwortlichkeit des Product Owners dabei ist, dass seine Arbeit dazu dient, den Wert des Produkts unter Berücksichtigung aller Stakeholder-Interessen zu maximieren. Wie genau dies geschieht, kann je nach Kontext unterschiedlich sein und wird im Scrum Guide nicht definiert. Dieses Kapitel gibt das notwendige Hintergrundwissen, was die Herausforderungen bei der Herstellung eines wertvollen Produkts sind.

    2.1Das Produkt, seine Funktionalitäten und die Interessengruppen

    Das Wort Produkt ist ein generalisierender Begriff. Ein Produkt kann ein materielles Gut, eine immaterielle Dienstleistung oder etwas noch Abstrakteres sein. Dabei ist Software in der Regel als immaterielles Gut zu verstehen¹. Ein Produkt im Sinne einer Software – und in diesem Sinn verstehen wir den Begriff im weiteren Verlauf des Buchs – umfasst diverse Funktionalitäten, die idealerweise darauf ausgerichtet sind, für die verschiedenen Interessengruppen eine positive Wirkung und somit einen Wert zu erzeugen.

    Als Interessengruppen oder auch Stakeholder werden alle diejenigen bezeichnet, die ein berechtigtes Interesse (Erwartung, Anspruch, Anteil) an den Wirkungen (dem Ergebnis) eines Produkts haben.

    Stakeholder umfassen die Nutzer und Nutznießer, aber auch andere Interessengruppen wie beispielsweise die Investoren oder Sponsoren eines Produkts oder Menschen, die vom Produkt in irgendeiner Art betroffen sind. Nutzer sind Stakeholder, die das Produkt mit direktem Kontakt nutzen, mit ihm interagieren, es also verwenden. Nutznießer sind Stakeholder, die einen Nutzen aus dem Produkt ziehen, ohne es zu benutzen.

    Ein Produkt erzeugt dann einen möglichst großen Wert, wenn es durch seine Funktionalitäten die Bedürfnisse der verschiedenen Interessengruppen befriedigt oder deren Probleme löst.

    2.2Bedürfnisse befriedigen, Probleme lösen

    Bedürfnisse und Probleme liegen nah beieinander. Als ein Bedürfnis wird in der Psychologie etwas definiert, das als Mangel erlebt wird, den es zu beheben gilt. Probleme sind Hindernisse, die man nicht ignorieren kann. Sie müssen in irgendeiner Weise behandelt werden, sonst wären sie keine Probleme. Wichtig hierbei ist: Bedürfnisse und Probleme sind subjektiv. Sie sind nicht einfach da, sondern äußern sich durch Gefühle von konkreten Personen. Das Erkennen dieser Gefühle kann helfen, den Bedürfnissen und Problemen auf den Grund zu gehen. Das bedeutet auch: Ein Bedürfnis oder ein Problem ohne eine Person, die dieses Bedürfnis oder dieses Problem verspürt, ist keins.

    Gibt’s niemanden, der ein Problem hat, dann gibt’s kein Problem.

    Leider wird oft über Probleme gesprochen, ohne das Subjekt hinter dem Problem zu sehen. Das Problem wird objektiviert. So gibt es technische, prozessuale oder fachliche Probleme. Dies führt zu einer Entpersonalisierung und im Zweifel zu Fehlinterpretationen. Auf Basis dieser Fehlinterpretationen werden dann Entscheidungen zur Problemlösung getroffen, die den Menschen mit seinen Bedürfnissen außen vorlassen und die letztendlich in nichts anderem als schlechten Produkten gipfeln.

    Das bedeutet: Der Product Owner muss möglichst sowohl die Bedürfnisse als auch die Probleme der Interessengruppen aufdecken – den Problemraum erkunden – und potenzielle Ansätze zur Befriedigung der Bedürfnisse sowie Lösungen der Probleme erkennen – den Lösungsraum eröffnen. Bedürfnisse zu erkennen, kann schwierig sein, da sich diese in den wenigsten Fällen gut in Worte fassen lassen. Der Satz »Ich habe das Bedürfnis, dass …« ist seltener zu hören als der Satz »Ich habe das Problem, dass …«. Um zu verdeutlichen, wie Probleme und Bedürfnisse aneinandergekoppelt sind, nehmen wir als Beispiel eine nicht vorhandene Funktionalität, die ein Sachbearbeiter braucht, um seine Aufgabe zu erfüllen: Die Funktionalität muss einen Kunden bei der Abwicklung eines speziellen Schadenfalls unterstützen. Dieser spezielle Fall wird aber leider nicht in der Schadensfall-Software abgedeckt. Der Sachbearbeiter hat also das Problem, den Fall sauber und schnell abzuwickeln. Das bringt er dem Kunden zum Ausdruck, indem er diesem sagt: »Tut mir leid, aber ich habe das Problem, dass ich den Schadensfall nicht so einfach abwickeln kann, weil dieser durch unsere Software nicht abgedeckt ist.« Durch dieses Problem werden Bedürfnisse aufseiten des Endkunden nicht befriedigt. Diese Bedürfnisse sind: die schnelle und sichere Abwicklung des Falls, um nicht noch mehr Ärger zu haben, weniger Zeit investieren zu müssen und den finanziellen Schaden schnell ersetzt zu bekommen.

    Dahinter können weitere Bedürfnisse liegen, wie das Bedürfnis nach finanzieller Sicherheit. Bedürfnis aufseiten des Sachbearbeiters wäre, keinen Konflikt mit dem Endkunden eingehen zu müssen, weil sich die Schadensabwicklung nur manuell lösen lässt und die Endkundenbedürfnisse damit nicht befriedigt werden können.

    Es ist schnell zu erkennen, dass Probleme oft leichter in Worte zu fassen sind als Bedürfnisse. Zusätzlich gibt es für jedes Produkt eine Vielzahl von Interessengruppen und damit verbunden noch mehr Probleme und noch mehr Bedürfnisse. Es ist unmöglich, alle Bedürfnisse zu erkennen. Das Eindringen in die Tiefen der menschlichen Bedürfnisse und das Aufdecken dieser birgt jedoch eine große Kraft, um gute Produkte zu entwickeln. Dabei reicht es oft schon aus, die Bedürfnisse der verschiedenen Interessengruppen auf einer höheren Ebene zu verstehen und den Begriff Bedürfnis als Anspruch, Forderung, Wunsch oder Verlangen zu übersetzen. Also zum Beispiel als etwas, was die Stakeholder dabei unterstützt, die Probleme, die diese zu lösen haben, besser zu lösen.

    Grundsätzlich ist die Grundlage für eine gute Produktentwicklung dann gegeben, wenn die folgenden Fragen zu Bedürfnissen und Problemen konsequent gestellt und beantwortet werden:

    Wer sind die Interessengruppen des Produkts?

    Was ist deren Arbeit, und welche Probleme müssen diese direkt oder indirekt mit dem Produkt lösen?

    Welche Probleme und Bedürfnisse haben die Interessengruppen bei ihrer Arbeit?

    Können die Interessengruppe ihre Probleme und derer Bedürfnisse klar benennen und dadurch explizit machen? Wie finde ich dies heraus?

    Aus diesen Fragen ergeben sich dann die nächsten Schritte auf dem Weg zu einem wertvollen Produkt:

    Welche dieser Probleme sind relevant und müssen gelöst werden?

    Welche dieser Bedürfnisse sind relevant und müssen befriedigt werden?

    Wie können gute Lösungen entdeckt werden?

    Wer kann mir Ideen hierzu liefern?

    Wie kann ich diese Ideen validieren und umsetzen?

    Was liefert wie den größten Wert?

    2.3Der Wert und der Mehrwert

    Der Begriff Wert stammt vom dem althochdeutschen »werd« ab und bedeutet wertvoll, kostbar oder begehrenswert. Häufig wird der Fehler gemacht, Wert mit Geldfluss gleichzusetzen, weil man Geld messen kann. Der Fokus muss aber auf Wert im Sinne der Bedürfnisbefriedigung oder der Problemlösung liegen – auf dem, was wertgeschätzt wird.

    Zur Abgrenzung: Der Begriff Mehrwert bezeichnet die Merkmale eines Produkts, die das Produkt wertvoller als andere Produkte machen und es sowohl unterscheiden als auch attraktiver machen. Mehrwert ist etwas, was mehr ist als das Erwartete. Es geht also in erster Linie darum, für die Problemstellungen der Interessengruppen gute, wertvolle Lösungen zu finden. Daraus ergibt sich für den PO:

    Ziel der Arbeit des Product Owners ist die Wertmaximierung.

    2.4Die Probleme mit komplexen Problemstellungen

    Abb. 2–1Lineares Vorgehen zur Problemlösung

    Damit das Ziel der Wertmaximierung erreicht werden kann, muss als Erstes der Problemraum erkundet werden. Der Knackpunkt dabei ist, dass die dynamischen Probleme mit dem in Deutschland allseits bekannten »German Engineering« und dem damit verbundenen starken Faible für Struktur, Prozesse, Kontrolle und Klarheit oft nicht mehr zu lösen sind. Probleme analytisch angehen, die Lösungsidee sauber konzipieren, dann umsetzen und dabei steuern und überwachen. Das funktioniert nicht mehr, wenn sich sowohl das Problem als auch die Umwelt dynamisch verändern.

    Die heutige Welt ist eben ungewiss, unklar, uneindeutig also komplex. Und oben drauf kommt noch, dass der Mensch und dessen Einflüsse außer Acht gelassen und dadurch Probleme versachlicht werden.

    Ein lineares und sequenzielles Vorgehen simplifiziert die wirkliche Problemstellung und birgt die Gefahr, das Ziel der guten Problemlösung nicht zu erreichen, sondern dauerhaft falsche Lösungswege zu gehen und völlig unnütze Lösungen herzustellen.

    2.4.1Die Aspekte komplexer Problemstellungen

    Es gibt keine eindeutige Definition, was eine komplexe Problemstellung ist. Es gibt aber verschiedene Aspekte, die dazu führen, dass eine Problemstellung komplex ist. Diese Aspekte verhindern, das Problem komplett zu durchdringen oder eine Lösung von vornherein umfassend zu konzipieren. Die Aspekte einer komplexen Problemstellung lassen sich wie folgt zusammenfassen²:

    Komplexe Problemstellungen können mangelnde Probleminformationen, eine hohe Anzahl vernetzter, dynamischer Einflussgrößen sowie vielfältige teils widersprüchliche Ziele haben.

    2.4.2Vielfältige, teils widersprüchliche Ziele

    Abb. 2–2Die Vielzieligkeit: Es gibt viele Lösungsmöglichkeiten.

    Vielfältige, teils widersprüchliche Ziele, die sogenannte Vielzieligkeit, beschreibt die Unklarheit über das zu erreichende Ziel. Dabei geht es immer darum, das Problem durch die Lösung zu beheben und somit das Ziel zu erreichen, einen Nutzen zu erzeugen. Dummerweise können bei komplexen Problemen viele Lösungswege zu verschiedenen Zielen führen. Diese Ziele können sich widersprechen und sind häufig nur schwierig zu beschreiben. So könnte es beispielsweise ein Ziel sein, eine Banking-App benutzerfreundlicher zu machen. Dabei sollen folgende Probleme behoben werden:

    Der Login ist nicht benutzerfreundlich, und der Prozess ist nicht intuitiv. Ziel wäre es, diesen zu vereinfachen und schneller zu machen.

    Der Login kann durch Dritte schnell missbraucht werden. Ziel wäre es, diesen sicherer zu machen.

    Die Ziele der beschriebenen Probleme stehen zwar nicht in Widerspruch zueinander, die denkbare Lösung der Probleme führt aber zu widersprüchlichem Nutzen, denn einen Login abzusichern, bedeutet auch gleichzeitig, ihn langsamer zu machen. Da nicht alle (Lösungs-)Wege gleichzeitig und schnell gegangen werden können, ist eine Priorisierung und somit eine Fokussierung auf diejenige Lösung notwendig, die den größeren Nutzen liefert.

    Die Problematik der Vielzieligkeit wird verstärkt durch den nächsten Aspekt komplexer Problemstellungen: der mangelnden Probleminformation.

    2.4.3Mangelnde Probleminformation

    Abb. 2–3Die weißen Flecken des Problems: Mangelnde Probleminformationen machen eine gute Lösung schwierig.

    Häufig sind die verfügbaren Informationen zu komplexen Problemstellungen unzureichend und führen zu Uninformiertheit. Diese Uninformiertheit kann zu Fehlinterpretationen führen oder dazu verleiten, immer mehr Aufwand in die Analyse der Problemstellung zu stecken. Ersteres birgt im schlimmsten Fall die Gefahr, mit der Problemlösung in eine völlig falsche Richtung zu gehen. Letzteres birgt die Gefahr der Paralyse durch Analyse. Insbesondere wenn die weiteren möglichen Aspekte komplexer Problemstellung einbezogen werden.

    2.4.4Hohe Anzahl vernetzter, dynamischer Einflussgrößen

    Abb. 2–4Hohe Anzahl vernetzter und dynamischer Einflussgrößen als Komplexitätstreiber

    Als wäre es nicht schon schwierig genug, mit den bereits genannten Aspekten komplexer Problemstellungen umzugehen, kommen auch noch die Anzahl der Einflussfaktoren, deren Vernetzung und Dynamik hinzu. Die Einflussfaktoren beziehen sich auf die Problemstellung, die Lösungsfindung und die Lösungsumsetzung. Geringe Veränderungen einer oder mehrerer der Einflussfaktoren können durch ihre Vernetztheit und die damit verbundenen unklaren Zusammenhänge große Auswirkungen auf die Probleme und deren Lösung haben. Wie beim Schmetterlingseffekt kann so aus einem eher unscheinbaren Detail etwas Gewichtiges werden. Dazu kommt noch, dass die Anzahl der Einflussfaktoren oft hoch ist, diese teilweise unbekannt sind und sie sich auch noch fortlaufend ändern. Die hohe Dynamik und die Unfähigkeit, das Zusammenspiel der Einflüsse zu überblicken, machen komplexe Problemstellungen und deren Lösungen unvorhersehbar.

    2.4.5Das Problem der Vorhersehbarkeit

    Abb. 2–5Die wahre Komplexität ist oft nur schwer erkennbar und eine Vorhersehbarkeit

    Gefällt Ihnen die Vorschau?
    Seite 1 von 1