Ich bin Softwareentwickler und habe keine fundierten Kenntnisse über die Best Practices rund um Objectives and Key Results (OKRs), daher stütze ich meine Frage hauptsächlich darauf, wie sie in meinem Unternehmen verwendet werden.
Jedes Quartal haben wir eine OKR-Woche, in der wir persönliche OKRs hinzufügen, basierend auf dem, was wir in diesem Quartal beenden möchten. Meine OKRs sind meistens Epics von Issue Tracker, also gibt es ein bisschen Doppelarbeit, die mich stört. Aber das ist eine Kleinigkeit.
Was mich wirklich stört, ist, dass ich eine Wasserfall-Stimmung von der ganzen Idee bekomme, Dinge für 3 Monate im Voraus zu planen (und dann macht die erste Zeile echten Codes diesen Plan veraltet). Es mag für stabile, alte Unternehmen gut funktionieren, aber für uns als Startup scheint es nicht viel Wert zu bieten, da sich die Dinge sehr schnell ändern (ironischerweise geschah es dieses Mal am nächsten Tag, nachdem die OKRs für ein Viertel fertig waren). .
Ich würde gerne wissen, ob ich mit meiner Einstellung richtig liege oder ob ich vielleicht nur etwas übersehe?
Mein Verständnis von OKRs ist, dass sie sich darauf konzentrieren sollen, den Menschen die erwarteten Ergebnisse klar zu machen, nicht unbedingt, wie man dorthin kommt (dh ein bestimmtes Epos abschließt).
Zum Beispiel:
Ziel: Steigerung der monatlich wiederkehrenden Einnahmen
--
Vielleicht hilft das Epos, das Sie abschließen müssen, bei der Lösung eines oder aller drei dieser Schlüsselergebnisse, es ist kein Schlüsselergebnis an sich.
Es ist in Ordnung, ein individuelles Ziel zu haben, dieses Epos in einem festgelegten Zeitraum abzuschließen, vielleicht sind OKRs auf individueller Ebene einfach nicht der richtige Rahmen oder Prozess dafür.
Viel Glück!
OKRs sind nur insofern mit Agilität verbunden, als die Unternehmen, die Pionierarbeit geleistet und das OKR-Modell gefördert haben, auch wesentliche Teile des Agile-Manifests und der Frameworks übernommen haben, die wir als agil betrachten.
OKRs sind jedoch in keiner sinnvollen Weise mit Agile verknüpft. Das heißt, sie können in einer agilen Umgebung fantastisch gut funktionieren oder spektakulär schief gehen.
Sie werden am häufigsten mit Lean Startup in Verbindung gebracht, nicht mit Kanban oder Scrum.
OKR steht für Objective and Key Result und unterscheidet sich von der Idee eines KPI. Es wurde (lose Bezeichnung) von Andy Grove bei Intel erfunden und dann durch die Tentakel von Risikokapitalgebern und dem Silicon Valley schnell von einer beträchtlichen Anzahl von Unternehmen übernommen, insbesondere von denen, in die Kleiner Perkins investierte.
Ein Ziel ist einfach ein einziges vereinheitlichendes Ziel, das einer Organisation einen Sinn gibt und ihr hilft, Prioritäten effektiv zu setzen. Es ist kein Leitbild oder ein hoher Anspruch. Es ist ein konkretes, nachweisbares, kühnes Ziel.
Die Schlüsselergebnisse sind die 3-5 Messungen, die Ihnen helfen, das Ziel zu erreichen, und der Organisationsebene unterhalb des Ziels eine Planungsebene bieten.
Für das Ziel, 100 Millionen Geräte zu verkaufen, benötigen wir also möglicherweise die wichtigsten Ergebnisse
usw usw
Diese Schlüsselergebnisse werden zum Ziel für die niedrigere Ebene (also übernimmt der Vertrieb den Schlüsselergebnis- Verkaufsplan für NA als sein Ziel. Sie produzieren 3-5 Schlüsselergebnisse, die zu den Zielen der niedrigeren Ebene werden und so weiter bis hin zu einer Einzelperson Arbeiter.
So lässt sich jedes einzelne Ergebnis auf ein übergeordnetes Ziel für das gesamte Unternehmen zurückführen.
Das Objective dient als massiver Wegweiser in die Zukunft und lässt ein Unternehmen alles ignorieren, was das Objective nicht unterstützt.
Google hat die Idee persönlicher OKRs gefördert (und dann verworfen). Dies wurde aus der Idee der Autonomie und Meisterschaft für Teams geboren. Sobald ein Ziel festgelegt wurde, hat es sich bewährt, die Teams selbst zu fragen, was unsere wichtigsten Ergebnisse sein sollen. Wie würden wir den Erfolg messen?
Mindestens die Hälfte der Key Results sollte von unten nach oben und ganzheitlich sein.
Dies wurde dann mit der Idee der beruflichen Entwicklung, des Leistungsfeedbacks, der Boni und der Aufbewahrung eines Teils Ihrer Zeit für persönliche OKRs wie z
Im liberalen Umfeld des Silicon Valley könnten persönliche OKRs mit Wohlbefinden, Beförderung, Wohltätigkeit usw. verbunden sein. John Doerr spricht darüber in Measure What Matters, indem er seine OKRs an seiner Bürowand postet.
Google ließ es schließlich fallen und ihre speziell entwickelte OKR-Plattform hatte einige Probleme.
Aber die Praxis existiert immer noch in anderen Unternehmen, da sie die OKR-Leitlinien von Google Ventures, Medium und anderen beliebten Blogs übernehmen, auch wenn Google einige Aspekte fallen gelassen hat. Die Legende lebt weiter...
Nun, ganz einfach, Ihr Produkt oder Ihre Dienstleistung sollte an ein Unternehmensziel gebunden sein . Wenn dieses Feature-Team an einem Produkt oder einer Dienstleistung arbeitet, sollte es 3-5 Schlüsselergebnisse haben, die angeben, wie es das Unternehmensziel unterstützt.
Das ist die Ebene, auf der OKRs mit Agile interagieren.
Wenn Sie etwas niedrigeres auferlegen, verwenden Sie effektiv keine OKRs, sondern SLAs oder KPIs mit vorgeschriebenen Lieferergebnissen.
Sie sollten jederzeit einen Product Owner fragen können
Wie unterstützt dieses Produkt/diese Dienstleistung die OKRs des Unternehmens?
Die Entwickler sollten in der Lage sein, zu fragen
Wie unterstützt diese Epic- oder User-Story die OKRs des Produkts?
So einfach ist es und sollte immer so einfach sein, nichts Komplexeres als das.
Wenn Sie nach einer hervorragenden Fallstudie suchen, veröffentlicht Gitlab alle ihre OKRs zusammen mit ihren Entwicklungs-Roadmaps und sogar ihren Epics und User Stories. Es ist eine umfassende Fallstudie.
Sarow
SibirischerTyp
Yitznewton