Wie misst man die Entwicklererfahrung?

Quotient, ein DevEx-Startup, nutzt KI, um zu ermitteln, welche Produktivitätskennzahlen für die Skalierung eines Unternehmens wichtig sind und wie die Daten in Prioritäten umgewandelt werden können.

Übersetzt aus „ How Do You Measure Developer Experience?“ von Jennifer Riggins.

Ob in Zeiten wirtschaftlicher Sparmaßnahmen oder anderswo, Unternehmen, die wachsen wollen, werden immer kreativer, wenn es darum geht, technische Talente anzuziehen und zu halten und gleichzeitig dringende Geschäftsziele zu erreichen.

Da Entwicklererfahrung, Plattform-Engineering und Produktivität für Unternehmen jeder Größe zu Prioritäten geworden sind, konzentriert sich ein Startup auf Unternehmen, die nicht die Zeit oder das Budget haben, DevEx-Forscher einzustellen – diejenigen, die möglicherweise nicht die Zeit haben, die neuesten Forschungsergebnisse zu lesen und Ich glaube nicht, dass DORA-Metriken von Unternehmen erfüllt werden, die ihren Anforderungen entsprechen. Quotient wurde 2022 gegründet und nutzt eine Kombination aus Systemdaten und monatlichen dreiminütigen Entwicklerumfragen, um Tools zu entwickeln, die Entwicklungsteams produktiver machen. Es nutzt künstliche Intelligenz , um vorrangige Verbesserungsbereiche zu identifizieren und kombiniert diese mit forschungsbasierten Handlungsempfehlungen. Ziel ist es, Benutzern dabei zu helfen, von den besten Ingenieurkulturen zu lernen.

The New Stack sprach exklusiv mit Lizzie Matusov , Mitbegründerin und CEO von Quotient, über forschungsorientierte technische Führung und die Psychologie leistungsstarker Ingenieurteams – und natürlich darüber, wie man das alles misst.

Jetzt werden Produktivitätstreiber für Entwickler benötigt

„In einem Markt wie diesem konzentrieren sich Unternehmen darauf, wie sie mit den gleichen oder sogar weniger Ressourcen als zuvor mehr Umsatz erzielen können“, sagte Matusov. „Um dieses Ziel zu erreichen, setzen sie auf die Produktivität der Entwickler.“

Sie fügte hinzu, dass Quotient, obwohl es sich für Organisationen wie Spotify , Microsoft und andere einsetzt, „einen großen Bedarf an einer klaren, ganzheitlichen Sicht auf die Produktivität und die Möglichkeit besteht, die richtigen Maßnahmen zu ergreifen“. Markt, in diesen Organisationen befindet sich das Engineering Management gerade im Aufbau. Während die Entwicklerproduktivität für ihre Unternehmen wichtig ist, kämpfen sie um die Markteinführung und verfügen oft nicht über das Budget, um ein vollwertiges Produktivitätstechnikteam zusammenzustellen, das umfassende vierteljährliche Umfragedaten schreibt und analysiert.

Bei diesen Startups können Technik und Produkt mehr als 70 Prozent des Unternehmensbudgets ausmachen, sodass die Beseitigung von Engpässen enorme Auswirkungen haben kann, sagte Matusov.

Produktivitätsdaten verstehen

Es geht nicht nur darum, die Perspektive des Entwicklers einzuschätzen. Es geht darum, was Sie mit den Informationen machen.

„Traditionell bestand der Markt für Entwicklerproduktivität darin, Dashboards zu teilen und dann von den Teams zu Experten für die Analyse und Bearbeitung der Daten zu werden“, sagte Matusov. Die technische Führung konzentrierte sich damals auf eine einzige Metrik, beispielsweise die Geschwindigkeit , weil dies einfacher war verstehen .

„Obwohl es attraktiv ist, führt die Konzentration auf eine einzige Kennzahl nachweislich zu einer geringeren Produktivität“, sagte sie. „Wenn man sich beispielsweise auf die Geschwindigkeit konzentriert, ohne die Entwicklererfahrung zu berücksichtigen, kann dies dazu führen, dass Teams weniger stabile Software liefern oder einen falschen Kundennutzen erzielen und gleichzeitig den Burnout erhöhen . “ Keine dieser Dimensionen wird in einer einzigen Metrik erfasst.“

