Mapowanie historii użytkowników

Późnym wieczorem samolot wreszcie osiada na płycie lotniska. To były intensywne dwa dni. Pomimo zmęczenia jakoś trudno mi się wyciszyć i oderwać od tego, co osiągnęliśmy. Ciągle jestem pod wrażeniem efektów, jakie uzyskaliśmy na warsztatach.

Jeszcze tylko krótka podróż przez puste i rozświetlone świątecznymi ozdobami ulice i będę w domu…to znaczy w hotelu. Bo tym razem jestem „zaledwie” kilkaset kilometrów od domu, gdzie jutro kontynuować będę swą podróż przez świat analizy wymagań i budowania produktów. Za niecałe 10 godzin zaczynamy kolejne warsztaty.

Mimo to lubię tę pracę!

Pewnego listopadowego dnia zadzwonił telefon. Jest sprawa – trzeba przeprowadzić warsztaty i zebrać wymagania – tak w skrócie brzmiała propozycja. Branża – zupełnie mi nieznana, lokalizacja – środkowa Anglia, termin – za kilka tygodni.

Te wszystkie czynniki spowodowały, że zastanawiałem się nieco dłużej niż zwykle. W kilka chwil jednak potwierdziłem – działamy! Szybko dograliśmy sprawy organizacyjne. A potem przyszedł czas na przygotowania merytoryczne.

Przeprowadzimy sesję mapowania historii użytkownika (User Story Mapping), bazującą na koncepcji Jeffa Pattona, ale z pewnymi modyfikacjami. Taki był plan.

Miałem już całkiem sporo wcześniejszych doświadczeń z tą techniką, jednak każdy produkt ma swoją specyfikę. No i nie istnieją dwa takie same zespoły.

To czego się nauczyłem, to że nie ma dobrych warsztatów bez wcześniejszego przygotowania.

Dlatego pierwszym krokiem, albo nawet krokiem zerowym, było przygotowanie uczestników. Jeszcze wcześniej precyzyjnie dobraliśmy osoby, które zostały zaproszone na warsztaty. Według mnie, na pierwszym spotkaniu obowiązkowo powinien być Product Owner oraz inni specjaliści biznesowi. Maksymalnie 5-6 osób. Specjalistów technicznych dołączam dopiero później, aby nie filtrować pomysłów przez kryteria wykonalności.

No ale wracamy do przygotowań. Jest już grupa, więc na kilka dni przed rozpoczęciem warsztatów wysyłam im szczegółową instrukcję – dlaczego się spotykamy, jaki mamy cel, co będziemy robić i czego potrzebujemy z ich strony, aby warsztaty zakończyć z sukcesem. Do tego dorzucam trochę teorii w postaci linków do materiałów wprowadzających w temat.

Nie zapominam też o logistyce – do przeprowadzenia warsztatów potrzebne będą różnokolorowe karteczki, coś do pisania, arkusze, na których można grupować wymagania, coś do przyklejenia kartek na ściany i niezawodna kolorowa taśma (dlaczego – o tym dalej).

Niby to oczywiste, ale byłem już świadkiem zabijania początkowego entuzjazmu grupy przez pośpieszne, a z czasem paniczne poszukiwanie wszystkich niezbędnych akcesoriów warsztatowych.

Przygotowanie uczestników to jedno. Równie ważne jest…

Skoro wymagam przygotowania ze strony uczestników, to wymagam go też od siebie. Możesz pomyśleć – będę tylko prowadzącym (facylitatorem), nie muszę znać danej branży. Oczywiście, nie musisz i nikt nie oczekuje, że będziesz ekspertem.

Pomyśl jednak o tym, jak o wizycie w obcym kraju. Jeżeli nauczysz się chociaż mówić „dzień dobry” w lokalnym języku, to już na starcie dużo łatwiej będzie Ci dogadać się choćby w sklepie czy restauracji. Nawet najgorzej wypowiedziane przywitanie w lokalnym języku wywołuje większą sympatię niż tradycyjne „good morning”.

Przygotowanie jest dla mnie ważne również ze względu na szacunek dla drugiej strony. Poświęcamy sporo czasu i energii, więc zróbmy to dobrze. Najlepiej jak się da, a nie po prostu byle jak.

Przeglądam więc wszystkie nadesłane materiały, analizuję, wypisuję pytania i wątki, które warto podrążyć. Ok, mam już pełną listę pytań, więc jeszcze tylko kilka dni i…

