Roadmapy w agile

Na co musisz uważać, kiedy tworzysz roadmapy w ujęciu zwinnym? Będziesz to wiedzieć, kiedy posłuchasz nagrania tego odcinka. Dowiesz się też, jakie odczuwamy wyzwania związane z roadmapami. Na bazie naszych wieloletnich doświadczeń, wgryźliśmy się w temat i przedstawiamy Ci najważniejsze problemy, pułapki, zagrożenia związane z roadmapami. Dodatkowo podsuwamy też kilka rozwiązań i alternatyw dla tych problemów.

Zobacz wersję wideo

Sprawdź nasz webinar o dzieleniu elementów Backlogu Produktu na mniejsze elementy.

Dodatkowe materiały

• Zwinne projekty i produkty
• Product Discovery
• „Strategize” Romana Pichlera – recenzja książki
• Propozycja szablonu roadmapy od Romana Pichlera

TRANSKRYPCJA

Jacek: Porozmawiamy dzisiaj o roadmapach, typowo w ujęciu zwinnym. Geneza tego odcinka jest taka, że bardzo łatwo jest trafić w Internecie na artykuły o tym, jak robić roadmapy, natomiast z naszej perspektywy dosyć rzadko są to faktycznie wskazówki, które pomagałyby tworzyć takie roadmapy w środowisku zwinnym. Dlatego zebraliśmy z Kubą nasze przemyślenia w tym obszarze i zamierzamy się tymi przemyśleniami dzisiaj z Tobą podzielić.

Kuba: W całym odcinku będziemy mniej mówić o definicji roadmapy, więc dosłownie superkrótko teraz powiem, co mamy na myśli. Roadmapa jest to takie narzędzie, ono jest używane w produkcie, ale jest też szerzej wykorzystywane to pojęcie. Roadmapa to pewien plan działania w pewnej perspektywie czasowej. W kontekście produktów to jest najczęściej roadmapa kwartalna, roadmapa półroczna lub roczna, pokazująca pewną perspektywę, pewne plany rozwoju danego produktu. W perspektywie zwinnej roadmapy są swojego rodzaju ogólniejszym ujęciem planu pracy, niż na przykład Backlog Produktu stosowany w Scrumie. Roadmapa to potrafi być kilka punktów pokazujących, gdzie zmierzamy z naszym produktem, jaki mamy konkretny, taktyczny plan na jego dalszy rozwój. Więcej szczegółów na temat tego, jak konstruować, z czego się składa taka roadmapa, jaki może być jej szablon, opisane jest to wszystko u Romana Pichlera, do którego mocno odsyłam, ponieważ tam temat jest wyczerpany. Link do tego materiału będzie w opisie odcinka lub na stronie. Gdyby interesował Cię temat głębiej, to ja też mocno Romana Pichlera polecam w postaci książki. Książka „Strategize”, którą swoją drogą też mam swój egzemplarz. Widać go u mnie na półce. Recenzowałem tę książkę jakiś czas temu na Agile247 i tam też trochę materiałów na temat roadmap jest. Natomiast w samym odcinku skupimy się na tym, żeby poopowiadać o tym, jakie czujemy wyzwania związane z roadmapami, jakie obserwujemy w firmach, z którymi współpracujemy lub w firmach, w których funkcjonowaliśmy jeszcze, jako osoby pracujące w środku tych organizacji. Jakie pierwsze wyzwanie chcemy wymienić?

Jacek: Pierwszy problem, który dostrzegamy z roadmapami, że one są bardzo często traktowane, jako już pewne konkretne zobowiązanie. Czyli scenariusz zwykle wygląda następująco, że osoba, która zarządza produktem, jest proszona najczęściej przez swoich zwierzchników, o przygotowanie roadmapy planu rozwoju produktu. Zwykle osoba taka wraca do zespołu. Konsultuje aspekty techniczne na zasadzie, kiedy pewne rzeczy mogły być zrealizowane. No i taki komplet informacji na zasadzie, kiedy zrobimy i kiedy to mniej więcej będzie, idzie w górę organizacji. Niestety te najczęściej podane konkretne daty, czy ramy czasowe do kiedy pewne rzeczy będą gotowe, no stają się zobowiązaniem. Czyli organizacja zaczyna rozliczać osobę odpowiadającą za produkt z tego, czy faktycznie te konkretne rzeczy, które na tej roadmapie się pojawiły, czy do tych konkretnych dat, które były deklarowane – zostały dostarczone.

Kuba: Zanim wejdę w możliwe rozwiązania, to ja tutaj dorzucę, czy dołożę akcentu na to, co Jacek powiedziałeś, że rozliczanie jest chyba tutaj najbardziej niepokojące w roadmapach, bo to, że roadmapa pokazuje pewne ambicje, pewne aspiracje, że jest jakąś formą planów, do których będziemy dążyć jako zespół, jako produkt, jako Product Owner, to jest dla mnie w porządku. Natomiast zaczyna się dla mnie kłopot, jak się zaczyna rozliczanie. Czyli wytłumacz się, wyjaśnij, dlaczego ta roadmapa nie została zrealizowana, nie została zrealizowana w całości, albo co gorsza – co do joty. W takim środowisku, czy w takiej perspektywie rozliczania takiej roadmapy – no pierwszy pomysł, który nam przychodzi do głowy, jako rozwiązanie, trochę takie obejście problemu, to unikanie dat na roadmapie. Czyli unikanie takiego wzorca, że roadmapa to jest jakiś rodzaj harmonogramu, jakieś ujęcie kalendarzowe tydzień po tygodniu, miesiąc po miesiącu, kwartał po kwartale. Jeszcze daleko w przód, bardzo precyzyjne punkty w czasie, które zostają, które są jakąś taką obietnicą, którą też bardzo trudno będzie wyjaśnić, jeśli ktoś nas będzie trzymał za słowo, że tak właśnie musi być. Taką konkretną alternatywą, to albo roadmapa bardziej pokazująca pewne dalsze kroki rozwojowe, ułożone w pewnej kolejności, ale niekoniecznie pokazana data, lub jeśli te daty jednak z jakichś powodów są potrzebne i o tym jeszcze powiem, że bywa, że są, no to taka perspektywa, że im bardziej w przód, tym mniej precyzyjni co do daty jesteśmy. Czyli perspektywa najbliższych miesięcy jest w miarę precyzyjna, ale już perspektywa kolejnych kwartałów, to już jest świadoma zmiana tej jednostki. Taka perspektywa wysoko poziomowa, kwartały, albo wręcz półrocza.