Google wird als erster zugeben, dass die meisten Entwicklungsteams DORA-Metriken falsch anwenden, wenn sie sich nur auf vier Schlüsselmetriken konzentrieren: Bereitstellungshäufigkeit, Änderungsdurchlaufzeit, Änderungsfehlerrate und Wiederherstellungszeit bei fehlgeschlagener Lieferung .

Aber Matusov glaubt, dass das daran liegt, dass das Sammeln und Analysieren von Dutzenden von Metriken wie jährlichen DORA-Berichten , SPACE-Frameworks , DevEx-Metriken und mehr überwältigend sein kann.

„Entwicklerproduktivität ist ein einzigartiges Feld, weil Sie genügend hochwertige Informationen benötigen, um zu zeigen, was in Ihrem Team vor sich geht und wie Sie diese Informationen in umsetzbare Zusammenfassungen umwandeln können“, sagte sie. „In den letzten Jahren haben wir daraus gelernt.“ Die Art und Weise, wie sich Software verändert, besteht darin, dass Einfachheit und Analyse entscheidend für die Wertschöpfung von Softwaretools sind.“

Dies ist ein Bereich, in dem sich generative KI als nützlich erweisen kann: Sie ermöglicht es uns, Informationen schneller zu durchsuchen und zu kontextualisieren, als wir es ohne sie tun würden.

Quotient sammelt Daten aus Entwicklersystemen und Entwicklerumfragen, um ein vollständiges Bild der Produktivität Ihres Teams zu erhalten. Dann, so Matusov, nutzt es künstliche Intelligenz, um „eine große Anzahl von Metriken zu extrahieren und sie in eine Teilmenge mit hoher Signalstärke umzuwandeln, damit die Teams Maßnahmen ergreifen können.“ Das Tool gibt dann drei Elemente aus:

  1. Eine Zusammenfassung der Entwicklerwahrnehmungen unter Hervorhebung der wichtigsten Treiber auf Teamebene.
  2. Metrikansicht der Entwicklererfahrung. Jeder Ingenieur kann alle Ergebnisse einsehen und Quotient hebt die obersten Prioritäten für jedes empfohlene Team hervor.
  3. Forschungsbasierte Handlungsempfehlungen für das Team.

Das Produkt nutzt außerdem künstliche Intelligenz, um die Analyse monatlicher Ergebnisse sowie laufender Systemdaten zu unterstützen.

Produktivitätskennzahlen wirken sich auf die psychologische Sicherheit aus

In der heutigen Entwicklererfahrung werden Entwickler selten zu etwas gezwungen, weshalb die Akzeptanz eine Schlüsselkennzahl für Plattform-Engineering und DevEx-Erfolg ist .

Quotient ist stolz auf eine durchschnittliche Antwortquote bei Umfragen von über 80 %, was Matusov auf „die Kultur des Tools zur Datenanonymisierung, -aggregation und -transparenz gegenüber dem Team“ zurückführt.

Wenn auf der Grundlage der Antworten der Entwickler Maßnahmen ergriffen werden, entsteht außerdem eine positive Feedbackschleife, die mehr Entwickler zur Teilnahme ermutigt. Interne Marketingaktivitäten, die als Reaktion auf Entwicklerumfragen durchgeführt werden, wie z. B. Demos, die gemeinsame Nutzung von Roadmaps und die Veröffentlichung neuer Funktionen, können dazu beitragen, die Rücklaufquoten bei zukünftigen Umfragen zu erhöhen.

Matusov sagte, Quotient sei zum Teil auf die Erfahrungen der Gründer als einzelne Mitwirkende zurückzuführen, die feststellten, dass ihre Arbeit in den Produktivitätsdaten der Entwickler unfair oder falsch dargestellt wurde, und „auf der Ausführungsebene des leitenden Ingenieurs hatten sie großes Vertrauen in die Vorgänge im Team.“ und „Wir haben keine klare Vorstellung davon, wie wir vorgehen sollen.“