Samolot wylatuje po 6 rano. Wstaję więc o nieludzkiej godzinie. Szybkie zebranie rzeczy i w drogę na lotnisko. Stolica o 4 rano wydaje się wymarła. Prawie bez ruchu. Wiozący mnie kierowca Ubera wydaje się tego nie zauważać. Jedziemy z niemalże ponaddźwiękową prędkością około 40 km/h, lewym pasem…Coś czuję, że to będzie długi dzień.

Na szczęście pilot samolotu prowadził pojazd dużo sprawniej i dalej wszystko było ok. Przybywam do Londynu o czasie. Czekam jeszcze na jedną osobę (UX designer), która przylatuje z innej lokalizacji. Pojawia się niewielkie opóźnienie. Nerwowe oczekiwanie przy stanowisku z biletami na pociąg. W końcu jest! Szybko kupujemy bilety za kosmiczne pieniądze (peak hours) i biegiem do autobusu. Uff, zdążyliśmy. Jest pierwszy sukces – dojeżdżamy na czas na dworzec kolejowy. Chwilę później obserwujemy już przez okno pędzącego pociągu różnorodny krajobraz środkowej Anglii.

Czas w pociągu wykorzystujemy na zsynchronizowanie poziomu wiedzy. Przeglądamy materiały, wyjaśniamy wątpliwości. W międzyczasie patrzę na zegarek. Jest około godziny 11 naszego czasu. Czyli od wstania z łóżka minęło już… nawet nie chcę tego liczyć.

Przygotowując się do warsztatów sprawdź też, kto będzie w nich uczestniczył. Co to za osoby, jakie mają doświadczenia czy staż pracy. I naucz się od razu imion, żeby nie mówić „ej Ty”.

Niezależnie jak dużo dowiesz się o uczestnikach, to ostatecznie i tak nie masz pewności z kim przyjdzie Ci pracować. W LinkedIn zwykle nie ma informacji o typie osobowości czy poczuciu humoru. Pozostaje więc ta nutka niepewności…

Po doświadczeniu i opisie stanowisk spodziewam się poważnego, może nawet sztywnego spotkania. Taka atmosfera nie ułatwia kreatywnej pracy. Gdy zbliżamy się do sali konferencyjnej pojawia się lekki niepokój…

Na miejscu niespodziewanie witają nas młode i uśmiechnięte twarze uczestników warsztatów. Nie ma mowy o sztywności. Będzie dobrze!

To już ostatni fragment o przygotowaniach. Obiecuję.

Najpierw pewna dygresja. Po przyjeździe na miejsce jest już około południa polskiego czasu. Szybko licząc godziny upływające od jakże wczesnego poranka, już dawno powinienem być po 8-godzinnej dniówce. A tu jeszcze nic się nie zaczęło…

Obmywam twarz i wypatruję ekspresu z kawą. Jest! Euforia nie trwa długo. W końcu jesteśmy w kraju smakoszy herbaty pitej z odrobiną mleka. A dobra kawa, po co to komu? Automat nie wydaje więc żadnych odgłosów mielenia, tylko nalewa ciecz o ciemnej barwie. Wydaje się, że nasza rodzima „Inka” ma więcej aromatu i daje lepszego kopa. Może umysł da się oszukać?

Wróćmy jednak do tematu.

Nawet jeśli wyślesz instrukcję i wyjaśnisz wątpliwości mailowo, to i tak, tuż przed warsztatami, powtórz o co chodzi i opowiedz, jak będzie wyglądała współpraca.

W tamtym momencie nieco zaniedbałem ten krok i na początku pojawiało się sporo niepewności. Po całym warsztacie uczestnicy zwrócili uwagę, że przydałoby się jeszcze takie solidne wprowadzenie. Brzmi jak oczywistość. I teraz już o tym pamiętam.

Warsztaty z mapowania historii zawsze zaczynam od… krótkiej historii. To znaczy nie bezpośrednio ja, ale proszę jednego z uczestników/uczestniczek o jej przygotowanie i opowiedzenie. Historia ta powinna dotyczyć docelowych użytkowników (person), ich problemów i wyzwań. Całkowicie w oderwaniu od poszczególnych funkcjonalności systemu.

Ten element zwykle sprawdza się doskonale. Znajdujemy z uczestnikami wspólny kontekst. Wiemy, co jest ważne, a przy okazji robimy notatki, co przyspiesza kolejne kroki.

Napisałem „zwykle”, bo kilkukrotnie słyszałem już anty-historie. Ta przypadłość pojawia się przeważnie wtedy, gdy budujemy wersję 2.0 istniejącego systemu. „Opowieść” może brzmieć: „…i użytkownik wybiera opcję… i wpisuje… a potem klika… i już”. Świetnie, ale zupełnie nie o to chodzi.

