In vielen Softwareteams läuft die Entwicklung wie geschmiert. Entwicklerinnen und Entwickler sammeln Anforderungen, setzen Features um, schließen Sprints ab und liefern Releases aus. Es wird gebaut, getestet, deployt, immer und immer wieder. Und doch bleibt häufig ein diffuses Gefühl zurück. Warum diese Arbeit, warum der ganze Code? Selbst wenn man mit KI-Unterstützung noch schneller mehr Code erzeugen kann, heißt das noch lange nicht, dass am Ende viel Wert entsteht.

Darin liegt das Problem, das viele Produktteams haben: Der Fokus liegt auf Output. Die Teams setzen mehr und mehr Features um und messen den Fortschritt anhand der erledigten Arbeit. Produkte sammeln immer mehr Funktionalität an und wachsen kontinuierlich. Viele Produktverantwortliche glauben, dass das nötig ist, um sich vom Wettbewerb zu differenzieren und bestehenden Nutzerinnen und Nutzern ständig etwas Neues zu bieten. Dabei ist nicht immer „mehr“ die Lösung, sondern manchmal sogar ein Problem. Je mehr Features das Produkt umfasst, umso mehr Arbeit muss in Bugfixing und Wartung fließen. Und genau hier setzt der Gedanke an, sich mehr auf Outcome statt Output zu konzentrieren.

Output ist nicht gleich Wert

Wo liegt der Unterschied zwischen Output und Outcome? Output beschreibt, was produziert wird. Outcome ist das, was das Produzierte bewirkt. Jede Funktion, jede neue Dokumentation, jeder neue Test ist erst einmal nur Output. Je mehr ein Team davon liefert, desto „produktiver“ ist es. Dabei bleibt zunächst unklar, was sich durch den erzeugten Output verändert. Was wird sich für Nutzerinnen und Nutzer ändern?

Zum Beispiel hat ein Onlineshop mit häufig wiederkehrenden Einkäufen (etwa für den Wocheneinkauf oder die Bestellung bei der Lieblingspizzeria) eine Funktion, die User beim Einkauf daran erinnern soll, dass sie ein oft gekauftes Produkt diesmal vergessen haben (zum Beispiel „Du nimmst normalerweise Pizzabrötchen dazu. Hast du sie vielleicht vergessen?“). Das Feature für diese Erinnerung ist erst einmal nur der Output. Wenn Kundinnen und Kunden das Feature aber nutzen und es dafür sorgt, dass sie mehr einkaufen, ist das der Outcome. In anderen Kontexten kann das dann auch eine schnellere Einarbeitung, glücklichere Kunden oder Ähnliches bedeuten. Outcome ist aber am Ende immer die Antwort auf die Frage, was sich durch den Output verbessern soll.

Das Konzept von Outcome und Output bei einem komplexen Produkt lässt sich gut am Beispiel des Essens für eine Feierlichkeit verdeutlichen. Jedes einzelne Gericht, jeder Dip, jede Soße und jede Beilage ist Output. Misst man den Erfolg der eigenen Arbeit an Output, so geht es in erster Linie darum, dass möglichst viel Essen auf dem Tisch steht. Geht es aber um Outcome, dann sind die Freude beim Essen, das Lächeln der Gäste und das Genießen des Essens von Bedeutung. Man geht demnach anders an die Arbeit, wenn man sich andere Fragen stellt. Braucht es möglichst viel Essen oder geht es darum, die Personen kulinarisch zufrieden zu stellen? Geht es um schlichte Sättigung oder um Begeisterung beim Essen? Bezogen auf Software: Nutzerinnen und Nutzer freuen sich nicht über zusätzliche Features an sich. Vielmehr freuen sie sich darüber, wenn sie ein Problem einfacher lösen, eine Arbeit schneller durchführen oder eine Funktion leichter bedienen können.

Output-Orientierung lässt sich in vielen Produktteams beobachten. Sie streben dann oft danach, die Arbeitszeit von Entwicklerinnen und Entwicklern maximal auszulasten. Eine hohe Anzahl an Arbeitsergebnissen erzeugt das Gefühl von Produktivität. Langfristig führt das aber nicht nur zu Produkten mit begrenzter Wirkung, sondern auch zu Frustration im Team. Gerade Developer erleben häufig, dass sie technisch anspruchsvolle Lösungen umsetzen, ohne zu wissen, ob diese überhaupt sinnvoll sind.

Outcome ist auch Entwickleraufgabe