Für Unternehmen ist es oft einfacher, technische Probleme mit vorhandenen Tools zu verfolgen. Nichttechnische Fragen sind oft schwieriger zu beantworten.

Zu den interessantesten Daten zur Entwicklerproduktivität gehört, wie Entwickler über ihre Arbeit denken . Sogenannte „Sentiment-Metriken“ können ebenso aufschlussreich sein wie Systemmetriken, wie zum Beispiel: Wie produktiv fühlen Sie sich bei der Nutzung dieser Tools? Was hält Sie Ihrer Meinung nach zurück?

Emotionale Intelligenz umfasst beispielsweise Messungen der psychologischen Sicherheit, und das Team arbeitete mit der Psychologin und Organisationsverhaltensexpertin Amy Edmondson zusammen, um ihre psychologische Sicherheitsskala an eine Softwareentwicklungsumgebung anzupassen.

„Wenn sich Ingenieure mit ihren eigenen unterschiedlichen Ideen nicht wohl fühlen“, sagt Matusov, „hat das enorme Auswirkungen darauf, wie schnell sie als Team mithilfe von Versuch und Irrtum die richtige Lösung finden und qualitativ hochwertige Software entwickeln können.“ ”

Zu den Überlegungen zur psychologischen Sicherheit gehören:

  • Die Mitglieder dieses Teams geben gerne Informationen weiter, auch darüber, was nicht funktioniert und was nicht.
  • Wie denken Entwickler über ihren Job?
  • Wie denken Entwickler über die Teams, mit denen sie zusammenarbeiten?

Da die Entwicklererfahrung soziotechnischer Natur ist, ist die Kombination der Metriken entscheidend. Quotient kombiniert Daten aus Entwicklersystemen und -perspektiven, einschließlich Daten darüber, wie Teams beliebte Kollaborationstools wie GitHub, Jira und Slack nutzen. Zu diesen Daten auf Teamebene gehören:

  • Wie teilt das Team die Zeiträume für die Codeüberprüfung ein?
  • Wie hoch ist die durchschnittliche Codeüberprüfungskomplexität des Teams?
  • Mit welchen Arten von Codierungsproblemen verbringt das Team die meiste Zeit?

Quotient kombiniert diese Daten dann mit monatlichen Entwicklerumfragen. Matusov sagte, beide Zahlensätze basierten auf dem SPACE Developer Productivity Framework , dessen Co-Autorin Jenna Butler als wichtige Beraterin von Quotient fungiert.

Das Gewicht der technischen Schulden

Technische Schulden sind oft eine Last auf den Schultern eines Teams, die unbemerkt bleibt, bis sie beseitigt wird. Es hat Auswirkungen auf die gesamte Organisation.

In einer TNS VoxPop-Umfrage vom April antwortete der mit Abstand größte Teil der Teilnehmer (43 %) auf die Frage „Was ist das größte Hindernis für die langsamste Auslieferung Ihrer Software?“ „Komplexe Codebasen und technische Schulden“.

Technische Schulden sind ein weiterer Engpass, der mehr als nur ein Team betrifft.

„Einer der Eckpfeiler von Quotient-Aktionen ist, dass kleinere, iterative Aktionen zu enormen Produktivitätssteigerungen für Teams führen“, sagte Matusov. „Wir empfehlen Teams nicht, technische Schulden sofort abzubezahlen – sie haben als Team keine unmittelbare Kontrolle darüber.“ Team-Dinge – wir geben Teams die richtigen Werkzeuge, um ihnen die direkte Kontrolle über ihre Produktivität zu geben.“

Eine der Empfehlungen von Quotient besteht darin, technische Schulden zu katalogisieren und zu kommunizieren. „Auf diese Weise geben wir den Teams die Möglichkeit, die größten Ursachen für technische Schulden zu identifizieren und diese zu priorisieren“, sagte Matusov. „Da die Teams jetzt über diese Informationen verfügen, ist es wahrscheinlicher, dass sie auf Teamebene Maßnahmen ergreifen, um ihre Situation zu verbessern.“

