EngThrive: Make It Fast and Easy to Do Great Work
Dieser Beitrag stellt EngThrive vor, ein mehrdimensionales Mess- und Verbesserungssystem, das bei Microsoft entwickelt wurde und die Entwicklerproduktivität um Geschwindigkeit, Einfachheit und Qualität herum organisiert, wobei das Wohlbefinden priorisiert wird und eine Kombination aus Telemetrie und Umfragen genutzt wird, um Metriken mit echten Ergebnissen statt mit Aktivitäten in Einklang zu bringen.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie sind der Kapitän eines riesigen Schiffes. Ihr Ziel ist es, das Schiff so schnell wie möglich an sein Ziel zu bringen. Seit Jahren messen Sie den Erfolg, indem Sie zählen, wie oft die Crew das Ruder herumwirft oder wie viele Eimer Wasser sie aus dem Schiff geschöpft haben. Sie dachten: „Mehr geschöpfte Eimer = schnelleres Schiff."
Doch dann bemerken Sie etwas Seltsames: Die Crew wirbelt das Ruder wild herum und schöpft wie verrückt Wasser, doch das Schiff bewegt sich nicht schneller. Tatsächlich ist die Crew erschöpft, wütend und bereit, das Schiff zu verlassen.
Das ist das Problem, dem sich die technischen Führungskräfte von Microsoft gegenüber sahen. Sie erkannten, dass das Zählen von „Aktivität" (wie Zeilen Code oder Pull Requests) eine schlechte Methode war, um zu messen, ob ihre Entwickler tatsächlich großartige Arbeit leisteten.
Dieses Papier stellt EngThrive vor, eine neue Methode zur Messung der Produktivität, die Softwareentwicklung wie ein lebendes Ökosystem und nicht wie eine Fließbandfertigung behandelt. Hier ist die einfache Aufschlüsselung, wie es funktioniert.
Der große Fehler: Die falschen Dinge zählen
Das Papier erklärt, dass Unternehmen lange Zeit versuchten, die Produktivität mit einer einzigen Zahl zu messen, wie zum Beispiel „Zeilen Code".
- Die Falle: Wenn Sie einen Schriftsteller nach dem Wort bezahlen, wird er lange, langweilige Sätze schreiben, nur um mehr bezahlt zu bekommen. Wenn Sie einen Entwickler nach der Codezeile bezahlen, wird er unordentlichen, ineffizienten Code schreiben, nur um die Zahl zu erreichen.
- Das „Remote Work"-Paradoxon: Während der Pandemie sah Microsoft, dass Entwickler 20 % mehr Code einreichten. Nach der alten Mathematik war jeder ein Superstar. Doch als sie die Entwickler fragten: „Wie fühlen Sie sich?", sagten 78 %, sie seien ausgebrannt. Das Schiff bewegte sich schnell, aber die Crew ertrank.
Die Lösung: Das „Geschwindigkeit, Leichtigkeit, Qualität"-Triad
Anstatt einer einzigen Zahl verwendet EngThrive einen dreibeinigen Hocker. Wenn ein Bein zu kurz ist, kippt der Hocker um. Sie brauchen alle drei, um stabil zu stehen.
- Geschwindigkeit (Das Rennen): Es geht hier nicht nur darum, schnell zu tippen. Es geht um Idee bis Kunde.
- Vergleich: Es ist egal, wie schnell Sie ein Auto lackieren, wenn Sie drei Wochen auf die Farbe warten müssen oder wenn der Manager ständig die Farbe ändert. Geschwindigkeit misst die Gesamtzeit vom Haben einer Idee bis zur tatsächlichen Nutzung durch den Kunden.
- Leichtigkeit (Die glatte Straße): Dies misst Reibung.
- Vergleich: Stellen Sie sich vor, Sie fahren ein Auto. Wenn die Bremsen klemmen, das Radio kaputt ist und Sie an jeder roten Ampel Formulare ausfüllen müssen, fahren Sie nicht schnell, auch wenn der Motor leistungsstark ist. „Leichtigkeit" misst, wie viel Zeit Entwickler damit verbringen, gegen ihre Werkzeuge zu kämpfen, auf Meetings zu warten oder defekte Builds zu reparieren, im Vergleich zur eigentlichen Entwicklung neuer Dinge.
- Qualität (Die Haltbarkeit): Dies misst, ob die Arbeit standhält.
- Vergleich: Wenn Sie ein Haus an einem Tag bauen (Geschwindigkeit) ohne Stress (Leichtigkeit), aber das Dach jedes Mal bei Regen leckt, waren Sie nicht produktiv. Sie haben nur mehr Arbeit für später geschaffen. Qualität misst, wie oft Dinge kaputtgehen und wie lange es dauert, sie zu reparieren.
Die Leitplanke: „Gedeihen"
Es gibt ein viertes Element namens Gedeihen. Dies ist kein Ziel, das maximiert werden soll; es ist eine Sicherheitsleitplanke.
- Vergleich: Denken Sie an den Tacho eines Autos. Sie können das Gaspedal durchdrücken, um schnell zu fahren, aber wenn der Motor zu rauchen beginnt und der Fahrer vor Schmerz schreit, müssen Sie die Bremsen betätigen.
- Wenn eine Veränderung das Team zwar schneller macht, sie aber unglücklich macht (Ausgebranntsein, schlechte Tage), schlägt die Metrik „Gedeihen" Alarm. Das Papier fand heraus, dass unglückliche Entwickler 25-mal häufiger sagen, sie seien unproduktiv, und doppelt so häufig kündigen. Sie können kein schnelles Schiff haben, wenn die Crew kündigt.
Wie sie es messen: Die „Mixed Method"
EngThrive schaut nicht nur auf Computerprotokolle (Telemetrie) oder fragt nur die Leute, wie sie sich fühlen (Umfragen). Es kombiniert beides.
- Telemetrie ist wie ein Fitness-Tracker: Sie sagt Ihnen, was passiert ist (z. B. „Sie haben 4 Stunden in Meetings verbracht").
- Umfragen sind wie die Frage an die Person: „Wie hat sich das angefühlt?" (z. B. „Diese Meetings waren nutzlos und frustrierend").
- Zusammen erzählen sie die ganze Geschichte: „Wir haben 4 Stunden in Meetings verbracht, und es fühlte sich wie eine Zeitverschwendung an."
Reale Beispiele aus dem Papier
Das Papier teilt drei Geschichten darüber, wie dies bei Microsoft funktionierte:
- Die „Meeting"-Lösung: Ein Team erkannte, dass Entwickler in Meetings ertranken. Sie setzten sich das Ziel, allen mehr „Fokuszeit" zu geben.
- Ergebnis: Entwickler bekamen 2 zusätzliche Stunden Fokuszeit pro Woche. Sie arbeiteten nicht nur schneller; sie reparierten alten, defekten Code (technische Schulden), der sie genervt hatte. Das Ergebnis? Weniger „schlechte Tage" und eine Steigerung der tatsächlichen Leistung um 13 %.
- Das „Gaming"-Experiment: Ein Team versuchte, eine Metrik namens „Time to First Pull Request" (wie schnell ein Neueinsteller Code einreicht) zu „betrügen", indem sie ihm am ersten Tag eine winzige, einfache Aufgabe gaben.
- Ergebnis: Überraschenderweise funktionierte das! Obwohl sie die Metrik „gespielt" hatten, fühlten sich die Neueinsteller selbstbewusster, lernten die Werkzeuge schneller und schrieben am Ende über das nächste Jahr hinweg mehr Code. Das „Spiel" erzwang das richtige Verhalten.
- Das „Gesundheitstage"-Experiment: Während einer Ausgebranntheitskrise gab ein Team allen zwei ungeplante freie Tage.
- Ergebnis: Die Codeausgabe sank zwei Tage lang (schlecht für „Geschwindigkeit"). Doch die Linderung des Ausgebranntseins hielt Monate an, und das Team holte die verlorene Arbeit in nur zwei Wochen nach. Ohne die „Gedeihen"-Leitplanke hätten Führungskräfte die freien Tage vielleicht abgesagt, weil sie am ersten Tag wie ein „Misserfolg" aussahen.
Was ist mit KI?
Das Papier argumentiert, dass KI nur ein weiteres Werkzeug ist, wie ein neuer Hammer oder ein schnelleres Auto.
- KI mag Menschen dazu bringen, Code schneller zu schreiben (Aktivität), aber EngThrive fragt: Bringt es Produkte tatsächlich schneller zu den Kunden (Geschwindigkeit)? Macht es den Job weniger frustrierend (Leichtigkeit)? Lässt es Dinge seltener kaputtgehen (Qualität)?
- Das Framework funktioniert für KI genauso gut wie für Bürogebäude, Urlaubsrichtlinien oder Meeting-Regeln.
Das Fazit
Sie können einen Menschen nicht mit einer einzigen Zahl messen. EngThrive ist ein System, das sagt: „Lassen Sie uns großartige Arbeit schnell, einfach und hochwertig machen, und stellen Sie sicher, dass die Menschen, die die Arbeit leisten, dabei glücklich und gesund sind."
Es bewegt Unternehmen weg von „Wie viele Zeilen Code haben Sie geschrieben?" hin zu „Wie viel Wert haben wir geschaffen und wie hat sich das Anlegen dieses Werts angefühlt?"
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.