Jak tworzyć mapę produktu? Case study GBX Soft.

Jak tworzyć mapę produktu? Case study GBX Soft.

Jesteś ciekawy jak tworzy się mapę produktu? Kto powinien ją tworzyć i jakimi zasadami się kierować?

Jakiś czas temu pisaliśmy na naszym blogu, czym jest mapa produktu i jakie daje korzyści. Dzisiaj chcę krok po kroku pokazać Ci, jak tworzyć mapę produktu oraz jakich narzędzi do tego używać. Przedstawię również, jak ten proces wygląda w naszej firmie. Pamiętaj, że mapa produktu to narzędzie uniwersalne i można je stosować zarówno przy budowaniu produktów cyfrowych, ale także w codziennym życiu, np. planując osobiste cele długoterminowe 😊

Rodzaje map produktowych

Mapa produktu jest ogólnym planem na budowę lub rozwój danego produktu cyfrowego. Pozwala na określenie i wytyczenie konkretnych punktów, do których dąży zespół pracujący nad projektem. Z tego względu wyróżniamy różne rodzaje map produktowych. Podział powstał, biorąc pod uwagę mierzalność i realność wyznaczanych celów – dla różnych projektów, te wartości są całkowicie inne.

Mapa zorientowana na konkretne epiki

Jest to roadmapa, która w swoim szablonie posiada stworzone już epiki – czyli zbiory historyjek użytkownika. Z tego typu mapy produktu korzystamy najczęściej. W naszym procesie przygotowania projektu jest moment, w którym Scrum Master wraz z Product Ownerem, przygotowują epiki, a w kolejnych iteracjach historyjki użytkownika. Na tej bazie tworzona jest roadmapa, wstępnie definiując priorytetowość poszczególnych epik, a tym samym wyznaczając kolejność prac nad danym projektem. Roadmapa zbudowana z epik świetnie sprawdza się podczas budowania nowego produktu. Jesteśmy wtedy zorientowani na konkretne funkcjonalności, które dowożą wartości biznesowe dla użytkowników.

Mapa zorientowana na konkretne cele (KPI)

Ten rodzaj najczęściej jest stosowany podczas rozwoju istniejących już produktów. Dzieje się tak, ponieważ wyznaczanie celów biznesowych, które mogą być atrakcyjne dla użytkownika końcowego lub potrafią wygenerować większy dochód dla pomysłodawcy, łatwiej określić mając już pewne dane i doświadczenia z rynku. Dla przykładu, łatwiej jest określić cel zwiększenia konwersji użytkowników o 5% w ciągu miesiąca, znając realne dane konwersji, która występuje przez ostanie 2 – 3 miesiące, aniżeli od razu założyć wysokość konwersji początkowej, nie mając żadnych danych. Kolejnym przykładem elementu roadmapy może być zwiększenie ilości użytkowników docierających do ostatniego kroku przy rejestracji – to też przykład, który określić możemy tylko wtedy, gdy posiadamy dane statystyczne zebrane przez dany okres czasu.

Kto powinien tworzyć mapę produktu?

Mapa produktu to diagram określający kierunek rozwoju lub budowy oprogramowania. Kto zatem powinien ten kierunek wyznaczać? Nie ma jasnych wskazówek, kto powinien być odpowiedzialny za stworzenie i zarządzanie mapą produktu, jednak najczęściej powinno to być zadanie dla Product Ownera / Product Managera. Dla jasności – mapa produktu nie jest stosowana tylko w projektach prowadzonych zwinnie. Z tego też względu, mapa może być doskonałym narzędziem do zarządzania dla Kierowników Projektów. W tym wypadku Kierownik Projektu zamiast stosować standardowy Excel z terminami, może zastosować roadmapę, która również będzie zawierała terminy, ale też czytelniejszy obraz całego projektu.

Narzędzia do tworzenia map produktów

Mapy produktów można tworzyć już za pomocą zwykłego Excela. Osobiście jednak bardziej polecam narzędzia, które zostały do tego specjalnie stworzone. Posiadają one zazwyczaj kilka rodzajów szablonów, które można dopasować do konkretnych procesów wdrożonych w danej firmie. Dodatkowo, świetnie sprawdzają się w pracy zespołowej, komentowaniu i udostępnianiu wyników. W naszej firmie korzystamy z Miro.com, który używany jest również podczas prowadzenia retrospekcji, budowania Mind Mapy produktu, a także estymacji projektów. Dzięki swobodnemu dostępowi oraz intuicyjnemu interfejsowi, Miro imituje pracę na klasycznych whiteboardach – dla mnie petarda! Poniżej krótka lista narzędzi – nie są to narzędzia tylko do tworzenia map produktów 😊

Jak wygląda tworzenie mapy produktu w GBX Soft?

Na potrzeby tego artykułu stworzyłem wymagania projektowe do aplikacji, która ma służyć do obsługi ofert pracy. Potencjalny pracownik szuka w aplikacji webowej ofert pracy, a pracodawca ma możliwość umieszczania w niej swoich ogłoszeń. Główne założenia aplikacji:

  • Rejestracja i logowanie dla pracownika oraz dla pracodawcy.
  • Dodawania ogłoszeń przez pracodawcę wraz z procesem płatności za ogłoszenie.
  • Przeglądanie ogłoszeń przez pracownika w formie listy.
  • Przeglądanie ogłoszeń przez pracownika w formie mapy.
  • Ustawianie filtrów do powiadomień dla pracownika.
  • Aplikowanie na dane ogłoszenie przez pracownika.
  • Wysyłanie powiadomień mailowych do pracodawcy o nowych aplikacjach na jego ogłoszenie.
  • Moje konto dla pracownika  – widzi listę ogłoszeń, na które aplikował.
  • Moje konto dla pracodawcy – widzi listę swoich ogłoszeń oraz dokonanych płatności.

