Z tego podcastu dowiesz się:
- Dlaczego backlog bez priorytetów sparaliżuje prace zespołu
- Po co właściwie Product Manager ustala priorytety
- Czym charakteryzują się najważniejsze metody priorytetyzacji
- Jak działają poszczególne techniki: RICE, The Product Tree, Story Mapping, Buy a Feature
- Która metoda jest najbardziej, a która najmniej skomplikowana
- Kiedy priorytetyzować backlog z zespołem, a kiedy z użytkownikami
- W jaką grę zagrać z klientami, żeby uzyskać od nich priorytety
- Co to jest paraliż decyzyjny i jak go uniknąć
Podcast wysłuchasz także na:
Materiały dodatkowe
Jeśli chcesz zgłębić temat innych technik priorytetyzacji, a nie znasz jeszcze Value va Effort, KANO czy MoSCoW, to koniecznie zajrzyj TUTAJ, gdzie nagrałem podcast o tych trzech podstawowych metodach ustalania priorytetów.
A teraz przejdźmy do ilustracji pomocniczych dla technik omówionych w tym podcaście:
RICE
Zwróć uwagę w jak prosty sposób można zobrazować technikę RICE. Poniżej umieszczam grafikę autorstwa popularnej ekipy produktowej, Roadmunk.
Product Tree
Drzewo produktowe może wyglądać inaczej za każdym razem, gdy je tworzysz z uczestnikami warsztatów. Zachęcam, żeby czasem dać się ponieść wyobraźni i dać jak najwięcej wolności osobom, które zgłaszają swoje pomysły biznesowe lub techniczne.
User Story Mapping
Poniższa ilustracja ładnie pokazuje jak zespół produktowy oddzielił najważniejsze (wartościowe) aktywności od tych, które pomogą jeszcze poczekać. W tym przypadku mamy:
- Różowa karteczka – większy obszar
- Niebieska karteczka – mniejszy obszar / kategoria akcji
- Żółta karteczka – zadanie / akcja
Buy a Feature
Każdy, kto chociaż raz w życiu grał w Monopoly lub Eurobiznes, polubi grę w Kupowanie Funkcjonalności. Zachęcałbym jednak, żeby ten eksperyment przeprowadzać offline (jeśli akurat nie jesteśmy w trakcie intensywnej pandemii), a wszystkich uczestników zgromadzić w jednym pomieszczeniu. Takie ustawienie sprzyja podejmowaniu negocjacji i zachęca stakeholderów do targowania się między sobą.
Jeśli mój podcast wydał Ci się interesujący, ale szukasz dodatkowego wsparcia w rozwoju zawodowym, to zapraszam na moje konsultacje managerskie.
Transkrypcja podcastu
Być jak manager. Podcast. Epizod 13.
Dzień dobry, jeżeli jesteś tutaj po raz pierwszy albo jeżeli jesteś tutaj po raz któryś, ale zapomniałeś już, do kogo kieruję ten podcast, to ja szybciutko przypomnę, że ten podcast kierowany jest głównie do osób, które są od niedawna albo zostaną wkrótce przedstawicielami tak zwanego managementu w branży IT, czyli do obecnych lub przyszłych product managerów, project managerów, product ownerów, analityków biznesowych, scrum masterów również. To, co staram się robić w ramach tego podcastu, to dzielić się pewną wiedzą i doświadczeniem praktycznym, które zdobywałem przez ostatnie lata, będąc właśnie częścią tej szeroko pojmowanej branży IT.
Jeżeli chodzi o dzisiejszy temat, to jest to trochę kontynuacja poprzedniego podcastu, ponieważ ostatnio rozmawialiśmy sobie o metodach priorytetyzacji backlogu, czyli o tym, jak definiować, jak ustalać priorytety dla poszczególnych czy to zadań, czy pomysłów biznesowych, czy pomysłów na usprawnienia funkcjonalne. To dość ważna część pracy każdego product managera, ale także product ownera, jeżeli product owner odpowiada za ustalanie priorytetów na backlogu.
Ostatnio opowiadaliśmy sobie właśnie, jak przygotować backlog produktu, zanim jeszcze sięgniemy po którąś technikę priorytetyzacji. Opowiedziałem również o takich trzech podstawowych technikach value kontra effort, MoSCoW czy KNO. Zachęcam do odsłuchania dwunastego epizodu podcastu, aczkolwiek nie jest to wymagane, żeby zrozumieć to, o czym dziś będziemy rozmawiać.
A dziś, przechodząc już coraz bliżej do sedna naszego spotkania i sensu tego, dlaczego dziś się spotykamy, to porozmawiamy sobie o czterech bardzo popularnych technikach priorytetyzacji, po które sięgają product managerowie tak naprawdę na całym świecie. Będą to: technika RICE, technika The product tree, czyli drzewo produktowe, technika story mapping albo user story mapping, różnie się to nazywa, oraz technika buy a feature, czyli kup funkcjonalność. Zanim grubo już wjedziemy w ten temat, zachęcam, żeby zapisać się na mój newsletter na stronie bycjakmanager.pl. Z góry też dziękuję za każdy komentarz pozostawiony na moim blogu lub na mediach społecznościowych. A jeżeli czujesz większą potrzebę omówienia jakiejś konkretnej kwestii lub szukasz indywidualnej porady managerskiej, ponieważ np. chcesz się przebranżowić na managera, to zachęcam do umówienia się ze mną na konsultacje jeden na jeden za pośrednictwem mojego bloga, zakładka Konsultacje.
Lećmy z technikami, bo jak zwykle lubię się rozgadywać, zwłaszcza na początku. Przypomnę też bardzo ważny kontekst. Mianowicie po co nam w ogóle znajomość jakichkolwiek technik priorytetyzacji? Otóż ustalanie priorytetów to jest jedna z najważniejszych kompetencji product managerskich. Bez niej ani rusz. Bez znajomości tych technik może cię dopaść tzw. paraliż decyzyjny. Nie będziesz wiedział w którą stronę pokierować produkt, pokierować zespół. I bez poprawie ustalonych priorytetów w końcu, zablokujesz sam proces deweloperski, a to z kolei złe ustalenie tych priorytetów może odbić się czkawką dla organizacji, w której pracujesz. W jaki sposób? Może chociażby ucierpieć wizerunek firmy, firma może stracić dobrą okazję rynkową, możesz wkurzyć samych użytkowników, wdrażając nie te funkcjonalności, na które czekali. Możesz także przepalić budżet projektowy na wdrożenie niepotrzebnych rzeczy, a wiadomo, że pieniądze są istotną częścią każdego biznesu. Jest wiele złych scenariuszy, które czyhają na ciebie za rogiem. Natomiast odpowiednia technika priorytetyzacji pomoże ci uniknąć jakiegokolwiek wykolejenia w projekcie.
Pierwsza technika nie jest to łatwa technika, aczkolwiek po tym, jak zrozumiesz w jaki sposób działa i jak się nią posługiwać, to uwierz mi, może ci nie tyle uratować tyłek, co tak naprawdę wnieść ogromną wartość do pracy twojej i całego zespołu projektowego. Tą techniką jest RICE – skrót od słów Reach, Impact, Confidence i Effort. Zaraz omówimy sobie dokładnie każdy z tych aspektów. To jest technika znana także jako taki wewnętrzny system scoringowy dla priorytetyzowania pomysłów. Dzięki skorzystaniu z tej techniki zespół może tak naprawdę pracować nad różnymi inicjatywami i decydować, które najbardziej, czyli najskuteczniej wpływają na cele samej organizacji. System mierzy tak naprawdę każdy feature pod kątem czterech obszarów. Obszar pierwszy to Reach, czyli powiedzielibyśmy zasięg – na ilu użytkowników wpłynie dana funkcjonalność w pewnym okresie czasu, jaki przyjmiemy. Przykładowa skala, jaką możemy tutaj przyjąć, to liczba użytkowników kwartalnie, których dotyczy albo będzie dotyczyć dane wdrożenie, usprawnienie, dana funkcjonalność. Albo np. kwartalna liczba transakcji, czyli na jakie transakcje wewnątrz systemu wpłynie dane usprawnienie. Najważniejsze jest to, że jeżeli siadam już do stołu, mamy tę listę funkcjonalności i przyjmujemy sobie te skale, to istotne jest, aby do każdej funkcjonalności ta skala była jednakowa. No bo jeżeli przyjmiemy różne skale dla różnych funkcjonalności, no to na logikę nie będziemy w stanie ich do siebie porównać. Skala musi być jedna. Impact – drugi obszar, czyli jak bardzo, jak intensywnie, z jaką mocą wpłynie dana funkcjonalność na indywidualnych użytkowników. I tutaj skala jest sugerowana z góry przez twórców tej techniki. Otóż jest to skala punktowa od 0,25 do 3. 0,25 oznacza, że wpływ jest naprawdę bardzo minimalny takiej funkcjonalności, ledwo wręcz zauważalny przez indywidualnych użytkowników. 0,5 no to już jest mały wpływ. Jeżeli wystawilibyśmy 1 punkcik, to jest to średni wpływ. Jeżeli 2 punkty, no to już tutaj mówimy o dość dużym wpływie na indywidualnych użytkowników, natomiast trójeczka to jest ogromny wpływ, jaki wywrze ta funkcjonalność na indywidualnych userów. Trzeci obszar – Confidence. Confidence, czyli pewność. Ale o jaką pewność chodzi? Chodzi o to, że tutaj estymujemy, oceniamy, na ile jesteśmy pewni tych naszych dwóch poprzednich estymacji, czyli Impactu i Reach, czyli zasięgu i wpływu. Na ile my jesteśmy pewni w ogóle tego, co wyestymowaliśmy? Zakładając, że Reach, pewna skala opiera się na danych, a Impact, czyli wpływ na indywidualnych użytkowników opieramy już na naszej intuicji, no to teraz ustalamy, na ile my w ogóle jesteśmy pewni naszych estymacji. I tutaj też jest skala sugerowana przez twórców techniki. Jeżeli jesteśmy pewni na 50%, no to to jest niska pewność. Jeżeli jesteśmy pewni tych dwóch poprzednich estymacji na 80%, no to tutaj już jest średnia pewność. Ale jeżeli my jesteśmy na 100% pewni, no to wiecie, wysoka pewność, naprawdę nie mamy żadnych obiekcji co do tego, jak wyceniliśmy poprzednie dwa obszary. I teraz jeżeli nie jesteśmy pewni wycen na co najmniej 50%, to tu jest taka sugestia, że być może warto zaparkować daną funkcjonalność gdzieś na boku i wrócić do niej za jakiś czas, kiedy zdobędziemy trochę więcej danych i informacji, które poprawią nam estymację. Bo jeżeli będziemy omawiać funkcjonalności, co do których w ogóle nie jesteśmy pewni, jak je wycenić, to zaparkujmy je. Pozbierajmy jeszcze więcej informacji albo danych na ich temat i wróćmy do nich, kiedy będziemy pewni bardziej tych naszych estymat. Kolejny, już ostatni obszar tego RICE to jest Effort. Effort – w wolnym tłumaczeniu wysiłek. Wysiłek, jaki jest potrzebny do wdrożenia danej funkcjonalności. I tutaj chodzi o to, że wszystkie poprzednie czynniki, zasięg, wpływ, pewność, reprezentują potencjalne korzyści. Dlatego je do siebie dodamy za niedługo. Natomiast wysiłek w tym zestawieniu to zawsze będzie nasz koszt, który musimy ponieść, żeby dowieźć dane rozwiązanie. Dlatego potencjalne korzyści zawsze będziemy dzielić przez ten koszt. Zaraz wyjaśnię to na przykładzie. Effort możemy wyceniać na kilka sposobów, w zależności od naszych potrzeb. Natomiast niezależnie od jednostki wycen, jaką przyjmiemy, pamiętajmy, żeby zawsze przyjmować, przed chwilą o tym mówiłem, taką samą skalę do wszystkie feature’ów. Najczęściej ten Effort to się wycenia w tak zwanych osobomiesiącach. Szacujemy, ile miesięcy potrzebuje cały zespół: designerzy, analitycy, programiści, żeby dowieźć dany feature. Jeden miesiąc to jest punkt, a wysiłek poniżej miesiąca to 0,5 punktu. Czyli jeżeli szacujemy, że wszystkie osoby zaangażowane w pracę nad daną funkcjonalnością będą potrzebowały 2 miesiące, to dajemy 2 punkty. A jeżeli mniej niż miesiąc, np. 2,5-3 tygodnie, to dajemy 0,5. Można też wyceniać w roboczodniach, czyli tak zwanych mondaysach – poniedziałkach. To jest może nieco bardziej uproszczona wersja tej skali. Wyceniamy bowiem, ile w sumie dni zajmie zespołowi wdrożenie rozwiązania. Jeżeli zajmie 14 dni albo 60 dni, no to dajemy tutaj albo 14, albo 60. To już od nas zależy, jaką skalę przyjmiemy. I co dalej z tym robimy? Mamy już wiedzę na temat tej techniki, wiemy, jak powinniśmy wyceniać, co dalej? Otóż wszystkie potencjalne wartości musimy przez siebie pomnożyć. Czyli Reach, Impact i Confidence, czyli ten zasięg, wpływ i naszą pewność wyrażoną w procentach mnożymy przez siebie, a następnie te trzy wartości przemnożone podzielimy przez ten nasz wysiłek, przez tę naszą ujemną, nasz Effort. Sięgnijmy teraz po jakiś namacalny przykład, bo rzeczywiście bez przykładu moglibyśmy się tutaj pogubić.
Wyobraź sobie, że jesteś product managerem w firmie międzynarodowej, która posiada swój produkt e-commerce. Jest to marketplace w modelu B2C, czyli tam, gdzie firmy, przedsiębiorcy odsprzedają coś użytkownikom końcowym. I to jest portal webowy, ale także aplikacja mobilna, za pośrednictwem których użytkownicy mogą wynajmować sprzęt elektroniczny od firm, sprzedawców, szeroko pojętych retailerów. Sprzęt jest nowy albo używany, laptopy, aparaty, gadżety. Wynajem jest krótko, ale także średnio lub długoterminowy, nawet na kilka lat. Taki jest kontekst biznesowy. Sam proces wynajęcia takiego sprzętu jest bardzo prosty. Użytkownik wchodzi na stronę, wybiera sprzęt, klika „Wynajmij”, wybiera jeden z dwóch sposobów rozliczenia: albo płatność z góry za wynajem za cały okres, albo płatność miesięczna pobierana np. z karty kredytowej. I w zależności od wybranej opcji podaje dane karty kredytowej lub debetowej i następnie czeka na paczkę ze sprzętem, umowa została zawarta, leasing czy tam wynajem ruszył. I do ciebie jako product managera z różnych źródeł docierają różne pomysły na nowe usprawnienia serwisu. Lista nowych pomysłów jest dość długa, dlatego postanawiasz wykorzystać właśnie technikę RICE, żeby ustawić scoring dla każdego pomysłu. I wtedy rozjaśnisz sobie oraz zespołowi, co tak naprawdę jest obecnie najbardziej, a co najmniej ważne. Jednym z pomysłów, na który podobno, tak słyszałeś, czekają nie tylko sami użytkownicy, ale także retailerzy, czyli ta strona biznesowa, jest tak zwana możliwość odroczonej płatności. Człowiek, który chciałby wynająć sprzęt, mógłby opłacić wynajem dopiero po trzydziestu, a nawet po sześćdziesięciu dniach od zakończenia wynajmu. Ogólnie chodzi o dodanie nowej, tak zwanej trzeciej metody płatności, czyli płatności odroczonej. Jedna z propozycji techniczno-biznesowych jest taka, aby zintegrować się z zewnętrznym serwisem, który taką właśnie usługę oferuje. I pomysł wydaje się naprawdę spoko. Ale ty jako PM wiesz, że na liście pomysłów są także inne rzeczy. Zbierasz więc zespół projektowy, odpalasz szablon Excela przygotowany pod wyceny według techniki RICE, no i lecicie z tematem. Szacujecie Reach, czyli zasięg, przyjętą skalę, jaką sobie wyznaczacie, to liczba użytkowników tygodniowo, czyli do ilu osób dotrze, ile osób odczuje tygodniowo tak naprawdę tą funkcjonalność. I wyceniacie tę odroczoną płatność na 350 punktów, nazwijmy to, ponieważ policzyliście sobie gdzieś tam, poestymowaliście i wyszło, że tygodniowo około nawet 350 osób może skorzystać z tej funkcjonalności, że takie jest potencjalne zapotrzebowanie. Teraz szacujecie Impact, czyli jak bardzo, jak intensywnie i z jaką mocą wpłynie ten feature na indywidualnych użytkowników. Skala od 0,25 do 3 punktów. I gdzieś przegadałeś to z zespołem, i jest tak, że mały albo znikomy wpływ to w sumie aż tak nie będzie, no bo tak naprawdę jeżeli użytkownicy zaczną z tego korzystać, to dla nich to może mieć naprawdę spory wpływ. Ale też nie będzie to jakiś ogromny wpływ dla wszystkich użytkowników z kolei. Gdzieś na drodze takiego dochodzenia do kompromisu z zespołem wyceniacie to na 1, czyli że ten wpływ będzie tak naprawdę średni, przeciętny, ale jednak będzie. Nie największy, ale też nie najmniejszy. Jak dochodzi do dyskusji o tym, na ile jesteście pewni tych estymacji, to zespół wypracowuje estymację tutaj w tym miejscu na poziomie 80%, czyli zgodnie twierdzicie, że nie możecie być 100% pewno co do tego, że 350 osób skorzysta tygodniowo z tej funkcjonalności. Co do tego, że będzie miało średni wpływ, nie możecie być 100% pewni. Dlatego wyceniacie własną pewność, własny Confidence na poziomie 80%, czyli taka średnia pewność. No i teraz Effort. Jaki wysiłek potrzebny będzie do wdrożenia takiej funkcjonalności, do zintegrowania się z takim serwisem odroczonej płatności? Podejmujecie decyzję, że wycenicie to w tak zwanych osobomiesiącach. Szacujecie, ile miesięcy potrzebuje cały zespół, designerzy, analitycy, programiści, testerzy, żeby ten feature dowieźć na produkcję. I wyceniacie to na 1,5 punktu, czyli 1,5 osobomiesiąca, tak bym powiedział, potrzebnego do dowiezienia tej funkcjonalności. I teraz co w tym magicznym Excelu, który przygotowałeś, powinno się zadziać? Otóż 350 punktów zasięgu, czyli liczbę 350 mnożysz razy Impact. Impact wyceniliście na 1. I mnożysz razy 80%. Czyli mnożysz przez tę waszą pewność. Z tego prostego równania: 350* 1*0,8 wychodzi wam 280. Natomiast Effort potrzebny do dowiezienia wyceniliście na 1,5. Czyli 280 dzielisz na 1,5 i wychodzi ci scoring tego konkretnego feature’a na poziomie 187 punktów. Liczba 187 to jest scoring.
I teraz podobne ćwiczenie, już nie będziemy brać kolejnego przykładu, bo po tym pierwszym, wydaje mi się, jasno wiemy, jak mamy to zrobić. Natomiast nie chcę sięgać po kolejny przykład, ponieważ dokładnie ten sam mechanizm wykorzystasz, omawiając kolejne funkcjonalności. I jeżeli masz na pipelinie 5 albo 10 funkcjonalności, robisz to ćwiczenie do każdej z nich i patrzysz, która z nich ma najwyższy scoring. Teoretycznie, jeszcze o tym będę mówił, powinno się wziąć w pierwszej kolejności na road mapę funkcjonalność, która ma najwyższy scoring, ale pamiętajmy, że mogą być tutaj pewne aspekty, których nie przewiduje ta technika.
Jakie są więc plusy wykorzystywania techniki RICE? Otóż ta technika wymaga od zespołu, żeby operować na pewnych mądrych metrykach, zanim w ogóle zaczniemy je mierzyć. I my jako zespół musimy się upewnić, że metryki powinny być odpowiednio dopasowane do specyfiki produktu, powinny być mierzalne i osadzone w jakimś okresie czasu. Drugim plusem jest to, że zmniejsza się ryzyko stronniczości, jakie wpływa często na priorytetyzację. Bo my wyceniając coś, jesteśmy bardzo subiektywni niejednokrotnie, a dodanie przy tej technice tego współczynnika pewności Confidence często prowokuje zespół do merytorycznej dyskusji na temat samej wyceny. Jeżeli ktoś mówi: słuchajcie, to zajmie trzy miesiące, to inni mówią: chwila, na ile jesteś pewien? Confidence.
Jakie są natomiast minusy RICE? Otóż ta technika nie uwzględnia zależności pomiędzy tymi funkcjonalnościami. Zdarza się, że trzeba specjalnie czasem zaniżyć scoring dla jakiegoś feature’a na rzecz innej rzeczy, która powinna iść najpierw, bo byłaby potencjalnym blokerem. Warto więc patrzeć na tę technikę bardziej jak na dobre ćwiczenie niż jak na finalną odpowiedź na pytanie, co robimy jako następne. Drugim takim minusem jest to, że estymacje RICE nigdy nie będą w 100% precyzyjne, operujemy bowiem na pewnym poziomie ogół i nie zawsze najwyższym możliwym stopniu pewności co do naszych estymacji. Tyle, jeżeli chodzi o technikę RICE.
Druga technika to Product Tree, czyli drzewo produktowe znane też jako podcinanie gałęzi na drzewie produktowym, bo tak się też mówi o tym ćwiczeniu. Bardzo proste, bardzo przyjemne ćwiczenie, a wręcz gra, w którą możesz zagrać ze swoimi klientami albo użytkownikami. W tej technice chodzi głównie o to, żeby skroić, mówiąc dosłownie, produkt tak, żeby odpowiadał idealnie albo blisko ideału na potrzeby klientów i dał organizacji najwyższą możliwą wartość. Samo ćwiczenie polega na przystrzyganiu, powiedzielibyśmy też przycinaniu backlogu produktu, który wizualizujemy sobie jako drzewo, oraz na upewnieniu się, że te innowacyjne pomysły, które były na tym backlogu, nie zostały w tyle.
Jak zatem wygląda w praktyce drzewo produktowe? Otóż bierzesz kartkę i ołówek, rysujesz wielkie drzewo z kilkoma dużymi gałęziami. I teraz tak. Pień twojego drzewa będzie reprezentował funkcjonalności, które wasz produkt już posiada. Gałęzie natomiast będą reprezentować funkcjonalności, które zostaną wkrótce wdrożone, np. w kolejnym releasie. Korzenie natomiast reprezentują infrastrukturę albo różne wymagania techniczne, bez których wasz produkt nie zadziała lub które po prostu wspierają wasz produkt. No i teraz czego tutaj brakuje? No brakuje nam liści. Jeżeli nie jest to okres zimowy, załóżmy, że jest to okres wiosenny albo nawet letni i drzewo jest w stanie najwspanialszego własnego rozkwitu, to bez liści byłoby to smutne drzewo, wręcz umarłe jak umarły produkt. Co powinieneś teraz zrobić? Zbierasz ludzi na spotkanie, na takie warsztaty i prosisz uczestników tego spotkania, w naszym przypadku niech to będą użytkownicy, prosisz ich, żeby na małych karteczkach samoprzylepnych napisali według nich potencjalnie najciekawsze, najfajniejsze funkcjonalności, które widzieliby w naszym produkcie. Następnie prosisz tych użytkowników, jak już rozpiszą sobie te funkcjonalności, żeby przykleili te karteczki do wybranych gałęzi. I właśnie te małe samoprzylepne karteczki będą naszymi liśćmi. Co osiągamy dzięki temu ćwiczeniu? Ty jako product manager możesz łatwiej zidentyfikować, które grupy funkcjonalności albo które gałęzie produktowe są najważniejsze, najbardziej obłożone liśćmi, gdzie wymagane będzie najwięcej pracy, które feature’y powinny zostać zmienione, a może które obszary z funkcjonalnościami mogą otrzymać niższy priorytet na rzecz bardziej pilnych usprawnień? Jak chcesz zobaczyć, jak takie przykładowe drzewko wygląda, to na moim blogu bycjakmanager.pl pod postem z dzisiejszym podcastem umieściłem przykładowe zdjęcie takiego drzewa produktowego. Spójrz, jakie proste ćwiczenie, a ile informacji możesz uzyskać.
Plusy Product Tree. Pierwszy plus to to, że daje nam wizualne odczucie, jak dobrze albo jak źle są zbalansowane funkcjonalności w naszym produkcie. I drugi plusik – ta technika pozwala nam uzyskać naprawdę ciekawe insighty, ale też opinie bezpośrednio od klientów bez potrzeby sięgania po jakąś sztywną ankietę. Tak jak wspomniałem, jest to fajna gra.
Natomiast są pewne minusy tego drzewa produktowego. Pierwszym z nich jest to, że nie da nam żadnej ilościowej wartości co do tego, jak stopniować, czyli jak priorytetyzować każdy feature. Otrzymujemy tylko ogólne, wizualne wskazówki. I drugi minus, to jeśli feature’y nie są posortowane wcześniej na jakieś sensowne grupy funkcjonalne, to takie ćwiczenie może być naprawdę czasochłonne, żeby odwzorować w nim ogromny backlog. Tyle jeśli chodzi o drzewo produktowe.
Technika numer 3, którą ja bardzo uwielbiam, uwielbiają ją także designerzy. Do dziś toczą się dyskusje, czy User Story Mapping albo Story Mapping, mapowanie historyjek, ciężko to przetłumaczyć na język polski, ale też nie będę się silił z tłumaczeniami na język polski, bo nie bardzo ma to sens w branży IT, gdzie język angielski jest językiem oficjalnym, powiedziałbym administracyjnym. User Story Mapping – dla niektóry to narzędzie product designera, dla innych product managera, dla mnie jest to narzędzie przydatne każdej osobie, która potrafi i chce z tego korzystać. Nieważne czy to product designer czy product manager. Otóż piękno tej techniki proprytetyzacji leży w jej prostocie oraz w tym, że kładzie większy akcent na realne doświadczenia użytkownika niż na wewnętrzne jakieś tam opinie zespołu i stakeholderów, czytamy: business ownerów.
Objaśniam technikę User Story Mapping. Wyobraź sobie, że wzdłuż linii poziomej tworzysz serię pewnych powtarzających się obszarów albo tworzysz pewne kategorie wzdłuż linii poziomej. Każda z tych kategorii reprezentuje inny etap, każdy kolejny etap tzw. user’s journey, czyli podróży użytkownika. Jeśli nie wiesz, czym jest user’s journey, to jako że to jest też duży temat, we wpisie na moim blogu pod dzisiejszym podcastem podlinkowałem krótki film, który to sprawnie wyjaśnia, a ja będę leciał dalej. Załóżmy, że tym naszym user’s journey będzie taka ścieżka. Użytkownik najpierw wyszukuje produkt, później po znalezieniu produktu ląduje na karcie produktu, później jest rejestracja tego użytkownika w serwisie, a na końcu checkout czy jakiś koszyk, czyli finalizacja zakupów. I ten manewr, to rozrysowanie wzdłuż tej linii poziomej tych obszarów, kroków, kategorii pozwala zespołowi zastanowić się nad tym, jak tak naprawdę nasi użytkownicy nawigują po naszym produkcie od momentu uruchomienia go, przez rejestrację, jakieś ustawienia aż do chwili korzystania z wybranych funkcjonalności. Natomiast wzdłuż linii pionowej przy każdej z tych kategorii, przy każdym z tych obszarów układamy zadania, czyli nasze, powiedzielibyśmy, user’s stories. Nasze historyjki. Scrum masterzy i product ownerzy doskonale wiedzą, o czym mówię, jeśli mówię o user’s stories. Myślę, że już wszyscy powinniśmy to znać na tym etapie. Zadania układamy od najważniejszych, które umieszczamy u góry danej kategorii do najmniej ważnych, które umieszczamy u dołu każdej kategorii. Do czego nas prowadzi ta zagrywka? Otóż ta zagrywka pozwala tobie jako PM-owi spriorytetyzować kolejność funkcjonalności, nad którymi będzie pracował zespół. I czasem zadania z dolnej części tej mapy nazywane są przedmiotami backlogu, backlog items, ponieważ ich implementacja może zostać przeparkowana na przyszłość. I co robisz z zespołem, kiedy macie już według poziomej linii narysowane kategorie, a w tych kategoriach umieszczone zadania od najważniejszych do najmniej ważnych? Bierzesz grubą kredkę lub mazak, marker i rysujesz linię przecinającą od lewej do prawej te wszystkie zadana, tak żeby rozdzielić funkcjonalności, które będą implementowane od razu, w sensie w najbliższym releasie lub sprincie, oddzielasz je od tych, które przechodzą na kolejne releasy. I koniec końców pod kreską umieszczone powinny być te zadania, które przeparkowujemy na porem, a nad kreską te zadania, które dotyczą naszej ścieżki użytkownika od początku do końca i uznaliśmy wspólnie, że są najważniejsze, bez których ten user journey, ta podróż użytkownika po prostu się nie wydarzy. I te funkcjonalności u góry powinny być implementowane jako pierwsze.
Jakie są plusy tego User Story Mapping? Otóż bardzo szybko pomaga zdefiniować twoje MVP. MVP to też jest narzędzie pracy product managera, a ta technika, już po rozdzieleniu tych funkcjonalności od mniej ważnych na ważniejsze – bierzesz te ważniejsze i pyk, MVP samo się zrobiło, chciałoby się powiedzieć. Drugi plus jest taki, że ta technika skupiona jest wokół doświadczeń użytkownika, ponieważ musimy rozpisać te user stories, musimy rozpisać te zadania, zastanowić się nad mini wcześniej. I trzeci plus to to, że User Story Mapping wywołuje fajną kolaborację w zespole i tak naprawdę aktywizuje wszystkich członków zespołu do podjęcia tej wspólnej inicjatywy, zastanowienia się wspólnie nad produktem i nad tym, czego potrzebuje nasz użytkownik.
Jaki jest minus tej techniki? Ja widzę jeden poważny minus User Story Mapping, mianowicie ta metoda nie bierze pod uwagę zewnętrznych czynników, które mogą mieć wpływ na priorytetyzację. Np. nie bierze pod uwagę wartości biznesowej albo tego, jak skomplikowana, jak kompleksowa i trudna w developmencie będzie dana funkcjonalność. Tutaj warto być może sięgnąć po jakieś inne estymacje lub dodatkowe techniki, żeby się upewnić. Tyle w temacie User Story Mapping.
Przechodzimy teraz do ostatniej, czwartej techniki proiorytetyzacji, jaką chciałbym z tobą omówić. Ja zostawiłem tę technikę na koniec, ponieważ najlepsze zawsze zostawiam na deser. Nie twierdzę, że ta technika jest najlepsza w sensie że służy do wszystkiego, ale to jest personalnie jedna z moich ulubionych technik. Uwielbiam tę technikę, jest prosta, jest taką pewną grywalizacją, pewną grą, w którą uwielbiam grać z klientami i stakeholderami. Naprawdę bardzo może ci się ta technika przydać. Ta technika nazywa się Buy Feature, czyli kup funkcjonalność. I podobnie jak drzewo produktowe, tutaj też mamy do czynienia z pewną grą, w którą wciągamy albo klientów, albo stakeholderów. Od ciebie zależy, kogo ostatecznie do tej gry zaprosisz. Jeśli zrobisz to ćwiczenie z klientami, to ta metoda w łatwy sposób pokaże ci, ile warta jest ta lub inna funkcjonalność dla osób, które będą jej używać. Gra idzie w ten sposób, skup się. Wybierasz listę feature’ów. No dobra, mamy tę listę feature’ów, mamy ten backlog. Tak naprawdę punkt wyjścia jest podobny do każdej z technik. Mamy listę pomysłów, listę feature’ów, musimy ustalić jakieś priorytety i zastanowić się, co jest mniej, a co bardziej ważne. I co robisz w tej technice? Do każdego tego pomysłu przypisujesz pewną wartość monetarną. Czyli przyklejasz do nich jakby cenę. Załóżmy, że przykleimy im cenę w polskich złotych. Możesz wybrać inną walutę, jeżeli pracujesz z jakimś zagranicznym zespołem stakeholderów czy tam grupą zagraniczną stakeholderów. Musisz nadać cenę każdemu z tych pomysłów. I niech ta cena nie będzie jakaś tam z czapy, tylko niech ona zależy na przykład od tego, jak trudne w implementacji, jak skomplikowane będzie wdrożenie danej funkcjonalności. Czyli przegadaj sobie wcześniej z zespołem technicznym albo z team leaderem technicznym każdy z tych pomysłów. Gdzieś na wysokim poziomie wyceńcie te funkcjonalności. I teraz masz już listę feature’ów i każda z tych funkcjonalności ma swoją cenę. Co robisz dalej? Zbierasz grupę osób. Zaleca się, żeby maksymalnie to była grupa ośmiu osób, klientów albo członków zespołu projektowego. Tu już decyzja należy do ciebie. Natomiast powyżej ośmiu osób może się zrobić po prostu bałagan. I teraz to, co robisz, to każdej z tych osób zaproszonych na spotkanie, na te warsztaty, przydzielasz taką samą ilość pieniędzy do wydania na te pomysły albo na te funkcjonalności. I każda z osób może tak naprawdę sama decydować, ile pieniędzy wyda i na jakie funkcjonalności, na które pomysły. Prosisz teraz uczestników, żeby kupili pomysły, które lubią. Bardzo proste, zrozumiałe polecenie. Prosta prośba. Część z nich, to się często spotyka, odda nawet całe swoje pieniądze na jeden feature, na jedną funkcjonalność, którą jarają się wręcz najbardziej. Takie rzeczy się spotyka w czasie takich warsztatów. Z kolei fajnie jest obserwować, kiedy inny rozdzielają swoje pieniądze, ponieważ chcą kupić kilka mniejszych feature’ów za mniejsze kwoty, ponieważ te feature’y są dla nich bardziej istotne niż dla innych stakeholderów. Oczywiście w tym zadaniu chodzi również o to, żebyś poprosił uczestników, żeby uzasadnili swój wybór, żeby wyjaśnili, dlaczego kupili właśnie te pomysły, a nie inne. I na końcu ty, tak naprawdę już widząc, ile pieniędzy wydali stakeholderzy na dane funkcjonalności, możesz przeorganizować tę listę pomysłów i ułożyć je według kolejności od najczęściej kupowanych, najbardziej wartościowych do najmniej wartościowych, czyli tych, które były najrzadziej kupowane w czasie warsztatów. I ta technika sugeruje też, że niekiedy cena wybranej funkcjonalności będzie zbyt wysoka, żeby jeden użytkownik mógł ją kupić. To jest ciekawy case, ponieważ wtedy użytkownicy w czasie takich warsztatów muszą negocjować między sobą, jeżeli bardzo im zależy na danej funkcjonalności, ponieważ będą musieli się dogadać i zrzucić, mówiąc dosłownie po chłopsku, na wybrany pomysł. Uczestnicy będą więc musieli podejmować fajne, kreatywne, merytoryczne negocjacje.
Jakie są plusy kupowania funkcjonalności? Jeśli wierzysz w mądrość klientów i użytkowników, ja często wierzę, uważam, że to jest jedna z najfajniejszych grup, z którymi można pracować, klienci albo użytkownicy, czyli ludzie, którzy korzystają z twojego produktu, to ta metoda będzie świetna, ponieważ opiera się bezpośrednio na tym, co, co prawda w teorii, ale jednak mogą pokochać użytkownicy albo klienci. Drugim plusem jest to, że ma elementy grywalizacji. W ogóle te warsztaty, ta technika sprawia, że samo wykonywanie tego zadania potrafi bawić, sprawiać pewną radość osobom, które w nim uczestniczą. I trzeci plus, który ja bym widział, to to, że ta technika zmusza użytkowników do racjonalnego wartościowania funkcjonalności z racji tego, że każdy z nich ma ograniczone środki. Dwa razy zastanowią się, zanim wydadzą jakąś swoją złotówkę na ten lub inny pomysł.
Są też minusy jak przy każdej technice, tak że przy tej również. Ta metoda priorytetyzacji uwzględnia tylko te funkcjonalności, które już znajdują się na road mapie produktowej. Czyli te, które na pewno będą w przyszłości implementowane. Warto żebyś pamiętał – ta technika wskaże jedynie, które z nich są bardziej, a które mniej wartościowe dla użytkowników. To jest informacja, którą uzyskujesz z końcem tego ćwiczenia. I przeprowadzenie tego ćwiczenia, to też w sumie jest pewien minus, wymaga od ciebie zebrania w jednym miejscu i czasie grupy użytkowników albo klientów, co też może być trudne do skoordynowania. Oczywiście można to przeprowadzić zdalnie online, aczkolwiek uczestnicy takich warsztatów mogą mieć trudności w swobodnym przeprowadzaniu negocjacji między sobą, bo w jednym pomieszczeniu można uruchomić negocjacje i każdy może negocjować z kimś w tym samym czasie, a w czasie spotkania online – tutaj już może być pewien problem, bo zawsze panuje jedna zasada, że jedna osoba naraz się wypowiada.
Przebrnęliśmy przez 4 wspaniałe, popularne techniki priorytetyzacji. Jestem super wdzięczny, jeśli dotarłeś razem ze mną do tego momentu. Podsumujmy to w kilku słowach. Powiedzieliśmy dziś sobie o czterech popularnych technikach: RICE, Product Tree, User Story Mapping oraz Buy a Feature. Technik priorytetyzacji jest oczywiście więcej, o czym wspominałem również w poprzednim podcaście. To, kiedy oraz po którą technikę sięgniesz, zależy od kontekstu. Między innymi od specyfiki produktu, struktury zespołu, wielkości backlogu czy celów, jakie twoja organizacja chce osiągnąć. Techniki priorytetyzacji nigdy nie powinny w pełni zastępować takiej ludzkiej umiejętności podejmowania decyzji. Oczywiście są rewelacyjną pomocą dydaktyczną dla product managera przed podjęciem ważnych decyzji produktowych, ale ostatecznie to ty jako PM te decyzje podejmujesz. Techniki można wykorzystywać na kilka sposobów: jako praktyczne ćwiczenie, które pomoże członkom zespołu spojrzeć na listę funkcjonalności w ten sam lub podobny sposób albo jako np. kreatywną grę z naszymi klientami, dzięki której lepiej zrozumiemy ich potrzeby.
To tyle ode mnie na dziś. Dziękuję ci pięknie za wysłuchanie, każdy komentarz i opinię na moich mediach społecznościowych. Zapraszam do zapisania się na newsletter bycjakmanager.pl i do usłyszenia wkrótce. Dbaj o siebie i innych. Cześć!
KONIEC
Źródła
https://roadmunk.com/guides/product-prioritization-techniques-product-managers/
https://slab.com/blog/eisenhower-matrix/
https://www.career.pm/briefings/product-prioritization-techniques
https://www.aha.io/roadmapping/guide/release-management/prioritization-framework
https://plan.io/blog/feature-prioritization/
https://spin.atomicobject.com/2018/04/10/pruning-the-product-tree/
https://medium.com/i-want-to-be-a-product-manager-when-i-grow-up/user-story-mapping-dd7462ee78cf
https://agilehunters.com/3-najlepsze-metody-priorytetyzacji-product-backlogu/
