Widzę wiele złych OKR (cele i kluczowe wyniki). Zwykle są to po prostu KPI (Key Performance Indicators) opatrzone nazwą OKR. Znasz je, ponieważ wydają się być czymś w rodzaju

Cel: dostarczyć produkt x

Kluczowy wynik: produkt x jest w produkcji

Cel: promowanie przyjęcia produktu y

Kluczowy wynik: 5 zespołów zostało włączonych do produktu y

W tym poście postanowiłem spisać moją definicję tego, jak wygląda dobry OKR. Mój sposób myślenia ewoluował od tego, czego nauczyłem się dawno temu z na wpół zapamiętanych wykładów, wpisów na blogu i książek, a teraz opiera się na moim doświadczeniu w wykorzystywaniu ich do wyznaczania celów zespołowych w ciągu ostatnich dziesięciu lat.

Cele

Cel ma charakter narracyjny i wyraża strategiczne ukierunkowanie i opinię na temat osiągnięcia tego wyniku, a nie tylko ogólnego wyniku, do którego dążysz.

Na przykład często znajdowałem się w roli kierującego zespołami, które są częścią migracji do chmury publicznej. Dla firmy dowolnej wielkości/złożoności migracja do chmury publicznej to wieloletnia inicjatywa. Tak więc, chociaż mógłbym mieć niezmienny cel: „przenieść firmę do chmury” lub „przyspieszyć przyjęcie chmury” lub co tam jeszcze, zwykle nie wyznaczam sobie tak szerokiego celu.

Zamiast tego patrzę na potencjalną pracę, którą naszym zdaniem musimy wykonać, na problemy, które napotykamy w związku z przejściem do chmury, i próbuję zidentyfikować kolejny kluczowy element strategii, na którym musimy się skoncentrować. Na przykład jednego roku celem było coś takiego:

Spraw, aby (nazwa firmy) była gotowa do pracy w chmurze

Ten cel był szeroki i obejmował prace, które dotyczyły bezpośrednio udostępniania i korzystania z chmury publicznej, ale obejmował również prace, które sprawiły, że nasze aplikacje były bardziej natywne w chmurze dzięki konteneryzacji i innym podstawowym ulepszeniom, niezależnie od tego, czy migrowały w tym czasie do chmury albo nie. W tym celu wyrażono opinię, że niezależnie od tego, czy zamierzamy przenieść wszystko do chmury publicznej, czy też nie, podstawowe praktyki, które są potrzebne, jeśli chcemy mieć architekturę i operacje „natywne w chmurze”, są ważne, aby iść naprzód.

Mam jeden wyjątek od pisania celów, które wyrażają opinię, i wtedy mam cel, który wyraża wieczną wartość i obszar zainteresowania. Dla mnie jest to zawsze „doskonałość operacyjna”. Co roku ustalam OKR doskonałości operacyjnej, który oznacza krytyczne projekty, które są potrzebne do rozwiązania problemów, takich jak, powiedzmy, migracja do Pythona 3, zmniejszenie nakładów pracy w krytycznych systemach lub inne główne obszary zorientowane na funkcjonalność i niezawodność. Robię to, ponieważ chcę podkreślić, że ta praca jest dla mnie równie ważna jak inne kluczowe inicjatywy, a ponadto oczekuję, że wszystkie moje zespoły skupią się na tym, bez względu na to, co jeszcze robią.

Kluczowe wyniki

Cele wyrażają strategię wysokiego poziomu z pewnego rodzaju opinią lub deklaracją wartości. Kluczowe wyniki dostarczają zagregowanych sygnałów i miar oczekiwanego wpływu lub postępów w osiąganiu tego celu.

Pokusa związana z kluczowymi wynikami polega na tym, aby bardziej odnosiły się one do wykonanej pracy niż wpływu. Jeśli Twoje kluczowe wyniki dotyczą systemów wysyłkowych, kończenia projektów lub osiągania kamieni milowych w dostawach, tak naprawdę mierzysz tylko to, czy robisz to, co szacujesz, że możesz zrobić. I to nie jest złe, dokładnie, ale ma dwie wady.

Pierwszym minusem jest to, że nie pozwala na dużą elastyczność w osiąganiu celu, a to jest dość ograniczające! Jedną z frustracji inżynierów związanych z planowaniem jest to, że może być ono bardzo sztywne. Kiedy mówisz o rocznym procesie tworzenia ogólnych OKR, próbujesz nie tylko przewidzieć, co zrobisz w ciągu roku, ale także które projekty są najważniejsze do wykonania. Jeśli okoliczności się zmienią i okaże się, że nie musisz przenosić wszystkich do EKS, ale zamiast tego musisz przenieść kilka osób do ECS, na przykład Twój KR „przenieś 100 aplikacji do EKS” zmieni się natychmiast na czerwony i musisz przepisać to na korzyść równie sztywnego „przenieś 50 aplikacji do EKS i 50 aplikacji do ECS”. Tam, gdzie to możliwe, uważam, że lepiej jest pisać KR, które pozwalają na elastyczność w sposobieosiągane są przez cały rok.

