Entwicklerproduktivität – wie man sie misst

Menschen sind von Natur aus kognitive Geizhalse und neigen dazu, komplexe Probleme auf einfachste Weise und mit dem geringsten Aufwand zu lösen. Auf diese Weise haben wir die „Entwicklerproduktivität“ mit der einfachsten verfügbaren Methode gemessen.

Was fällt Ihnen als Erstes ein, wenn Sie „Entwicklerproduktivität“ hören?

Ich wette, das ist negativ und es besteht kein Zweifel daran, dass dies in Entwicklungsteams fast ein Tabu ist, da Führungskräfte oft befürchten, dass das Team durch das Reden über dieses Problem den Eindruck erweckt, dass es ihnen an Mikromanagement mangelt oder es ihnen an Vertrauen mangelt. Zwei Gründe:

1. Die Art und Weise, wie Entwickler produktiv sind, wird von technischen Führungskräften und wie wir es nennen, missbraucht.

2. „Entwicklerproduktivität“ ist keine Formel und wir gedeihen nicht in Unsicherheit, also entscheiden wir uns dafür, entweder den einfachsten Weg zu gehen oder uns davon fernzuhalten.

Denken Sie mal darüber nach: Jedes Jahr werden Milliarden von Dollar für Entwicklungsteams ausgegeben. Wenn es eine einheitliche Methode zur Messung der Entwicklerproduktivität gäbe, wäre das immer noch ein Rätsel? Oder lesen Sie diesen Blog?

PS: Wenn Sie diesen Blog mit der Absicht lesen, Ihre produktivsten Entwickler zu messen oder eine Zahl zu erhalten, die Ihnen hilft, Entwickler zu fördern und zu entlassen, wenden Sie sich ab, denn Sie werden enttäuscht sein.

Sollten wir also versuchen, die Entwicklerproduktivität zu messen?

Ja, das stimmt! ! Denn bei der Entwicklerproduktivität geht es nicht nur um die Verbesserung der Entwicklungsergebnisse, sondern auch darum, die Zufriedenheit und das Wohlbefinden des Teams sicherzustellen. Produktivitätskennzahlen helfen häufig auch dabei, Engpässe im Entwicklungsprozess und Herausforderungen in der Arbeitsumgebung und -kultur des Teams zu erkennen.

Phil Jackson, einer der erfolgreichsten Basketballtrainer, hat es wunderbar ausgedrückt:

„Die Stärke jedes einzelnen Mitglieds ist die Stärke des Teams.“ – Phil· Jackson

In Im Kontext eines Entwicklungsteams hängt der Erfolg jedes Teams davon ab, dass jeder Entwickler sein Bestes gibt und kontinuierlich zum Erfolg des Teams beiträgt.

Okay, wie soll ich nun die Entwicklerproduktivität messen?

Zwei Grundpfeiler zur Maximierung Ihrer Erfolgschancen bei der Messung der Entwicklerproduktivität.

1. Reduzieren Sie die Produktivität niemals auf eine einzige Kennzahl

Die Messung der Entwicklerproduktivität ist schwierig, da wir versuchen, Menschen zu messen, die sowohl an logischen als auch an kreativen Aufgaben beteiligt sind. Und wir als kognitive Geizhals versuchen, die Produktivität auf eine Metrik zu reduzieren – lassen Sie mich klarstellen, dass dieses Modell scheitern wird.

Versuchen Sie stattdessen, die Produktivität über mehrere Dimensionen hinweg zu erfassen und nutzen Sie etwas wie das SPACE-Framework (S-Satisfaction and Happiness, P-Performance, A-Activity, C-Communication and Collaboration, E-Efficiency and Process), das Entwicklerteams bei der Messung unterstützen kann Entwicklerproduktivität auf die richtige Art und Weise steigern.

2. Kommunizieren Sie mit dem Team

Es gibt ein sehr häufiges Missverständnis: Entwicklerproduktivität ist nur für Manager geeignet. Das könnte nicht weiter von der Wahrheit entfernt sein. Untersuchungen zeigen, dass es erhebliche Unterschiede zwischen der Wahrnehmung der Entwicklerproduktivität durch Entwickler und Manager gibt. Die meisten Entwickler assoziieren höhere Produktivität mit höherer Aktivität, während die meisten Manager Produktivität mit Leistung und Effizienz assoziieren.