Wracam do głównego wątku i opowiedzianej tam historii.

Chwila niepewności, bo nie wiadomo co usłyszymy. Po chwili wiadomo, że jest bardzo dobrze. Opowieść jest dynamiczna, zawiera to co trzeba i przesadnie się nie przeciąga.

Po chwili mamy sporo notatek i możemy zacząć działać.

Jeszcze w temacie notatek, to zespół doskonale przygotował się do warsztatów. Mamy cały stos różnokolorowych karteczek i innych przyborów. Jest nawet niebieska taśma, która okaże się niezwykle przydatna. Kolejny duży plus!

Wstajemy i zaczynamy wspólnie budować główny proces – ścieżkę, którą podążają zdefiniowane persony. I tu jak zwykle wkrada się nieporozumienie.

Gdy standardowo planujemy budowanie systemów, to naturalne są poziomy typu:

• implementacyjnego – zaczynamy od architektury, potem baza danych, API itd.
• funkcjonalnego – definiujemy najważniejsze funkcjonalności, a potem całą resztę
• projektowego – dzielimy czas na etapy, najpierw zbieranie wymagań, analiza, projektowanie itd.

Opcja, którą stosuję na warsztatach jest zupełnie inna. Często uczestnicy próbują nieudolnie wpasować ją w znane sobie ścieżki. Tak też było w tym przypadku.

Chwila wyjaśnienia i dodatkowe przykłady załatwiają sprawę. Wiadomo już, dokąd zmierzamy.

Prace nad głównym scenariuszem przerywa lunch. Faktycznie, jest już dość późno. Uzupełniamy akumulatory porcją przeróżnych kanapek i jak to w Anglii – frytek.

Wkrótce główna historia jest ustalona i wyklejona. Dorzucamy do niej persony – użytkowników, których wspólnie zdefiniowaliśmy. To dopiero początek pracy.

Potem przychodzi czas na szczegóły. Omawiamy dokładnie każdy z kroków. Pojawiają się pytania, wątpliwości i sprzeczne oczekiwania. To wszystko jest zupełnie normalne. Notujemy skrzętnie każdy pomysł, bo na tym etapie nie ma głupich odpowiedzi.

Ten moment jest najbardziej krytyczny dla powodzenia całego procesu. Można „popłynąć” brnąc zbyt głęboko w szczegóły lub przeciwnie – dotknąć tematów jedynie powierzchownie.

Dzięki wcześniejszemu przygotowaniu, z sukcesem angażuję uczestników w kreatywne dyskusje. Oni zaś odwdzięczają mi się konkretnymi, bazującymi na przeprowadzonym badaniu rynku odpowiedziami (a nie na własnych domysłach, co często ma miejsce). Im więcej wiem o tej branży, tym celniej zadaję pytania pogłębiające i stopniowo posuwamy się do przodu. Stopniowo… bo właśnie czas jest tutaj kluczowy! Warsztaty mogą ciągnąć się w nieskończoność. Lubimy sobie po prostu pogadać o tym co nas interesuje. Aby wspomóc kontrolowanie czasu rysuję coś a’la burndown chart z tematami do omówienia i pozostałym czasem. Mamy konkretną liczbę kroków do omówienia oraz określony czas. Łatwo wyliczyć jaka jest optymalna prędkość pracy. To narzędzie załatwia sprawę.

Na story mapie wprowadzamy też odrębne oznaczenie dla tematów, co do których nie znajdujemy rozwiązania. Parkujemy je na bocznicy i sprawnie przechodzimy dalej.

Na zewnątrz już od jakiegoś czasu jest ciemno. Pracujemy kolejną godzinę nad szczegółowymi wymaganiami. Czuć spadającą energię i zaangażowanie. Najdobitniej widać to po uczestnikach, którzy wcześniej aktywnie stali przy tablicach, a teraz w większości siedzą sporadycznie wykazując kreatywność.

Pewnie znasz to uczucie z imprez czy spotkań przy planszówkach. Przychodzi taki moment, gdy ludzie mówią – „grajcie dalej beze mnie” albo zwyczajnie idą spać. Co zrobić?

Mógłbym napisać, że wrzucę drugi bieg i zdynamizuję dyskusję. Tyle, że drugi bieg to włączyłem na początku. Po kilkunastu godzinach na nogach przydałoby się doładowanie paliwem rakietowym. Chwila przerwy, kilka luźnych dyskusji o otaczającym nas lesie Sherwood, łyk kawo-podobnego napoju i lecimy dalej. Odnajduję jeszcze resztki sił. Wstaję, nie pozwalam sobie na odpoczynek.

