Die fünf wichtigsten Erkenntnisse aus der Softwareentwicklung, die ich als Product Owner anwende.
Seit einigen Jahren arbeite ich in der Rolle des Product Owners und helfe Softwareentwicklungsteams bei Ihrer Arbeit. Der Product Owner hat das Ziel, den Kunden- oder Usernutzen der zu entwickelnden Software zu maximieren. Ok - das heißt also, man sollte als Product Owner (kurz PO) die Kunden oder User und deren Ziele bzw. Verhalten sehr gut kennen. Dazu kommt dann noch, dass man eine bestimmte Tätigkeit des Nutzers unterstützt (schneller, einfacher, weniger Fehler) oder aber sogar neue Möglichkeiten schafft. Dadurch schafft es das Produkt einen Nutzen zu stiften.
So weit, so gut - jetzt kann man sich also als PO auf die den Kunden und den Nutzenmaximierung zurückziehen. Dem stimme ich zu. Das funktioniert ganz gut, wenn man sich darauf fokussiert. Da gibt es aber noch mehr, was man tun kann. Und dabei geht es mir um die Frage des “wie”. Als Product Owner kann ich mit Verständnis für das Handwerk der Softwareentwicklung meine Arbeit nochmal ein ganzes Stück verbessern. Daher möchte ich gern die fünf wichtigsten Erkenntnisse aus der Softwareentwicklung mit euch teilen. Bevor ich als Product Owner tätig wurde, habe ich selbst über einige Jahre Software entwickelt und tue das auch immer noch im Rahmen kleinerer Projekte. Aus diesen Erfahrungen entnehme ich die folgenden Dinge, die ein PO beim Entwickeln von Software lernen kann. Probiert es doch selbst mal aus und entwickelt ein kleines Projekt. Ihr werdet sehen, es bringt euch ein ganzes Stück weiter.
Zunächst mal hier die kurze Erklärung zu den Begriffen “Happy Path” und “Edge Cases”. Auf dem Happy Path bewegt sich ein User oder Entwickler, wenn er genau das tut, was eine Software von ihm erwartet. Wenn der User zum Beispiel beim Anlegen eines Profils eine existierende E-Mail-Adresse angibt und es seine Wohnanschrift tatsächlich gibt. Sobald man den Namen der Stadt in das Feld für die Postleitzahl schreibt oder die E-Mail-Adresse keine Bestätigungsmails empfangen kann, verlässt man den Happy Path. Man hat es mit Fällen zu tun, die nicht dem erwarteten Verhalten entsprechen - den “Edge Cases”.
Was kann man hier also als Product Owner lernen? Sicher wurdet ihr schon mal von einer Entwicklerin gefragt, was eigentlich passieren soll, wenn […] passiert oder wenn der User […] eingibt. Was hier passiert, ist das die Entwicklerin über Edge Cases nachdenkt. Der wichtige Punkt, den es hier zu verstehen gilt, ist, dass es sehr, sehr viele Edge Cases geben kann. Und selbst die Entwicklerin, die darüber nachdenkt, hat oft nicht alle möglichen Fälle im Kopf (mehr dazu weiter unten).
Wenn du mal selbst entwickelt hast, wird es dir leichter fallen an mögliche Edge Cases zu denken. Das erspart dir als Product Owner viel Zeit und Ärger. So kannst du zum Beispiel von mit Usern oder Stakeholder über Edge Cases diskutieren, bevor die eigentliche Implementierung anfängt. So lassen sich von Anfang an größere Nacharbeiten oder manchmal auch Bugs vermeiden. Hier im Folgenden mal einige Beispiele von Edge Cases, die mir als sowohl als Product Owner als auch als Entwickler über den Weg gelaufen sind:
All die Beispiele oben machen klar, was du hier tun solltest. Du solltest probieren, so viele Fälle - die Edge Cases - wie möglich zu antizipieren. Das heißt aber nicht, dass jeder Edge Case vorhergesehen werden kann. Du kannst die aber darauf einstellen, dass du im Lebenszyklus deiner Software mehr Fälle entdecken wirst. Ebenso gehört es für mich zu dem probaten Mittel zum Umgang mit Edge Cases, einige davon einfach zu ignorieren. Sollte das Verhältnis von Aufwand (zum Behandeln der Fälle) zum Nutzen stark im Ungleichgewicht stehen, kann man diese Fälle auch einfach unbehandelt auftreten lassen.
Einer meiner ehemaligen Kollegen pflegte zu sagen “Naming is haaard”. Er warf das immer ein, wenn wir mal wieder einige Minuten über die Benennung einer Variable oder Funktion diskutiert hatten. Zunächst mal - ja, passende Benennungen zu finden ist sehr schwierig. Nun kann man natürlich fragen, ob es sich lohnt mehrere Minuten damit zu verbringen? Ich finde, das ist es wert. Das liegt für mich darin begründet, dass Benennungen ganz viel Information beinhalten und bei den Rezipienten bestimmte Assoziationen auslösen. Ich werde da im folgenden anhand von zwei Beispielen verdeutlichen. Es wird bei den Beispielen klar, dass man auch als Product Owner Wert darauf legen sollte, wie man bestimmte Dinge benennt.
Greifen wir wieder auf ein ähnliches Beispiel zurück wie oben - die Registrierung bei einem Online Service wie zum Beispiel einem eCommerce Shop. Damit ist wohl jede Leserin vertraut. Als Product Owner möchtest du ein Feature entwickeln, welches überprüfen soll, ob die eingeebnet Email-Adresse korrekt ist und sie tatsächlich dem sich registrierenden User gehört. Dazu solle eine Email versendet werden, die einen Link enthält. Nur der rechtmäßige Empfänger der Email kann diesen Link klicken und damit seine Registrierung abschließen.
Nun habe ich erlebt, dass diese beschriebene E-Mail als “Approval”-E-Mail bezeichnet wurde. Als Product Owner weißt, du natürlich, was gemeint ist: Der User “stimmt der Registrierung zu”. Wenn dir dieser Gedankengang aber nicht geläufig ist, denkst du als Softwareentwickler eher, dass eine dritte Person der Registrierung zustimmen muss (“approven”). Und schon ist es geschehen - die Implementierung wird vermutlich anders ausfallen, als du es als Product Owner erwarten würdest.
Ein weiteres anschauliches Beispiel aus der Praxis ist die “Komponente”. Als Product Owner nutzen viele das Tool Jira. In Jira gibt es Komponenten. Das sind logische Container für mehrere User Stories, die einen Bezug zueinander haben und vielleicht auch gemeinsam deployed/released (mehr dazu unten) werden. Nun stell dir vor, dass dir eine Frontend-Entwicklerin gegenübersitzt, die viel mit dem Framework React entwickelt. Für sie ist eine Komponente ein wiederverwendbares Stück Code, das einen Teil der Fronteid-Anwendung darstellt. Die Verwirrung ist hier quasi “vorprogrammiert” 🤪.
Ich arbeite an dieser Stelle überwiegend mit Beispielen. Sobald ich einen Begriff nenne, der mehrdeutig sein könnte, füge ich Beispiele an. Das hilft, Verwirrungen vorzubeugen und ein gemeinsames Verständnis von Begriffen und Benennungen zu erzeugen. Wenn es gar nicht anders geht, kann man sich auch explizit auf eine neue Benennung von Dingen einigen. Dabei ist nicht die Benennung an sich das wichtig, sondern der Umstand, dass man diese gemeinsam findet.
Der Begriff “Deployment” wird in der täglichen Arbeit als Product Owner oft verwendet. Trotzdem ist oft nicht ganz klar, was ein Deployment eigentlich ist. Dabei hilft es enorm zu verstehen, wie ein Deployment eigentlich vonstattengeht und wie man es gut (stressfrei für Entwickler und fehlerfrei für User) hinbekommt.
Zunächst mal ist ein Deployment der Vorgang, wie neuer oder geänderter Code, dem bestehenden Code bzw. der in Betrieb befindlichen Software hinzugefügt wird. Am Ende des Vorgangs befindet sich der neue/geänderte Code in Betrieb - kann also von den Usern genutzt werden. Dabei kann in unterschiedliche Umgebungen (oder Environments) deployed werden. Das bedeutet in der Praxis meist, dass Änderungen an einer Umgebung zum Testen (mit beschränktem Zugriff) vorgenommen werden, bevor sie in die Umgebung eingespielt werden, die von Kunden oder Usern benutzt werden (oft “live”, “prod” oder “production”).
Streng genommen müsste ich hier noch zwischen Release und Deployment unterscheiden. Dabei würde ich das Deployment als den technischen Vorgang und das Release als einen bestimmten Versionsstand (als Ergebnis eines Deployments) einer Software bezeichnen. Im Rahmen dieser Artikel benutze ich die beiden Begriffe allerdings synonym und meine mit Deployment auch das Release.
Als Product Owner nehme ich oft eine bestimmte Haltung gegenüber Deployments wahr. Diese kann von Zurückhaltung oder sogar Angst vor Deployments bis hin zu einem sehr untergeordneten Stellenwert reichen. Das liegt meiner Meinung nach an zwei Kennzahlen - der Häufigkeit von Deployments sowie dem Grad der Automatisierung (beinhaltet auch Testabdeckung). Dabei können wenig automatisierte Deployment lange dauern, kompliziert sein und sind oft mit Fehlern verbunden. Mit steigender Automatisierung können Deployments auch in höherer Frequenz durchgeführt werden. Das führt dazu, dass Deployments keine “große Sache” mehr sind und an Stellenwert verlieren. Durch die höhere Frequenz tritt auch mehr Übung ein und die Anzahl der Fehler sinkt.
Deployments sind ein sehr technisches Thema, das sich auch in verschiedensten Ausprägungen und Arbeitsabläufen widerspiegelt. Einer der bekanntesten Workflows ist der Git Workflow. Falls es dich interessiert, kannst du dich auf der Website von Jira genauer darüber informieren. Darauf einzugehen, würde den Rahmen dieses Artikels sprengen.
Neben der Klärung der Begriffe möchte ich dir aus meiner Praxis als Product Owner noch einige Learnings bezüglich Deployments mitgeben.
Bereits in der Einleitung habe ich beschrieben, dass ich es als Product Owner als meine Aufgabe ansehe, den Nutzen der Software zu maximieren. Es sollte also selbstverständlich sein, dass ich als Product Owner ein klares Bild von Nutzen eines Features oder einer Änderung habe. Insofern scheint der nächste Hinweis vielleicht banal zu sein, allerdings muss ich mich auch selbst oft daran erinnern.
Du solltest den Nutzen und damit die Begründung, warum eine bestimmte Änderung vorgenommen oder ein bestimmtes Feature entwickelt werden soll, auch dein Entwicklungsteam kommunizieren. In vielen Fällen mündet der, von dir angestrebte Nutzen, in einer Reihe von Akzeptanzkriterien in einer User Story. Du nimmst damit quasi das Nachdenken über die Lösung vorweg.
Aus eigener Erfahrung als Softwareentwickler kann ich allerdings berichten, dass man als Entwickler vermutlich noch viel mehr über ein bestimmtes Feature nachdenkt, als der Product Owner. Das folgt allein schon daraus, dass man (meistens) viel mehr Zeit mit der Entwicklung verbringt als mit dem Entwurf des Features. Dabei denkst du als Entwickler auch über die ganzen Edge Cases (siehe oben) nach. Du beschäftigst dich also zwangsläufig sehr viel mit der Änderung oder dem Feature.
Ich denke also, dass es hier als Product Owner sehr wertvoll ist, das “Warum” für eine Änderung klarzumachen. Natürlich kannst und solltest du dir schon Gedanken über eine mögliche Lösung machen. Allerdings solltest du nicht die Kreativität und den Einfallsreichtum von Softwareentwicklern unterschätzen. Nur wenn diese die Hintergründe deiner User Story kennen, können sie - oftmals sehr gute - eigene Lösungsvorschläge mit einbringen. Das führt nicht nur zu besseren Umsetzungen, sondern auch ganz nebenbei zum mehr Wertschätzung und Teilnahme der Softwareentwickler.
Viele Softwareentwickler kennen die Situation: Der Product Owner kommt mit einer neuen User Story um die Ecke und möchte gern eine Schätzung haben. Ich habe als Softwareentwicklung immer dann nur widerwillig eine Schätzung abgegeben, wenn ich das Gefühl hatte nach eine Dauer gefragt zu werden. Aus der Sicht eines Product Owners kann ich die Frage nach der Planbarkeit (und der Schätzung als Mittel dazu) sehr gut nachvollziehen. Dies kommt oft daher, dass man als Product Owner von seinen Stakeholdern nach Zeitpunkten gefragt wird oder es andere Deadlines wie zum Beispiel ein ablaufendes Supportdatum gibt.
Nichtsdestotrotz, möchte ich dafür plädieren, die Schätzung als Product Owner eher als eine Einschätzung über Komplexität einer Anforderung anzusehen. Daraus folgt leider nicht die Dauer, die es benötigt, die Anforderung umzusetzen. Mit dieser Diskrepanz muss man als Product Owner umgehen können. Dazu ist mein Rat, eine offene und transparente Kommunikation gegenüber alles zu betreiben, die einen nach Zeitpunkten fragen. Aber warum dauert es denn nun eigentlich immer länger?
Aus meiner Erfahrung sowohl als Entwickler als auch als Product Owner möchte ich hier drei große Gründe erwähnen - Komplexität, Unwissenheit und Abhängigkeiten.
Bei der Softwareentwicklung bewegen wir uns in einem sehr komplexen Umfeld aus Libraries, Netzen, Verbindungen, Usern, Stakeholder, rechtlichen Gegebenheiten und vielen mehr. Oft wissen wir bedauerlicherweise einfach nicht, was passiert, wenn wir eine Änderung vornehmen. Am einen Tag kann aus A → B folgen und am nächsten Tag folgt aus A → C. Da sich das Umfeld ständig verändert, ist es oft schwer die Folgen vorherzusehen. So kann sich zum Beispiel eine Library (Code von dritten Parteien) ändern, ohne dass wir einen Einfluss darauf haben. Wir müssen darauf reagieren - das verlängert zum Beispiel Entwicklungszeiten, wenn es zwischen der Schätzung und der eigentlichen Umsetzung passiert.
Ebenso kann es vorkommen, dass wir diese Art von Veränderungen gar nicht vorher kennen. Bei der Verwendung von mehreren Dutzend oder sogar mehreren Hunderten an Libraries ist es fast unmöglich den Überblick über Änderungen zu behalten. So kann es gut sein, dass wir bei der Schätzung gar nichts von möglichen, für die Schätzung wichtigen, Aspekten wissen. We don’t know - es klingt banal, ist aber oft der Fall. Daran ist aus meiner Sicht weder der Product Owner noch eine Softwareentwicklerin Schuld. Das Umfeld ist zu komplex als dass man vollständige Informationen haben könnte.
Darüber hinaus gibt es nicht nur technische Abhängigkeiten (z.B. Libraries), sondern auch Abhängigkeiten zu anderen Menschen oder Teams. So kann es sein, dass organisatorische Prozesse oder das Warten auf Zuarbeiten von anderen Teams die Entwicklung verlangsamen. Hier gilt es für mich als Product Owner, diese Abhängigkeiten im Blick zu haben und sie mit gutem Management zu minimieren.
Der wichtigste Punkt bei der Arbeit mit Schätzungen ist für mich als Product Owner das Verständnis darüber, was sie aussagen oder bewirken können. Ich empfehle sie nicht, als Mittel zu nutzen, eine bestimmte Dauer oder Fertigstellung abzuschätzen. Vielmehr empfinde ich Schätzung im Rahmen eines Regiments beispielsweise als gutes Mittel, um Verständnis zu fördern. Wenn man im Team schätzt, ergeben sich unterschiedliche Einschätzungen über die Komplexität. Die anschließende Diskussion darüber fördert meist neue Aspekte zutage, die eine Stories wiederum besser einschätzbar machen.
Ich hoffe dir in diesem kurzen Artikel vermitteln zu können, dass es sich lohnt mal selbst in die Softwareentwicklung einzusteigen. Dabei reicht oft schon ein Miniprojekt oder eine “Praktikum”, um wichtige Erfahrungen zu sammeln. Diese helfen dir dann wiederum bei deiner täglichen Arbeit als Product Owner.
Erzähle uns in einem kostenlosen Erstgespräch mehr über dein individuelles Projekt. Wir helfen dir bei den nächsten Schritten und teilen unser Wissen.
Nachricht schreiben