Schlagwort-Archive: product

Domain Driven Design (PO-Tools Nr.2)

Hier die Fortsetzung meines Beitrags zu Product Owner Tools.

Domain Driven Design

Für die Modellierung des Produkts bedienen wir uns verschiedener Methoden aus dem Domain Driven Design (DDD), insbesondere Context Maps und Event Storming Workshops:

Context Map

Context Maps können helfen um Rahmenbedingungen zu definieren und/oder zu visualisieren.

In Zusammenarbeit mit dem Entwicklerteam und Domänen Experten modelliert man den Produktkontext und die Schnittstellen zu angrenzenden Bereichen, also welche Fachdomänen von dem Produkt berührt werden und welche nicht.

ddd1

Event Storming Workshop

Eine Methode zum Ermitteln und Validieren der Kontextgrenzen ist Event Storming: In einem gemeinsamen Brainstorming erschließen sich Entwickler und Fachexperten die Domäne und bringen sich gegenseitig auf ein gemeinsames Verständnis.

Dies sind die grundlegenden Schritte zu dem Vorgehen:

Die richtigen Leute einladen.

Idealerweise benutzt man einen großen Meetingraum mit sechs bis acht Leuten. Es sollten die Personen anwesend sein, die die richtigen Fragen stellen können, in der Regel sind das die Entwickler. Sowie die Personen, die die Antworten dazu haben, die Domänenexperten.

eventstorming

Keine Limitierung

Wenn man eine Domäne noch nicht kennt, kann man auch nicht wissen wieviel Platz man braucht um sie zu modellieren. Deswegen sollte man den Platz nicht begrenzen. Idealerweise bereitet man die Wände des gesamten Raums mit einer Papierrolle vor.

Entdecke die Domäne anhand von Events (Ereignissen).

Events werden immer in der Vergangenheitsform aufgeschrieben. Man verwendet orangene Stickies für die Events und ordnet diese in einer zeitlichen Abfolge. Der Workshop startet mit der Frage an die Domainexperten: “Was ist das für euch wichtigste Event”. Der erste orangene Sticky wird in die Mitte der Wand geklebt. Dann geht es weiter mit der Frage: “Was passiert davor” und “Was passiert danach” usw.

Entdecke die Auslöser von Events

Was muss passieren, damit ein Event eintritt. Manche Events werden durch eine Aktion ausgelöst (Commands). Für Commands werden blaue Stickies verwendet.

Events können durch externe Systeme oder andere Events ausgelöst werden. Für externe Systeme werden pinke Stickies verwendet. Die Auslöser von Events werden an das Event selber geklebt.

Entdecke Aggregate und ordne das Chaos

Hier geht es nicht um Aggregate im technischen Sinne. Es geht darum zusammengehörige Events in Clustern zusammenzufassen. Beispielsweise könnten alle Events die den Shop betreffen zum Aggregat Shop zusammengefasst werden. Aggregate selber können Commands entgegen nehmen und Ereignisse auslösen.

Entdecke Subdomains

Im letzten Schritt werden Aggregate zu Subdomains zusammengefasst. Hier wird ermittelt für welchen Bereich des Prozesses welche Fachexperten zuständig sind. Ausgehend von den Subdomains können dann die Kontextgrenzen und Kontextzusammenhänge definiert werden.

Fortsetzung HIER

gregor Gregor Meyenberg ist Product Owner bei Goodgame Studios

Advertisements

Product Owner Tools – Teil 1

von Gregor Meyenberg

Der Gedanke, dass ich als Produkt Owner meine eigenen Produktideen verwirklichen kann war für mich stets verlockend. Nach einigen Jahren weiß ich aber, dass die Realität der Arbeitswelt meist anders aussieht. In sehr vielen Fällen muss ich die Idee eines anderen übernehmen, mich selbst dafür begeistern, um dann wiederum andere von der Idee begeistern zu können und schließlich das Produkt effizient in die Umsetzung bringen.

