OKRy na konferencji KIWAB – jak od celów firmy dojść do wymagań i priorytetów

Miałem przyjemność opowiedzieć o Objectives and Key Results na konferencji KIWAB, co jest skrótem od Inżynierii Wymagań i Analizy Biznesowej. Oto najważniejsze slajdy i tezy prezentacji.

Wszystkie slajdy można znaleźć na Slideshare, dodaję jednak opis, ponieważ nie „tłumaczą się same”.

Korzyści jakie przynosi wdrożenie OKR można zaprezentować za pomocą takiej piramidy. Podstawowe rzeczy to wybór priorytetów i komunikacja. Potem – opisywany już tutaj rytm spotkań i dyscyplina, która nie pozwala zapomnieć o tym, co ważne.

Nas jednak będzie interesował wzrost świadomości biznesowej i dojście do metod pracy, w których decyzje zależą od liczb, a nie siły przekonywania czy argumentów „najwyżej płatnych osób”.

Czyli, do merytokracji, a w efekcie wzrostu zaangażowania.

Cel, jaki stawia sobie zespół w metodzie OKR jest inspirowany celem i priorytetami firmy. Jest też wynikiem ustaleń między zespołami w procesie, w którym uczestniczą kluczowe osoby.  Każdy może zobaczyć cele innych. Dzięki temu rośnie świadomość biznesowa wszystkich zespołów w firmie.

Po ustaleniu celów, zmiany i realizowane przez zespół zadania powinny je wspierać. Zwykle szuka się rzeczy, które wpływają na zmianę konkretnych kluczowych rezultatów.

Żeby cel biznesu inspirował, nie może być nim zysk. Zysk powstaje niejako „przy okazji”. Ważne są cele niefinansowe, związane z tym, co firma oferuje klientom i użytkownikom. W końcu nie latamy samolotami dlatego, że linia lotnicza ma fajne zyski, tylko dlatego, że ceny są dobre a samoloty się nie spóźniają.

Zysk, jak wiadomo, zależy od przychodów i kosztów.

Przychody rosną wraz z popularnością produktu. Na tą z kolei ma wpływ zdolność firmy do pozyskiwania użytkowników / klientów oraz ich lojalność. Czyli to, jak chętnie zostają po „spróbowaniu” produktu. To uproszczenie, ale w gruncie rzeczy to jest tak proste.

Lojalność zależy od dwóch rzeczy.

Po pierwsze jak bardzo produkt angażuje użytkownika, jak często i z ilu jego funkcji korzysta. Po drugie, jak bardzo jest z niego zadowolony. Użytkownicy są zadowoleni, gdy produkt dobrze spełnia ich potrzeby. Gdy skutecznie realizuje zadania, do których go „zatrudniają”. Co to jednak znaczy, jak to zmierzyć?

Tu zaczynają się schody, ponieważ mówimy o Jakości.

Dla każdego może to być co innego, więc nie ma prostych, uniwersalnych metod. Dobra wiadomość jest taka, że można się tego nauczyć…

W książce „Competitive engineering” Tom Gilb podaje różne przepisy na kwantyfikacje rzeczy pozornie niewymiernych. Tu mamy przykład, na jakie czynniki można rozłożyć jakość.

Jednym z czynników może być użyteczność , którą można wyrazić w postaci miary „training requirement”. Mówi ona ile godzin nauki potrzeba, żeby ktoś mógł zacząć korzystać z produktu.

Przed epoką produktów cyfrowych, wyroby informatyczne kupowane były przez przedsiębiorstwa. Wtedy ich użytkownicy nie mieli wyboru – musieli korzystać z konkretnego rozwiązania. Nie musiało być użyteczne, firmy robiące rozwiązania wraz z produktem oferowały szkolenia. W czasach użyteczności coraz częściej robimy systemy, np. księgowe, z których użytkownicy są w stanie korzystać bez żadnego przygotowania.

Sięgnijmy jednak po prostszy przykład. W 2008 Google wprowadzało na rynek przeglądarkę Chrome. Jeden z Kluczowych Rezultatów działu produktowego mówił o milionach użytkowników, którzy tygodniowo korzystają z przeglądarki. Tak zachowywał się w kolejnych latach.

Gdy zadamy sobie pytanie, czy to jest dobry cel dla zespołu programistów, budzą się wątpliwości. Można sobie wyobrazić, że mając go, stwierdzą „ale to nie tylko od nas zależy”. Często byłaby to uzasadniona wątpliwość.

W przypadku Chrome zespół nie inwestował w „miliony użytkowników”. Znalazł miarę, która była mu bliższa – szybkość działania przeglądarki. Posługując się taką miarą można podejmować decyzje o tym, co robić i co zmienić, żeby program działał szybciej.

Poszukiwanie odpowiednich miar to kluczowa faza w procesie rozwoju produktu. Jest ważniejsze niż zarządzanie backlogiem, listą dziesiątków tematów do zrobienia.

Prawda jest jednak taka, że łatwiej jest nam zaczynać rozmowę od propozycji działań, zmian i rzeczy do zrobienia.

Dlatego warto zacząć od ustalenia jakie wartości mają znaczenie. Jakie zachowania użytkowników i systemu powodują efekty wpływające na nasz biznes? Jakie obserwowalne wartości je opisują? Może to być wspomniana użyteczność, skuteczność rekomendacji (na poziomie najprostszym mierzona liczbą interakcji z nimi) czy też coś tak fundamentalnego jak wysoka dostępność strony mierzona liczbą awarii…

Rozmowa o wartości i metodach jej poszukiwania to jedna z ważniejszych rozmów jakie obecnie się toczą w rozwoju produktu. OKRy mogą być dobrym wstępem do niej.

Nie jest to jednak proste. Wymaga cierpliwości, poszukiwania i testowania miar a przede wszystkim dobrego zrozumienia użytkownika.

Zniechęcić się można choćby tym, o czym wszyscy zajmujący się produktem wiedzą od dawna. Niewiele funkcji produktu jest wykorzystywanych przez użytkowników, większość wprowadzanych zmian niczego nie daje. Gdy się zacznie to mierzyć, takie rzeczy po prostu widać. Czasem jest to przykre, ponieważ przekonujemy się, że zrobiliśmy coś niepotrzebnie.

Jednak dzięki tej rozmowie możemy zacząć naprawdę zacząć się uczyć sztuki wybierania i priorytetyzowania zmian. W efekcie osiągamy prostotę, realizując jedną z fundamentalnych zasad Agile, którą jest „sztuka maksymalizacji pracy niewykonanej”.


Dziękuję za lekturę. OKR-ami zajmuję się od ponad 4 lat.
Jeśli potrzebujesz wsparcia we wdrożeniu skontaktuj się ze mną.

Zapraszam też na warsztaty otwarte.