Technische Schulden sind eines der klaren Beispiele für die Priorisierung von Geschäftsauswirkungen. Der Druck, Mehrwert für die Kunden zu schaffen, ist groß. Der Umgang mit technischen Schulden hat jedoch Auswirkungen auf die Fristen, die zwischen Technik und Produkt ausgehandelt werden.

Laut Matusov verzeichnete einer der neuen Kunden von Quotient erhebliche Verbesserungen bei der Teamautonomie und den Auswirkungen technischer Schulden. Wie ist die Beziehung zwischen ihnen? Da die technischen Schulden sinken, sagt sie: „Teams müssen sich nicht mehr um technische Schulden streiten, was bedeutet, dass sie mehr Möglichkeiten haben, die Dinge zu tun, die sie für wichtig halten. Das ist entscheidend für die Produktivität.“

Messen Sie die Teamleistung, nicht die Einzelleistung

„Wir melden die Daten einzelner Ingenieure überhaupt nicht auf der Plattform“, sagte Matusov, obwohl die Berichterstattung auf Teamebene möglich ist.

„Wir sind der festen Überzeugung, dass es schwierig ist, sowohl die Produktivität als auch die individuelle Leistung auf einer einzigen Plattform zu verbessern, ohne dabei das Vertrauen in den Prozess zu zerstören. Und Vertrauen ist der Kern unseres Handelns.“

Denn genau darum geht es bei DevOps , wobei der Fokus auf der Beseitigung von Barrieren bei Teamprozessen liegt. Dies spiegelte sich nicht in McKinseys berüchtigtem Entwicklerproduktivitäts-Framework wider, das letztes Jahr veröffentlicht wurde und bei dem das Schreiben von Codezeilen im Vordergrund stand. Aktuelle Untersuchungen zur Entwicklerproduktivität, einschließlich Metriken von SPACE und DevEx, unterstützen Quotients Fokus auf Teams.

Das Produkt enthält auch Freitextfelder, wenn eine Person zusätzliche anonyme Informationen angeben möchte.

Natürlich bleibt „Team“ ein vager Begriff. Quotient arbeitet mit der technischen Leitung jedes Kunden zusammen, um zu definieren, was das Team meint. Manchmal war es ein Scrum-Team aus 5 bis 9 Leuten, aber bei einem anderen Unternehmen, mit dem Matusov zusammenarbeitete, war es ein ganzes KI-Team, das eine einzigartige Arbeitsweise hatte, obwohl es über die gesamte Organisation verteilt war.

Während die Organisation dann versucht, Vorteile zu erschließen, um eine schnelle Skalierung zu ermöglichen – was sie „1 + 1 = 5“ nennt – bietet Quotient der Führung einen Gesamtüberblick, der zur Förderung früher Plattform-Engineering-Initiativen genutzt werden kann. Das Tool umfasst Einblicke auf Organisationsebene und empfohlene Maßnahmen und wird durch Forschung aus Industrie und Wissenschaft unterstützt.

Dokumentation ist hilfreich – wenn alle mitmachen

Bei allen Tools und Umfragen zur Entwicklerproduktivität bleibt die Dokumentation ein Engpass – Entwickler wünschen sich immer mehr und bessere Dokumentation, möchten aber nicht die Zeit damit verbringen, sie zu schreiben. Wenn die Dokumentation unweigerlich zur Priorität wird, empfiehlt Quotient den Übergang zu einer Kultur der kontinuierlichen Dokumentation.

„Die Herausforderung für Teams besteht darin, dass die Dokumentation ihr größtes Anliegen ist“, glaubt Matusov, denn „innerhalb des Teams herrscht die Kultur, dass man auf die Fertigstellung des Produkts wartet, bevor man die gesamte Dokumentation schreibt, was normal ist.“ Ich war alle dort.