Diese große Wahrnehmungslücke kann nur geschlossen werden, wenn Entwicklungsteams darüber kommunizieren, was Produktivität für sie bedeutet und was ihre wahren Absichten bei der Produktivitätsverfolgung sind. Dies hilft zu klären, warum dies wichtig ist und wie wir es messen sollten, und beseitigt auch die Vorbehalte, die die meisten Entwicklungsteams haben. Ist diese Zahl ausschlaggebend für unsere Bewertung? Oder tun wir das, weil die Führung nicht glaubt, dass wir die Aufgabe bewältigen können?

Was zu tun ist

1. Verwenden Sie das SPACE-Framework, um die Entwicklerproduktivität über mehrere Dimensionen hinweg zu verfolgen.
2. Teilen Sie Ihre Absichten dem gesamten Team mit.
3. Verwenden Sie Produktivitätskennzahlen, um Bereiche mit Verbesserungspotenzial zu identifizieren und Engpässe zu beseitigen.

Was Sie nicht tun sollten

1. Reduzieren Sie die Produktivität auf eine einzige Kennzahl.
2. Entwickeln Sie geheime Maßnahmen zur Überwachung der Produktivität.
3. Verwenden Sie Metriken als einzige Metrik, um Ihre Bewertung zu bestimmen.

Kennzahlen zur Entwicklerproduktivität

Schauen wir uns nun einige Kennzahlen zur Entwicklerproduktivität an, die über räumliche Dimensionen hinweg verfolgt werden.

Kennzahlen zur Entwicklerproduktivität:

Zufriedenheit und Glück

Ein hochzufriedenes Team ist ein hochproduktives Team. Dies ist einer der größten Indikatoren für eine gesunde Team- und Arbeitskultur. Zufriedenheit ist jedoch ein abstraktes Konzept, und wenn Sie jemand fragt: „Wie zufrieden sind Sie?“, vergessen Sie die Messung. Ich bin mir sicher, dass Sie vor der Beantwortung dieser Frage einige Minuten darüber nachdenken werden, was Zufriedenheit für Sie bedeutet und wie Sie diese quantifizieren können. Wir wissen, dass es äußerst schwierig ist, diesen Aspekt numerisch zu erfassen. Was Sie hier sehen, sind Proxy-Metriken, die versuchen, verschiedene Aspekte der Entwicklerzufriedenheit und -zufriedenheit bestmöglich zu erfassen.

• Job abgeschlossen: Immer wenn wir eine Aufgabe erledigen, schüttet unser Gehirn Dopamin aus, wodurch wir uns sofort nach Abschluss der Aufgabe zufrieden und motiviert fühlen. Daher wird eine hohe Arbeitsabschlussquote im Vergleich zu den versprochenen Arbeiten für den Entwickler ein hohes Zufriedenheitsgefühl auslösen, da er/sie in der Lage ist, die versprochenen Arbeiten fristgerecht abzuschließen und zum Erfolg des Teams beizutragen.
• Überstunden: Überstunden ≠ höhere Produktivität; das Gegenteil ist der Fall, Überstunden tragen am meisten zum Burnout von Entwicklern bei und schaden ihrem Wohlbefinden. Durch die Verfolgung zusätzlicher Arbeitsstunden, beispielsweise an Wochenenden oder spät in der Nacht, können Sie nachvollziehen, ob Ihre Entwickler zufrieden sind und in ihrer aktuellen Arbeitsumgebung gute Leistungen erbringen.
  • Geschäft ist kein Mittel zum Erfolg, es ist ein Hindernis für den Erfolg
    - Alex Soojung-Kim Pang
    
