Ich denke dabei an die Produktivität der Entwickler.

Die Produktivität von Entwicklern ist derzeit ein heißes Thema. Es ist ein Thema, das viele verschiedene Ideen, Ansätze, Perspektiven und Forschungen inspiriert: McKinsey, Antwort an McKinsey, RAUM, DevEx, Google. Eine Schlussfolgerung, auf die wir uns wahrscheinlich alle einigen können, ist, dass die Modellierung der Entwicklerproduktivität schwierig ist.

Vor einiger Zeit hat der Podcast Planet Money erstellt ein Folge in der sie mehreren prominenten Ökonomen die Frage "Was ist die nützlichste Idee in der Wirtschaft?" stellten und fünf verschiedene Antworten erhielten. Können wir diese fünf Ideen als Linse verwenden, durch die wir die Entwicklerproduktivität betrachten können? Werden sie uns helfen, die Modellierung der Entwicklerproduktivität zu verbessern? Lassen Sie uns das untersuchen.

Wenn ich über Softwareentwicklungsaktivitäten und ihre Opportunitätskosten nachdenke, denke ich an die Entscheidungen, die wir auf Produktebene treffen. Ein Entwicklungsteam kann in Bezug auf den Output sehr produktiv sein, z. B. indem es schnell mehrere Funktionen liefert. Aber wie wertvoll sind diese Aktivitäten? Hätte man die Zeit, die für diese Aktivitäten aufgewendet wird, auch für die Entwicklung wertvollerer Funktionen verwenden können, um ein nützlicheres Produktziel zu erreichen? Wenn wir versuchen, die Produktivität der Entwickler zu modellieren, sollten wir dann auch die Effizienz des Produktmanagements berücksichtigen?

Wenn wir die Produktivität von Entwicklern anhand des Outputs modellieren, können wir natürlich nicht viel über den Wert der Arbeit aussagen. Selbst wenn wir einen Anstieg des Outputs feststellen, bedeutet das nicht, dass auch der Wert steigt. Die Verwendung von Messungen der Ergebnisse auf Produktebene in unserem Produktivitätsmodell ist eine Verbesserung und kann relative Veränderungen der Ergebnisse im Laufe der Zeit aufzeigen. Aber sollten wir unserem Modell eine weitere Dimension hinzufügen, um die Ergebnisse mit dem Ergebnispotenzial zu verrechnen?

Vor kurzem habe ich das Buch"Tidy First?" von Kent Beck gelesen, das ich sehr empfehlen kann. In dem Buch werden die wirtschaftlichen Aspekte des Aufräumens von Code ausführlich erörtert. Wenn es um die Randanalyse geht, musste ich an eine bestimmte Frage denken, die Beck stellt:

"Wie viel Aufräumarbeit müssen Sie leisten? Das heißt, wenn wir 'Aufräumen' als strukturelle Veränderungen definieren, die die nächste Verhaltensänderung unterstützen, wie viele strukturelle Veränderungen müssen Sie dann vornehmen, um die nächste Verhaltensänderung zu unterstützen?" [1]

Meiner Erfahrung nach kommt es nur allzu häufig vor, dass Entwicklerteams ihre Aufräumarbeiten vernachlässigen, was sich in immer längeren Zykluszeiten für die Entwicklung von Funktionen niederschlägt und die Teams dazu zwingt, große und riskante Refactorings zu planen. Wenn wir versuchen, die Produktivität von Entwicklern zu modellieren, wie können wir dann die inkrementellen Entscheidungen berücksichtigen, die Verhaltensänderungen mit strukturellen Änderungen unterstützen? Sollten wir die Fähigkeit der Entwicklungsorganisation einbeziehen, die Kosten für Verhaltensänderungen zu stabilisieren und sie mit den Kosten für strukturelle Änderungen in Verbindung zu bringen? Aber wie gut können wir zwischen den beiden Arten von Änderungen unterscheiden?

Betrachten wir die ranghöchste Person in einem Entwicklungsteam, d.h. die Person mit dem größten Wissen und der größten Erfahrung bei der Arbeit an der Software. Was die messbaren Ergebnisse angeht, so sind die Senior-Mitarbeiter vielleicht am effektivsten, wenn sie die Entwicklung von Funktionen selbst abschließen. Sie sind aber auch am besten geeignet, um das Team zu leiten, indem sie z.B. Junioren als Mentoren zur Seite stehen und neue Mitarbeiter an Bord holen. Die durchschnittliche Effektivität eines Teammitglieds kann höher sein, wenn die erfahreneren Mitarbeiter sich die Zeit nehmen, ihre Teammitglieder zu unterstützen, anstatt sich nur auf ihren eigenen Output zu konzentrieren.

Wie können wir in unserem Modell der Entwicklerproduktivität die Verteilung von Wissen und Erfahrung in einem Team oder einer Organisation berücksichtigen? Sollten wir die Beherrschung als eine Dimension der Entwicklerproduktivität neben den Produktergebnissen in unser Modell aufnehmen? Wie verhalten sich die verschiedenen Dimensionen in unserem Modell zueinander oder wie lassen sie sich miteinander vergleichen? Führt eine Steigerung der Beherrschung, also des gesamten Wissens- und Erfahrungsstands eines Teams, zu einer Steigerung der Produktergebnisse?

In einer Softwareentwicklungsorganisation ändern sich die Aktivitäten ständig. Einige manuelle Aufgaben werden automatisiert. GenAI-Tools liefern sofortiges Feedback. Niedriger Code ersetzt manchen Code. Diese Veränderungen wirken sich auf die Produktivität aus, wie auch immer wir sie modelliert haben. Ein Rückgang der Aktivitäten kann lokalisiert sein, wenn sich die Aktivitäten in einem Bereich ändern oder ganz verschwinden. Dieser örtlich begrenzte Rückgang bedeutet nicht, dass die Mitarbeiter schlechtere Arbeit leisten. Er kann bedeuten, dass sich die Art ihrer Arbeit ändert und dass sie Zeit brauchen, um sich weiterzuentwickeln.

Können wir die Produktivität von Entwicklern mit genügend Kontext modellieren, um nicht die falschen Schlussfolgerungen zu ziehen? Sollte ein Modell eine Dimension enthalten, die zeigt, wie sehr sich ein Team oder eine Organisation im Wandel befindet? Sollte die Anpassung an den Wandel selbst Teil unseres Modells für die Entwicklerproduktivität sein?

Softwareentwicklungsunternehmen sind komplexe Systeme. Es gibt mehrere Beispiele von Unternehmen, die viele Daten sammeln, um eine Vorstellung davon zu bekommen, wie ein solches System funktioniert, wie z.B. Googles"Project Aristotle". Und wir können aus solchen Untersuchungen wertvolle Erkenntnisse gewinnen. Allerdings gibt es keine randomisierten oder natürlichen Experimente, die eine Art von Kausalität nachweisen könnten.

Welches Modell für die Entwicklerproduktivität wir auch immer wählen, wir müssen uns darüber im Klaren sein, dass wir nicht Ursache und Wirkung modellieren. Unser Modell und die Daten, die wir sammeln, um es abzufragen, können uns Einblicke geben und Korrelationen aufzeigen. Es kann uns dazu veranlassen, bestimmte Experimente durchzuführen und die Auswirkungen zu beobachten. Es kann uns auf Bereiche hinweisen, die problematisch sein könnten und weiter erforscht werden müssen. Es kann nicht zeigen uns einen genauen Grund für ein bestimmtes Ergebnis.

 

Bei der Modellierung eines beliebigen Problemraums erinnere ich mich an die Bedeutung des Wortes model mit Worten von Eric Evans:

"Ein Modell ist eine Vereinfachung. Es ist eine Interpretation der Realität, die von den Aspekten abstrahiert, die für die Lösung des vorliegenden Problems relevant sind, und die überflüssige Details ignoriert." [2]

Welches Problem versuchen Sie mit Ihrem Modell für die Produktivität von Entwicklern zu lösen?

Zitate

• [1]: Beck, K. (2023). Zuerst aufräumen? "O'Reilly Media, Inc." (S. 43)
• [2]: Evans, E. (2004). Domain-Driven Design: Tackling Complexity in the Heart of Software "Addison-Wesley" (S. 2)
• Alle anderen Zitate stammen aus der NPR-Folge Planet Money "13.000 Ökonomen. 1 Frage. ", veröffentlicht am 10. Januar 2020.

  Dieser Blog ist Teil unserer Serie " Ganzheitliche Horizonte ". Sehen Sie sich den vorherigen Eintrag an - "Value Stream Mapping für früheres Vertrauen" von Lennart Tange.