Jacek: Tutaj warto dodać, że pułapka, którą często obserwuję, jest taka, że domyślnie osoba odpowiadająca za roadmapę zakłada, że ona musi być bardzo szczegółowa, jeśli chodzi o daty. I mogą być to po prostu doświadczenia wyniesione z poprzednich organizacji, dlatego warto też zbadać w aktualnej organizacji, w której się znajdujemy, czy faktycznie te daty są wymagane, bo może niekoniecznie. Może jest tak, że wystarczy, że sobie zdefiniujemy, nad czym teraz pracujemy. Co będziemy robić w następnej kolejności, a co będziemy robić kiedyś. No i tu jest też jakaś alternatywna granulacja w stosunku do takiego bardzo konkretnego obiecywania dat. Oczywiście biorąc pod uwagę, że pewne daty, być może powinny pojawiać się na roadmapie. Czyli nie wiem, jakiś moment ważnej zmiany prawnej. Być może my chcemy zaakcentować na roadmapie świadomie, no po to też, żeby wzbudzić w organizacji świadomość tego, że no są pewne terminy, których po prostu nie jesteśmy w stanie przekroczyć.

Kuba: I nawiązując do tego, co powiedziałeś o deadline’ach, to kolejna rada, która mi przychodzi do głowy, to też taka poważna refleksja, czy sposób, w jaki konstruujemy daty na roadmapach jest poprawny i czy czasami nie narzuca nam dużej pułapki myślowej. Co mam na myśli? Wiele roadmap jest ułożonych, jako takie konkretne kroki, na przykład w miesiącach lub w kwartałach. W taki bardzo sztuczny sposób obiecujemy, że coś zrobimy do końca kwartału. Nie wynika to z autentycznej potrzeby czasowej. Nie wynika to z budżetu, który posiadamy na daną inicjatywę. Tylko wynika to z tego, że w organizacji rozliczamy się kwartałami, albo latami. Czyli do końca roku jest deadline na zrobienie jakiegoś projektu i ten koniec roku jest zupełnie sztuczną datą. Zupełnie z niczego nie wynika. Nasz cykl biznesowy jest inny. Początek sezonu to jest na przykład w e-commersie jesień, w niektórych biznesach – na przykład w turystyce, to będzie okolica początku wiosny. Więc te cykle są zupełnie inne niż taki sztuczny kalendarzowy cykl, koniec roku, albo koniec roku budżetowego, czy koniec kwartału. Więc tutaj takie zobowiązanie się do końca kwartału może się wzajemnie nakręcać, jeśli stosujemy właśnie taki bezsensownie biznesowy deadline w postaci końca kwartału lub końca roku.

Jacek: Kolejnym rozwiązaniem do rozważenia jest edukacja interesariuszy wewnątrz organizacji, którzy być może nie do końca rozumieją, jakie są konsekwencje funkcjonowania w złożonym środowisku. Mocno skracając historię, nie jesteśmy w stanie pewnych rzeczy przewidzieć. No i też trudno oczekiwać od zespołów, żeby pracowały zwinnie i jednocześnie w tym samym czasie oczekiwać, że będą prezentowane bardzo szczegółowe roadmapy w przód, na powiedzmy rok do przodu. Tak więc zdecydowanie warto poczynić kroki, które pomogą interesariuszom zrozumieć, jakie ograniczenia w pewnym sensie nakłada na nas w środowisku zwinnym. No i można to zrobić na szereg różnych sposobów, od rozmów jeden na jeden, takich planowanych, poprzez takie rozmowy kontekstowe, kiedy widzimy na przykład, powiedzmy sobie na przeglądzie Sprintu, że rozpoczyna się dyskusja na temat roadmapy i widzimy, że jest tutaj pewne niezrozumienie, czy poprzez taką bardzo świadomą, bardzo zaplanowaną serię edukacyjną, gdzie wciągamy interesariuszy w temat zwinności, no po to, żeby mieli taki wystarczający kontekst, który pomoże organizacji, jako całej funkcjonować w zwinnym środowisku.

