|
Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+: www.dpunkt.plus |
Effektives Stakeholder-Management
für Product Owner
Aus dem Niederländischen von Rolf Dräther
Robbin Schuurman · rschuurman@xebia.com
Willem Vermaak · wvermaak@xebia.com
Lektorat: Christa Preisendanz
Übersetzung: Rolf Dräther, www.happycentric.de
Copy-Editing: Ursula Zimpfer, Herrenberg
Satz & Layout: Birgit Bäuerlein
Herstellung: Stefanie Weidner
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN:
Print 978-3-86490-740-1
PDF 978-3-96910-060-8
ePub 978-3-96910-061-5
mobi 978-3-96910-062-2
1. Auflage 2021
Translation Copyright für die deutschsprachige Ausgabe © 2021
dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Autorisierte Übersetzung der niederländischen Originalausgabe mit dem Titel »50 Tinten Nee – Effectief stakeholdermanagement voor de Product Owner« von Robbin Schuurman and Willem Vermaak. ISBN 978-9024427079.
Copyright © 2019 Boom uitgevers Amsterdam & Robbin Schuurman en Willem Vermaak.
Hinweis:
Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.
Schreiben Sie uns:
Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: hallo@dpunkt.de.
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag noch Übersetzer können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
»Ja zu sagen ist einfach, doch Nein zu sagen
erfordert wirklich Mut.«1
– Anonym –
Die Vielzahl der Wünsche, die Geschwindigkeit der Veränderung und die Agilität von Organisationen werden für viele Produktverantwortliche zur Herausforderung. Dadurch nimmt das Bedürfnis enorm zu, sich für die Dinge zu entscheiden, die wirklich wichtig sind. In der Produktentwicklung ebenso wie in anderen Arbeitsbereichen, ja sogar zu Hause oder im Vereinsleben ist die Versuchung groß, all den Wünschen von außen nachzugeben. So haben manche Eltern kaum noch Zeit für sich selbst, weil sie ihre Kinder von einem Hobby zum nächsten fahren – mit einer Flexibilität, um die sie manches Taxiunternehmen beneiden würde. Das führt eher zu Stress und Hektik als zu Selbstentfaltung und dazu, wirklich für seine Umgebung präsent zu sein.
Die Inspiration zum [niederländischen] Buchtitel stammt von Rini van Solingen – vielen Dank dafür. Dieser Titel mag Sie vielleicht in die Irre führen, er scheint das Neinsagen in den Mittelpunkt zu rücken. Doch im Gegenteil: Die Essenz dieses Buches ist es, Ja zu sagen. Ja zu sagen zu den Dingen, die wirklich wichtig sind. Ja zu sagen zu etwas, das vielleicht dringend, aber vor allem wertvoll ist – auf kurze wie auf lange Sicht! Und das, ohne sich von Nebensächlichkeiten oder zukünftigen Anforderungen vereinnahmen zu lassen. Denn wie wollen Sie einer Vision folgen, wenn Sie ständig zu kleinen und weniger wichtigen Dingen Ja sagen!
Robbin und Willem werden Sie dabei unterstützen. Denn das können sie wirklich! Neben ihrer Erfahrung in der Produktentwicklung, den vielen Trainings, die sie gegeben haben, und den Organisationen, die sie begleitet haben, trifft man in diesem Buch auf ihren unverwechselbaren Stil und ihre Persönlichkeit – auf die Geduld und den Sachverstand von Robbin ebenso wie die Scharfsinnigkeit und den Humor von Willem, kombiniert mit einer Vielzahl von praktischen Tools und Neins. Gemeinsam haben sie ein hilfreiches und praktisches Handbuch für den Product Owner geschaffen. Dieses Buch unterstützt Sie beim effektiven Stakeholder-Management und stärkt Ihnen den Rücken, sodass Sie zu den Dingen Ja sagen können, die Ihnen wichtig sind.
In diesem Buch geht es ums Jasagen. Der Inhalt dieses Buches hilft Ihnen, mit mehr Empathie und mehr Klarheit mit Ihren Stakeholdern zu kommunizieren – eine Kombination, die für Product Owner Gold wert ist. Es kommt also darauf an, sich auf die wirklich wichtigen Dinge zu konzentrieren. Deshalb habe ich sofort und aus vollem Herzen Ja gesagt, als Robbin und Willem mich baten, das Geleitwort zu diesem Buch zu schreiben!
Euch beiden vielen Dank, dass ihr dieses praktische Handbuch geschrieben habt. Ihnen als Leser wünsche ich viel Freude und Erfolg bei der Umsetzung der Tipps aus diesem Buch.
Rob van Lanen
Management Coach/Change Agent
Einleitung
1Der Product Owner
Projektmanagement oder Produktmanagement?
Der Product Owner
Das Mandat des Product Owners
Product-Owner-Typen
Der Schreiber
Der Stellvertreter
Der Business-Repräsentant
Der Sponsor
Der Entrepreneur
Mit Verantwortung und Mandat wachsen
2Stakeholder-Management
Was sind Stakeholder?
Stakeholder-Typen
Interessen und Einfluss
Interessen der Stakeholder
Einfluss der Stakeholder
Stakeholder-Map
Stakeholder mit geringem Interesse und wenig Einfluss
Stakeholder mit geringem Interesse und viel Einfluss
Stakeholder mit großem Interesse und wenig Einfluss
Stakeholder mit großem Interesse und viel Einfluss
Wie viel Zeit widmen Sie Ihren Stakeholdern?
3Nein sagen
Einleitung
Was geschieht, wenn Sie Nein sagen?
Was macht Nein sagen so schwer?
Wie sagt man effektiv Nein?
Schritt 1:Wer – Zu wem werden Sie Nein sagen?
Schritt 2:Was – Was ist die Frage des Stakeholders?
Schritt 3:Intention – Was ist Ihre Intention? Werden Sie Ja oder Nein sagen?
Schritt 4:Nein sagen – Was ist das richtige Nein für diese Situation?
Schritt 5:Zuhören – Hat der andere verstanden? Wie reagiert Ihr Gegenüber?
4Die 50 Facetten von Nein
Einleitung … ehe Sie die Neins nutzen
Die neun Kategorien des Neinsagens
1 –Das deutliche Nein
Einleitung
Für welche Stakeholder nutzen Sie dieses Nein?
Sieben Formen dieser Kategorie Nein
2 –Das Nein aus Sicht des Kunden/Anwenders
Einleitung
Für welche Stakeholder nutzen Sie dieses Nein?
Sieben Formen dieser Kategorie Nein
3 –Das Nein aus Sicht des Wertes
Einleitung
Für welche Stakeholder nutzen Sie dieses Nein?
Sieben Formen dieser Kategorie Nein
4 –Das Nein aus Sicht des Budgets
Einleitung
Für welche Stakeholder nutzen Sie dieses Nein?
Sieben Formen dieser Kategorie Nein
5 –Das Nein aus Sicht des Timings
Einleitung
Für welche Stakeholder nutzen Sie dieses Nein?
Sieben Formen dieser Kategorie Nein
6 –Das Nein aus Sicht der Auswirkung auf das Umfeld
Einleitung
Für welche Stakeholder nutzen Sie dieses Nein?
Sieben Formen dieser Kategorie Nein
7 –Das Nein aus Sicht der Qualität
Einleitung
Für welche Stakeholder nutzen Sie dieses Nein?
Sieben Formen dieser Kategorie Nein
8 –Das Nein, wenn alle anderen Neins nicht (mehr)funktionieren
Einleitung
Für welche Stakeholder nutzen Sie dieses Nein?
Das Nein, wenn alle anderen Neins nicht (mehr) funktionieren
9 –Bonus! Die Neins, um Ihr Mandat zu erweitern
Einleitung
Für welche Stakeholder nutzen Sie dieses Nein?
Sieben Formen dieser Kategorie Nein
Anhang
Zusammenfassung
Alle 50 Arten Nein im Überblick
Ihre eigenen Neins
Leere Stakeholder-Map
Beispiel einer Stakeholder-Map
Glossar
Danksagung
Über die Autoren
Über den Übersetzer
»Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.«
– Agiles Manifest, 10. Prinzip –
Stress, Stress, Stress! Das ist eine der häufigsten Antworten, wenn man Menschen fragt, wie es ihnen geht. Man rennt von einem Meeting zum anderen. Zwischendurch muss man schnell telefonieren, fix einen Kaffee holen und dann weiter zum nächsten Meeting. Es gibt unheimlich viel zu tun, doch es ist zu wenig Zeit, um alles schaffen zu können. Das bedeutet, man muss Entscheidungen treffen. Und aufgrund der wachsenden Komplexität muss man sich nicht nur immer häufiger, sondern auch immer schneller entscheiden.
Abb. 1Der agile Regenschirm
Viele Organisationen haben in den vergangenen Jahren eine »agile« Arbeitsweise eingeführt, um mit der wachsenden Komplexität umgehen zu können. In diesen agilen Organisationen strebt man nach Flexibilität, Wertmaximierung und Fokussierung auf den Kunden. Agilität kann man als ein alles überspannendes Gedankengut betrachten. Es besteht aus vier Werten und zwölf Prinzipien, die man unter www.agilemanifesto.org finden kann. Dieses agile Gedankengut wird innerhalb verschiedener »Frameworks« umgesetzt. Das Scrum-Framework ist eines davon.
Daneben existiert noch eine Reihe von »Praktiken«, die innerhalb agiler Organisationen zum Einsatz kommen. Dabei handelt es sich um weitere Tools und Ansätze, die zwar von den Teams eingesetzt, von den Frameworks oder dem agilen Gedankengut jedoch nicht gefordert werden. Das Verhältnis zwischen Agilität, dem Scrum-Framework und den weiterführenden Praktiken zeigt Abbildung 1. Innerhalb des Scrum-Frameworks wird die Rolle des »Product Owners« benannt. Viele Unternehmen beschäftigen derzeit Product Owner, um die Agilität zu erhöhen, Wert zu maximieren und mehr Fokussierung rund um ihre Kunden zu erreichen. Diese Product Owner spielen eine entscheidende Rolle bei der (Weiter-)Entwicklung von (neuen) Produkten und Dienstleistungen. Ihre größte Verantwortung ist, »den Wert des Produktes zu maximieren«. Product Owner treffen laufend Entscheidungen. Sie wägen ab, was das Nächstwichtige und Wertvollste für die Umsetzung ist. Sich ständig entscheiden zu müssen, bedeutet auch, regelmäßig Nein zu sagen.
In vielen Unternehmen gibt es mehr Wünsche, Anforderungen und Anfragen, als Kapazität verfügbar ist, um all diese Arbeit zu erledigen. Vom Markt, durch staatliche Stellen, Konkurrenten und aus der eigenen Organisation wird zudem Einfluss geltend gemacht, um Veränderungen herbeizuführen. Diese Faktoren beeinflussen die Produkte und Dienstleistungen des Unternehmens. Darüber hinaus müssen Unternehmen entscheiden, in welche ihrer Produkte sie investieren wollen. Häufig wird dabei eine gute Balance zwischen Innovation, Erweiterung, Wartung und Architektur angestrebt. All das wirkt sich auf die Produkte und Dienstleistungen aus, die Sie liefern, und deshalb ist es unumgänglich, Entscheidungen zu treffen. Als Product Owner spielen Sie bei diesen Entscheidungsprozessen eine Schlüsselrolle.
Wenn Sie häufiger Nein sagen, werden Sie auch bewusster Ja sagen, dann aber vorrangig zu den »richtigen Dingen«. Vielleicht sind die wichtigsten Dinge in Ihrem Kontext vor allem durch Gesetzgebung und Regularien bestimmt und somit entscheidend für den Fortbestand des Produkts. Doch das Ziel bleibt natürlich, dass es Dinge sind, die für die Organisation oder den Kunden wirklich Wert hinzufügen. Indem Sie Nein sagen, schaffen Sie Raum, um zu wirklich wichtigen und wertvollen Dingen Ja sagen zu können. Das bereitet Ihnen selbst vielleicht etwas mehr Freude und damit auch der Organisation, den Kunden und den Anwendern! Wie das Zitat vor dieser Einleitung bereits sagt: »Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.«
Nein sagen ist nicht immer einfach. Nein sagen funktioniert nicht immer auf dieselbe Weise. Und Nein sagen ist auch nicht immer möglich. Deshalb haben wir das Buch 50 Arten, Nein zu sagen geschrieben. Dieses Buch unterstützt Sie bei einem effektiveren Stakeholder-Management. Es stellt keine Anleitung dar, um in jeder nur denkbaren Lebenssituation Nein sagen zu können, und richtet sich vorrangig an Product Owner und Produktmanager.
Dieses Buch will Sie beim Stakeholder-Management unterstützen, denn Stakeholder-Management ist ein schwieriges »Spiel«. Um dieses Spiel gut zu spielen, ist es entscheidend, erfolgreich Nein sagen zu können. Dazu reicht es nicht aus, lediglich Nein zu sagen. Kennen Sie beispielsweise die Bedürfnisse Ihrer Stakeholder? Kennen Sie die Kräfteverhältnisse innerhalb und außerhalb der Organisation? Und – wie viel dürfen Sie eigentlich selbst entscheiden? Ziel dieses Buches ist es, Sie auf praktische Weise dabei zu unterstützen, ein effektives Stakeholder-Management zu etablieren. Zusätzlich erhalten Sie eine Reihe von Tipps, um Ihr Mandat zu erweitern. So lernen Sie, auf eine effektive Weise Nein zu sagen.
Dieses Buch unterstützt Sie beim erfolgreichen Neinsagen. Es geht nicht darum, dass Sie nach der Lektüre dieses Buches zu allen Anfragen Ihrer Stakeholder nur noch Nein sagen. Auch »ja«, »vielleicht« oder »darüber sollten wir erst noch einmal nachdenken« werden Sie weiterhin nutzen. Ein guter Product Owner weiß, was er weiß, aber auch, was er nicht weiß. Das bekannte Zitat »Seek first to understand, then to be understood«1 ist für einen Product Owner äußerst wichtig. Sagen Sie zu den richtigen Dingen Nein, nachdem Sie Ihre Stakeholder verstanden haben. Und sagen Sie zu den richtigen Dingen Ja, nachdem Sie Ihre Stakeholder genau verstanden haben. Sorgen Sie dafür, dass Ihnen das »Was« und »Wozu« klar ist, ehe Sie Entscheidungen treffen. Und machen Sie sich das Wissen der Menschen in Ihrem Umfeld zunutze. Lassen Sie sich gut von ihnen informieren und treffen Sie erst dann die richtigen, falschen oder überaus wichtigen Entscheidungen. Ja sagen ist deshalb ebenso wertvoll wie Nein sagen, auch wenn der Fokus dieses Buches vornehmlich auf dem Neinsagen liegt.
Das Buch umfasst vier Kapitel und Sie können es auf Ihre eigene Weise lesen. Sie können das Buch einfach von vorn nach hinten lesen, aber auch mit anderen Kapiteln beginnen. Wollen Sie mehr über Konzepte rund um Produktentwicklung, die Product-Owner-Rolle und deren Verantwortlichkeiten wissen, dann sollten Sie mit Kapitel 1 beginnen. Wenn Sie mehr über Stakeholder-Management und verschiedene Typen von Stakeholdern erfahren wollen, dann steigen Sie bei Kapitel 2 ein. Sie wollen etwas über das Konzept des Neinsagens lernen und wissen, weshalb das für Sie wichtig ist und wie Sie es am besten anpacken? Dann lesen Sie Kapitel 3. Vielleicht wollen Sie aber auch direkt in die 50 Facetten von Nein eintauchen und mit ihnen loslegen? Dann ist Kapitel 4 der richtige Einstiegspunkt. Am Ende des Buches finden Sie eine Zusammenfassung und eine Reihe von Anlagen, zum Beispiel eine komplette Übersicht über alle 50 Arten, Nein zu sagen, und eine Vorlage für eine Stakeholder-Map.
Wir wünschen Ihnen viel Freude beim Lesen des Buches und natürlich viel Erfolg beim Anwenden der 50 Arten von Nein in der Praxis!
»Der Product Owner ist dafür verantwortlich, den Wert des Produktes zu maximieren, das aus der Arbeit des Development-Teams entsteht.«
Scrum Guide – Ken Schwaber und Jeff Sutherland –
Arbeiten Sie (als Product Owner) in einer Projekt(management)-Organisation oder in einer Produkt(management)-Organisation? Die Antwort auf diese Frage ist für Sie von Bedeutung, um Ihre Product-Owner-Rolle (oder Funktion) effektiv auszufüllen. In vielen Organisationen ist die Rolle (oder Funktion) des Product Owners relativ neu. Sie wird oft mit der Rolle eines Projektmanagers verglichen. Dieser Vergleich ist unpassend, weil zwischen einem Product Owner und einem Projektmanager deutliche Unterschiede bestehen.
Viele Organisationen sind auf die Durchführung von Projekten ausgerichtet. Sie bauen eine zeitlich begrenzte Organisation auf, um damit innerhalb einer bestimmten Zeit und eines bestimmten Budgets einen vorab festgelegten Funktionsumfang an die Linienorganisation zu liefern. Umfang, Zeit und Budget sind dann häufig auch die Metriken, mit denen ein Projekt gesteuert und an denen sein Erfolg gemessen wird. Das Fatale daran ist, dass innerhalb einer Projektorganisation das Liefern eines bestimmten Funktionsumfangs innerhalb von Zeit und Budget oft viel wichtiger ist als die Produktnutzung, die Kundenzufriedenheit und die Time-to-Learn (also die eher marktorientierten Facetten, die viel mehr über den Wert des Produkts aussagen).
Abb. 1–1Projektmanagement versus Produktmanagement
Abbildung 1–1 zeigt, wie sich der Fokus einer Projektorganisation (steuern nach Zeit und Budget) von dem einer Produktorganisation (steuern nach Wert/Umfang) unterscheidet. Bei der Projektorganisation steht der Umfang fest, während Zeit und Budget flexibel sind (denken Sie an das Verschieben von Projekt-Deadlines oder das Hinzufügen neuer Mitarbeiter zu Projekten). Die Qualität wird dabei (implizit und manchmal auch unbewusst) verhandelbar. In der Produktorganisation sind Zeit und Budget fix. Das wird durch die Arbeit mit festen, stabilen Teams in kurzen Iterationen (Sprints) erreicht. Die Qualität wird durch die sogenannte Definition of Done sichergestellt, die für jedes gelieferte Item eingehalten wird. Und was geliefert wird, ist in einer Produktorganisation flexibel. Der Umfang steht also noch nicht fest. Der Erfolg der Produktorganisation wird über den gesamten Entwicklungszeitraum kontinuierlich auf der Basis von Feedback von Kunden, von Anwendern und aus der Organisation gemessen. In einem solchen Prozess ist eine Steuerung nach Produktnutzung, Kundenzufriedenheit und Time-to-Learn dann auch wertvoller als das Steuern auf Basis von Umfang, Zeit und Budget.
Ein Product Owner kann seine Wirksamkeit am besten in einer Produktorganisation entfalten, denn ein Product Owner ähnelt eher einem »Produktmanager« als einem »Projektmanager«. Sowohl Product Owner als auch Produktmanager beschäftigen sich mit Dingen wie Produktvision, Strategie, Stakeholder-Management und Produkt-Roadmap. Ein Produktmanager arbeitet häufig mit anderen Abteilungen zusammen, denen die Umsetzung der Anforderungen übertragen wurde. Ein Product Owner hingegen ist Teil eines oder mehrerer cross-funktionaler Scrum-Teams und maximiert aktiv den Wert des Produkts. Der Product Owner kann so tatsächlich Entscheidungen über den Einsatz des Entwicklungsteams treffen. Man könnte auch sagen, dass das Produktmanagement eher einen Funktionsbereich darstellt, während Product Owner eine Rolle ist.
Denkanstöße …
Man kann beobachten, dass sich viele (Projektmanagement-)Organisationen hin zu Produktorganisationen wandeln. Arbeiten Sie derzeit noch in einer Projektorganisation? Dann denken Sie doch einmal über mögliche Schritte nach, mit denen Sie die Transformation zu einer Produktorganisation gestalten können. Orientieren Sie sich dabei an John Kotters »8-Stufen-Modell«. Einige Fragen, über die es sich nachzudenken lohnt, sind:
