Roadmapa jako plan będący listą funkcjonalności w postaci wykresu Gantta – znasz to? To najczęściej spotykany sposób prowadzenia Roadmapy. Współczesne Zespoły Produktowe proponują jednak inne podejście – Roadmapy rezultatów, w których zamiast na dostarczanych funkcjonalnościach, skupiamy się na planowanych rezultatach.
O podejściu tym pierwszy raz usłyszałam słuchając rozmowy Marii Chec z Pawłem Hurynem w „Agile state of mind”. Wydało mi się ono ciekawe i zainspirowało mnie do zgłębienia tematu. Zapraszam Cię do wyników mojego researchu!
PO CO NAM ROADMAPA?
Roadmapa jest artefaktem, którego celem jest ujęcie strategii Produktu i ukazanie jak będzie ona wspierać osiągnięcie celów biznesowych [3]. Pomaga ukazywać dalekosiężne plany i prowadzić wartościowe rozmowy na temat rozwoju Produktu z Zespołem, Interesariuszami i organizacją.
Za utrzymanie Roadmapy zwyczajowo odpowiada Product Owner, choć kontrybuować do jej tworzenia powinni również Interesariusze i Zespół Scrumowy. Roadmapa nie jest elementem Scruma, natomiast jest często wykorzystywanym narzędziem, dzięki któremu Product Owner może realizować swoją rolę.
Dobrze zbudowana Roadmapa dodaje przejrzystości do planowania i komunikacji rozwoju Produktu. Pomaga uzyskać wspólne rozumienie planów na przyszłość.
ROADMAPA FUNKCJONALNOŚCI
Najczęściej spotykaną formą Roadmapy jest listą zaplanowanych funkcjonalności, których data dostarczenia jest widoczna na osi czasu. Jest to popularny wykres Gantta (przykład poniżej).
Źródło. Przykładowa Roadmapa funkcjonalności
Takie Roadmapy można zazwyczaj spotkać w środowiskach, które potocznie nazywane są „Feature factory”. Zespoły pracujące w ten sposób skupiają się jedynie na tworzeniu nowych funkcjonalności, nie za bardzo wiedząc jakie potrzeby i pragnienia użytkowników spełniają, a zatem jaką wartość dostarczają. Najczęściej Zespoły te nie mierzą korzyści wynikających z wdrażanych rozwiązań. Czy ktoś używa nowej funkcji? Czy działa ona optymalnie? Czy można ją usprawnić? Czy dostarczyliśmy wartość? Nikt nie zadaje tych pytań. Na dostarczeniu funkcjonalności się kończy – można ogłosić sukces.
Wracając jednak do omawianego artefaktu…
Dobra Roadmapa powinna ułatwiać rozmowę o planach na przyszłość w kontekście celów biznesowych. Powinna inicjować rozmowy o kierunku rozwoju Produktu. Ta Roadmapa tego nie robi, bowiem ciężko z listy funkcjonalności uchwycić szerszy obraz sytuacji i odpowiedzieć na pytanie „dlaczego” wykonujemy dane elementy. Nie ukazują jasno wartości, która płynie z dostarczenia danych funkcjonalności. Trudno na jej podstawie uchwycić jak planowane czynności będą zaspokajać potrzeby i pragnienia użytkowników, by napędzać sukces Produktu.
Pokazują natomiast, że Zespoły są zajęte dostarczaniem funkcjonalności. Czy są one wartościowe? Z tej Roadmapy tego nie wyczytamy.
Roadmapy funkcjonalności dają złudne poczucie, że wszystko jest pod kontrolą (np. daty wdrożeń). Patrząc na taką Roadmapę, możemy wyciągnąć niefortunne wnioski, że elementy na niej umieszczone są zobowiązaniem (ang. commitment). A przecież feedback od użytkowników, metryki i inne narzędzia empiryczne ( o ile z nich korzystamy 😉 ) mogą wymusić na nas zmianę planu działania.
Release Plan?
Taka Roadmapa funkcjonalności jest de facto Release Planem. Nie pokazuje strategii. Pokazuje natomiast taktykę, czyli konkretne kroki, które zamierzamy podjąć. Dokładnie wskazuje jakie funkcjonalności będziemy dostarczać i kiedy.
ROADMAPA REZULTATów
Alternatywą do „standardowych” Roadmap jest tzw. Outcome-based Roadmap (OBR). Ukazuje ona oczekiwane rezultaty produktowe przyszłych prac, które wynikają z celów biznesowymi. Roadmapa taka jest pomostem pomiędzy wizją Produktu, a taktyką, którą będziemy realizować.
Zamiast skupiać się dostarczanych funkcjonalnościach (output), pokazujemy jakie rezultaty dla użytkowników planujemy osiągnąć (outcome).
Roadmapa rezultatów będzie prezentować strategię, czyli plan działań, który pozwoli osiągnąć cel. Daje framework do podejmowania decyzji, który jest stale wykorzystywany przez Zespół w dążeniu do rezultatów, które finalnie umożliwią osiągnięcie celu i wizji Produktu.
Więcej o różnicach między output, outcome i impact pisałam tutaj.
Zalety skupienia na rezultatach
Roadmapa rezultatów przynosi Zespołom wiele korzyści. Umożliwia skupienie się na tym co przyczyni się do osiągania celów biznesowych. Zamiast ślepego dowożenia nowych funkcjonalności, umożliwia całościowe patrzenie na Produkt, uwzględniając również perspektywę potrzeb biznesowych.
Z perspektywy Interesariuszy
Taka Roadmapa umożliwia wartościowe rozmowy o planach z Interesariuszami. Dużo łatwiej będzie nam prowadzić rozmowy o skutkach dla użytkownika niż o konkretnych funkcjonalnościach. Wprost nazwiemy potrzeby i pragnienia użytkowników i umieścimy na Roadmapie. Pozwoli to Interesariuszom lepiej zrozumieć kierunki prac i interweniować, gdy pojawi się pilniejszy aspekt biznesowy do zagospodarowania.
Dodatkowo, będziemy wskazywać związek rezultatów produktowych (ang. outcome) z ich wpływem na wzrost biznesu (ang. impact). Na podstawie tych informacji będą mogli planować budżet, działania marketingowe i sprzedażowe [2].
Z perspektywy Zespołu
Taka Roadmapa daje Zespołom autonomię w szukaniu najlepszych sposobów na dotarcie do oczekiwanego rezultatu. Generowane przez nich rozwiązania, będą przynosić pozytywne skutki dla użytkowników i zmieniać ich zachowania, w sposób, który umożliwi osiągnięcie jasno wytyczonych celów biznesowych. Dana elastyczność motywuje Zespół i daje poczucie odpowiedzialności za Produkt.
Kolejność elementów w Product Backlogu będzie bezpośrednio i logicznie wynikała z Roadmapy. Priorytetyzacja staje naprawdę łatwa, gdy wiemy jaki problem próbujemy rozwiązać i do osiągnięcia jakich rezultatów dążymy.
JAK WYGLĄDA ROADMAPA REZULTATów?
„The GO Roadmap”
Źródło. The Go Roadmap. Roman Pichler
„The GO Roadmap” jest propozycją pochodzącą od Romana Pichlera [6]. Przejdźmy przez poszczególne elementy tej Roadmapy:
Goal, czyli cel jaki planujemy osiągnąć. Najważniejszy element tego szablonu. Wpisujemy tutaj rezultat (ang. outcome) lub wartość, którą planujemy dostarczyć dla użytkownika lub biznesu. Odpowiadamy na pytanie „dlaczego” rozwijamy dany kawałek Produktu. Cele te mogą być tworzone za pomocą np. modelu S.M.A.R.T.
Date, czyli data, do której planujemy osiągnąć dany cel. I choć jest wielu przeciwników stosowania dat na Roadmapach, to w praktyce określenie ram czasowych jest często wymagane przez organizacje i Interesariuszy. Jeżeli Twoją Roadmapą dzielisz się z użytkownikami końcowymi, staraj się unikać podawania konkretnych dat. Zamiast tego możesz użyć np. kwartałów lub całkowicie usunąć ten wiersz.
Name, czyli nazwa lub numer wydania. Używamy tego wiersza, jeżeli osiągnięcie celu jest zbieżne z wydaniem nowej wersji oprogramowania.
Features, czyli funkcjonalności umożliwiające osiągnąć dany cel. Określamy na tym etapie output przyczyniający się do uzyskania rezultatu dla użytkownika. Wysokopoziomowo, czyli bez zbędnych szczegółów, określamy funkcjonalności lub nowe możliwości Produktu. Najlepiej ograniczyć się do podania 3-5 funkcjonalności na cel.
Metrics, czyli miary, które pozwolą nam zweryfikować czy osiągnęliśmy dany cel. Określamy czym jest sukces i jak go zmierzymy. Definiujemy wskaźniki skupione na dostarczonej wartości Produktu. Jest to kluczowy element empirycznego tworzenia Produktu.
Darmowy szablon do wydrukowania można ściągnąć tutaj.
Now, Later, Future
Innym podejściem są Roadmapy bez określania konkretnych dat [4, 10]. W końcu w złożonym środowisku ciężko przewidzieć kiedy ukończymy inicjatywę i osiągniemy oczekiwany rezultat. W szczególności, jeżeli do rozwoju Produktu wykorzystujemy metody Product Discovery. Robimy zatem założenia i ukazujemy nasze plany w formie Now, Next, Later.
Źródło. Roadmapa Now, Next, Later. Paweł Huryn
Roadmapa jest narzędziem do komunikowania wysokopoziomowych planów i strategii na rozwój Produktu. Dlatego podejście, w którym rezygnujemy z dat ma sporo sensu. Zamiast tego korzystamy z trzech kolumn:
Now, czyli to nad czym aktualnie pracujemy w bieżącym kwartale.
Next, czyli co planujemy na następny kwartał.
Later, czyli cała reszta. Wszystkiego co nie mieści się w najbliższym półroczu, nie ma sensu dokładnie planować. Z biegiem czasu może się dużo zmienić. Praktykując empiryczne podejście do tworzenia Produktu wiele się uczymy, a zdobyta wiedza może zmienić naszą perspektywę na dalszy rozwój Produktu.
Dodatkowo, Roadmapa skupiająca się na rezultatach będzie miała dwa rodzaje wierszy:
Product Outcomes, czyli cele lub rezultaty, które planujemy osiągnąć w Produkcie. Powinny wynikać z celów biznesowych. Cele tworzone w modelu S.M.A.R.T będą konkretne, mierzalne i określone w czasie.
Customer Needs, czyli potrzeby użytkownika, które będziemy starać się spełnić w ramach pracy nad danym rezultatem / celem. Takie podejście umożliwia np. budowania planów marketingowych bazujących na wartości, którą dostarczamy użytkownikowi [10]. Na koniec bowiem nie chodzi o konkretne funkcje, tylko o zapewnienie by Produkt spełniał potrzeby i pragnienia, tych którzy z niego korzystają.
Themes & Initiatives
Kolejny szablon Roadmapy bazuje na grupowaniu jej elementów wykorzystując tematy przewodnie (ang. themes) i inicjatywy (ang. initiatives) [3].
Źródło. Przykład Roadmapy skupionej na rezultatach według Elan Sviridenko
Autorka proponuje 3 poziomy podziału:
Themes, czyli tematy przewodnie jako najwyższy z poziomów. Określają obszar skupienia prac i definiują oczekiwany rezultat. Dają możliwość połączenia z celami biznesowymi.
Initiatives, czyli inicjatywy jako środkowy z poziomów. Określają kierunek prac i sterują podejmowanymi taktykami. Można o nich myśleć jako o kategorii dla Epiców.
Epics, jako najniższy z poziomów. Kolekcja połączonych ze sobą tematycznie historyjek użytkownika (ang. User Stories), najczęściej tworzących daną funkcjonalność. Określa output realizujący przypisaną inicjatywę.
Do każdego takiego wiersza można dodać interesujące szczegóły takie jak: status, horyzont czasowy, priorytet czy poziom ryzyka.
By ułatwić rozmowę z Interesariuszami można również zwizualizować taką Roadmapę w formie tabeli z podziałem na Now, Next i Future.
Źródło. Roadmapa Now, Next, Future. Elan Sviridenko
4 KROKI BY STWORZYĆ ROADMAPĘ REZULTATÓW
#1. Określ wizję i cele
Spotkaj się z kluczowymi Interesariuszami i porozmawiajcie o celach biznesowych. Ustalcie dokąd dążycie w ramach rozwoju Produktu i co chcecie osiągnąć długoterminowo. Ustal 1-2 najważniejsze cele biznesowe do osiągnięcia przez Produkt. Wyznaczone cele powinny być konkretne i mierzalne.
O budowaniu Celu Produktu możesz więcej przeczytać tutaj.
#2. Określ strategię
Określ rezultaty produktowe (ang. Product outcomes), które będą wspierać osiągnięcie ustalonych celów biznesowych. Wyznacz plan działania ukazujący drogę, którą obierzesz by przybliżać się do osiągnięcia Celu Produktu.
#3. Zbuduj Roadmapę
Ustal jaki rezultat ma najwyższy priorytet, by określić kolejność poszczególnych tematów. Do każdego celu ustal (w zależności od wybranego formatu Roadmapy) jakie potrzeby i pragnienia użytkowników będziesz spełniał, lub jakie funkcjonalności planujesz dostarczyć, by osiągnąć dany rezultat.
Umieść ustalenia na wybranym wzorze Roadmapy.
#4. Skomunikuj Roadmapę
Każdy zaangażowany w proces wytwórczy powinien znać Roadmapę. Określa ona bowiem wysokopoziomową strategię, która pozwoli jednoczyć wysiłki ukierunkowane na osiąganie wyznaczonych celów Produktowych i biznesowych.
Przedstaw zatem wszystkim zainteresowanym wyniki swojej pracy nad Roadmapą. Odbywaj cykliczne spotkania, na których będą omawiane zachodzące zmiany. Może to być przykładowo Sprint Review, by uniknąć konieczności organizowania dodatkowych spotkań.
PODSUMOWANIE
Roadmapa, która w centrum uwagi stawia rezultaty produktowe, jest narzędziem ukazującym strategię rozwoju Produktu. Ukierunkowuje rozmowy z Interesariuszami na to co istotne – na wizję Produktu i wynikające z niej cele biznesowe stawiane przed Zespołami. Skupienie na celach daje Zespołom dużo swobody i elastyczności, wpływając pozytywnie na ich motywację. I choć kolejność funkcjonalności i daty ich dostarczania mogą być istotne, to jednak lepiej zostawić je dla taktycznego Release Planu.
BIBLIOGRAFIA
[1] Increase Transparency with Outcome-Focused Product Roadmaps; https://www.scrum.org/resources/blog/increase-transparency-outcome-focused-product-roadmaps
[2] Roadmapa produktu w środowisku Agile; https://productvision.pl/2016/praca-roadmapa-produktowa-srodowisku-agile/
[3] Outcome-driven product roadmap; https://productcoalition.com/outcome-driven-product-roadmap-f705c49032b2
[4] Roadmapping Without Dates: Build Yourself A Better Strategic Plan; https://www.prodpad.com/blog/roadmapping-without-dates/
[5] OUTCOME BASED ROADMAPS : Unleash the Power of a Shared Vision and Purpose; https://medium.com/swlh/outcome-based-roadmaps-unleash-the-power-of-a-shared-vision-and-purpose-851401c7aa54
[6] The GO Product Roadmap; https://www.romanpichler.com/tools/the-go-product-roadmap/
[7] How to build an outcome-driven product roadmap — a step-by-step guide; https://www.productboard.com/blog/4-steps-for-building-outcome-driven-roadmaps/
[8] What Are Outcome-Based Roadmaps?; https://www.feedbear.com/blog/outcome-based-roadmaps
[9] Why Most Outcome-Based Roadmaps Fail (and How to Keep Yours From Doing the Same); https://www.productplan.com/learn/problems-with-outcome-based-roadmaps/
[10] S2E2 Roadmaps & Avoiding Product Fiction With Paweł Huryn; https://www.youtube.com/watch?v=-_1PRwAx1VM