• Loslösung: Der häufigste Indikator für Unzufriedenheit und Burnout ist die Loslösung von Teams und Teamaktivitäten. Eine Möglichkeit, das Entwicklerengagement zu messen, besteht darin, Änderungen in der allgemeinen Reaktionszeit eines Entwicklers auf Teamaktivitäten wie Codeüberprüfungen oder eine Abnahme der Interaktion oder Teilnahme an Teambesprechungen zu messen.
• Entwicklerumfragen: Wenn es darum geht, die besten Produktivitätskennzahlen zu ermitteln, vergessen wir oft den offensichtlichsten Weg, nämlich Ihr Team zu befragen und die Stimmung Ihres Teams zu verstehen, indem wir Umfragen zur Entwicklerzufriedenheit durchführen und analysieren. Stellen Sie Fragen wie „Sind Sie zufrieden?“ (Bewertung 1-5)“ ist die schlechteste Art, dies zu verstehen. Möglicherweise gibt es jedoch auch andere Fragen, die Ihnen dabei helfen können, ähnliche Informationen auf unterschiedliche Weise und in unterschiedlichen Dimensionen zu erfassen Angesichts der Art der Entwicklertrends könnte ein geeigneter Zeitraum zwischen 12 und 18 Monaten liegen, was definitiv zu Bedenken hinsichtlich der Leistung führt von Entwicklern und Entwicklungsteams besteht darin, die Ergebnisse und nicht den Output zu messen. Das ideale Ergebnis für jeden Entwickler ist eine zeitnahe Lieferung und maximale Kundenzufriedenheit.
• Nacharbeit: Wenn Entwickler ihre Pull-Requests korrigieren müssen oder häufig Aufgaben von der Qualitätssicherung zur Fehlerbehebung an Entwickler zurückgegeben werden, ist dies ein klarer Hinweis darauf, was getan wurde. Die Qualität der Arbeit entspricht wiederholt nicht dem erwarteten Standard Der Funktionsentwicklungszyklus wird jedoch nicht auf Null-Revisionen ausgedehnt, und Überarbeitungen sind häufig auf Änderungen in den Anforderungen zurückzuführen Für andere ist das definitiv ein Zeichen für eine Leistungslücke.

Pünktliche Lieferung: Ein Ergebnis, das jedem Ingenieur und Unternehmensleiter am Herzen liegt, ist die Vorhersehbarkeit der Lieferung, da viele andere Geschäftsentscheidungen den Kunden oft mitgeteilt werden Um während des gesamten Entwicklungsprozesses Vorhersehbarkeit zu gewährleisten, ist es absolut wichtig, dass jeder Entwickler diese Qualität auch annimmt. Eine Möglichkeit, dies zu messen, besteht darin, zu prüfen, was Entwickler während eines Entwicklungssprints/einer Iteration leisten Zufriedenheit: Es besteht Einigkeit darüber, dass dies das wichtigste Ergebnis ist, um für jedes Unternehmen einen Mehrwert zu schaffen. Daher kann die Zufriedenheit der Kunden auch für den App Store zu besseren Ergebnissen führen und schnellere Reaktionszeiten, oder für das Plattformteam kann es bedeuten, dass die von anderen Teams verwendeten internen Bibliotheken einfacher zu verwenden sind und trotz zufriedener Kunden nur minimale Fehler gemeldet werden. Abschlüsse werden nicht nur von Entwicklungsteams gesteuert, sondern als Leistungsmetrik verwendet Hält Entwicklungsteams mit echten Benutzern der von ihnen entwickelten Produkte in Kontakt und hilft ihnen, sich auf die richtigen Dinge zu konzentrieren. Aktivität allein kann die Entwicklerproduktivität niemals wirklich messen. Die Verfolgung von Aktivitätsmetriken in Verbindung mit anderen Dimensionen aus verschiedenen Bereichen des SDLC-Prozesses wird Ihnen dabei helfen, Ihre tatsächlichen Entwicklerengpässe und Verbesserungsbereiche zu identifizieren

.

• Gelöste Aufgaben: Aktivitäten in dieser Phase helfen dabei festzustellen, wie oft und in welchem ​​Umfang Entwickler zu Entwicklungsaufgaben beitragen. Da Entwicklungsaufgaben immer als Aufgaben, User Stories oder Unteraufgaben im Projektmanagement-Tool geplant werden, kann ein Blick auf die insgesamt gelösten Aufgaben dabei helfen, die Beteiligung der Entwickler an diesem Teil des Entwicklungszyklus zu verstehen.
• Pull-Requests überprüfen: Normalerweise ist nur der technische Leiter oder der Manager des Entwicklungsteams für die Überprüfung von Änderungen/Pull-Requests verantwortlich, was ein offensichtliches Anti-Pattern darstellt. Indem Sie jeden Entwickler dazu ermutigen, immer mehr Code seiner Kollegen zu überprüfen, können Überprüfungsengpässe vermieden werden. Diese Metrik wäre eine gute Möglichkeit, festzustellen, ob ein Entwickler zur Überprüfungslast des Teams beiträgt.
• Bereitstellungshäufigkeit: Die Häufigkeit, mit der Ihr Team Änderungen an einem Produktionssystem bereitstellt, kann Ihnen helfen, den Geschwindigkeitsaspekt Ihres Entwicklungsprozesses zu verstehen. Dies ist auch eine der DORA-Kennzahlen, die laut Studien auch in hohem Maße mit der Kundenzufriedenheit und sogar der Rentabilität eines Unternehmens korreliert, was sie zu einem hervorragenden Maß für die Verfolgung der Dimensionen der Produktivitätsaktivitäten in Entwicklungsteams macht.