Kuba: A ja dorzucę do tego, co powiedziałeś, kto to może robić? Bo to jest ten największy interes w tym, żeby te roadmapy nie były traktowane jako zobowiązanie ma Product Owner, tylko że on jest jednocześnie mało obiektywny, bo siłą rzeczy osoby, które mogą nalegać na to, żeby ta roadmapa była zobowiązaniem, mogą sobie myśleć – Aha, Product Owner mnie teraz będzie przekonywał do tego, że te roadmapy muszą być bardziej otwarte, bardziej może nowoczesne. No bo nie chce się zobowiązywać. Więc tutaj jest świetne pole do popisu dla współpracy ze Scrum Masterem, z Agile Coachem. To jest może też miejsce, gdzie powinien aktywizować się lider transformacji. Czyli osoby, które są jednak trochę niezależne od tego Product Ownera i mogą z tymi samymi argumentami, o których Jacek powiedział pójść. I dalej mają rację. Tylko już może nie są bezpośrednio osobiście zaangażowani w taką dyskusję. Jak mówię o wsparciu lidera transformacji, to ja myślę też, że bardzo dużą rolę i takim ostatnim rozwiązaniem, które nam przychodzi do głowy, jest tutaj wsparcie od zarządu, wsparcie od najwyżej zarządzających w organizacji. Bo coś, co obserwuję też zwłaszcza w tych największych organizacjach, z taką powiedzmy wypiętrzoną strukturą, to to, że taka fiksacja na bardzo konkretne plany i ich ścisłą realizację, często pochodzi od średniego managementu. To jest oczywiście uprawnione. To bardzo ułatwia koordynację prac, na takim powiedzmy pośrednim szczeblu w organizacji. No tylko niestety ja obserwuję, że tutaj można się zapędzić. Czyli góra firmy ma ochotę na Agile. Dół sobie działa dzielnie w zespołach zwinnie, a pośredni szczebel zarządzania nie jest w żaden sposób hamowany przed tym, żeby egzekwować roadmapy, jako ścisły plan i plan, którego nie wolno nie wykonać. No i tutaj jest miejsce też na to, żeby propagować od góry do szczebla zarządzania informacją na temat tego, że pewne nie realizacje roadmapy, zwłaszcza jeszcze w tym kontekście, o którym jeszcze będziemy mówić, wynikający z konkretnych przyczyn, jest czymś, co się zdarza w organizacjach pracujących w złożonym środowisku, czy mającym trudny rynek. Następnym wyzwaniem, które z roadmapami tutaj obserwujemy, jest to, że one regularnie potrafią mieć przekroczony planowany czas. Czyli innymi słowy, zwykle potrzeba trochę więcej czasu na realizację, czy to założonego, czy to celu, czy realizację pewnego określonego ficzera, niż ktoś pierwotnie zaplanował. Zwłaszcza jeśli rozpatrujemy to z perspektywy rezultatu, no to ten rezultat nie zawsze będzie osiągnięty w pierwotnie przewidywanym czasie. Zaczyna się bardzo niepokojący efekt. Albo efekt domina, czyli poprzednio opóźniony projekt opóźnia wszystkie kolejne, albo poprzedni ficzer przesuwa realizację następnych ficzerów. Albo jeszcze gorszy efekt, który w jednej organizacji był nazywany gasnącym światłem, czyli niezależnie od tego, że rezultatu nie osiągnęliśmy, to mieliśmy okazję tylko do końca kwartału. W następnym kwartale już tupie nóżkami zupełnie nowy ficzer i on ma być realizowany, rzućcie wszystko i róbcie je. No i tutaj albo jest jakaś szara strefa i jednak dorabiamy to stare, ale udajemy, że robimy to nowe. Albo tak naprawdę ten produkt jest ciągle niedoskonale realizowany. I to już nawet nie chodzi o polerowanie tutaj złotych klamek, tylko po prostu ten produkt jest niedokończony, bo się musimy, kierując roadmapą, przekierować na nowe ficzery.

Jacek: To, co tutaj może pomóc, to ustalenie podstawowego czynnika naszego sukcesu, czyli na czym nam najbardziej zależy. Kłania się tutaj klasyczny trójkąt projektowy, gdzie mamy do dyspozycji zarówno zakres, jak i pewien czas realizacji, jak również i budżet. No i warto się zastanowić, co jest dla nas priorytetem. Czyli przykładowo, jeżeli ogranicza nas czas, no to pozostaje nam możliwość operowania zakresem i możliwość operowania budżetem. Jeżeli mamy budżet, który jest ograniczony, no to znów, może powinniśmy pewne rzeczy robić krócej, albo w mniejszym zakresie. No jeżeli zakres jest stały, albo będziemy go realizować dłużej, no albo możemy wydać więcej pieniędzy, żeby ten sam zakres dostarczyć w pewnym konkretnym czasie. Oczywiście jest to pewne takie uproszczenie, w które trzeba byłoby się bardziej zagłębić, bo jest nieco bardziej złożone, ale jednak to, o czym mówię, pozwala nam, w ogóle wejść w rozmowę – Dobrze, to żeby ta roadmapa stała się rzeczywistością, no to, co możemy zrobić? I jest to trochę dyskusja, nazwijmy to, o poświęceniach, bądź o dodatkowych inwestycjach. Nie mniej, otwiera to drogę do tego, że jeżeli na którymś z tych elementów zależy nam najbardziej, no to możemy sobie tymi dwoma dodatkowymi, nazwijmy to, trochę pożonglować. 

Kuba: No i ta dyskusja taka bardzo asertywna, jest tu potrzebna. Po prostu rozmawiamy sobie o pewnej rzeczywistości, a nie traktujemy pewne rzeczy, jako fakty dokonane. Coś zostało spisane do roadmapy, więc musi się wydarzyć i jesteśmy w sytuacji bez wyjścia. Następne rozwiązanie, takie klasyczne na nas, chyba nie będziemy za długo o nim rozmawiać, to oczywiście iteracyjne wytwarzanie rozwiązań. Czyli fakt, że coś na roadmapie jest zapisane, jest jakimś takim klockiem w czasie. Na przykład mamy X miesięcy, albo to jest nasze najważniejsze coś, czym się będziemy zajmować w najbliższym kwartale, to jeszcze wcale nie oznacza, że my to będziemy realizować jednym wielkim wdrożeniem na koniec kwartału. Jeśli mamy jakiś nowy ficzer, albo nowy cel do osiągnięcia, to najlepsze co możemy zrobić, to spróbować jeszcze dalej pociąć to rozwiązanie, albo testować pewne hipotezy i spróbować dostarczać te rozwiązania mniejszymi fragmentami, mniejszymi kawałkami wartości i dostarczać je wcześniej, dostarczać je często. I być może uciekniemy sprzed tej pułapki, że skończył nam się na przykład czas, jako nasz tutaj czynnik sukcesu i zostajemy z niczym, bo w tym czasie nie udało nam się osiągnąć satysfakcjonującego rezultatu. Jeśli będziemy dostarczać regularnie, często i wcześnie, to jest szansa, że ten cząstkowy rezultat przybliża nas do tego sukcesu lub daje tę satysfakcję, na którą czekamy, czy do której potrzebowaliśmy.

