LeanAgile.ninja - Roadmapa

Wyobrażacie sobie jak wyglądały mapy rozwoju produktów takich jak Zoom, Teams czy Mural na początku roku 2020? Założę się, że nie zakładały ani pandemii, ani skokowego wzrostu zainteresowania rynku.

Czy firmy, które rozwijały jakiekolwiek produkty, lub usługi, które zostały dotknięte przez pandemię (czyli właściwie wszystkie) trzymały się kurczowo obranych planów? Jeśli tak to może już ich nie ma. Tak jak na przykład kilku sieci handlowych, które niedawno zajmowały przestrzenie w galeriach handlowych.

Nie trzeba jednak wydarzeń tak drastycznych i jak dotąd rzadkich by mapy rozwoju produktów musiały zmieniać się częściej niż to się dzieje.

Ten artykuł powstaje jako rozwinięcie tegorocznego wystąpienia na konferencji AgileByExample (2020). Nagranie i prezentację znajdziecie poniżej (YouTube), ale pomyślałem, że warto dodać kilka słów komentarza po polsku. Z wielką radością przyjąłem informację, że po pierwsze moja prezentacja została oceniona przez wielu uczestników. To fajnie, że chcieli się podzielić informacją zwrotną, a jeszcze większą radość pokazały liczby postaci czołówki ocen pod kątem treści i formy. To wielki zaszczyt być biorąc pod uwagę liczbę i poziom prelegentów z całego świata.

Po pierwsze mamy jako branża problem z roadmapami. Wiele z nich nie istnieje, jest ukrywana, lub jeśli jest aktualizowana to za rzadko. Dzieje się tak z różnych powodów, od strachu o poufność planów, po strach przed tym, że mapa taka będzie stanowiła obietnicę tego jak będzie wyglądała przyszłość i argument oskarżeń, że nie dotrzymujemy obietnic.
Ponadto w praktyce wiele map przypomina bardziej rozkład jazdy autobusów, a nie prawdziwą, a najlepiej interaktywną i zwinną mapę taką jak choćby Google Maps.

leanagile.ninja - Jeśli mapa 1

Niestety wiele map rozwoju produktu wygląda niczym analogowe rozkłady jazdy. Nie dość, że podaję one pojedyncze wartości, tak jak precyzyjna godzina przyjazdu, która zwykle nie jest osiągalna, oraz dokonują projekcji w przyszłość.

Powoduje to, że organizacja pozostaje ślepa na fakt, że tempo dostarczania, przy założeniu ograniczonych zasobów, jest determinowane przez kilka czynników. Kluczowe z nich to, ile mamy inicjatyw w toku, oraz to, że rozwój złożonych produktów nie polega jedynie na dokładaniu nowych „ficzerów”.

Rozwój produktu powinien być drogą prowadzącą przez różnego rodzaju eksperymenty, niczym odwiedzanie napotkanych po drodze miejscowości, w których możemy znaleźć coś na tyle interesującego, że postanowimy się tam zatrzymać. Być może dowiemy się również o czymś, co zechcemy dodać do naszego planu przejazdu.

Temu nie sprzyja budowanie map rozwoju produktów w oparciu o oś czasu, a raczej o kolejność doświadczeń, jakie chcemy zapewnić użytkownikom, informację, które chcemy pozyskać (np. z metryk) czy też eksperymenty, które chcemy przeprowadzić. To również ścieżka rozwoju technologii, bezpieczeństwa czy skalowania i innych wymagań niefunkcjonalnych.

leanagile.ninja - Jeśli mapa 2

Pamiętajmy, że prawdziwie zwinna i interaktywna mapa pozwala nam na wybór jednego z kilku scenariuszy prowadzących do celu. Podobnie jak w przypadku podróży mogą liczyć się napotkane atrakcje i nowe możliwości a nie jedynie czas przejazdu. A co jeśli nasz cel zmieni się w trakcie podróży. Czy wasza mapa produktu jest gotowa na taką szybką zmianę?

Tempo pozyskiwania informacji powinno dyktować nam tempo aktualizacji mapy, tak by nie była ona jedynie listą życzeń sprzed kwartału czy roku. W nawiązaniu do nowego Scrum Guide’a datowanego na 2020, który wprowadza koncepcję Celu Produktu warto zastanowić się, czy takie cele, nie powinny znaleźć się na mapie. Powinniśmy naturalnie unikać stratnego i niebezpiecznego budowania kilku różnych celów do przodu, a na pewno na bieżąco skupiać się na jednym, najbliższym i najszybciej weryfikowalnym. Cel produktu to też przecież rodzaj hipotezy.

leanagile.ninja - Jeśli mapa 3

Mapa rozwoju produktu powinna zawierać kilka wymiarów, być może takich, które mogą niezależnie zmieniać się w czasie (nauka o produkcie, użytkowniku, grupy docelowe, najważniejsze – nowe doświadczenie użytkownika, oraz często pomijany rozwój technologii). Mapa taka powinna przedstawiać możliwe zakresy a nie zafiksowane bloki oparte o myślenie życzeniowe, co do czasu trwania!

A jak wygląda Twoja mapa rozwoju produktu?

  • Czy jest dostępna i dla kogo?
  • Jak często jest aktualizowana?
  • Kiedy miało to miejsce ostatni raz?
  • Czy oparta jest o oś czasu czy inne wymiary? Czy widać na niej ścieżkę rozwoju technologii?
  • Czy operuje konkretnymi, szczegółowymi datami czy może zakresami?
  • Czy pokazuje tylko nowe „ficzery”?
  • Czy jest wypełniona po brzeg?
  • Czy zostawia miejsce na reakcję na pierwsze dostarczone releasy, lub wersje?
  • Co dzieje się, gdy widzimy, że coś nie zostało dostarczone np. na czas?

 

To tylko kilka z pytań, którymi możesz sprowokować w swoim otoczeniu dobrą dyskusję o tym jak „roadmapować” jak zawodowcy 😊
Na koniec obiecane nagranie z AgileByExample, a jeśli po przeczytaniu lub obejrzeniu masz komentarze, lub pytania to daj znać!

AgileByExample 2020: Radosław Orszewski – A real road map or just a bus stop timetable? – YouTube

Dzięki!