KOMMUNIKATION & ZUSAMMENARBEIT

In jedem Entwicklungsteam ist das Endprodukt (sei es eine Funktion, ein Service, eine Anwendung oder eine Erweiterung) immer das Ergebnis einer Teamarbeit. Gute Kommunikation und Zusammenarbeit sind die Grundlage für den Aufbau eines effizienten Entwicklungsteams. Die Einbeziehung dieser Dimension in die Messung der Entwicklerproduktivität kann eine Kultur der Transparenz und des Informationsaustauschs fördern. Einige Produktivitätsmetriken, die dabei helfen, dies zu erfassen, sind:

• PR-Wartezeit und Zykluszeit: Wenn das Entwicklungsteam gut zusammenarbeitet, kann sich dies deutlich in seinem Überprüfungsprozess widerspiegeln, da dies wahrscheinlich der größte Engpass im Entwicklungsprozess ist, da dies der Fall ist hängt von einer effektiven Kommunikation zwischen Mitwirkenden und Gutachtern ab und umgekehrt. Eine Metrik, die hilft, die Zusammenarbeit eines Entwicklers zu verfolgen, ist die Messung der Zeit, die dieser Entwickler benötigt, um mit der Überprüfung einer Pull-Anfrage zu beginnen, nachdem sie zugewiesen wurde. Als nächstes kann die Messung der durchschnittlichen Zykluszeit von Pull-Requests dabei helfen, die Kommunikationsfähigkeiten eines Mitwirkenden zu verstehen.
• Anzahl der zusammenarbeitenden Mitglieder: Entwicklungsteams haben oft Wissenssilos und Gruppen von Entwicklern, die nur untereinander und nicht mit dem Rest des Teams interagieren. Dies ist ein weiteres klassisches Anti-Pattern. Die Messung, wie gut ein Entwickler mit anderen Teammitgliedern kommuniziert, ist eine gute Möglichkeit, diese Dimension zu messen.
• Onboarding-Zeit für neue Mitglieder: Immer wenn ein neuer Entwickler dem Team beitritt, durchläuft er eine erste Lernkurve, versteht die Geschäftsumgebung, macht sich mit dem Technologie-Stack vertraut und erhält in der Regel Hilfe bei Code-Komplettlösungen. Die Zeit, die ein Entwickler seit seinem Beitritt benötigt, um die erste wirkungsvolle Änderung vorzunehmen, ist eine wichtige Produktivitätskennzahl für die Kommunikation im Entwicklungsteam. Als Team mit guten Dokumentationspraktiken ermöglichen Entwickler, die bereit sind, sich die Mühe zu machen, Neuankömmlingen zu helfen, so schnell wie möglich wirkungsvolle Änderungen vorzunehmen. Ein guter anzustrebender Maßstab ist das erste produktive Ergebnis eines neuen Entwicklers innerhalb der ersten 30 Tage.

Effizienz und Prozess

Das ist die Dimension des „Eintretens in den Prozess“, von der Entwickler oft sprechen. Hier helfen Metriken zu verstehen, wie viele Unterbrechungen es im Entwicklungszyklus gibt und wie reibungslos eine Aufgabe von Anfang bis Ende abläuft. Häufige Unterbrechungen beeinträchtigen nicht nur die Produktivität der Entwickler, sondern können auch zu erhöhtem Stress und Ermüdung führen.