Jacek: Jeżeli ten temat, o którym Kuba powiedział, iteracyjnym wytwarzaniu rozwiązań, jest dla Ciebie interesujący, to mamy nagrany cały odcinek o tym aspekcie. Odcinek 36, gdzie rozmawiamy trochę o różnicach pomiędzy zwinnymi projektami a produktami. No i tam, ten temat iteracyjności został poruszony. Co jeszcze możemy zrobić? To, co z mojej perspektywy jest takim bardzo empirycznym podejściem, to jest po prostu urealnienie możliwości zespołu, bądź zespołów, jeżeli mówimy o większej skali. Czyli ja to rozumiem w ten sposób. Spójrzmy sobie historycznie, jakie są możliwości naszych zespołów i pod te realne możliwości zacznijmy sobie planować, co jesteśmy w stanie zrealizować. Zwykle, na bazie moich doświadczeń to się kończy tym, że powinniśmy sobie powiedzieć, po prostu powinniśmy zaplanować mniej. No bo roadmapa zwykle nie uwzględnia wszelkiego rodzaju wrzutek. Na zasadzie, pojawiają się jakieś okazje, które warto wykorzystać. Pojawiają się jakieś błędy, problemy. Pojawiają się zmiany w otoczeniu projektowym, biznesowym. No i jakby roadmapa zwykle nie przewiduje buforów na takie rzeczy. Natomiast z różnych powodów musimy takie sytuacje wyjątkowe obsługiwać. Tak więc realne spojrzenie na możliwości zespołu i też trochę takie świadome przygotowanie się na to, że realnie jesteśmy w stanie zrobić trochę mniej, może spowodować, że ta roadmapa będzie po prostu trochę bardziej realna.

Kuba: Bardzo podobną kwestią, już tak pewnie na poziomie całej organizacji, jest temat limitowania pracy w toku. Czyli realnie dobierajmy to obciążenie per zespół, ale też nie skazujmy zespołu na równoległe atakowanie wielu wątków. To może w zasadzie zamykać drogę zespołowi do skupienia również w poszczególnych Sprintach. Skupienia się na jednym celu produktowym w Backlogu Produktu, na przykład, jeśli zespół korzysta ze Scruma. Czyli limitujmy pracę na poziomie całej organizacji. To jest taka duża pułapka, że na takich dużych etapach planistycznych, taktycznych, gdy budujemy taką mapę produktu, no papier jest cierpliwy, przyjmie wszystko. W Excelu wygląda to ładnie. W Power Poincie działało. Jest wiele takich powiedzonek korporacyjnych. Czyli obietnica, że wykonamy coś w najbliższym roku w naszym produkcie, w zasadzie nie jest niczym limitowana. Tutaj od mądrości i zarządzających i osób kierujących danym produktem, zależy to, żebyśmy sobie jasno powiedzieli, jaki mamy limit. Skupili się na tym, co jest naprawdę najważniejsze i już na tym etapie dobierali te rzeczy i też od razu podejmowali pewne decyzje, co jest naprawdę najważniejsze, a co będzie czekać na lepsze czasy, a co w ogóle nawet w tej chwili nie jest realizowane. Wiele zespołów już w tym miejscu ma taką źródłową przyczynę dalszych problemów. Na przykład z wielocelem w Sprincie, albo z brakiem sensownej wizji, w którą stronę nasz produkt jest rozwijany.

Jacek: Kolejny problem, który możesz spotkać, kiedy używasz roadmap w środowisku zwinnym, jest sytuacja, w której to, co jest zaplanowane w roadmapie, nie odnosi sukcesu. I tutaj powodów może być kilka. Po pierwsze te zaplanowane zmiany w produkcie mogą po prostu nie być używane przez naszych Użytkowników. Na takiej zasadzie, że wydawało nam się, że to będą fajne dodatki do produktu, ale nasi Użytkownicy uważają inaczej. Inny problem może być taki, że być może trafiamy z rozwiązaniami w potrzeby Użytkowników, ale realizujemy je w taki sposób, że te rozwiązania nie są intuicyjne. Czyli albo w ogóle nasi Użytkownicy do nich nie docierają, albo używanie tych funkcji rodzi taką frustrację, że po prostu porzucają i przestają z tego korzystać. Inny przykład braku sukcesu. Może być tak, że to, co właśnie powiedziałeś Kuba, zadziałało w Power Poincie, może być bardzo trudne do wyprodukowania. W szczególności, jeśli mówimy o produktach technologicznych, gdzie mamy pewne ograniczenia. Na przykład, jeżeli nie korzystaliśmy wcześniej z jakiejś technologii, albo w ogóle technologia jest nowa na rynku, no to może się okazać, że jakieś tam nasze pierwotne estymaty, ile coś nam zajmie, mogą być kompletnie przestrzelone. Na takiej zasadzie, myśleliśmy, że to będzie inicjatywa na miesiąc. Mija szósty miesiąc, a to nadal nie działa, jakbyśmy to sobie wyobrażali.

Kuba: I tutaj rozwiązaniem na takie zagadnienie, że zespół realizuje niewłaściwe rzeczy, albo te rzeczy, które zostały zrealizowane, nie są tym, co jest naprawdę potrzebne. Jest cała sfera Product Discovery. Warto się zainteresować całym tym zagadnieniem. Nagraliśmy na ten temat osobny odcinek. Polecam odcinek 10. i tam sporo głębiej w to weszliśmy. Ale tutaj w kontekście roadmap to jest taka cała sfera tego, żeby nie traktować roadmapy, czy procesu budowania roadmapy, może roadmapowania, jako taki jednorazowy event, nieprzyjemny moment raz na jakiś czas, tylko raczej jest to jeden z wielu etapów, który na przykład połączony przez ciągłe Product Discovery, oznacza ciągłe odkrywanie, ciągłe rewidowanie, ciągłe zastanawianie się, co jest potrzebne. Czy to, co realizujemy, faktycznie odpowiada na potrzebę? Czy dobrze dopasowujemy nasze rozwiązanie do grupy docelowej? Czyli jakby po pierwsze, nie dajmy się tutaj skusić takiemu złudzeniu, że zbudowaliśmy sobie fajną roadmapę, więc już mamy z głowy myślenie, co jest naprawdę potrzebne. No i bądźmy cały czas czujni, że te podejmowane decyzje produktowe w trakcie roadmapowania, powinny być też w trybie ciągłym rewidowane. W czasie kolejnych kroków pracy takiego zespołu produktowego z wykorzystaniem na przykład konkretnych technik Product Discovery.

