Roadmapy i OKRy – jak to pogodzić?

Jaki ma sens roadmapa w zwinnym rozwoju produktu? Jak powinna wyglądać, gdy wykorzystujemy OKRy? Jak połączyć OKR z celami sprintów i backlogami?

Rozwój produktów cyfrowych to dobre miejsce do wykorzystania podejścia Objectives and Key Results. Określone cele i stała rozmowa o nich mogą zastąpić tradycyjne planowanie i tworzenie roadmap.

Roadmapa to nadmiar treści

Roadmapa to plan rozwoju nałożony na kalendarz. Pokazuje jakie zmiany w produkcie będą miały miejsce w kolejnych miesiącach. Gdyby świat był przewidywalny, wystarczyłoby ustalić taki plan w styczniu na cały rok.

Jeden z typowych szablonów roadmap.

W rzeczywistości produktowej to nie działa. Planując nie wiemy ile czasu mogą zająć zmiany. Nie możemy być pewni jak wpłyną na zachowanie użytkowników. Nie mamy pojęcia co się wydarzy na rynku. Terminy realizacji i korzyści z planowanych zmian są przeszacowane. Zawsze w złą stronę a im dalej w przyszłość, tym bardziej.

W tego typu dokumentach zwykle wpisujemy więcej niż ma sens. Sam format kalendarza wymusza sposób myślenia typowy dla długoterminowego planowania. Zapełniamy go informacjami o rzeczach, o których nie mamy pojęcia. Na dodatek plany powstają daleko od miejsca, w którym jest wiedza, bez udziału ludzi, którzy będą je realizować.

Tworząc te szczegółowe dokumenty, przywiązujemy się do ustaleń lub wręcz traktujemy je jak zobowiązania. To prowadzi do niepotrzebnych rozmów o tym co miało być, choć w zasadzie powstać nie mogło.

Plan bez dat

Samo planowanie nie jest niczym złym. Potrzebujemy rozmów o przyszłości, by przygotować działania i podejmować decyzje. Gdy zapadną, trzeba je zakomunikować, aby wszyscy znali kierunek i wiedzieli co mają robić. Potem mogą przydać się do rozmowy o postępie.

Mając na uwadze funkcje planów i wiedząc jakie problemy powodują, warto odejść od roadmap na rzecz uproszczonego planowania. Pierwszą rzeczą jakiej należy się pozbyć są daty – zwłaszcza dotyczące tego, co ma się wydarzyć później niż za kwartał. W dłuższej perspektywie powinny one dotyczyć tylko rzeczy, które muszą się wydarzyć, bo wynikają z okoliczności niezależnych od planujących. Tu warunki końcowe są często precyzyjnie określone co eliminuje część niewiadomych.

Zmiany wprowadzane w najbliższych 2-3 miesiącach dotyczą rzeczy, o których dużo już wiemy. Tu terminy mogą być potrzebne do koordynacji działań związanych np. z wprowadzaniem produktu na rynek.

Cele jako plany

Zmian wymaga też sama treść. Tradycyjnie roadmapa to informacje o tym co “zbudujemy”. Decydujemy w niej o modyfikacjach i wprowadzaniu nowych możliwości produktu. Tymczasem nie więcej niż jedna czwarta takich zmian przynosi korzyści.

Menedżerowie produktu powinni o tym wiedzieć co najmniej od 10 lat. Wtedy ukazały się książka “Lean Startup” Erica Riesa i “Inspired” Marty Cagana. Nie chodzi o to, żeby stosować wszystko co napisali, ale by zrozumieć problemy, które próbują rozwiązywać. Zdumiewające w jak niewielu miejscach jest to stosowane.

Planowanie konkretnych zmian w produkcie powinny zastąpić cele. Stosując je, rozmawiamy o tym co chcemy osiągnąć i nie zamykamy się na to “jak” to zrobimy.

Poziomy celów w produkcie

Dziś najczęściej stosowany cel w rozwoju produktu to cel sprintu. Obejmuje on krótki okres i jest określany, gdy już wiadomo co należy zbudować. Sprinty są częścią metodyki Scrum, ale stawianie celów raczej nie jest tam aktywnością, do której przykłada się dużą wagę. Tak przynajmniej wynika z doświadczeń scrum masterów i wpisów ekspertów na ten temat. To jednak się zmienia.

