Roadmapy i OKRy – jak to pogodzić?

Jaki sens ma roadmapa w zwinnym rozwoju produktów? Jak powinna wyglądać, gdy wykorzystujemy OKRy? Co się dzieje, jeśli plany zastąpi się celami?

Rozwój produktów bazujących na oprogramowaniu to jedno z najczęstciekawszych miejsc do wykorzystania podejścia Objectives and Key Results. Dobrze postawione cele i stała rozmowa o nich może zastąpić tradycyjne planowanie i tworzenie roadmap.

Roadmapa z założeń

Roadmapa to plany rozwojowe nałożone na kalendarz. Pokazuje czym zespoły rozwojowe będą się zajmować w kolejnych miesiącach i jakie zmiany wprowadzą. W idealnym świecie wystarczyłoby ustalić wszystko w w styczniu a potem trzymać się tego i zgodnie z planem wdrożyć coś np. we wrześniu.

Jeden z typowych szablonów roadmap.

W rzeczywistości to nie działa. Rzadko z wyprzedzeniem jesteśmy w stanie przewidzieć niespodzianki jakie przynosi rozwój a także choćby zachowanie użytkowników i zmiany na rynku. W szczególności nie wiemy ile coś może zająć. Terminy i korzyści z planowanych zmian są w takich planach przeszacowane. Zawsze w złą stronę a im dalej w przyszłość, tym bardziej.

Dlatego roadmapę trzeba traktować jak plan orientacyjny. Jej dokładność powinna „z czasem” maleć. Powyżej 3 miesięcy od dziś powinny być to tylko ramy, wstępne decyzje na temat tego, czym powinniśmy się zająć. Wyjątki i konkretne daty mogą dotyczyć np. tylko rzeczy, które wynikają np. ze zmian w prawie. O nich wiemy, że są potrzebne i muszą spełnić określone, znane z wyprzedzeniem założenia.

Sztuka planowania

Snucie planów jest łatwe, dobre planowanie trudne. Więc jak to robić? Odpowiedź może przynieść zrozumienie, jakie funkcje ma pełnić plan. Powinien najpierw wymuszać podjęcie decyzji o priorytetach, potem umożliwić komunikację i dać pretekst do regularnej rozmowy o postępie.

Wyboru priorytetów dokonujemy odpowiadając na pytanie, dlaczego coś jest ważne, dlaczego warto się tym zająć. Odpowiedzi na te pytania powinny stanowić kontekst i dawać wszystkim w firmie wiedzę o tym, dokąd zmierzamy. Roadmapa czy inny plan powinny wynikać ze strategii i długoterminowych celów (nie odwrotnie).

Świadomość, że – jak każdy plan – jest to tylko zbiór założeń powinna spowodować dwie rzeczy. Po pierwsze, że będzie to dokument w miarę „lekki”, a po drugie – że będzie wymagał aktualizacji. Zespół liderski, nie rzadziej niż raz na kwartał, powinnien rozmawiać o postępie zmian i decydować co się zmienia uwzględniając aktualne informacje.

Cele jako plany

Usłyszałem na jednym z warsztatów, że „OKRy to taka roadmapa”. Gdy ustalimy co firma chce osiągnąć w ciągu roku, pierwszy cykl planownia kwartalnego powie, czym zajmą się zespoły, żeby ten plan zrealizować.

Proces OKR wymusza wypełnienie funkcji komunikacyjnej, a aktualizacje i stawianie celów w kolejnych cyklach umożliwiają kontrolę realizacji i aktualizację planów. Dzięki nim stale kontrolujemy kurs. Mamy substytut roadmapy w wersji lekkiej.

Czy to oznacza, że starej roadmapy należy się pozbyć? Z czasem będzie to możliwe, w początkowym okresie jednak można się nią wspierać by mieć dobry materiał do wyboru celów. Z założenia w OKRach będzie ich się mieściło mniej niż w roadmapie. Roadmapy są zwykle pojemne, co jest paradoksem, bo kalendarz nie jest.

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”

W OKR informacje o planach są w porównaniu z tradycyjnymi roadmapami będą dość niedokładne. Zamiast rozpiski projektów ustalamy priorytety zawarte w celach i miarach zapisanych w metodzie.

Treść jest tu kluczową zmianą.W roadmapie mówi się „co powstanie”. Dobrze postawione OKRy nie powinny mówić „co zbudujemy” ale jaką zmianę chcemy uzyskać. Na początku drogi zwykle nie wiemy, co ją spowoduje. Dlatego w roadmapach pisanie list rzeczy do zbudowania zamiast definiowania tematów i obszarów zmian jest błędem, natomiast cele nie mogą być listami rzecz do zbudowania.

Jeśli skupiamy się na zamiarach (co chcemy poprawić) a nie założeniach (co powstanie) to zmienia się sposób pracy zespołów, które realizują zmiany.

Jak to wpływa na zespoły

Pisząc OKRy zespołowe odchodzimy od rozmowy nt. dodawania funkcjonalności i przechodzimy na język korzyści, które mają przynieść zmiany. To wyzwanie o większej skali niż samo porzucenie „centralnego planowania”. Wymusza na zespołach zaproponowanie czegoś – wciąga ich w rozmowę o tym, co zamierzają osiągnąć. To lepsze dla nich, ale na początku bywa trudniejsze niż dotychczasowe „podpinanie się pod roadmpę”. Choćby dlatego, że zespoł może coś zaproponować dopiero, gdy wie, za co odpowiada – a bez inwestycji w autonomię często nie jest to jasne.

W rozwoju chodzi o to, żeby zawsze robić najbardziej wartościową rzecz. Tę, która przyniesie najwięcej korzyści przy najmniejszych kosztach. Cele i zawarte w nich miary mają pomagać w wyborze i prorytetyzacji backlogu. W praktyce jednak bardzo rzadko wiemy, czy coś rzeczywiście przyniesie korzyść.

Stosując rygorystycznie miary z KRów będziemy się przekonywać jak często się mylimy. Zaczyna mieć sens poszukiwanie rzeczy, które rzeczywiście przynoszą wartość. Tego też trzeba się nauczyć, a jest to spore wyzwanie. Potrzebna jest cierpliwość i gotowość do nauki.

Nowa duża rzecz

Wskutek autonomii i takiego podejścia zespołom łatwiej zająć się poprawianiem istniejących rzeczy. W mniejszym stopniu realizując cele będa budować nowe. Ma to sens, bo nawet średnio rozbudowany produkt, który spełnia już potrzeby użytkowników ma dziesiątki funkcji, które mogą działać lepiej. Co jednak robić, gdy wiadomo, że trzeba coś zbudować?

Może to być funkcja, znaczna zmiana w aplikacji lub całkowita przebudowa. Podstawą do uruchomienia prac jest zwykle odgórna inspiracja, wynikająca choćby z realizacji strategii. Czyli mamy większy plan, w ramach którego powinno powstać coś istotnego. Najczęściej wiążą się z tym dwie rzeczy: przeszacowane korzyści (coś ma dać bardzo dużo) i niedoszacowany koszt pracy (znowu).

Możemy wydać bardzo dużo na rozwój zanim dowiemy się, czy było warto. Jeśli się nie powiedzie, oznacza to straty, których nie lubimy. Wiemy to już dziś – choćby na podstawie doświadczeń. Takie słonie jednak nie wyginą i również na minimalizację strat z nimi związanych trzeba znaleźć sposób – to jednak materiał na osobny wpis.

////

Nie podaję przepisu – zależy mi raczej na opisaniu fundamentów. Trzeba znaleźć własną drogę i samo jej poszukiwanie zajmuje od 6 miesięcy do 2-3 lat, w zależności od doświadczenia, skali i kultury organizacji.

Ten wpis oparty jest na praktyce oraz na sporej liczbie źródeł – od tekstów Marty’ego Cagana, Henrika Kniberga czy Jeffa Gothelfa po książki – takie jak „Lean Startup”. Nie cytuję ich tu, ale od czasu do czasu w newsletterze wysyłam zestawienia tekstów na takie tematy, które uważam za warte poznania.


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.