Jacek: I to, co Kuba mówi, można rozwinąć do takiej koncepcji, w której roadmapa jest bardziej takim pewnym zbiorem pomysłów i kierunków, które chcemy zwalidować, niż na bardzo wczesnym etapie zadecydowanym planem, którego będziemy się trzymać. Celowo w tym odcinku będziemy skupiać się na rozmawianiu o roadmapach w środowisku zwinnym. Uważam, że ten aspekt jest szczególnie istotny. Bardzo często pracuje z organizacjami, w których zespoły pracują zwinnie. Dostarczanie produktu odbywa się iteracyjnie. No i jakby do tej całej układanki, nagle pojawia się pewna roadmapa, która jest decydowana w grudniu, czy w styczniu i ona obowiązuje przez najbliższy rok. Czyli trochę to wygląda tak, jakby zespoły były już zaadaptowane do pracy zwinnej. Natomiast gdzieś jeszcze pokutuje to takie myślenie, że mamy kontrolę nad zmieniającą się rzeczywistością. Tak więc warto spojrzeć na roadmapę, jako coś, co, będziemy zmieniać, będziemy adaptować. Pewnie im bardziej zmienne środowisko, tym częściej, niż że to jest pewien plan. No bo umówmy się, spisanie tego planu nie spowoduje, że faktycznie tak się potoczy nasza rzeczywistość.

Kuba: I może to jest trochę zabawa w grę słów, ale im bardziej z roadmapy wybrzmiewa takie, to co zrobimy, albo takie bardzo konkretne działania, nasza taktyka, nasze pomysły, nasze projekty, które na pewno zrobimy, tym mniej może wybrzmiewać, że my tak naprawdę na tym etapie zgadujemy, że to jest, albo gut feeling, albo u konkurencji się to sprawdza, to u nas chyba też się sprawdzi. To są wszystko znaki zapytania. Pełno założeń. Pełno wątpliwości. Podoba mi się taka metafora, która po angielsku może brzmi trochę lepiej, niż w języku polskim – zakładów. Tak, jak są zakłady bukmacherskie, że niektórzy obstawiają, że wygramy, albo obstawiają, że strzelimy ileś bramek, zdobędziemy jakiś puchar. Tu jest bardzo podobna sytuacja. Tak naprawdę na etapie roadmapowania, opowiadamy o tym, jakie obstawimy zakłady i liczymy na to, że się wygra. Wygramy, że będzie tutaj trafne przewidywanie, ale tak naprawdę musimy sobie jasno powiedzieć, że to jest tylko nasze zgadywanie, że to właśnie pomoże. Zwłaszcza w kontekście całego biznesu. Czyli, że damy rezultaty, że uda to się w tym czasie i że tak w ogóle konkurenci też będą patrzeć na temat to, jak my realizujemy swoje, nasze działania. Następnym rozwiązaniem w temacie wątpliwości tego, czy odniesiemy sukces naszą roadmapą, czy naszymi planami produktowymi, jest takie założenie bardzo odważne, że zacznijmy od tych najbardziej ryzykownych aspektów naszego pomysłu na produkt. Czyli, jeśli mamy w planach jakieś większe rozwijanie naszego produktu i są w nim zmienne, które są bardziej i mniej prawdopodobne, czy bardziej ryzykowne i mniej ryzykowne, to nie odkładajmy nie wiadomo na kiedy tych bardziej ryzykownych, tylko w roadmapie umieśćmy je na początku. Też w konkretnej realizacji tej roadmapy również od początku, od pierwszej iteracji rozpocznijmy atakowanie tego najbardziej wątpliwego zagadnienia, czy najbardziej trudnego zagadnienia. No i dzięki temu, albo wcześnie się dowiemy, że tego sukcesu nie będzie i przynajmniej minimalizujemy stratę, albo też najwcześniej atakujemy zagadnienie, jak się najlepiej dopasować, żeby to nasze rozwiązanie było właściwe, było takie, jakiego potrzebuje rynek.

Jacek: To przykład do tego, co tutaj Kuba to może być, jeżeli robimy jakieś rozwiązania technologiczne, no to być może częścią jakiejś zmiany w produkcie będzie integracja z jakimś partnerem, dostawcą, przez jakieś API. No i to zwykle już powinno zapalać lampkę, że coś może pójść nie tak, no bo otwieramy tak naprawdę ścieżkę pewnych zależności zewnętrznych. Stąd lepiej dowiedzieć się wcześniej, że to nie działa, tak jakbyśmy się spodziewali, niż zostawić to sobie na koniec, na zasadzie – została nam tylko integracja. No bo de facto może ona nie być taka prosta, jak myśleliśmy, a czasu możemy już nie mieć. Tak więc no to spojrzenie, perspektywa patrzenia przez ryzyko w pewnych sytuacjach może być sensowna. Właściwie tylko jednym zdaniem tutaj podsumowując jeszcze, no to de facto wspomniane już wcześniej iteracyjne wytwarzanie produktu, to też jest strategia, czy pewien pomysł, który może być pomocny we wczesnym walidowaniu, czy nasze pomysły faktycznie mają sens i czy faktycznie dobrze zdiagnozowaliśmy potrzeby na rynku i też, czy dostarczyliśmy sensowne rozwiązanie, które jakiś tam konkretny problem rozwiązuje.

