Jak ma wyglądać roadmapa w zwinnym rozwoju produktu? Jak wykorzystać cele produktu, by zamiast tworzyć niepotrzebne funkcjonalności skupić się na potrzebach użytkowników? Jaka jest relacja OKR z celami sprintów i backlogami?

Firmy produktowe zbyt często tworzą funkcjonalności, których nikt nie używa. By od tego odejść, trzeba porzucić tradycyjne tworzenie roadmap opartych o nazwy funkcjonalności i potencjalnych rozwiązań. Trzeba się również pozbyć większości dat.

Roadmapa jako plan i zobowiązanie

Roadmapa produktu to plany rozwoju nałożone na kalendarz. Pokazuje co zespół zamierza wdrożyć w kolejnych miesiącach. Funkcjonalności i daty określa z dużym wyprzedzeniem. To jednak fikcja, która się nie sprawdza. Roadmapa nie może być traktowana jak wykuty w kamieniu plan. Powinna żyć i pomagać w podejmowaniu decyzji o priorytetach.

Jeden z typowych szablonów roadmap.

W produkcie nie wystarczy w styczniu ustalić roadmapę na cały rok a potem ją realizować. Na etapie planowania nie wiemy ile czasu zajmie zaprogramowanie i wdrożenie każdej ze zmian. Nie możemy być pewni jak wpłynie ona na zachowanie użytkowników. Nie mamy też pojęcia co się wydarzy na rynku i w otoczeniu, zmieniając nasze plany. W efekcie podane w roadmapie terminy realizacji i korzyści z wprowadzanych funkcjonalności są przeszacowane. Zawsze w złą stronę a im dalej w przyszłość, tym bardziej.

Plany rozwoju produktu są przestrzenią interesów – wiele osób stara się, by trafiły tam rzeczy dla nich ważne. Zarządowi zależy na szybkości realizacji, ale jego członkowie też mają pomysły na zmiany. Marketing chce lepszej rejestracji, dział sprzedaż funkcji, o którą pytają klienci a obsługa klienta domaga się poprawy często zgłaszanego problemu. Wszyscy “wiedzą” co trzeba zmienić i chcą tylko wiedzieć “kiedy będzie wdrożone”. Gdy te oczekiwania trafiają do roadmapy, ich kolejność i terminy ukończenia traktuje się jak zobowiązanie zespołów, które rozwijają produkt.

Z czasem okazuje się, że daty są przekraczane. Zaczyna się szukanie winnych. W najlepszym wypadku próbuje się znaleźć sposób na “poprawę systemu”. Wprowadza się zmiany, ale daty w kalendarzu długoterminowych planów produktowych zostają. Potem cykl się powtarza.

Lepszy kalendarz funkcjonalności

Zderzenie z rzeczywistością weryfikuje założenia każdego planu, również te stojące za roadmapą. Dlatego z czasem najwięcej wiemy o najbliższych zmianach i możemy o nich rozmawiać dość odpowiedzialnie. Wniosek jest oczywisty – szczegółowe plany na długi czas trzeba zastąpić takimi, które zawierają mniej informacji, ale są regularnie omawiane. Wszystko co ma się zdarzyć później niż za kwartał znane jest tylko w zarysie i tak też powinno być opisane.

Odległe daty mogą dotyczyć rzeczy, które wynikają z okoliczności zewnętrznych (np. zmiany w prawie). Też nie wiemy ile zajmą, ale zwykle związane z nimi wymagania są na tyle precyzyjne, że da się to ustalić z dużym przybliżeniem. Często wiadomo dlaczego te zmiany są niezbędne. Nie da się tego powiedzieć o większości funkcjonalności, które wypełniają plany rozwoju produktu.

Tradycyjnie roadmapa nazywa możliwości i funkcje jakie mają zostać wprowadzone. Zakłada się, że wpłyną pozytywnie na produkt i użytkownika. Tymczasem nie więcej niż jedna czwarta takich założeń się sprawdza, a z większości wprowadzanych możliwości użytkownicy nie korzystają. Produkty mogłyby działać i odnosić sukcesy również bez nich.

Menedżerowie firm rozwijających produkty powinni o tym wiedzieć co najmniej od 10 lat. Około 2010 roku ukazały się książki “Lean Startup” Erica Riesa i “Inspired” Marty Cagana, które opisują meandry tworzenia produktów cyfrowych. Ich autorzy wałkują temat błędnych decyzji podejmowanych w rozwoju produktu. Pokazują, jak często budując funkcjonalności przyjmujemy fałszywe założenia. Zdumiewające, że ta wiedza nie jest powszechna.

Potrzeby zamiast rozwiązań

Problem z datami w roadmapach kojarzy się przede wszystkim z IT. Szacowanie terminów przy rozwoju oprogramowania zawsze było wyzwaniem. Na starcie, zanim powstanie dokładny projekt, nie wiadomo co trzeba napisać, żeby zbudować funkcjonalność. Potem wyzwaniem są testy i integracja z istniejącym systemem. Przez ostatnią dekadę sporo uwagi poświęcono poprawie procesów dostarczania oprogramowania. Coraz mniej tu niespodzianek, budowanie stało się nieco bardziej przewidywalne, jest też lepiej rozumiane. Jednak samo wdrożenie to nie koniec drogi.

Lubimy “myśleć rozwiązaniami” dlatego w roadmapach znajdują się przede wszystkim funkcjonalności. Wyzwanie w produkcie nie polega jednak na tym, żeby udostępnić funkcję. Sukces osiąga się dopiero wtedy, gdy użytkownicy z niej korzystają i są z tego zadowoleni. Trzeba zapewnić, że będą w stanie ją znaleźć, zrozumieć i użyć. Dlatego musi być dobrze zaprojektowana. Przede wszystkim jednak musi być potrzebna – powinna rozwiązywać istotny dla nich problem i zaspokajać ich potrzebę.