Uczestnicy również łapią drugi oddech. Dyskusja ponownie nabiera tempa. Jeszcze tylko moment i kończymy. Na dziś.

Na koniec patrzymy z podziwem na nasze dzieło. Kilka arkuszy wyklejonych historiami użytkowników. Widok robi wrażenie. Przed nami jeszcze trochę obszarów do dokończenia, ale to już jutro.

Wieczorem gospodarze zabierają nas na spacer po urokliwym mieście, wizytę w pubie (a jakże) no i tradycyjne brytyjskie (czytaj hinduskie) jedzenie. Wszystko naprawdę super. Wieczór kończymy spacerem pod zamek, aby przywitać się ze stojącym tam Robin Hoodem. Potwierdzam – jest i ciągle pilnuje Nottingham.

Powrót do hotelu, krótka drzemka i zaczynamy kolejny dzień.

Dzień zaczynamy kolejnym sukcesem. Wszystkie kartki dalej wiszą tak, jak je zostawiliśmy. Nie zawsze jest tak dobrze. Czasami dzień zaczyna się od zbierania wyników pracy z podłogi.

Uzupełniamy szczegóły już do końca zakresu. Mapa rozrasta się coraz bardziej.

Teraz przed nami ostatnie większe ćwiczenie – podział tego zakresu na wersje.

Zaczynamy od określenia MVP, czyli minimum do uruchomienia produkcyjnego. Wcześniej definiujemy co dla nas oznacza MVP, aby nie było nieporozumień.

Proces grupowania historii i przypisywania do wersji bywa trudny i momentami bolesny dla uczestników, bo przecież wszystko jest ważne. Część funkcjonalności ląduje przy samej podłodze, co oznacza – „super pomysł, ale nie na teraz”. Reszta zostaje podzielona na trzy części (wersje). I tu do gry wkracza niebieska taśma, która w czytelny sposób rozgranicza kolejne etapy.

Jak widać na załączonej mapie, pierwsza wersja (od góry) jest naprawdę minimalna, ale pokrywa większość kroków procesu. Pozwoli nam szybko przetestować przyjęte założenia. Najwięcej funkcjonalności dołożymy w wersji trzeciej, gdy będziemy mieć już wystarczająco dużo informacji od rzeczywistych użytkowników.

I to jest sedno przedstawionej metody. Zaprojektowanie minimalnej, a jednocześnie w pełni funkcjonalnej wersji.

Na koniec drugiego dnia patrzymy na efekt końcowy z jeszcze większą satysfakcją. Jak na dłoni widać tu konkretne, mierzalne efekty zastosowanej techniki.

Teraz już dużo dokładniej:

• wiemy co chcemy osiągnąć w pierwszym etapie prac (MVP) i do czego posłuży ta wersja,
• wiemy dla kogo budujemy rozwiązanie i które problemy rozwiążemy w pierwszej kolejności,
•  wiemy czego nie zrealizujemy na początku i to też jest ok.

Pozostaje jeszcze wykonać zdjęcia (wszelki wypadek robi to kilka osób!) i zarchiwizować fizyczne elementy. Na podstawie zrobionych zdjęć kilka dni później przygotuję mapę w postaci wirtualnej (choćby w Excelu), co będzie ostatnim etapem warsztatów.

Potem pozostaje jeszcze powrót do kraju. Wszystko przebiega sprawnie i późnym wieczorem lądujemy w Pyrzowicach.

Po opisanych warsztatach były jeszcze kolejne i wkrótce potem projekt miał w końcu wystartować. Niespodziewanie przyszła wiadomość o opóźnieniach. Przesunięcie spowodowały wyniki osiągnięte na warsztatach – mniej więcej tak brzmiał przekaz. Co zrobiliśmy nie tak?

Wręcz przeciwnie! W trakcie spotkań pojawiło się tak wiele pytań i niedomkniętych wątków, że zespół prowadzący projekt potrzebował kolejnych kilku tygodni na przygotowania.

Należy to uznać za sukces, czy nie? Z tym pytaniem już Was zostawię.

Jeżeli temat mapowania historii użytkowników (User Story Mapping) jest Ci bliski, chcesz się dowiedzieć więcej, zarówno od strony teoretycznej jak i praktycznej, to mam dla Ciebie dobrą wiadomość. Wkrótce będziemy ćwiczyć tę metodę na warsztatach. Pozostań w kontakcie, aby nie przegapić tego wydarzenia.

_{Autorem artykułu jest Artur Guła, Starszy Analityk.}