Kuba: Kolejnym problemem związanym z budowaniem roadmap jest coś może z innego poziomu abstrakcji. Fakt, że taki proces budowania roadmapy jest pracochłonny. Czyli wymaga dużego nakładu wysiłku, czasu. Być może całego zespołu, być może jakiejś podgrupy, być może też zainteresowania interesariuszy w to, żeby taką roadmapę zbudować. Jeśli przemnożymy to, że zmienność biznesowa, zmienność otoczenia, powoduje, że ta roadmapa jest też zmieniana, no to później aktualizacja tej roadmapy jest czasochłonna i też może się okazać, że poświęciliśmy dużo energii w generowanie pewnych punktów na roadmapie, które w najbliższym czasie jednak realizowane nie będą. Czyli no takie czyste marnotrawstwo planowania pewnych działań, które jednak realizowane, w ogóle nie są.

Jacek: To, co warto głośno sobie powiedzieć i zrozumieć, to jest to, że roadmapa po prostu nie jest Backlogiem Produktu. Często widzę pokusę, żeby roadmapa była taka samo tłumacząca się. Żeby była na dużym poziomie detalu. No tylko z mojej perspektywy – od tego jest Backlog Produktu. Transparentny, dostępny, dobrze opisany, uporządkowany. Natomiast roadmapa to jest coś na wyższym poziomie. Coś bardziej ogólnego. Kiedy mówimy tutaj o pracochłonności, no to zdecydowanie trzymałbym się pewnego poziomu wyższego, niż Backlog Produktu. Pewne koncepcje, pewne elementy, które mamy w Backlogu Produktu, po prostu agregowałbym na roadmapie w jakieś pojedyncze myśli, czy sentencje, czy jakieś takie bloki. No tak, żeby to był wyraźnie nieco, na innym poziomie granulacji artefakt.

Kuba: Druga rada, która też może poprawić ten temat potrzebnego nakładu czasu na wyceny zadań, czy na ficzery, czy na taką powiedzmy przepracowywaną koncepcję naszą produktową, jest to i tutaj zachęcam do tego, żeby rozważyć, czy nie warto zorientować roadmapy na cele, zamiast bardziej popularnego modelu roadmapy zorientowanej na funkcje, czy na ficzery, czy cechy produktu. Jeśli roadmapa zawiera właśnie cechy konkretne produktu, konkretne ficzery, które obiecujemy dostarczyć, być może jeszcze jak przemnożymy to przez to jednak oczekiwanie, że pewne konkretne daty na tej mapie będą się znajdowały, to siłą rzeczy skazujemy się bardzo konkretnie już mocno na wycenianie, na analizę, na taką poważną refleksję. No bo za chwilę będziemy stać twarzą za tą mapą i rozmawiać na temat tego, dlaczego pewne rzeczy są, a inne nie są na niej zawarte. I dlaczego wydaje nam się, że te zrobimy, a tamtych nie zrobimy. Stąd roadmapa zorientowana na konkretne funkcje, w moim odczuciu troszkę nas przesuwają w stronę większego szczegółu, o którym Jacek przed chwilą mówił. A roadmapa zorientowana na cele, bardziej mówi, w tych kierunkach rozwojowych, w tych konkretnych wskaźnikach biznesowych, będziemy starali się uzyskać jakieś usprawnienia, ale już taktykę, konkretne rozwiązania, konkretny dobór zakresu zostawiamy, jako ten element konkretnej realizacji i nie musimy tego deklarować na tym etapie, właśnie, czy w tym procesie roadmapowania.

Jacek: Kolejną wskazówką, która może pomóc w skróceniu czasochłonności produkowania roadmapy jest wybranie prostego, elastycznego narzędzia, które pozwoli nam w łatwy sposób też tą roadmapą zarządzać. Bardzo często dostaję pytanie, jakie jest najlepsze narzędzie do budowania roadmapy? Konsekwentnie, moja odpowiedź zaczyna się od tego. Z jakich narzędzi dzisiaj korzystacie? No bo, jeżeli dużo rzeczy robicie w Excelu, w chmurze, to Wam działa – zróbcie roadmapę w Excelu. Jeśli macie, nie wiem, Confluence’a na przykład i on już funkcjonuje – zróbcie w Confluensie. Jeżeli pracujecie na Google Docs’ie – użyjcie Google Docs’a i tak dalej. Czyli, znów, to pewnie jest dobra umiejętność marketingowa tych wszystkich firm, które robią te narzędzia, że tak patrząc na landing page, że nam się wydaje, że jak już tylko narzędzie X zainstalujemy, no to proces budowania roadmapy będzie prosty, gładki i przyjemny. Nie będzie. W sensie te narzędzia często mają pewien taki próg wejścia, który będziemy musieli zainwestować. Automatycznie mamy vendor lock. W takim sensie, że być może tej roadmapy nie będziemy w stanie wyeksportować. Tak więc proste narzędzia. Łatwość zmiany. Jeżeli pracujemy stacjonarnie, no to może po prostu tablica, która jest dostępna w jakimś takim centralnym punkcie firmy, wokół której łatwo się będzie spotkać i po prostu porozmawiać o tej roadmapie, a jak będzie trzeba coś zmienić, to weźmiemy gąbkę, zmażemy i markerem dorysujemy nowe elementy do tej roadmapy.