Zeszłoroczna aktualizacja “Scrum guide” kładzie większy nacisk na cele. Mówi, że długoterminowy cel produktu jest zobowiązaniem zespołu, który zajmuje się rozwojem. Podaje, że jest to “przyszły stan” produktu, co właśnie stanowi definicję celu. Produkt ma być “wehikułem”, który dostarcza wartości (w domyśle biznesowi i użytkownikowi). Daleko tym górnolotnym stwierdzeniom do praktyki. Jak do tego podejść?

Przede wszystkim powinno być jasne komu i do czego produkt ma służyć. Takie informacje tworzą wizję produktu. Wizja jest też celem. Zwykle mówi o horyzoncie 2-3 letnim. Opowiada gdzie chcemy się znaleźć, ale nadal jest… tylko wizją. Bardziej precyzyjnie cele warto postawić na rok. Są one zapisem decyzji o zmianach w produkcie, które chcemy osiągnąć w pierwszej kolejności. Podejmując ją odpowiadamy na pytanie “Co przede wszystkim trzeba zmienić, by zbliżyć się do wizji”. Trzeba wybrać najwyżej 2-3 cele.

Przykład ze Scrum.org - są cele ale również plan "co zbudujemy"Przykład roadmapy ze Scrum.org – są cele ale również plan „co zbudujemy”

Wizja i cele roczne tworzą kontekst do podejmowania decyzji rozwojowych. W codziennej praktyce znaczenie mają cele na średni termin – kwartał lub dwa. Tu już sprawdza się format OKR. Objective w produkcie powinien określać co chcemy osiągnąć. Kluczowe Rezultaty natomiast powinny mierzyć zmianę zachowania użytkowników.

To wbrew pozorom szerokie stwierdzenie. Zmiana zachowania może oznaczać, że użytkownicy zaczynają korzystać z jakiejś funkcji, że coś zajmuje im mniej czasu lub, że zmienią opinię na temat produktu. Te zachowania powinno się być w stanie powiązać z wartością dla biznesu, nie tylko w takich sytuacjach jak “większa wartość koszyka zakupów”.

To nie są proste rzeczy. Dużo łatwiej tłumaczyć je mówiąc czego nie robić. Naprawdę trudne jest tu odejście od nazywania zadań lub funkcjonalności w KR. One powinny się pojawić dopiero po wyjaśnieniu celów na najbliższe miesiące.

Jak to wpływa na zespoły

Cele są podstawą do priorytetyzacji backlogu produktu, listy zmian do wprowadzenia. Zespół rozwijający produkt musi ustalić, które z nich są najbardziej efektywne. Innymi słowy: co przy najmniejszych kosztach najszybciej zbliża do realizacji celu.

Gdy zaczniemy mierzyć efekty wprowadzanych zmian zobaczymy, że nie warto działać, w oparciu o “dobre pomysły” i intuicję. Wiedzę o tym, co warto zbudować, uzyskuje się pracując z użytkownikami, robiąc testy i weryfikując hipotezy produktowe. Nie jest to łatwe, ale takie podejście ogranicza wydatki na zbędne funkcje. Czas developmentu sporo kosztuje, a wprowadzone zmiany trzeba utrzymywać.

Na początek najłatwiej zająć się poprawianiem istniejących rzeczy. Nawet średnio rozbudowany produkt ma wiele funkcji, które mogą działać lepiej. Jest na ich temat sporo danych – statystyka zachowania użytkowników a także płynący od nich feedback.

Warto stale sprawdzać na co wpłynęły zmiany. To pozwala przekonać się jak niewiele rzeczy coś daje. To pierwszy krok na drodze odejścia od tradycyjnych roadmap i zmniejszania strat, jakie powstają w rozwoju.

Wpis opublikowany w maju 2019, zaktualizowany w styczniu 2021.


Warsztat otwarty "OKRy w praktyce" 24 czerwca. Ostatnie miejsca.