Wenn Ihr Team jedoch eine Kultur der kontinuierlichen Dokumentation einführt, sagt sie: „Schreiben Sie eine Dokumentation zu jeder Aufgabe, die Sie ausführen, oder zu jedem Ticket, das Sie schreiben, und nicht erst am Ende des Projekts, wenn es sich um ein zweiwöchiges Projekt A handelt.“ Riesenarbeit.“

Das Ergebnis sind weniger Schmerzen. Doch dokumentenbasierte Produktivitätssteigerungen können ihren Preis haben.

„Es gibt eine Fülle von Untersuchungen darüber, wie Daten über das Verhalten von Entwicklern missbraucht und möglicherweise ausgenutzt werden können, um der Vielfalt von Teams zu schaden und die Vielfalt zu beeinträchtigen“, warnte Matusov.

Beispielsweise ergab die Studie der Google DevOps Research and Assessment Group (DORA) aus dem Jahr 2023 – auch bekannt als „ Accelerating DevOps Report“ –, dass Teams mit Dokumentation von höherer Qualität insgesamt besser abschnitten als Teams mit Dokumentation von geringerer Qualität.

„Das ist großartig; es erhöht die Produktivität. Allerdings bemerkten sie auch einen Trend, dass in Teams, in denen die Dokumentation verbessert wurde, ihre unterrepräsentierten Gruppen auch höhere Belastungen meldeten “, sagte sie, was bedeutet, dass Frauen und Teammitglieder aus Minderheitengruppen mehr Dokumentationsverantwortung trugen als ihre Kollegen.

„Dies unterstreicht, wie wichtig es ist, die Entwicklererfahrung auf vertrauenswürdige und umfassende Weise zu messen. Wenn Sie diese wichtigen Signale verpassen, kann dies unbeabsichtigt die Gesamtproduktivität Ihres Teams beeinträchtigen.“

Da die Branche große Erfolge bei der Steigerung der Entwicklerproduktivität erzielt, ist es wichtig, dass dies nicht auf Kosten bestimmter Teammitglieder geht, die mehr Arbeitsbelastung auf sich nehmen. Eine einfache Lösung für dieses Problem könnte darin bestehen, eine Aufgabe als „erledigt“ zu definieren, wenn sie dokumentiert ist, und diesen Standard für alle anwendbar zu machen, die die Software in der Produktion bereitstellen.

Psychologische Sicherheit, technische Schulden und Arbeitsverteilung sind drei Beispielbereiche, die ein differenziertes Verständnis der Entwicklererfahrung in einer technischen Organisation erfordern, um Verbesserungen vorzunehmen, die die Gesamtproduktivität des Teams steigern.

„Der Zauber der Entwicklerproduktivität besteht darin, dass alle davon profitieren, wenn Sie sich darauf konzentrieren, Ihr Team zu stärken und sich an seinem Ziel zu orientieren, den Kunden hochwertige Lösungen zu liefern“, sagte Matusov. „Ingenieure, Teamkultur und Kunden werden von der gesteigerten Produktivität enorm profitieren.“

Dieser Artikel wurde zuerst auf Yunyunzhongsheng ( https://yylives.cc/ ) veröffentlicht, jeder ist herzlich willkommen.

RustDesk stellt inländische Dienste wegen grassierendem Betrug ein. Apple veröffentlicht M4-Chip. Taobao (taobao.com) startet die Arbeit zur Optimierung der Webversion neu. Oberstufenschüler erstellen ihre eigene Open-Source-Programmiersprache als Geschenk für das Erwachsenwerden – kritische Kommentare von Internetnutzern: Verlassen Sie sich auf die Verteidigung Yunfeng ist von Alibaba zurückgetreten und plant , in Zukunft Java 17 als Ziel für unabhängige Spieleprogrammierer . Es ist die am häufigsten verwendete Java LTS-Version mit einem Marktanteil von 70 % und Windows 11 gehen weiter zurück. Google unterstützt die Übernahme von Open-Source-Rabbit. Microsoft hat die offene Plattform geschlossen
{{o.name}}
{{m.name}}

Acho que você gosta

Origin my.oschina.net/u/6919515/blog/11105732
Recomendado
Clasificación