Kuba: I ostatnia porada związana z tą pracochłonnością budowania roadmapy, to jest taka dyscyplina w tym, żeby ograniczyć sobie czasowo cały ten proces. Zwłaszcza jeśli chcemy zatrzymać się na poziomie ogólności. Zwłaszcza jeśli chcemy zachować pewną gruboziarnistość. To możemy mieć taką nieodpartą pokusę, żeby jeszcze dla pewności jeszcze chwilę porozmawiać. Jeszcze bardziej to przeanalizować. Jeszcze trochę bardziej rozmóżdżyć się wokół tego wątku. No zdecydowanie, warto sobie po prostu na początku tego procesu powiedzieć, ile chcemy na to poświęcić czasu. Do kiedy chcemy to mieć i zadowolić się takim powiedzmy rozwiązaniem good enough. Czyli z perspektywy zespołu, z perspektywy Product Ownera, po prostu powiedzieć sobie jasno. OK, na pewno dałoby radę to dopieścić, ale powiedzieliśmy sobie, że do końca tygodnia to tworzymy. W ciągu ostatniego tygodnia tyle byliśmy w stanie stworzyć i po prostu z tym będziemy iść dalej. No i dokładnie to samo, lustrzane odbicie tego podejścia powinno też być też po stronie odbiorców takiej roadmapy. Czyli pewna świadomość, że roadmapa to nie jest jakiś taki dokument, czy produkt, który jest perfekcyjny. Nieskończenie doskonały. Tylko poświęciliśmy na to chwilę, ale nie możemy za bardzo skupiać się na takich procesach zastępczych. W czasie, gdy tworzyliśmy roadmapę, mogliśmy lepiej poznawać Klienta, lepiej budować produkt, dostarczać kolejne ficzery. No i warto tego nie zgubić z optyki. Czyli też odbiorcy tego dokumentu powinni pamiętać, że to też jest koszt. Budowanie tej roadmapy, zwłaszcza koszt alternatywny, jest dosyć prosty do pokazania. W tym czasie mogliśmy robić te ficzery, zamiast robić jeszcze doskonalszą roadmapę.

Jacek: I ostatni aspekt, o którym chcieliśmy Ci opowiedzieć, to jest taka pułapka, w której roadmapa może stać się takim zastępczym sposobem monitorowania postępów w rozwoju produktu. Czyli oznacza to, że tak bardzo skupiamy się na realizacji, i tutaj to słowo jest ważne – roadmapy, że zapominamy, że tak naprawdę pod spodem najprawdopodobniej są jakieś wskaźniki biznesowe, dla których zdecydowaliśmy się podjąć jakieś konkretne kroki. No i bardzo łatwo wpaść w pułapkę, w której tak bardzo się interesujemy, gdzie jesteśmy w roadmapie, że zapominamy, o tym wszystkim, co jest pod spodem. Czyli zapominamy, dlaczego, po co, w jakim celu te rzeczy realizujemy.

Kuba: I mamy tu na myśli taki przypadek w szczególności, gdzie zaplanowana roadmapa, czy opublikowana roadmapa, staje się punktem odniesienia dla dalszych kroków. Na przykład ustanowienia celów dla zespołu, albo rozliczania skuteczności pracy Product Ownera, czy Product Managera. Czyli dokument, który powstał, według tego wszystkiego, o czym mówiliśmy do tej pory, w sposób dosyć ogólny. W sposób dosyć też taki szczupły. Nagle staje się punktem analizy i monitorowania tego, czy dobrze realizujemy pracę w naszym produkcie, czy nie. Jasno sobie tutaj powiedzmy. To jest zastępczy sposób monitorowania produktu, no bo tym właściwym produktem, raczej powinno być zadanie pytania, gdzie jest nasz produkt? Jak zadowoleni są nasi Klienci? I to, czy robimy, czy nie robimy zaplanowane jakiś czas temu kroki, może nie mieć ścisłej korelacji z tym, czy ten produkt odnosi sukces, czy go nie odnosi. I tutaj konkretne rozwiązanie, które niestety w wielu organizacjach kuleje, to to, czy mamy strategię produktową? Czyli roadmapa wykonywana w pewnym cyklu, ale niemająca żadnego oparcia w strategii produktowej, będzie pewnie losowym koncertem życzeń. Być może pokazem, kto dzisiaj jest najsilniejszy w firmie i kto przewalczył tutaj jakieś priorytety w ramach jakiejś politycznej walki, to będzie się bardzo średnio łączyło z tym, co jest produktem? Co jest ważne? Dla kogo robimy? Jak ten produkt wyróżnia się na tle naszej konkurencji, jeśli mówimy tu o produkcie działającym na rynku. Stąd osoby, czy zespoły, czy firmy, które borykają się z roadmapą, warto, żeby sobie zadały pytanie też, czy czasami jednym ze źródeł, czy problemów w tej sferze roadmapowania, nie jest kulejąca sfera strategii produktowej. I to od strategii produktowej trzeba zacząć. Od ustalenia tych wszystkich zagadnień. Dopiero na bazie istniejącej strategii produktowej, tworzyć dalsze roadmapy i później też monitorować produkt z perspektywy strategii produktowej, a nie z perspektywy zgodności z kiedyś tam powstałą roadmapą. 

Jacek: To, co może pomóc też, to stworzenie, zdefiniowanie, pewnych konkretnych celów, które mamy powiązane z produktem. Ustalanie też pewnych też pewnych konkretnych mierników. No i po prostu konsekwentne monitorowanie. Czyli zastanowienie się, co tak naprawdę jest dla nas istotne? To oczywiście mogą być różne rzeczy. To może być przychód. To może być czas obsługi Klienta. To wszystko zależy od produktu. Natomiast, no tak trochę jak u Simona Sinka, zacznij od dlaczego, tak samo tutaj zacząłbym od tego, żeby najpierw sobie zdefiniować sobie jakieś konkretne cele, które chcemy osiągnąć i dopiero potem zastanowić się. OK. Tak trochę myśląc impactmapą, w jaki sposób możemy dojść do realizacji tych celów, no bo najczęściej jest więcej, niż jedna ścieżka do ich rozwiązania.

