Die drei Stakeholdergruppen eines Systems

Ein Mensch kann einer Software gegenüber drei Rollen einnehmen: Anwender, Entwickler und Domainexperte. Je mehr Rollen eine einzelne Person einnehmen kann, desto leichter und besser verläuft der Entwicklungsprozess. Der Idealfall liegt vor, wenn eine Person eine Software für ihre eigenen Bedürfnisse schreibt.

An der Universität besuchte ich Vorlesungen von PD Dr. Christian Dahme, der sich in seinen Vorlesungen mit tätigkeitstheoretischen Ansätzen und der Interaktion in sozialen Systemen beschäftigte. Zum Anfang des ersten Semesters bei ihm durften wir dann auch seine beiden Bücher kaufen, auf die er als für das Semester wichtig hinwies. Seit dem bin ich im Besitz eines Buches zu HyperCard von Apple und eines Buches zur Systemanalyse menschlichen Handelns. Letzteres ist 2015 aktualisiert bei Spring erschienen. Bei Interesse kann man es sich bei Sprinter Nature in der aktualisierten Ausgabe von 2015 ansehen.

Aus seiner Vorlesung ist mir vor allem sein Rollenmodell im Gedächtnis geblieben, mit dem er uns erläutert hat, welche Rolle ein Mensch gegenüber einem (Software-)System einnehmen kann und wie sich das auf die Wissensverteilung auswirkt. Dieses ist auch heute noch sehr nützlich, um zu verstehen, warum uns manchmal die Entwicklung so leicht von der Hand geht, ein anderes Mal aber ein zähes Ringen um ein gemeinsames Verständnis der Domäne ist.

Dahme hat im Software-Entwicklungsprozess drei Rollen für die Beteiligten gesehen.

Um eine Software zu entwickeln, braucht es alle drei Rollen. Dabei spreche ich hier bewusst von Rollen und nicht von unterschiedlichen Gruppen oder Personen. Denn je mehr Rollen sich in einer Person vereinigen oder von mehreren Personen eingenommen werden können, desto eher verbessert sich das Ergebnis, also die von uns entwickelte Software.

Schauen wir uns die für diese drei Rollen wichtigsten Konstellationen an.

Der Domainuser benötigt für seinen eigenen Einsatzzweck eine Software, die er selber nutzen will. Diese Person vereinigt in sich die Rolle des Anwenders und des Domainexperten. Mittels seines Wissens kann er genau beschreiben, was benötigt wird, und anschließend als Nutzer auch gleich validieren, ob das Geforderte richtig umgesetzt wurde, ob es nützlich ist und welche weiteren Funktionen benötigt werden. Wie effizient die Entwicklung eines Systems erfolgt, hängt in dieser Konstellation im Wesentlichen von dem Austausch zwischen Entwickler und Domainuser und deren Fähigkeiten zur Kommunikation und Zusammenarbeit ab.

Stellt die Vereinigung aller drei Rollen in einer Person die Idealsituation dar, stellt die Verteilung aller drei Rollen auf unterschiedliche Personen die schwierigste Konstellation dar. Der Nutzer des Systems verfügt nicht über das notwendige vollständige Domainwissen, sondern benutzt nur das System für seine Teilaufgaben. Das diese richtig im richtigen Rahmen ausführt, wird durch das System sichergestellt. Der Domainexperte kennt die Domain, doch arbeitet er nicht mit dem System. Der Programmierer ist hier auf die reine Umsetzung beschränkt und kann nur auf dem Wissen des Domainexperten aufbauen.

Das hier von mir beschriebene Modell ist an sich nicht neu. Es findet sich in ähnlicher Form bei Jakob Nielsen für den Bereich Usability Engineering.

Ebenfalls findet es sich beim Participatory Design und Computer-Supported Cooperative Work (CSCW), wobei der Schwerpunkt hierbei vor allem auf der Kooperation zwischen den einzelnen Gruppen, hier Rollen, liegt.