To prowadzi nas do drugiej wady KR wydajności pracy: nie uwzględniają one wpływu. Jest to szczególny martwy punkt zespołów inżynierskich typu platformowego, które skupiają się na budowaniu i dostarczaniu rzeczy, które według nich powinni zbudować i dostarczyć, nie zatrzymując się, by zapytać, czy jest to najbardziej użyteczna rzecz, aby pomóc użytkownikom osiągnąć ich cele. Kiedy piszesz KR, które dotyczą wpływu (skróć czas wdrożenia nowej aplikacji w chmurze z 2 tygodni do 2 dni (lub o 50% lub…)), zmuszasz ludzi do zmagania się z pytaniem: jak moja praca przyniesie rezultaty uderzenie?

W rzeczywistości KR ma jeszcze trzecią wadę, która pojawia się częściej, gdy prowadzisz większe organizacje. Moja osobista zasada OKR brzmi: nie więcej niż 5 celów, każdy z nie więcej niż 4–5 KR. Bez względu na to, jaką masz najbardziej spójną jednostkę nadzoru, staraj się jej trzymać, niezależnie od tego, czy Twój zespół liczy 50, czy 500 osób. Kiedy próbujesz reprezentować duże portfolio pracy w wielu różnych zespołach, nie masz miejsca do stracenia KR na cokolwiek mniejszego niż duża inicjatywa, a wyniki pracy KR mogą być stratą cennego miejsca KR.

Będziesz miał trochę pracy wyjściowej KR, jest to nieuniknione. Są rzeczy, które po prostu trzeba zrobić, a praca nad nimi jest na tyle ciężka, że ​​chcesz mierzyć to jako postępy, z których należy raportować. Ale nie bądź leniwy! Przeanalizuj każdy wynik pracy KR i naprawdę zadaj sobie pytanie, czy istnieje lepszy sposób pomiaru tego, który opiera się bardziej na wpływie niż na samej realizacji.

To wszystko jest trudne

To wraca do mojego początkowego punktu: OKR są trudne. Musisz mieć strategiczną opinię, aby napisać dobre cele, i musisz mieć dobre pomysły na to, czego chcą Twoi klienci, co Twój zespół może dostarczyć i co możesz zmierzyć, aby stworzyć dobre KR. Musisz zrozumieć potencjalnie bardzo duży zbiór zespołów i projektów, aby tworzyć OKR, które są zarówno inspirujące, jak i agresywne, ale nie niemożliwe.

A potem, oczywiście, są wszystkie wyjątki, które cię kuszą. Mam wycięcie na doskonałość operacyjną, a kiedy już zaczniesz, kuszące jest dodawanie coraz większej liczby wydzieleń. Zawsze powinniśmy mieć OKR do spraw związanych z kulturą zespołu/zatrudnieniem/rozwojem talentów. Nie możemy pominąć rozpoznawania funkcji X, więc musimy stworzyć coś specjalnego dla tej grupy. Nie mogę powiedzieć, że mój model 4-5 Os każdy z 4-5 KR naprawdę, naprawdę skaluje się powyżej kilkuset lub z każdym rodzajem biznesu. I prawdopodobnie są zespoły, które tak naprawdę po prostu nie potrzebują OKR, ze względu na charakter ich pracy, kontrolę nad tym, jak są mierzone, ich rozmiar, czy cokolwiek innego.

To jest upadek OKR-ów. Są trudne, ale sprzedawane jako coś, co każdy powinien robić, więc wszyscy robią to źle, a większość ludzi nie widzi w rezultacie żadnej wartości. Nie musisz robić OKR (chyba że pracujesz dla mnie, w takim przypadku możesz). Jeśli nie zamierzasz przynajmniej spróbować włożyć pracy w napisanie dobrych, nie powinieneś ich robić! Ale jeśli wykonasz pracę, zmuszą cię do bardziej strategicznego myślenia o swoich celach i zadawania trudnych pytań o to, jaki wpływ masz nadzieję osiągnąć dzięki nim i jak to zmierzysz. Dobre OKR-y opowiadają o tym, co jest ważne, pomagają zainspirować ludzi do zastanowienia się, dlaczego pracują nad tym, nad czym pracują, i myślę, że niosą ze sobą trochę energii, która bierze się z dostrzegania, jak to wszystko do siebie pasuje zwięzła forma.