Kuba: I kończąc tutaj listę porad na temat tej właśnie roadmapy, jako zastępczego sposobu monitorowania produktu, w wielu organizacjach widzę takie zjawisko rozliczania realizacji roadmapy. Czyli raz na jakiś czas ten Product Owner, Product Manager, może grupa Product Ownerów, odpowiedzialnych za jakiś większy produkt, spotykają się, analizują. Być może analizują z interesariuszami, być może z wyższymi zarządzającymi stan prac w danym obszarze analizę właśnie roadmapy. To jest wielka pułapka. Dokładnie ten problem traktowania roadmapy, jako coś, co jest wyryte w kamieniu, staje się zobowiązaniem. Zamiast tego mocno rekomenduję, żeby ten produkt wykorzystywać takie cykle, by produkt monitorować tak holistycznie. Czyli wziąć te mierniki, o których mówił Jacek. Wziąć strategię produktową, o której mówiłem z pierwszej z porad w tej sferze. Popatrzeć na to, co się działo w trakcie ostatniego okresu. Jakie jakieś nowe produktowe wyzwania się pojawiły? Jakieś nowe okoliczności, które zrewidowały dotychczasowe plany rozwojowe. Czyli popatrzeć szerzej, niż tylko taka, co się udało, a co się nie udało, zrealizować z planowanej roadmapy. Bo to, że się coś nie udało zrealizować, w za wąskim myśleniu może być już wystarczającym powodem, żeby Product Owner miał minusika w swoim dzienniczku ucznia, a może się okazać, że właśnie najlepsze, co zrobił, to zdecydował, że nie będzie realizował pierwotnie planowanej roadmapy, ponieważ okazało się, że zmieniło się prawo. Pojawił się jakiś nowy konkurent. Coś takiego, jakaś fajna okazja biznesowa się pojawiła. No i produkt jest w lepszy stanie. Okazje zostały wykorzystane i jedynym problemem jest to, że roadmapa została zaktualizowana, czy może przesunięta. Jeśli spojrzymy za wąsko, to to jest błąd. A jeśli spojrzymy szerzej, to jest najlepsze, co można było w tym produkcie zrobić. I żebyśmy w ten błąd nie wpadali, zarówno produktowcy, jak i zarządzający obszarem powyżej produktu, powinni ten produkt analizować i przeglądać holistycznie, a nie tylko z perspektywy zgodności z wcześniej deklarowaną roadmapą.

Jacek: W temacie roadmap warto sobie to głośno powiedzieć. Nie ma rozwiązania idealnego. Słuchając tego odcinka, na pewno masz refleksję, że jest to złożony proces i bardzo często to, jak roadmapy wyglądają, zależy po prostu od tego, jaka jest kultura organizacyjna w organizacji, jakie są przyzwyczajenia, na jakim rynku funkcjonujemy, kto jest w organizacji, kogo zatrudniamy i tak dalej. Tak więc warto ten odcinek potraktować, jako pewne takie zaproszenie do podyskutowania o tym, czym są roadmapy w naszej organizacji? Jak zwykle zresztą zachęcamy z Kubą po prostu do poszukania drogi środka. Drogi, która daje nam wartość. Pomaga nam. No i po prostu te działania, które w okolicy roadmapy wykonujemy, po prostu przynoszą nam biznesowo sens.

Kuba: I też taka refleksja na koniec, że widzę, że roadmapa to taka próba połączenia ognia z wodą. Czyli połączenia takiego świata złożoności rozwoju produktu, ze światem mamy konkretne plany, konkretne daty. Mamy pewne zobowiązania. Pewne rzeczy zostają zafiksowane, wyryte w kamieniu. I do jakiegoś stopnia w organizacjach takie napięcie pewnie będzie występowało, ponieważ firma to zawsze byt składający się i z tych światów bardzo agile’owych, bardzo elastycznych, ale będą też te aspekty działania, czy poszczególne aktywności, które jednak wymagają pewnych planów, budżetów, zatrudnień, przesunięć, ustandaryzowanych procesów. Czyli do jakiegoś stopnia roadmapa będzie potrzebna. Tylko nie zgubmy tego momentu, gdzie roadmapa nam narzuca ten taki klasyczny, stary styl, ignorujący złożoność świata. Czyli takie przegięcie w jedną stronę. Ale też nie dajmy się takiej pokusie, że jesteśmy zwinni, więc nie musimy mieć żadnego planu. Będzie, co będzie. Jak skończymy, to skończymy. No bo w każdej organizacji, o trochę większej skali, taki tekst może nas mocno deprecjonować. Może nas mocno ustawić w takiej przegródce – dobra, z tymi ludźmi nie można rozmawiać poważnie biznesowo. Więc tutaj wielkie wyzwanie, żeby to pogodzić, żeby znaleźć tę drogę środka, o której mówił Jacek. No i jakby tutaj rozmawiajmy, jakie są potrzeby względem roadmapy, otoczenia zespołu zwinnego, ale też nie dajmy sobie narzucić roadmapowania, jako taki sposób na – bądźmy zwinni, ale też koniecznie realizujemy precyzyjnie założone plany.

Jacek: Niezależnie od kontrowersji związanych z roadmapami, o których dzisiaj rozmawialiśmy, możemy się zgodzić, że co do zasady organizacje zwykle potrzebują roadmap i jakąś formułę sobie do wyprodukowania tych roadmap przyjmują. Pracując z Kubą zawodowo, pomagamy firmom wypracowywać roadmapy, które z jednej strony spełniają potrzeby interesariuszy, a z drugiej strony uwzględniają złożoność i zmienność otoczenia rynkowego. Jeżeli temat roadmap jest u Ciebie, w Twojej firmie wyzwaniem, możemy pomóc Ci przepracować ten temat. Nie będziemy pracować na hipotetycznych przykładach z Internetu, tylko warsztatowo wypracujemy Twoją konkretną roadmapę. Jeżeli czujesz, że takie warsztaty dałyby wartość w Twojej organizacji, odezwij się do nas poprzez formularz kontaktowy na stronie porzadnyagile.pl/kontakt.

Kuba: A notatki do tego odcinka, linki do polecanych przez nas materiałów, czyli Romana Pichlera, recenzję jego książki i konkretnych odcinków podcastu, które wymienialiśmy w toku tego nagrania, znajdziesz na stronie porzadnyagile.pl/58.

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.