Pracując jako Product Manager oraz Product Owner często stajemy przed dylematem, jak definiować właściwe produkty oraz funkcjonalności do dostarczenia i w jaki sposób je priorytetyzować. Z jednej strony musimy się zastanowić, co przyniesie realną wartość dla klienta, a z drugiej wygeneruje przychód dla biznesu. Wśród wielu dostępnych technik dodatkową trudność sprawia wybór tej odpowiedniej dla naszego produktu.
W tym artykule chciałabym zarekomendować jedną z nich – mapowanie historyjek użytkownika, którą uważam za bardzo pomocną zarówno w fazie „product discovery” oraz „product delivery”. Swoje wnioski przedstawiłam opierając się na publikacji Jeffa’a Patton’a „Mapowanie historyjek użytkownika. Przepis na produkt idealny”.
W zwinnych metodach dostarczania produktu mamy do czynienia z wieloma technikami i narzędziami, które wspomagają ten proces i czynią go jeszcze bardziej efektywnym. Technika „mapowania historyjek użytkownika” pozwala nie tylko zrozumieć funkcjonowanie produktu jako całość (big picture), ale również zidentyfikować jego elementy składowe. Jednak, aby dobrze rozpocząć proces mapowania historyjek, najpierw trzeba zrozumieć istotę “historyjki użytkownika”.
ZACZNIJMY OD PODSTAW – HISTORYJKI UŻYTKOWNIKA
Cała koncepcja tworzenia historyjek użytkownika wzięła się z odejścia od tradycyjnego sposobu planowania pracy. Takie planowanie zakładało wykorzystanie szczegółowej dokumentacji produktu oraz określenia jasnych wymagań biznesowych. Dokumenty mogą być różnie interpretowane w zależności od osoby, która je czyta, a końcowy efekt wykonanego produktu może znacznie odbiegać od początkowych założeń, co często jest zrzucane na „kiepsko określone wymagania”.
Dlatego istotą dobrej dokumentacji w postaci historyjki staje się zwykła papierowa karteczka (fiszka), która zawiera następujące elementy:
- Jako [kategoria użytkownika]
- Chcę [coś zrobić]
- Aby [uzyskać jakąś korzyść]
Jest to skondensowana informacja, która pokazuje jaki cel chcemy osiągnąć dzięki wdrożeniu tej historyjki. Szablon ten jest na tyle uniwersalny, że do dzisiaj wykorzystuje się go w metodologii scrum. Uniwersalność historyjki użytkownika udokumentowana na karteczce polega także na tym, że stanowi ona narzędzie do werbalnej komunikacji z innymi członkami zespołu, aby na bieżąco notować frazy dotyczące poruszanych obszarów. Robocze notatki wykonywane są na tej samej karteczce lub nowej, która może również reprezentować nowe podejście lub pomysły, które obejmują takie obszary jak:
- Dlaczego dana historyjka jest tak ważna dla użytkownika?
- Co dzieje się poza programem?
- Wątpliwości oraz założenia
- Czy mamy do dyspozycji lepsze rozwiązania ?
- Czas potrzebny na implementację
Praca z historyjkami użytkownika może opierać się także o schemat zaczerpnięty z “Extreme Programming Installed” (Ron Jeff). Składa się on z 3C:
- Karta (card) – Opisuje cel danej historyjki (Jako…Chcę…Aby…), a więc co użytkownik chciałby wykonać za pomocą naszego oprogramowania.
- Rozmowa (conversation) – Jest to wymiana wzajemnych myśli oraz wyobrażeń co do działającego rozwiązania. Celem takich rozmów jest uzyskanie wzajemnego zrozumienia pomiędzy wszystkimi uczestnikami zaangażowanymi w konwersację oraz wypracowanie najlepszego rozwiązania danego problemu (implementacja danej historyjki).
- Potwierdzenie (confirmation) – W jaki sposób sprawdzimy, czy dane zadanie jest ukończone oraz czy rezultat końcowy jest tym, na co umawialiśmy się z naszymi stakeholderami? Odpowiedzi na te pytania przedstawiane są jako kryteria akceptacji historyjki.
MAPOWANIE HISTORYJEK W FAZIE PRODUCT DISCOVERY
Technikę mapowania historyjek można zastosować już w fazie product discovery. Dzięki temu na bardzo wczesnym etapie mamy możliwość zdefiniować, jaki produkt budować, by rozwiązać problem użytkownika. Dodatkowo wykorzystując historyjki otwieramy szerokie pole do dyskusji co do istotności danego problemu oraz proponowanego rozwiązania. Pozwala to na efektywne wypracowanie kompromisu co do priorytetów oferowanego rozwiązania.
W fazie product discovery autor traktuje mapowanie historyjek jako pewnego rodzaju schemat, który służy do rozbicia całości problemu na mniejsze kawałki. Krótkie historyjki spisane np. podczas warsztatu przez zespół na małych fiszkach zapobiegają tworzeniu skomplikowanej i rozległej dokumentacji już na samym początku kreowania produktu. Zanotowane w ten sposób wnioski stanowią kanwę do prostych wizualizacji, które wspierają każdą kolejną dyskusję. Dużo łatwiej wtedy w dowolnym momencie przeorganizować priorytety i notować nowo pojawiające się pomysły. Proces definiowania i notowania nowych pomysłów, składa się z następujących kroków:
- Myśl – W czasie pracy nad mapą historyjek pojawia się wiele nowych pomysłów, które warto potem przedyskutować.
- Pisz – Pamięć ludzka często jest ulotna, stąd warto wykorzystać fiszki do zanotowania w paru słowach nowo pojawiające się pomysły.
- Objaśniaj – Posługując się zapiskami na karteczce wyjaśnij swój pomysł innym uczestnikom warsztatów wykorzystując własną gestykulację oraz obrazy.
- Organizuj – Umieść fiszkę w przestrzeni roboczej zespołu, aby zainteresowani mogli ją zobaczyć, dopisać własne wnioski, zmienić lub przesunąć karteczkę w inne miejsce.
Integralną częścią opisu historyjek w fazie odkrywania produktu są jego użytkownicy. Szybko można zidentyfikować, która grupa odbiorców jest dla nas kluczowa, a następnie szybko wyeliminować te funkcjonalności, które nie są dla niej w tym momencie istotne.
Dodatkowo możemy odkryć innych użytkowników naszego produktu lub funkcjonalności, które być może będzie trzeba zaadresować w pierwszej kolejności. Należy jednak pamiętać, że wchodząc w detale przy opowiadaniu historii różnych użytkowników nie pomijać tego, co jesteśmy w stanie dostarczyć. W graficznej prezentacji wygląda to tak, że nasze karty przedstawiające ogólne zagadnienia znajdują się na szczycie danych kolumn, natomiast ich szczegóły poniżej.
Źródło: https://masteringbusinessanalysis.com/wp-content/uploads/2015/04/Story-Map.jpg
Po zdefiniowaniu kluczowych historyjek użytkownika musimy znaleźć docelowe rozwiązanie, które dostarczy nam odpowiedzi na następujące pytania:
- Co konkretnie użytkownik ma teraz zrobić?
- Co mógłby zrobić zamiast tego?
- Co zrobić, żeby było to naprawdę atrakcyjne?
- Co w sytuacji, kiedy coś pójdzie nie tak?
Często dochodzimy wtedy do wniosku, że „zawsze jest więcej do zrobienia, niż wystarczy na to czasu”.
HISTORYJKI OKAZJI I ICH PRIORYTETYZACJA
Każdą nową okazję do rozwoju produktu trzeba najpierw zweryfikować. Autor nawiązuje tutaj do koncepcji odkrywania produktu Marty’ego Cagana. Wstępne rozmowy z użytkownikami pozwolą podjąć decyzję, czy ten pomysł warto dalej analizować i realizować, czy od razu go odrzucić. Główne obszary, którymi należy się zająć to odpowiedzi na następujące pytania:
- Dla kogo przeznaczony będzie nasz produkt lub funkcjonalność? – grupa docelowa lub rynek
- Jaki problem zostanie zaadresowany? – identyfikacja konkretnego problemu oraz w jaki sposób jest on obecnie adresowany
- Jakie mamy wyobrażenie co do danej funkcji lub produktu? – proaktywne dyskusje z różnymi grupami odbiorców
- Dlaczego? – korzyści dla organizacji dzięki stworzeniu danej funkcji lub produktu, zwrot inwestycji oraz wpisanie w wizję i strategię firmy
- Skala – jak rozbudowane będzie nowe rozwiązanie oraz czas potrzebny na jego realizację
Ujęcie pomysłów w historyjki pozwala stworzyć rejestr okazji. Przy użyciu szablonu „Opportunity Assessment” zdobywamy wiedzę, jak może wyglądać nasze potencjalne rozwiązanie.
Rozmowa o historyjce okazji pozwala także określić ogólny zakres prac, jaki trzeba wykonać, by osiągnąć zamierzony cel. Jednak należy się upewnić, czy każdy z uczestników rozumie, jaki konkretnie problem będzie rozwiązywany i jakie korzyści przyniesie to dla organizacji.
Zrobienie kroku wstecz i przyjrzenie się obecnej mapie historyjek dla istniejącego produktu pozwoli także zidentyfikować nowe okazje. Prowadząc weryfikację pomysłów trzeba być krytycznym i bez cienia wątpliwości odrzucać te, które nie doprowadzą nas do oczekiwanych rezultatów. Pozwoli to na odfiltrowanie listy featerów i pozostawienie tych, które trzeba dobrze zaplanować w procesie delivery.
MAPOWANIE HISTORYJEK W FAZIE PRODUCT DELIVERY
“Mapowanie historyjek” ma także szerokie zastosowanie w fazie product delivery. Zanim jednak rozpoczniemy proces mapowania w pierwszej kolejności musimy zrozumieć i zastosować założenia MVP (Minimum Viable Product): „MVP to najbardziej minimalistyczne wydanie produktu, które z powodzeniem osiąga pożądane rezultaty”. Autor nawiązuje także do innej definicji MVP, którą przedstawia Eric Ries w publikacji „The Lean Startup”. Według niej MVP to eksperyment, tak jak kolejne wersje produktu.
PLANOWANIE PRACY
Wyobrażenie o działającym produkcie jako końcowym efekcie pracy jest bardzo łatwe. Prawdziwym wyzwaniem jest jednak odpowiednie zaplanowanie pracy. Jest ona jak tort, który należy podzielić na mniejsze kawałki, nie tracąc z pola widzenia produktu jako całości. Dostarczając oprogramowanie kawałek po kawałku, szybciej możemy oceniać postępy prac i weryfikować, czy jesteśmy w stanie osiągnąć nasz cel. Z drugiej strony użytkownik ma możliwość sam ocenić na podstawie kawałków działającego oprogramowania, czy jest w stanie wykonywać swoje zadania, bądź rozwiązać aktualny problem.
Planując odpowiedni rozmiar historyjki, należy wziąć pod uwagę różne oczekiwania osób zaangażowanych w jej implementację. Zacytuję tutaj autora:
- „Historyjka opowiedziana z perspektywy użytkownika powinna być takiej wielkości, aby zaspokajała potrzebę”.
- „Historyjka odpowiedniej wielkości według deweloperów to taka, której opracowanie i przetestowanie trwa kilka dni”.
- „Historyjka odpowiedniej wielkości z perspektywy firmy to taka, która pomaga firmie w osiągnięciu pożądanego celu”.
Nadal jednak może się okazać, że stworzona historyjka jest za duża. To doskonały moment, by rozpocząć dodatkowe dyskusje z stakeholderami oraz członkami zespołów, tak by rozbić ją na kilka mniejszych, które wciąż doprowadzą do osiągnięcia oczekiwanego rezultatu. Mając już skończoną ilość nowych historyjek, znacznie łatwiej nam je pogrupować w zbiory, które obejmują jedno zagadnienie i tym samym zredukować zakres prac w danym obszarze. Ich doskonaleniem i uszczegółowieniem można się zająć w czasie spotkania „grooming”, które jest jednym z elementów metodologii scrum. Warto też co jakiś czas zatrzymać się i zweryfikować, czy realizujemy produkt zgodnie z planem oraz czy spełnia on kryteria jakościowe. Uwzględnijmy także aspekty organizacyjne i efektywność pracy zespołu. Są to doskonałe tematy na cykliczne spotkania retrospektywy, które z pewnością pozwolą wyciągnąć wnioski na przyszłość, by planować i pracować efektywniej.
Podobną ewaluację należy także przeprowadzić z naszymi interesariuszami. To przecież oni na co dzień będą korzystać z naszego produktu i są zainteresowani ogólnym postępem prac. Stworzenie odpowiednich metryk, które dadzą informację, czy i jak produkt jest naprawdę używany przez naszą grupę docelową, pozwolą szybko zidentyfikować nadarzające się okazje do jego ulepszania
Jak to przedstawić graficznie w postaci historyjek? Należy utworzyć rdzeń mapy i umieścić karteczki z historyjkami, które zawierają krótką informację, jak użytkownicy wykorzystują dany produkt. Im dalej w dół kolumny, tym większe uszczegółowienie konkretnych czynności oraz brakujących funkcjonalności, by w pełni skorzystać z produktu. Co istotne, rdzeń pozostaje niezmienny (główna funkcjonalność produktu), a szczegółowe zmiany są wprowadzane wraz z kolejną wersją produktu. Jest to pętla działań przedstawiona przez E. Riesa’a: twórz, mierz, ucz się. Każdy release produktu to eksperyment, który da nam odpowiedź na wcześniej postawione pytania. Zastosowanie w tym przypadku map historyjek pozwala skoncentrować się na tym, jaki powinien być produkt i dla kogo.
Źródło: https://www.mountaingoatsoftware.com
“CHODZĄCY SZKIELET”
Grupa historyjek, która pozwala zweryfikować, czy produkt w ogóle działa to tzw. „chodzący szkielet”. Używanie go w minimalistycznej wersji przysparza wielu problemów, ale pozwala znaleźć potencjalne problemy techniczne na bardzo wczesnym etapie jego wprowadzenia. Dodatkowo “chodzący szkielet” może dostarczyć odpowiedzi na pytanie, czy podążamy we właściwym kierunku z naszym rozwiązaniem.
Źródło: https://jeffpatton.wpengine.com/wp-content/uploads/2008/10/backbone_and_skeleton.png
Druga grupa historyjek w mapie historyjek zawiera te funkcjonalności, które pozwolą już realnie używać danego rozwiązania. Wciąż nie będzie ono idealne, ale pozwoli zidentyfikować inne problemy, które wcześniej przeoczyliśmy i zapisać je jako tzw. „historyjki zagrożeń”. Iteracyjne podejście do planowania nowych oraz modyfikacji istniejących funkcji pozwala szybciej i z mniejszym ryzykiem weryfikować wcześniej ustalone hipotezy. Aby wprowadzić jeszcze większą transparentność, co do kolejności dostarczania rozwiązań, autor proponuje zastosowanie autorskiej strategii, która składa się z następujących kategorii:
- Otwarcie – są to najważniejsze funkcjonalności dla klienta. Nie można tutaj jednak zapominać o kwestiach technicznych i ryzykach.
- Gra środkowa – udoskonalenie najważniejszych funkcjonalności, wprowadzenie nowych oraz testowanie pod względem wydajności, skalowalności oraz użyteczności
- Gra końcowa – praca nad tym, by produkt był jeszcze bardziej atrakcyjny
”Podstawowe cegiełki mapy opowieści” to proste zadania użytkownika, które tworzą logiczny „ciąg narracyjny” od lewej do prawej strony. Każde z zadań jest ukierunkowane na osiągnięcie jednego celu.
MAPOWANIE HISTORYJEK A PRACA ZESPOŁOWA
Technikę mapowania historyjek może stosować zarówno jeden zespół, jak również kilka, które ze sobą współpracują w ramach jednego projektu. Łatwiej jest w takiej sytuacji odkryć wzajemne zależności między zespołami, a następnie budować ich większą odpowiedzialność za produkt. Praca w grupach umożliwia ciągłe identyfikowanie nowych elementów, które będą wymagały szerszej dyskusji. Ich rezultatem jest zazwyczaj kategoryzowanie podobnych rzeczy powyżej lub poniżej linii, które wyznaczają priorytety naszych działań. Tak powstała struktura w sposób przejrzysty przedstawia harmonogram kolejnych releasów produktu. Zawsze powinna to być lista rzeczywistych korzyści, jakie dostarczamy naszym klientom, a nie tylko zbiór kolejnych funkcji produktu.
Pozostaje odpowiedzieć na pytanie, kto w takiej pracy zespołowej powinien wziąć na siebie odpowiedzialność za pisanie “historyjek użytkownika”. Jest to jeden z paradoksów metodologii scrum, na który autor zwraca uwagę. Uzasadnia to w następujący sposób:
Droga od ogólnego pomysłu aż do sformułowania konkretnych czynności, pozwalających go zwalidować i zrealizować jest długa. Wymaga to przeprowadzenia wielu dyskusji i konsultacji, co dla jednej osoby może być fizycznie niemożliwe.
Osoba odpowiedzialna nie zawsze prezentuje pakiet wiedzy biznesowej, technicznej, UX-owej oraz wielu innych obszarów związanych z developmentem.
Rozwiązaniem takiej sytuacji jest współpraca z ludźmi, którzy są specjalistami w danej dziedzinie. Reprezentując specyficzną wiedzę domenową, mogą oni zespołowo podjąć decyzje, które przyczynią się do zbudowania produktu, który osiągnie sukces na rynku. O tym wspomina Marty Cagan w swojej książce “Zainspirowani”. Stworzenie wewnętrznego zespołu, który działa pod nadzorem właściciela produktu, pozwala wypracować optymalne rozwiązanie pod względem następujących kryteriów: wartościowość, użyteczność, wykonalność.
Głównym zadaniem właściciela produktu w tym obszarze jest budowanie świadomości, aby wszyscy zainteresowani produktem czuli się za niego odpowiedzialni. Historyjki udokumentowane jako wnioski z przeprowadzonych dyskusji to nasza baza wiedzy, jak będzie wyglądał produkt, który zaspokoi potrzeby obecnych oraz przyszłych użytkowników.
UDOSKONALANIE, DEFINIOWANIE I BUDOWANIE
Często w swojej praktyce spotykamy się z sytuacją, że skończony produkt trafia do użytkownika końcowego i nie spełnia jego oczekiwań lub nie działa, tak jak powinien. By w przyszłości uniknąć podobnej sytuacji, przy starcie nowego produktu warto dodatkowo wdrożyć technikę wspomagającą, jaką jest Design Thinking. W jej przypadku niejako wchodzimy w buty naszego użytkownika, by lepiej zrozumieć, z jakim problemem się mierzy. Prace badawcze rozpoczynają się od interakcji z klientem, a dopiero potem z produktem. Tak działa pętla: „buduj – mierz – ucz się” opisana w książce “The Lean Startup”. Nowe pomysły ujęte w historyjkach pomagają tworzyć opowieści na naszej mapie, jak użytkownicy funkcjonują dzisiaj z naszym produktem oraz wysnuć przypuszczenia, jak będą funkcjonować w przyszłości, gdy zastosują nasze nowe rozwiązanie.
Dyskusje i zapisywanie informacji na karteczkach ma także za zadanie ułatwienie podjęcia ostatecznych decyzji co do zakresu i sposobu dostarczenia rozwiązania. W tym przypadku bardzo pomocne może okazać się przeprowadzenie warsztatów historyjek. Rezultat takiego spotkania to wzajemne określenie i zrozumienie, co chcemy stworzyć. Rozłożenie zaplanowanej pracy na mniejsze kawałki, wybranie niezbędnych elementów do dostarczenia działającego artefaktu pozwoli na jego dalsze udoskonalenie w kolejnych fazach. Technika dzielenia historyjek na: dobre – lepsze – najlepsze i umieszczenie ich na mapie wspiera efektywne monitorowanie postępów w dostarczaniu rozwiązania oraz identyfikację tego, co jeszcze pozostało do zrealizowania.
KOŃCOWY PRODUKT I JEGO WERYFIKACJA
Po zakończeniu procesu produkcyjnego warto poświęcić czas na refleksję oraz przegląd zarówno naszych planów i sposobu ich realizacji. Pozwoli to wyciągnąć wnioski, jak w przyszłości pracować bardziej efektywnie i rozlokować czas na poszczególne etapy odkrywania oraz dostarczania produktu.
Interakcja z użytkownikiem to doskonała okazja do obserwacji produktu w działaniu oraz zebranie informacji, co należy zmienić lub poprawić. Dzięki temu wciąż możemy się uczyć na podstawie kolejnych iteracji wprowadzanego produktu. Jest to koncepcja zapożyczona z metodologii “lean strartup”.
PODSUMOWANIE
Technika mapowania historyjek użytkownika jest techniką, którą warto uwzględnić w swojej praktyce w fazie “product discovery” oraz “product delivery”. Pozwala ona nie tylko zidentyfikować potrzeby naszego użytkownika i jaki produkt chcemy budować. Dzięki niej łatwiej można priorytetyzować zadania, a tym samym efektywnie planować dostarczanie nowych rozwiązań i udoskonalać te istniejące. Mapowanie historyjek użytkownika to także jedno z bardziej efektywnych narzędzi komunikacji z naszymi stakeholderami, w myśl zasady: „Ucz się od swoich użytkowników”. To oni tak naprawdę są prawdziwymi testerami naszych rozwiązań i dostarczają informację, czy nowy produkt lub usługa zaspokoił ich potrzeby. Dobór odpowiednich metryk pozwoli także na bieżąco obserwować, w jaki sposób dany produkt lub funkcja jest używana. Każda nowa wersja produktu jest rezultatem tego, czego nauczyliśmy się na podstawie obserwacji naszych użytkowników.
