.png)
.png)
Produkt-Teams sind funktionsübergreifende Gruppen aus Product Managern, Designern, Data Scientists, Copywritern ... und Entwicklern. Sollten Engineering-OKRs also überhaupt existieren, wenn es bereits Produkt-OKRs gibt?
Ja. Engineering-OKRs konzentrieren sich auf die Qualität der Arbeit, während sich Produkt-OKRs auf die Bereitstellung des richtigen Werts konzentrieren. Das ist eine etwas vereinfachte Darstellung, aber sie zeigt die zwei Seiten der Medaille. In vielen Fällen brauchen Sie großartige Entwicklungsarbeit, um die Nutzererfahrung zu verbessern. Es gibt aber auch viele Aspekte, die spezifisch für Engineering sind und die Produktziele nicht abdecken.
Fokusbereiche:
Wichtige Fragen:
Wie effizient ist unser Entwicklungsprozess?
Wie gut ist die Qualität unserer Releases?
Erzeugen wir zu viele technische Schulden?
Kann unser Entwicklungsteam seine beste Arbeit leisten?
Wie schreibt man OKRs für Engineering-Teams
Schritt 1. OKRs vs. Projekte verstehen
Bevor Sie mit dem OKR-Prozess beginnen, ist es wichtig, den Unterschied zwischen Zielen, Key Results und Projekten zu verstehen:
- Ziele: Was wollen wir im nächsten Quartal erreichen?
- Key Results: Wie werden wir den Fortschritt messen?
- Projekte/Initiativen: Was sind unsere besten Wetten, um dorthin zu gelangen?
Projekte werden hier erwähnt, weil ein häufiger Fehler darin besteht, sie als Key Results aufzulisten. Ein Projekt ist jedoch ein Liefergegenstand (Output) und kein Ziel (Outcome).
Ein gutes Ziel sollte inspirierend und für jeden in Ihrer Organisation leicht verständlich sein. In den Key Results können Sie spezifischer werden, aber die Ziele sollten eine klare Vorstellung von der erwarteten Wirkung am Ende des Quartals geben.
Ein guter Key Result sollte Ihnen helfen, den Fortschritt in Richtung Ihres Ziels zu messen. Ein guter Test ist die Frage: „Würden wir etwas anders machen, wenn dieser KR aus der Spur gerät?“. Wenn die Antwort negativ ist, müssen Sie Ihr OKR verfeinern.
Ihre Projekte sind schließlich Wetten, die Sie eingehen, um Ihre OKRs zu erreichen. Manche werden funktionieren – verdoppeln Sie den Einsatz. Manche werden scheitern, und es sollte in Ordnung sein, aufzuhören und zur nächsten Idee weiterzugehen.
Schritt 2. Wählen Sie 2-3 Fokusbereiche
Der nächste Schritt besteht darin, den richtigen Fokus zu wählen. Ein Engineering-Team hat mehrere Optionen zur Auswahl:
- Zuverlässigkeit: sicherstellen, dass der Dienst immer wie erwartet funktioniert.
- Benutzerfreundlichkeit: bestehende Funktionen verbessern, um die Plattform intuitiver zu machen.
- Funktionalität: neue Fähigkeiten bereitstellen.
- Sicherheit: bestehenden Schutz verbessern und neue Schutzmaßnahmen zum Schutz der Kunden hinzufügen.
- Performance: sicherstellen, dass Ihre Anwendung reaktionsschnell und skalierbar ist.
- Geschwindigkeit der Entwicklung: in Ihren Entwicklungszyklus investieren, um schnellere Releases zu ermöglichen.
Versuchen Sie aber nicht, alles gleichzeitig anzugehen. Sie müssen 2 oder 3 Themen für das Quartal isolieren und diese als Ausgangspunkt für Ihre OKRs verwenden.
Schritt 3. Erstellen Sie Ihren Plan
Sobald Sie Ihren Fokus eingegrenzt haben, können Sie mit dem Schreiben Ihrer OKRs beginnen.
Einigen Sie sich auf 2-3 Ziele, bevor Sie sich mit den Key Results befassen. Weiter unten finden Sie einige Beispiele, und hier ist ein Leitfaden zum Schreiben von OKRs, falls Sie gerade erst anfangen
Beispiel für Engineering-OKRs
OKRs zum Abbau technischer Schulden
Technische Schulden bewältigen, die durch überhastete Feature-Entwicklung entstanden sind
Den Anteil der als Schulden markierten Issues um 30 % reduzieren
80 % der Projekte auf die neue UI-Bibliothek migrieren, um UI-Schulden zu reduzieren
Die auf technische Schulden zurückgehende Kontaktrate um 50 % senken
OKRs zur Verbesserung der Entwicklungsgeschwindigkeit
Die Entwicklung durch Automatisierung beschleunigen
100 % der Repositories verfügen über eine Continuous-Delivery-Pipeline
Die Testabdeckung von 30 % auf 60 % erhöhen
Die Build-Zeit von 20 auf 5 Minuten reduzieren
Die Zykluszeit von 8 Tagen auf 24 Stunden reduzieren
Alle Entwickler haben Zugriff auf eine QA-Bibliothek mit Beispielen für automatisierte Tests
OKRs für bessere Performance und Zuverlässigkeit
Eine erstklassige Infrastruktur aufbauen
Den Apdex-Wert von 0,7 auf 0,98 erhöhen
Die Anzahl der Vorfälle mit ausgelöstem Alarm um 40 % reduzieren
Die Crash-free-Sessions von 75 % auf 95 % verbessern
Die Ladezeit der wichtigsten Seiten auf unter 3 Sekunden senken
OKRs zur Verbesserung der Codequalität
Herausragende Standards bei der Codequalität nachweisen
100 % der Pull Requests werden von 2 Entwicklern überprüft
75 % der Entwickler haben eine QA-Schulung absolviert
100 % der Repositories nutzen Code-Linting und statische Codeanalyse
Den Anteil QA-bedingter fehlgeschlagener Builds um 60 % reduzieren
OKRs für ein hervorragendes Nutzererlebnis
Das Nutzererlebnis durch bessere Performance deutlich verbessern
Die Anzahl der Produktionsausnahmen um 45 % senken
Die Kaltstartzeit der Kundeninstanzen von 2 Minuten auf 10 Sekunden verkürzen
Die API-Antwortzeit von 900 ms auf 450 ms reduzieren
Den NPS von 15 auf 35 verbessern
Ihre OKRs verfolgen
Zu wissen, wie man gute OKRs schreibt, ist entscheidend, aber ohne ein gutes Tracking verlieren die OKRs an Bedeutung und der Fokus geht verloren.
Das sagen nicht nur wir:
- Peter Kappus schreibt, dass „Check-ins der wichtigste Teil von OKRs sind".
- Felipe Castro warnt davor, OKRs zu Neujahrsvorsätzen verkommen zu lassen.
- Christina Wodtke sagt uns, dass „Kadenz wahrscheinlich das Wichtigste überhaupt ist".
Je einfacher es für ein Team ist, wöchentliche Gespräche über die OKRs zu führen, desto besser wird die Umsetzung gelingen. Hier sind einige Best Practices für das Tracking von OKRs.
1. Führen Sie wöchentliche Check-ins durch
Quartals-OKRs sollten wöchentlich verfolgt werden, um wirksam zu sein. Ohne eine kontinuierliche Reflexion über den Fortschritt unterscheiden sich Ihre OKRs kaum von KPIs.
Der Check-in-Prozess kann mit einer Plattform wie Tability automatisiert werden, die sich um Erinnerungen kümmert und Updates an die Teams verteilt.
2. Behalten Sie Ihre Zuversicht im Blick
Gute Fortschrittsupdates sollten allen helfen zu verstehen, wie weit wir von unserem Ziel entfernt sind, aber auch, wie zuversichtlich wir sind, es zu erreichen. Sie können eine einfache Rot/Gelb/Grün-Farbcodierung verwenden, um Ihre Zuversicht anzuzeigen.
3. Machen Sie Trends leicht erkennbar
Schließlich ist es wichtig, Trends zu betrachten, um falsch-positive Ergebnisse zu vermeiden. Es ist nicht selten, dass ein Team stark startet und sich dann zur Mitte des Quartals verlangsamt. Das ist schwer zu erkennen, wenn Sie nicht die Fortschrittstrends für einzelne Key Results betrachten können.
Welche anderen Engineering-Kennzahlen können Sie verwenden?
Jetzt, wo Sie gute Ziele haben, ist es an der Zeit, passende Key Results auszuwählen – und gute Kennzahlen zu finden, die zu Ihrem Team passen, kann knifflig sein. Zum Glück haben wir alle zusammengestellt, die Sie nutzen können.
Hier sind ein paar, um loszulegen:
Zykluszeit
Wie lange es dauert, vom committeten Code bis zum an Kunden ausgelieferten Code zu kommen.
Deployment-Volumen
Wie viele Deployments täglich/wöchentlich/monatlich durchgeführt werden.
Öffnungs-/Schließungsrate
Anzahl der geöffneten Issues geteilt durch die Anzahl der geschlossenen Issues.
Anzahl der Vorfälle
Wie viele Vorfälle in der Produktion aufgetreten sind, idealerweise nach Schweregrad kategorisiert.
Testabdeckung
Wie hoch der Prozentsatz des Codes ist, der durch automatisierte Tests abgedeckt wird.
Build-Zeit
Wie lange es im Durchschnitt dauert, einen Build abzuschließen. Gibt an, wie lange ein Entwickler warten muss, um zu erfahren, ob seine Änderungen die Anwendung beschädigt haben.
Review-to-Merge-Zeit (RTMT)
Wie lange es dauert, bis ein Code-Review abgeschlossen und gemergt ist.
Sie haben ein Ziel vor Augen, wissen aber nicht, wie Sie es erreichen sollen?
Die kostenlose KI von Tability erstellt eine detaillierte Strategie mit allen Schritten, die Sie zum Erreichen Ihrer Ziele benötigen.
Strategie mit KI generieren
