Roadmapa produktu i OKRy: jak to pogodzić?

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

Rozwój produktów cyfrowych to dobre miejsce do wykorzystania Objectives and Key Results. Określone cele i stała rozmowa o efektach wprowadzanych zmian mogą pomóc ograniczyć straty i poprawić jakość produktu. By tak jednak się stało trzeba porzucić tradycyjne planowanie i tworzenie roadmap.

Roadmapa i iluzja planowania

Roadmapa to plany rozwoju produktu nałożone na kalendarz. Pokazuje jakie zmiany 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 to nie działa. 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. Na dodatek plany często powstają bez udziału ludzi, którzy będą je realizować. W efekcie terminy realizacji i korzyści ze zmian są przeszacowane. Zawsze w złą stronę a im dalej w przyszłość, tym bardziej.

Planowanie daje nam fałszywą iluzję bezpieczeństwa. Znamy to z życia – w sytuacji kryzysowej, po spisaniu listy rzeczy, które trzeba zrobić zaczynamy czuć się lepiej, choć nic się jeszcze nie wydarzyło. Gdy coś jest tylko zaznaczone w kalendarzu traktujemy to tak, jakby już miało mieć miejsce. W produkcie wszelkie plany realizacji są przestrzenią interesów – każdy z zaangażowanych stara się, by trafiły tam rzeczy dla niego ważne. Potem te ustalenia traktuje się jako zobowiązania.

Gdy okazuje się, że terminy są przekraczane, prowadzimy rozmowy o tym co miało być, choć w zasadzie powstać nie mogło. Potem cały cykl się powtarza. Wprowadza się różne zmiany organizacyjne, ale jedno się nie zmienia – odległe daty w kalendarzu planów produktowych pozostają fikcją.

Plan bez dat

Samo planowanie nie jest niczym złym. Potrzebujemy rozmów o przyszłości, by przygotować działania i podejmować decyzje. Wiedząc jednak co zwykle dzieje się z planami, warto odejść od dokładnych długoterminowych 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 nie zależą od planujących jak np. zmiany w prawie.

Zmiany wprowadzane w najbliższych miesiącach dotyczą spraw, o których dużo już wiemy. Tu terminy są już bardziej realne. Mogą też być potrzebne do koordynacji działań związanych np. z wprowadzaniem produktu na rynek.

Cele jako plany

Tradycyjnie roadmapa mówi o tym co “zbudujemy”. Nazywa planowane zmiany i terminy ich wprowadzenia. Zakłada, że warto je robić, ponieważ wpłyną pozytywnie na biznes lub realizację funkcji produktu. Tymczasem nie więcej niż jedna czwarta takich założeń się sprawdza i nie jest to nowa wiedza.

Menedżerowie produktu i szefowie firm produktowych powinni o tym wiedzieć co najmniej od 10 lat. Około 2011 roku ukazały się książki “Lean Startup” Erica Riesa i “Inspired” Marty Cagana, które opisują meandry rozwoju produktów cyfrowych. Autorzy wałkują temat błędnych decyzji podejmowanych w tym procesie. Większość założeń dotyczących wpisywanych w plany funkcjonalności jest równie fikcyjna jak daty, które ich dotyczą. Zdumiewające, że ta wiedza nie jest powszechna.

Nie wiemy więc jakimi zmianami w produkcie uzyskać pożądany efekt. Gdy to zrozumiemy, jasne się stanie, że zamiast mówić co wdrożymy, powinniśmy decydować o tym, co chcemy osiągnąć i w jakiej kolejności. Innymi słowy: określać jakie mamy w produkcie cele.

Poziomy celów w produkcie

Dziś najczęściej stosowany cel w rozwoju produktu to cel sprintu z metodyki Scrum. Działające w niej zespoły do stawiania celów bardzo się nie przykładają. Tak przynajmniej wynika z doświadczeń scrum masterów i wpisów ekspertów na ten temat. To jednak się zmienia.

Wydana w 2020 roku aktualizacja “Scrum guide”, oficjalnego przewodnika po metodzie, wzmocniła znaczenie celów. Zgodnie z nią, długoterminowy cel produktu jest zobowiązaniem zespołu, który zajmuje się rozwojem. Ma to być “przyszły stan” produktu. Jak to zastosować w praktyce?

Przede wszystkim osoby odpowiedzialne za produkt powinny wyjaśnić komu i do czego produkt ma służyć – dokąd zmierza jego rozwój. Takie informacje tworzą wizję produktu, która jest celem, zwykle opisującym jak ma być za 2-3 lata. Są opisane różne formaty wizji, warto wybrać jeden i się nim stale posługiwać.

Cel sprintu jest określany na krótki okres, gdy wiadomo co należy zbudować i jaki będzie tego efekt. Między sprintem a wizją potrzebny jest cel pośredni, który odpowie na pytanie “co jest najważniejsze”. Mogą tu być nawet dwa poziomy – mówiący o zmianie jaka ma nastąpić w ciągu roku i o najbliższym okresie, obejmującym od dwóch do sześciu miesięcy. Tu sprawdzi się format OKR z nazywającym zmianę Objective i mierzącymi zachowanie użytkowników Kluczowymi Rezultatami.

Zmiana zachowania może oznaczać, że użytkownicy zaczynają częściej korzystać z jakiejś funkcji, że coś zajmie im mniej czasu lub, że wyrażają lepszą opinię na temat produktu. Te zmiany można powiązać z wartością dla biznesu. Gdy użytkownicy chwalą produkt, łatwiej znajduje on kolejnych nabywców, co wpływa korzystnie na sprzedaż itp.

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”

Jak to wpływa na zespoły

Cele są podstawą priorytetyzacji planu zmian. To one determinują co robić, nie odwrotnie: nie tworzy się celów na podstawie listy rzeczy do zrobienia. Zespół rozwijający produkt powinien ustalić, które z propozycji przy najmniejszych kosztach najszybciej prowadzą do realizacji celu. Pytanie jak to zrobić.

Wiemy już, że nie warto działać w oparciu o intuicję i “dobre pomysły”. Niewiele z nich w rzeczywistości wpływa na zachowanie użytkowników. Zanim cokolwiek zbudujemy warto sprawdzić jakie są szanse, że wywoła pożądany efekt. Tutaj jest największa zmiana w procesie produktowym i zwyczajach z nim związanych.

W świecie budowania “ficzerów” i roadmap po prostu budowaliśmy. Pracując na celach trzeba stale mierzyć i sprawdzać efekty zmian. Zainwestować w metody, które pozwolą przekonać się czy warto zanim cokolwiek zbudujemy. To się jednak opłaca, ponieważ pozwala zmniejszyć straty. Ogranicza wydatki na tworzenie a także utrzymanie zbędnych funkcji.

Wpis opublikowany w maju 2019, zaktualizowany we wrześniu 2021.


Warsztat otwarty "OKRy w praktyce". Zapraszamy.