• Ununterbrochene Entwicklungszeit: Für Entwickler ist es absolut wichtig, jeden Tag genügend ununterbrochene Zeit zu haben, um sich in den Prozess einzuarbeiten und Zeit in Entwicklungsaktivitäten zu investieren. Eines der größten Hindernisse sind Teambesprechungen. Um längere Entwicklungszeiten zu fördern, führen Teams oft besprechungsfreie Arbeitstage ein oder legen strenge Zeitfenster fest, in denen Teambesprechungen geplant werden können. Eine längere ununterbrochene Entwicklungszeit bedeutet nicht unbedingt eine höhere Entwicklerproduktivität. Es ist jedoch sicher, dass der für die Entwicklung erforderliche Prozess nicht erreicht werden kann, wenn den Entwicklern nicht genügend ununterbrochene Zeit zur Verfügung steht.
• Commit-Vorlaufzeit: Mehr Unterbrechungen im Entwicklungszyklus, mehr Übergaben und ein zu häufiges erneutes Öffnen von Aufgaben sind Indikatoren für eine schlechte Effizienz und einen schlechten Ablauf von Entwicklungsaufgaben. Die Commit-Vorlaufzeit erfasst dies genau, da sie die Gesamtzeit misst, die benötigt wird, bis eine Änderung Auswirkungen auf die Endbenutzer hat. Eine relativ hohe Commit Lead Time (CLT) bedeutet definitiv eine Verringerung der Effizienz und des Flusses des Entwicklungsteams. CLT ist auch einer der DORA-Indikatoren. Weitere Informationen hierzu finden Sie hier.
• Durchschnittliche Work-In-Progress (WIP)-Tickets: Kontextwechsel sind definitiv ein Produktivitätskiller. Mehr Dinge gleichzeitig zu erledigen, bedeutet immer, dass mehr Zeit benötigt wird, um alles zu erledigen, und kann auch zu unnötiger geistiger Erschöpfung führen.
  • Zwei parallele Aufgaben – 20 % Verlust durch Kontextwechsel.
  • Drei parallele Aufgaben – 40 % gehen aufgrund von Kontextwechseln verloren.
  • – Gerald M. Weinberg

WIP-Tickets erfassen perfekt die Anzahl der Aufgaben, an denen ein Entwickler parallel arbeitet. Das Verfolgen dieser Produktivitätsmetrik und der Versuch, sie unter drei Aufgaben zu halten, ist eine gute Anfangspraxis für Ihr Entwicklungsteam.

Veränderungsengagement

Wenn Sie sich die Kennzahlen ansehen, die die Entwicklerproduktivität steigern, werden die Maßnahmen, die Ihnen dabei helfen, Veränderungen voranzutreiben, Veränderungen im Entwicklungsprozess sein. Die Messung des Engagements der Entwickler bei den vom Team vorangetriebenen Änderungen hilft dabei, die Anstrengungen zu verstehen, die jeder Einzelne in die Korrektur der Prozesse des Teams unternimmt. Mit jeder Prozessänderung kann eine Metrik verknüpft sein, die erfasst, wie gut der Prozess befolgt wird, und Bestenlisten, die diese Metriken verfolgen, können Ihnen dabei helfen, Gamification zu betreiben und zu verstehen, welche Entwickler einen guten Beitrag zu Ihrer Prozessänderungsinitiative leisten.

Das ist jeder!

Wir sehen, dass die Entwicklerproduktivität oft als einzelne Metrik oder als einfach zu verfolgende Metrik missverstanden wird und nicht als die Metriken, die wirklich wichtig sind. Es ist absolut wichtig, dass wir die Entwicklerproduktivität verfolgen und einen ganzheitlichen Ansatz zur Verbesserung der Entwicklerproduktivität verfolgen und uns dabei von Frameworks wie SPACE inspirieren lassen. Es ist am besten, mit einigen wenigen Indikatoren zu beginnen, aber es ist wichtig, diese Indikatoren entlang mindestens dreier Dimensionen auszuwählen. Wir haben die umfassende Liste der Dimensionen und die vielen Metriken innerhalb jeder Dimension besprochen. Jetzt müssen Sie und Ihr Team die richtigen Dimensionen und Metriken herausfinden, die die größte Wirkung haben.

Das obige ist der detaillierte Inhalt vonEntwicklerproduktivität – wie man sie misst. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!