Roadmap to z angielskiego “mapa drogowa”. Przyjęło się używać, również w Polsce, tego terminu jako planu działania czy harmonogramu działań. “Roadmapping” jest rodzajem planowania strategicznego w którym skupiamy się nad zadaniami które należy wykonać by osiągnąć pewien cel. Sam harmonogram posiada skumulowane cele i czas wykonania.

Takie planowanie pozwala na rozłożenie zasobów i możliwości oraz skoordynowanie, i skomunikowanie działań wewnątrz zespołu… Bla, bla, bla…

A po normalnemu, czy tworzyć harmonogram produktu, a jeśli tak to po co?

Tworzenie takich planów wewnątrz firmy, czy tylko dla siebie jest bardzo przydatne. Wykonujesz konkretne działania, nie musisz się zastanawiać co dowieźć następne, bo to zaplanowałeś zanim zacząłeś jakąkolwiek pracę. Jeśli dodatkowo jest ona terminowa (a taka w sumie jest w projekcie “Daj się poznać“), to można poszczególne punkty umieścić w odpowiednich przedziałach czasowych. Widać wtedy czy w ogóle mamy szansę zdążyć, oraz jeśli zrobiliśmy wszystko z głową, kto i co jest nam potrzebne przy realizacji poszczególnych punktów. To pozwala nam na wykonywanie pewnych działań z wyprzedzeniem lub jeśli pojawią się jakieś nieprzewidziane trudności na zmianę planu odpowiednio wcześniej.

Minusy takiego harmonogramu to czas poświęcony na jego tworzenie (co od razu wskazuje, że nie warto go tworzyć dla bardzo prostych rozwiązań). A drugi (dość subiektywny) plan psuje możliwość kreatywnego tworzenia. Troszkę zmniejsza zabawę i z 80% RnD/20% programming robi 80% programming/20% RnD.

Załóżmy że zdecydowałeś się stworzyć roadmapę, co dalej?

A dalej prosta sprawa. Siadasz i tak naprawdę szykujesz pewnego rodzaju GTD dla swojego projektu. Jaką ma przybrać formę? – zapytasz. Dowolną! W większości widuję po prostu listę rzeczy, rzadziej (a szkoda) algorytm wykonania poszczególnych elementów wraz z planem B, czasem po prostu listę TODO.

Zdania na temat tego, czy roadmapa powinna, czy nie powinna posiadać daty wykonania poszczególnych elementów są podzielone. Według mnie to zależy czym dla Ciebie ten harmonogram jest. Planem wykonania, właściwie już planem zadań bądź dużych przypadków użycia, czy raczej zakreślenie wizji produktu. Takim rzeczywiście strategicznym podejściem byłoby zrezygnowanie z dat i traktowanie tego jako wizji zależnej od wykonania poszczególnych kroków.

Masz już roadmapę? To prawie super…

Roadmapa jeśli jest ukryta staje się fajną wizją czy też planem. Natomiast odkryta, pokazana klientowi staje się pewnego rodzaju kontraktem. Często kulą u nogi. Nie wiem czy mieliście sytuacje – “…obiecaliście mi możliwość X na której mi zależało…”, “…mieliście rozwijać się w kierunku Y, jesteście nieprzewidywalni…”? To spory problem, zwłaszcza w podejściu Agile w którym ustalamy, że pewne rzeczy, w tym harmonogram (lepiej brzmi niż roadmapa), są stałe tylko i wyłącznie na okres sprintu. A potem wszystko może ulec zmianie. Tylko, że klienci nie lubią zmian w strategii. Warto się zastanowić nad upublicznieniem… Choć w zakresie “Daj się poznać” chyba spokojnie można to zrobić. Więc czas przygotować roadmapę produktu.

2 Replies to “Roadmap – czy to potrzebne?

  1. Z doświadczenia komercyjnego mogę powiedzieć, że roadmapa daje dużo wartości jeśli jest publikowana przez klientem. Owszem nakłada na nas pewne ograniczenia, które są trudne do przesunięcia. Z drugiej strony działają niesłychanie mobilizująco. Wszystko zależy od sytuacji, ale nie skreślałbym opcji publikowania roadmapy. Czasami łatwo ją przesunąć a na pewno harmonogram jest dzięki niej lepiej przestrzegany.

    1. Tu się zgadzam, wskazuję tylko, że trzeba uważać. Jeśli to dla Ciebie mobilizujące to super!

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *