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.

Dziękuję!

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.

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.

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.

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ć!

Dzięki!