- Häufige Fehler bei der Messung der Produktivität von Entwicklern
- Probleme bei der Messung des Inputs
- Sich auf Inputs oder Aufwand wie „Arbeitszeit“ zu stützen, fördert falsches Verhalten
- Wenn zum Beispiel eine Unternehmenskultur die vor dem Bildschirm verbrachte Zeit wertschätzt und belohnt, können Entwickler viel Zeit darauf verwenden, ohne dass die Qualität der Arbeit gewährleistet ist
- In härteren Umgebungen kann das zu einem Wettbewerb darum verkommen, „am frühesten zu kommen und am spätesten zu gehen“
- Probleme bei der Messung von Ergebnissen
- Zu dieser Kategorie gehören einige der schlechtesten Metriken, etwa die Anzahl der Codezeilen oder Commits
- Entwickler können sehr schnell große Mengen an Code schreiben, daher ist es leicht, das zu messen
- Alle Ergebniskennzahlen müssen im jeweiligen Kontext verstanden werden
- Probleme bei der Messung von Ergebnissen und Wirkung
- Die Herausforderung bei diesen beiden Metriken besteht darin zu verstehen, „wie viel Verantwortung das DevOps-Team trägt“
- Wenn man den Anstieg des Geschäftserlöses misst, ist es unmöglich, ihn allein den Entwicklern zuzuschreiben
12 Kommentare
Ganz schön heftig. Ich glaube, die Perspektive von Managern und die der Leute in der Praxis unterscheiden sich wahrscheinlich,,
Das scheint genau der Teil zu sein, für den ein LLM gebraucht wird.
Da es im Artikel keine Alternative gibt, wird die beabsichtigte Aussage teilweise verwässert. Ich stimme der Behauptung zu, dass die Menge der Outputs aus der Ergebnismessung ausgeschlossen werden sollte, kann aber nicht zustimmen, dass die Arbeitszeit bei der Messung des Inputs vollständig ausgeklammert werden sollte, weil das nicht zur Realität passt. Wie auch immer: Während Wissensarbeit geleistet wird, vergeht Zeit, daher sollte Zeit meiner Meinung nach bei Entscheidungen unbedingt berücksichtigt werden.
Ich denke, es ist leichter verständlich und effizienter, die Produktivität von Entwickler:innen zu diskutieren, nachdem man zunächst einen Frühindikator wie
Gesamtfortschritt = (Anzahl erfüllter Anforderungen / Arbeitszeit)gemessen hat.In letzter Zeit betrachte ich solche Artikel eher kritisch, weil ich denke, dass die Schlussfolgerung, zu der Menschen nach der Lektüre solcher Texte am Ende kommen, darin besteht, überhaupt kein Management zu betreiben. Egal, mit welcher Kennzahl man steuert, am Ende gibt es ähnliche Probleme. Außerdem entstehen Nebenwirkungen, wenn man irgendeine Kennzahl dazu nutzt, Menschen oder Teams gegeneinander antreten zu lassen oder miteinander zu vergleichen. Deshalb sollte man nicht nur mit einer einzigen Kennzahl steuern, sondern mehrere sich ergänzende Kennzahlen gemeinsam betrachten, und ich denke, man sollte Kennzahlen so einsetzen, dass sie dem Team helfen, sich selbst zu verbessern.
Wie wäre es, wenn man nach der Anzahl von PRs misst, die in sinnvollen Einheiten eingereicht werden?
Tatsächlich gibt es hierzulande sogar einen großen Konzern, der Leistung anhand der Anzahl geschriebener Codezeilen misst, seufz
Haha, das habe ich auch schon gesehen.
Da wurden ständig Commits hochgeladen, in denen nur Variablennamen geändert wurden .. hehe
Dann scheint es wohl ein Umfeld zu sein, in dem keine Code-Reviews stattfinden?
Haha, auch Code-Reviewer müssen Code-Reviews bekommen.
Die helfen sich da gegenseitig aus..
Hahahaha, ach du meine Güte...
Hallo, Hölle Welt ;)
Ist das etwa diese berühmte Produktivitätsmessung anhand von LOC? krass