Nie da się rozwijać produktu bez znajomości potrzeb użytkowników. To potrzeby powinny determinować co zbudować, nie odwrotnie. To, gdzie występują największe związane z nimi wyzwania i w jakiej kolejności warto je zaspokajać powinno być podstawą decyzji rozwojowych i głównym tematem planowania.

Roadmapa oparta o potrzeby i wyzwania nazywana jest “tematyczną”. Zwykle ma trzy horyzonty. Realizowane właśnie zmiany są opisane w sekcji “Teraz”. Za nimi czekają dość dobrze już rozpoznane tematy pod hasłem “Wkrótce”. Zarysowane tylko są zagadnienia, które występują w części “Potem”. Często nigdy nie trafiają do realizacji, dlatego nie ma dużego znaczenia jak je nazwiemy. Im bliżej coś jest sekcji “Teraz” tym lepiej powinno być określone. Najlepiej w postaci średnioterminowych celów produktu.

Cele w produkcie

Najczęściej stosowany cel w rozwoju produktu to cel sprintu z metodyki Scrum. Pracujące w niej zespoły do określania celów nigdy się nie przykładały. To jednak się zmienia.

Opublikowana 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ę jego rozwojem. Ma to być “przyszły stan” produktu. Co trzeba z tym zrobić?

Przede wszystkim ustalić komu i do czego produkt ma służyć. Te informacje tworzą wizję produktu, która mówi jak powinno być za 2-3 lata. Cel sprintu opisuje krótki czas, do dwóch tygodni. Brakujący element to najbliższy etap na drodze realizacji wizji: cel na dwa do sześciu miesięcy. Tu sprawdzi się format OKR, w którym elementy celu odpowiadają na dwa pytania: co chcemy osiągnąć i po czym poznamy, że się udało.

Objective mówi co ma być lepsze: wygodniejsze, bardziej dostępne, prostsze. Powinna być to jedna, konkretna rzecz. To sformułowanie oznacza doprecyzowanie tematu zmiany albo bardzo dobrą odpowiedź na pytanie “Co chcemy osiągnąć wdrażając tę funkcję”. Z zastrzeżeniem, że wskazuje ona na rzeczywisty, istotny problem i wcale nie musi prowadzić do wdrożenia “tej funkcji”.

Kluczowe Rezultaty mają mierzyć efekt realizacji celu – najlepiej zmianę zachowania użytkowników. Dowodem na to, że modyfikacja w produkcie coś dała jest właśnie zmiana w zachowaniu użytkowników. Może polegać na tym, że przestaną o coś pytać (Jak użyć tej funkcji lub Jak to zrobić?), będą robić czegoś więcej (używać funkcji) lub sprawniej (zajmie im to mniej czasu). Można mierzyć też zmianę zachowania systemu – gdy wiadomo, że wpływa na postrzeganą przez użytkowników jakość. Bezpieczny przykład to przyspieszenie działania aplikacji.

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

Wpływ roadmapy tematycznej na pracę zespołu

Gdy skupiamy się na potrzebach okazuje się czasem, że ich zaspokojenie można osiągnąć prostszymi środkami niż budowanie konkretnej funkcji. Wymaga to jednak sporej zmiany w podejściu do rozwoju produktu.

Zespoły produktowe działają dziś przeważnie w oparciu o backlogi – ułożone listy rzeczy do zrobienia. W świecie roadmapy tematycznej ich zawartość i kolejność powinna zależeć od tego, które zmiany przy najmniejszych kosztach najszybciej prowadzą do realizacji celu. Skąd to wiadomo? Na początku te decyzje opiera się o przekonania i założenia. Często bazują one na obserwacji i doświadczeniu, ale nadal pozostają tylko hipotezami. Ich weryfikacja i poszukiwanie rozwiązań, które zaspokoją realne potrzeby – na to zespoły produktowe powinny poświęcać najwięcej czasu.

Zadaniem rozwijających produkt jest weryfikować potrzeby i testować rozwiązania zanim zaczną być budowane. W efekcie – lepiej wybierać i redukować koszt realizacji. Powinni stale mierzyć efekty zmian i wyciągać wnioski. To oznacza naukę definiowania wartości, mierzenia zachowania użytkowników i dużo “niewidocznej” pracy. To jedno z większych wyzwań – robione są tu rzeczy, których po prostu nie widać.

Rozumie to coraz więcej ludzi zajmujących się rozwojem produktu. Rozmawiając z nimi i czytając to, co piszą na serwisach społecznościowych, można jednak odnieść wrażenie, że są w tym osamotnieni. Ich głównym zadaniem nie jest praca z użytkownikiem i poszukiwanie rozwiązań tylko przekonywanie otoczenia—”interesariuszy”—którzy zwykle o procesie rozwoju produktu mają pojęcie z czasów zarządzania projektami, a to zupełnie inne dziedziny. To jest jak para w gwizdek – strata czasu kompetentnych ludzi.

Nie zmieni się tego bez zwiększenia świadomości managementu. Wprowadzenie sensownego podejścia do rozwoju produktu i opartej na celach roadmapy tematycznej powinno ograniczyć wydatki na tworzenie i utrzymanie niepotrzebnych funkcji. Powinno zmniejszyć ilość pracy i zamieszania związanego z tworzeniem fikcyjnych planów. Wynikająca ze zrozumienia potrzeb użytkownika priorytetyzacja powinna natomiast korzystnie wpłynąć na jakość produktu. W dłuższym terminie może się to tylko opłacać.

Aby pogłębić temat przeczytaj wpis Metryki w rozwoju produktu cyfrowego.

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