Znamy założenia aplikacji – to od czego zaczynamy? Pierwszym etapem jest określenie epik dla danego projektu. W tym wypadku epiki prezentują się następująco:

Roadmapa / mapa produktu

Mamy podzielony projekt na składowe, które staną się kolejnymi celami i wyznacznikami na roadmapie. Teraz warto zastanowić się, jakie działy / osoby będą brały udział w projekcie. W naszym przypadku zakładamy, że w projekcie mamy już przygotowane grafiki i skupiamy się na warstwie programistycznej. Dzielimy projekt na działy oraz osoby:

Roadmapa / mapa produktu

Każdy kafelek oznacza kolejną osobę potrzebną do pracy nad projektem. Teraz musimy określić jednostkę czasową, w której będziemy się poruszać, układając mapę produktu. Pracując zwinnie, gdzie jednostką czasu jest Sprint, u nas trwa to zazwyczaj 2 tygodnie. Przyjmujemy taką jednostkę i tworzymy podział czasowy projektu – przy okazji definiujemy też większą jednostkę. Na poniższym przykładzie będzie to miesiąc, ale dla większych projektów może to być kwartał, półrocze a może nawet cały rok.  

Roadmapa / mapa produktu

Tak wygląda nasz szablon do mapy produktu dla tego projektu. Nie wiem, jak zespół oceni długość całego projektu, dlatego dodałem dużą ilość sprintów. W całości pusta mapa prezentuje się następująco:

Roadmapa / mapa produktu

Teraz przychodzi czas na rozłożenie epik w czasie. W zależności od sposobu zarządzania projektami, może robić to sam Kierownik Projektu (o ile posiada w tym temacie doświadczenie i potrafi poprawnie określić wymagany czas pracy) lub cały zespół. My określamy wymagany czas pracy w zespole, który docelowo będzie wykonywał zadaną pracę. Podczas określania orientacyjnego czasu pracy nad poszczególnymi epikami, zawsze zakładamy margines błędu – jeżeli uda nam się szybciej skończyć to super 😊 Jako, że pracujemy zwinnie, to często mapa produktu musi być aktualizowana, ale główne elementy pozostają w ryzach. Powyższa mapa produktu nie jest wykorzystywana do wyceny prac programistycznych – służy jako narzędzie wspomagające planowanie prac. Każdy dział może pracować w innym tempie, dlatego kopiujemy epiki i dodajemy je w dwóch różnych kolorach ze względu na poszczególne działy. Teraz to już praca zespołowa i rozłożenie kolejności wykonywanych prac.

Roadmapa / mapa produktu

Tak prezentuje się roadmapa omawianego projektu. W naszych projektach zawsze dodajemy jeden dodatkowy sprint, tzw. Bug sprint. Pozwala on na spokojnie dokonać jeszcze testów regresji i wdrożyć poprawki do błędów, które mogły pojawić się w ostatnich sprintach. Mapa dostarcza wiele informacji i pozwala zaplanować prace zespołu na kolejne miesiące. Dla przykładu, z powyższej mapy możemy wyczytać, że:

  • Do stworzenia projektu potrzebujemy 2 programistów frontendowych i 3 backendowych.
  • Można wykonać projekt w dobrym czasie, korzystając z 2 progrmiastów frontendowych oraz 2 backendowych.
  • W zespole  (2 front + 3 back) jesteśmy w stanie dostarczyć projekt w niecałe 3 miesiące.
  • „Front” będzie miał część logiki serwerowej gotowej wcześniej, co pozwoli im lepiej rozkładać prace i od razu pracować nad docelową logiką.
  • Wiem, w którym momencie, który cel zostanie osiągnięty.

Oczywiście musimy brać pod uwagę, że jest to ogólny obraz i w trakcie prac może dojść do nieoczekiwanych zwrotów – wtedy należy skorygować roadmapę. Przy projektach zwinnych jest to bardzo częste, ponieważ dowozimy wartości i jakość, a nie godziny pracy. Osobiście podczas każdego projektu dokonuję korekt kilka razy. Nasz partner, z którym współpracujemy, zawsze ma dostęp do aktualnej wersji mapy produktu.

Podsumowanie

W artykule starałem się przekazać Ci wiedzę praktyczną związaną z tworzeniem map produktów. Technik jest wiele – każdy powinien dostosować ten proces do swojej branży i jej realiów. Z mojego punktu widzenia najważniejsze i warte zapamiętania jest to:

  • Mapa produktu to nie świętość – przygotuj się na to, że w miarę rozwoju oprogramowania może być modyfikowana.
  • Nie potrzebujesz od razu płatnych narzędzi do stworzenia mapy – wystarczy nawet kartka papieru i kilka markerów.
  • Mapa wskazuje drogę i kierunek rozwoju – nie jest harmonogramem, którego używa się jako załącznik do umowy.
  • Warto jest dokonywać estymacji czasowej z całym zespołem – cały zespół zdaje sobie wtedy sprawę z kierunku rozwoju oraz stara się dotrzymać „danej obietnicy”.

A czy Ty tworzysz mapy projektowe? Jeżeli tak, to chętnie posłucham o Twoich doświadczeniach! Zostaw komentarz 😊

Spodobał Ci się artykuł?

Masz pytania? Zacznijmy rozmowę! 🙂

Klikając wyślij, zgadzasz się na wykorzystanie Twojego adresu email oraz imienia do kontaktu elektronicznego, a także do przesyłania wiadomości marketingowych. Administratorem Twoich danych osobowych jest Graphicbox Sp. z o. o. ul. Lwowska 6/201, Rzeszów. Więcej w polityce prywatności.

Form Men

2 Komentarzy

Dodaj komentarz

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