Die Einteilung der Sicht auf ein System in drei Rollen hilft uns einen Faktor zu verstehen, der dazu beiträgt, warum manche Projekte gut laufen und warum bestimmte Produkte besser sind als andere. Je mehr sich diese Rolle nicht auf einzelne Personen konzentriert, je mehr Personen mehr als eine Rolle einnehmen können, desto eher bildet sich ein gemeinsames Verständnis von dem, was zu erreichen ist. Das hilft ein gemeinsames Ziel zu etablieren und zu erreichen. Gleichzeitig sinkt der Aufwand für den Wissenstransfer und die Gefahr von Transferverlusten und Missverständnissen sowie von Konflikten.

Genau davon profitieren maßgeblich viele Open Source-Projekte in ihrer initialen Phase. Sie werden von Menschen begonnen, die die Software schreiben, die sie selber brauchen, um eigene Probleme zu lösen. Und wenn es nicht ein Problem ist, ist es die intrinsische Motivation und Neugier.

Auf der anderen Seite stehen Projekte, bei denen kontinuierlich die Velocity fällt, je größer das Projekt wird, je mehr Personen beteiligt sind, das Wissen diffundiert und die Aufgabenverteilung feiner und separierter wird.

Die Begeisterung vieler Menschen für die Arbeit mit Coding Agents und dem Gefühl, dass auf einmal alles gehen würde, kann nach meiner Ansicht nicht allein damit erklärt werden, dass mittels Coding Agents schneller der erste Prototyp gebaut oder Features für den produktiven Einsatz entwickelt werden können. Self Empowerment at it’s best. SQL, 4GL und Low Code-Plattformen haben das Gleiche versprochen. Es ist die Idealform, in der alle drei Rollen sich vereinen. Es fällt damit der notwendige Aufwand für die Kommunikation und den Wissensaustausch mit anderen weg. Damit fallen wesentliche Aufwandstreiber wie Wissenstransfer und Konfliktlösung weg. Zudem steht über den Coding Agent auch das gesamte Wissen des dahinterstehenden Large Language Models zur Verfügung. Nicht das diese allumfassend und feherfrei wäre, doch groß genug, um viele Fragen beantworten zu könen oder sie erst gar nicht stellen zu müssen, da der Coding Agent das Wissen automatisch einwebt. Diese Medaille hat zwei Seiten. Auf der einen ist es der Idealzustand, in dem wir Systeme schaffen können. Gleichzeitig steigt damit auch das Risiko dafür, dass sich mehr und mehr einzelne Inseln an System bilden, die nur von einzelnen Personen gekannt, verstanden und betrieben werden können. Das ist die andere Seite der Medaille.

In der idealen Konstellation hat jede Rolle sein Verständnis für die Bedürfnisse der jeweiligen anderen Rollen und darüber, welches Wissen sie beisteuern können. Daher gilt es den Austausch und die Zusammenarbeit zwischen den Trägern dieser Rollen zu fördern. Dies wird leider allzuoft nicht getan, weil alle aus falsch verstandenem Effizienzdenken auf ihre jeweilige Rolle beschränkt werden.

Das Grundprinzip hierbei ist immer, dass eine Person eine andere Person mit einer anderen Rolle entweder begleitet oder für eine gewisse Zeit die Aufgaben übernimmt. Und das wiederholt und nicht nur einmalig.

Dafür gibt es zwei einfache Methoden:

Stakeholder werden zu oft vorrangig unter dem Aspekt ihrer Interessen betrachtet. Für eine erfolgreiche Produkt- und Software-Entwicklung ist die kooperative Frage danach, wer über welches Wissen verfügt und wie dieses geteilt werden kann, wichtiger. Ein wichtiger Aspekt dabei ist der Wille und die Fähigkeit zu Kooperation, Kommunikation und Externalisierung von Wissen. Inwieweit sich der Einsatz von LLMs und Coding Agents auf die Rollenverteilung auswirken wird, kann ich jetzt nicht sagen. Es könnte sein, dass bei einer konsequenten Externalisierung aller beteiligten Stakeholders die Trennung in Rollen bei der Umsetzung keine Rolle mehr spielt. Wir werden es erleben. 🖖🏻