Damit das gelingt, ist es wichtig die Intention des geplanten Produktes im Detail zu durchdringen. Wir stellen hier ein paar Tools vor, die sich für Product Owner bei Goodgame Studios (GGS) im Alltag bewährt haben.

Rahmenbedingungen

Bei GGS gibt es verschiedene zentrale Abteilungen, die für die Game-Studios und andere zentrale Bereiche Produkte liefert (Shop, Landing Pages etc.). Sich veränderndende Produktwünsche und -prioritäten sind eine ständige Herausforderung. Anstatt für jedes Produkt ein neues Team aufzusetzen geben wir neue Produkte an bestehende Teams. So verhindern wir einen ständigen Neustart des Tuckman Cycle (Forming – Storming – Norming – Performing).

Der Auftrag

Eine Fachabteilung tritt mit einer neuen Produktidee in der Regel an den Product Owner heran, den sie bereits kennt. Um ein Gefühl für die Priorität zu bekommen, versuchen wir initial den erwarteten Business Value abzuschätzen (Revenue Uplift, Steigerung der Registrierungen, Erhöhung der Retention etc.).

Geht es um ein größere Produktidee entscheiden die Product Owner des Bereichs gemeinsam, welche Teams für die Entwicklung in Frage kommen. Die Entscheidung basiert immer auf dem Wert des neuen Produktes in Relation zu dem Wert der Lieferung, die ein Product Owner bereits in seiner Roadmap geplant hat.

Jeder Product Owner in dessen Team eine Umsetzung  des neuen Produktes Sinn ergibt, liefert drei mögliche Umsetzungsoptionen, legt die jeweiligen Auswirkungen anhand seiner Roadmap dar und listet Vor- und Nachteile für das Unternehmen in einer knappen Zusammenfassung.

Die Gruppe der Product Owner aggregiert die besten Optionen und stimmt sie (bei besonders großem Impact) mit dem Management ab. Dazu betrachten wir insbesondere den “Cost of Delay”. Nach der Entscheidung für eine Option geht der Arbeitsauftrag ins Backlog des gewählten Teams.

Story Mapping

Damit Entwickler, Product Owner und Stakeholder ein gemeinsames Verständnis der Produktidee entwickeln, hilft es gemeinsam die “Geschichte” zum Produkt zu erarbeiten. Gerade zu Beginn eines Projektes führen wir dazu gerne Story Mapping Workshops durch.

Das Big Picture und die Projektziele sollten für alle Beteiligten gut sichtbar gemacht werden, z.B. mit einer Product Wall.

storymap

Der “User” sollte immer im Vordergrund stehen. Letztendlich ergibt sich die Daseinsberechtigung der Software daraus, dass sie für jemanden von Nutzen ist.

Insofern kann man sich als Product Owner die zentrale Frage stellen, wessen Leben man zum Positiven verändern will und warum?

Daraus ergibt sich dann der Business Case.

Produktvision

Die Produkt-Vision ist ein Steuerungs-Werkzeug für die Produktentwicklung. Sie ermöglicht es allen Projektbeteiligten immer wieder zu validieren, ob die geplante Arbeit auf die Vision einzahlt.

emails

Produkt-Vision neben dem Team-Taskboard

Eine gute Vision wird oft in intensiven Gesprächen mit den Stakeholdern erarbeitet, z.B. im Zusammenhang mit oben genanntem Story Mapping Workshop. In seinem Management3.0-Buch listet Jurgen Appelo hilfreiche Qualitätskriterien für eine Vision auf:

criteria.jpg

Zudem orientieren wir uns an den zahlreichen Templates für Product Visionen, wie dem Business Model Canvas oder Roman Pichlers Product Vision Board.

Am Ende sollten sich alle Beteiligten auf die Vision committen, von der Geschäftsleitung bis zum Entwicklungsteam.

Fortsetzung HIER.

gregor Gregor Meyenberg ist Product Owner bei Goodgame Studios