Jetzt kann man es sich relativ einfach machen. Die Entscheidung, was gebaut wird, liegt häufig beim Produktmanagement oder der Konzeption. Als Entwicklerin oder Entwickler muss man „nur noch“ die Anforderungen umsetzen beziehungsweise in Code konvertieren. Dieses Übersetzen setzt jedoch einiges an Expertise voraus, denn gute Software zu bauen ist alles andere als trivial. Aber sich auf die Umsetzung von Features zurückzuziehen, entbindet Entwickler nicht von der Verantwortung, sich um die eigene Wirksamkeit zu kümmern. Sich nur als Umsetzende zu sehen, ist zu kurz gedacht, denn gerade Entwicklerinnen und Entwickler sitzen an zentraler Stelle. Sie übersetzen Ideen in Realität, treffen dabei aber wichtige Architekturentscheidungen und kennen die technischen Möglichkeiten und Grenzen am besten. Wenn sie in diesem Prozess Fragen zum angestrebten Outcome stellen, hilft Ihr Wissen dabei, gute Lösungen zu finden, statt nur Anforderungen umzusetzen.

Der stärkste Hebel sind die richtigen Fragen

Developer müssen aber nun keine neuen Rollen übernehmen. Häufig hilft es schon, an den richtigen Punkten die richtigen Fragen zu stellen (siehe Textkasten). Insbesondere in Terminen, in denen es um Anforderungen geht, entstehen oft wertvolle Diskussionen und somit auch Gelegenheiten, den Grund (den gewünschten Outcome) eines Features zu erfragen und durch das Gespräch gegebenenfalls den Fokus der Entwicklung zu verschieben. Warum soll das jeweilige Feature gebaut werden? Warum benötigen die User das Feature? Woran erkennt man hinterher, dass es sich gelohnt hat, das Feature zu entwickeln?

Natürlich ist es für diejenigen, die die Anforderungen stellen, einfacher, direkt eine bestimmte Funktion zu bestellen. Aber es ist überraschend, wie oft sich auch diese Menschen noch nicht so richtig Gedanken dazu gemacht haben, warum die Welt dieses Feature benötigt und welche Wirkung es eigentlich genau erzielen soll.

Sicherlich sollte jemand aus dem Produktmanagement oder anderen Bereichen die obigen Fragen beantworten können, aber zwei wichtige Aspekte darf man dabei nicht vergessen. Zum einen arbeiten auch dort nur Menschen. Vielleicht finden sie die Idee für das Feature einfach spannend oder haben einfach Lust darauf, es im Produkt zu sehen. Welche Wirkung es bei den Usern auslöst, wurde vielleicht nicht bedacht. Zum anderen passiert es jeder und jedem hin und wieder einmal, dass man sich sehr in einer Lösungsidee verfängt und aus den Augen verliert, dass die gleiche Wirkung auch auf einem anderen Weg erreichbar wäre.

Entwicklerinnen und Entwickler haben als vollwertige Teammitglieder auch die Aufgabe, dafür zu sorgen, die richtigen Dinge zu tun. Manche Teammitglieder wollen aber nicht als Widerstand empfunden werden. Vor allem wer noch nicht viel Arbeitserfahrung hat, stellt mitunter die eigene Perspektive hinten an und geht davon aus, dass der Rest schon wissen wird, warum es sinnvoll ist, das Feature zu bauen. Aber Fragen bremsen nicht, sie schärfen. Sie helfen Teams, bewusster Entscheidungen zu treffen.

Outcome in der täglichen Arbeit verankern

Eine verstärkte Outcome-Orientierung darf aber nicht vom Engagement einzelner Teammitglieder abhängen. Sie muss vielmehr Teil der Arbeitsroutine werden, und auch dazu gibt es wirksame Hebel. Einige Produktteams nutzen beispielsweise eine Definition of Ready (DoR), die beschreibt, welche Eigenschaften erfüllt sein müssen, damit eine Anforderung umgesetzt werden kann. Eine DoR kann dann unter anderem aufführen, dass bestimmte Fragen zum angestrebten Outcome beantwortet sein müssen. Zu diesen Fragen gehören beispielsweise die im Textkasten genannten. Durch die Einbindung solcher Fragen in die DoR müssen einzelne Entwicklerinnen und Entwickler nicht mehr jedes Mal nachfragen und gefühlt stören, sondern ein Team verpflichtet sich als Ganzes dazu, die Fragen abzuarbeiten. Wenn beim Überprüfen der DoR unklar ist, wofür eine Anforderung umgesetzt werden soll oder woran Erfolg erkennbar sein soll, ist es sinnvoll, die Umsetzung zu verschieben und erst einmal das angestrebte Ziel oder die angestrebte Wirkung zu klären.