Budowanie wspólnego zrozumienia #storymapping

Przykład Story Mappingu

Przykład Story Mappingu

Kilka godzin temu zakończyłem warsztaty produktowe. Ich głównym celem było przygotowanie użytecznego oraz wykonalnego rozwiązania, realizującego konkretną potrzebę klienta.

To już któryś raz z rzędu, gdy wychodzę z tego rodzaju warsztatów zafascynowany, jak niesamowicie prostym, a zarazem nadzwyczaj skutecznym narzędziem jest Story Mapping.

Posłużę się prawdziwym przykładem, oczywiście na potrzeby tego wpisu w uproszczonej wersji, aby móc podzielić się z Wami wysokopoziomową ideą oraz przebiegiem samego ćwiczenia.

Co to jest Story Mapping? #podstawy

Gdyby miał opisać Story Mapping jednym zdaniem, to powiedziałby, że jest to narzędzie służące do budowania wspólnego zrozumienia produktu.

Jeśli miał do dyspozycji jeszcze kilka kolejnych zdań, powiedziałbym, że skupienie w trakcie ćwiczenia utrzymywane jest na użytkowniku oraz tym, w jaki sposób będzie korzystał z z produktu. Realizowane jest to poprzez opowiadanie historii użytkownika (czyli popularnych User Stories, wystepujące w życiu zespołów także jako historyjki, storysy oraz storyjki #truestory), dekomponowanie ich na mniejsze części oraz układanie ich w kolejności zgodnej z tym, jak użytkownicy używają systemu.

Główną osią naszej mapy szkielet aplikacji, który odzwierciedla opowieść o tym, w jaki sposób użytkownicy będą z niej korzystać. Szkielet ten uzupełniają zdekomponowane historie, które funkcjonują na niższym poziomie szczegółowości i ułożone są według priorytetów lub odzwierciedlają alternatywne scenariuszy korzystania z produktu.

Dla osób, które chcą głębiej zanurzyć się w temacie Story Mappingu, z czystym sercem rekomenduję książkę Jeff’a Patton’a, który jest autorem tej techniki. Książkę czytam i został mi jeszcze kawałek do dokończenia – w niedalekiej przyszłości napiszę o niej kilka słów na blogu.

Kółka, trójkąty, kwadraty… #komunikacja

Scenariusz warsztatów produktowych jest zazwyczaj bardzo podobny. Zespół wchodzi na warsztat mając dosyć mgliste pojęcie, co tak faktycznie jest do zrealizowania. Często nie wiedzą o produkcie więcej, niż kilka zdań wymienionych poprzez e-maile. Domena produktu bywa obca. Bywa, że w zrozumieniu wyrazów oraz skrótów charakterystycznych dla domeny produktowej nie pomaga nietypowy akcent klienta, charakterystyczny np. dla mieszkańców północnej części Wielkiej Brytanii.

Patrząc z boku na przebieg warsztatu jako moderator, często odnoszę wrażenie, że w głowach uczestników rodzą się kompletnie różne obrazy tego, co tak naprawdę jest do stworzenia. Szum informacyjny jest bardzo wysoki – myśl zwerbalizowana przez klienta trafia do osoby po stronie dostawcy, który na swój prywatny sposób interpretuje ten komunikat i buduje swoje wyobrażenie tego, jak mogło by to wyglądać. Może to prowadzić do sytuacji, w której każdy wyobraża sobie coś „nieco” innego (wspomniane w nagłówku kółko, trójką lub kwadrat) chociaż istnieje poczucie, że rozmawiamy o tej figurze geometrycznej.

Story Mapping to proces ciągły

Podczas ostatniego warsztatu działałem jak uruchomiony w tle proces w systemie operacyjnym: pozostając na drugim planie dyskusji, wykonywałem konsekwentną pracę związaną ze stopniowym budowaniem Story Mapy.

W tym konkretnym przypadku było to nieinwazyjne dokumentowanie wszystkiego, co rodziło się podczas dyskusji dotyczącej produktu. Starałem się wyłapywać z rozmowy zarówno duże, rozbudowane aktywności dotyczące głównego flow użytkownika (np. logowanie) jak również ich szczegóły oraz detale (np. zapamiętanie hasła, możliwość odzyskania zapomnianego hasła, dodatkowe informacje na ekranie logowanie) i dokładałem je do Story Mapy. Tym samym, w pewnym sensie mimowolnie, na ścianie stopniowo rodził się obraz produktu, do którego co jakiś czas mogliśmy się odwołać i upewnić, że rozumiemy go w ten sam sposób.

Story Mapping lubi się z UX

Uzupełnieniem Story Mapy były pierwsze szkice interfejsu użytkownika, budowane na różnym poziomie odwzorowania szczegółów: od uproszczonych, szybkich “bazgrołów” na tablicy suchościeralnej do całkiem szczegółowego interfejsu, wyklikanego między pierwszym a drugim dniem w dedykowanej aplikacji.

Te dwie aktywności, tj. budowanie Story Mapy oraz tworzenie szkiców, działy się symultanicznie. W proces od strony narzędziowej zaangażowaliśmy:
– zwykła rozmowę,
– słowo pisane,
– dwu-wymiarową, wizualną reprezentację produktu oraz
– szkice interfejsu o różnym poziomie szczegółowości.

Wszystko to, aby upewnić się, że – jak to mawiają nasi anglojęzyczni koledzy – jesteśmy na tej samej stronie, czyli po prostu tak samo rozumiemy rzeczy, o których właśnie toczy się rozmowa.

Wykrawanie pierwszej wersji produktu

Na koniec drugiego dnia warsztatów poprosiliśmy Product Ownera po stronie klienta, aby przeglądnął stworzoną Story Mapę pod kątem priorytetów oraz zestawu funkcjonalności stanowiących pierwszą wersję produktu. Odkreślił on wyraźną linią to, co stanowi dla niego priorytet i na czym powinniśmy się skupić od tego, co na dzisiaj nie jest dla niego istotne.

Wszystkie elementy powyżej linii skonwertowaliśmy do postaci niedużych User Stories z kryteriami akceptacyjnymi, które ostatecznie zasiliły Product Backlog. W ćwiczenie to zaangażowany był cały zespół: każda osoba otrzymała kawałek Story Mapy to skonwertowania. Moje obserwacje są takie, że pomogło to dodatkowo wzmocnić zaangażowanie produktowe po stronie zespołu oraz wywołało kilka dodatkowych dyskusji rozjaśniających zrozumienie produktu.

Przykład Story Mappingu z opisem

Przykład Story Mappingu z opisem

Nie wyrzucaj Story Mapy do kosza

Czy mając już przygotowany Product Backlog, zdecydowaliśmy się zedrzeć Story Mapę ze ściany i umieścić ją w koszu na śmieci? Oczywiście moglibyśmy tak zrobić, jednak byłaby to wielka strata dla zespołu oraz stakeholderów. Dostrzegam co najmniej trzy użyteczne sposoby zastosowania Story Mapy w dalszym procesie deweloperskim jako:

  • narzędzie wspierające codzienną komunikację zespołu – Story Mapa dostępna na przestrzeni zajmowanej przez zespół jest wygodnym narzędziem wspierającym dyskusje produktowe. Wielokrotnie byłem świadkiem sytuacji, w których członkowie zespołu w trakcie pracy podchodzą do Story Mapy, wskazują palcem konkretne elementy, dyskutują flow procesu, dodają lub usuwają kartki reprezentujące funkcjonalności. Story Mapa bywa tez pomocna, gdy pojawia się potrzeba, aby wytłumaczyć nowo zatrudnionym osobom, jak wysokopoziomowo wygląda produkt oraz jakie są dalsze plany rozwoju.
  • wysokopoziomowy artefakt przydany podczas Przeglądów Sprintu – w jednym z zespołów z którym współpracuję, Story Mapa jest wykorzystywana podczas Sprint Review jako nośnik informacji dotyczący aktualnego stanu rozwoju produktu. Wyświetlana jest zwykle na początku spotkania a przejście po jej elementach jest szkieletem prezentacji zmian w produkcie. Dodatkowo, zespół zastosował kodowanie kolorami, które odzwierciedlają status elementów Story Mapy: zadania zielone są zrealizowane, pomarańczowe to zadania z bieżącego Sprintu, białe reprezentują zadania czekające na realizację (domyślny kolor), natomiast czerwone to zadania zablokowane, czyli oczekujące na reakcję poza zespołem, np. ze strony działu marketingu. W tym konkretnym przypadku zespół wykorzystuje aplikację http://storiesonboard.com/, która pozwala na utrzymywanie elektronicznej wersji mapy oraz jej synchronizację z JIRA.
  • materiał do kolejnych warsztatów i dyskusji produktowych: jak wspomniałem wcześniej, w pewnym momencie Product Owner odkreślił linią pierwszą wersję produktu. Nic nie stoi na przeszkodzie, aby świadomość i zrozumienie kolejnych wersji produktu nadal budować przy użyciu Story Mapy, która “żyje” wraz z trwającym rozwojem produktu.

Podsumowanie

Dobre kilka lat temu pierwszy raz prowadziłem coś, co z perspektywy czasu nazwałbym bardzo uproszczonym i dosyć płytkim warsztatem produktowym. Opisałem to ćwiczenie jakiś czas temu na portalu agile247.pl. Nie korzystałem wtedy ze Story Mapy w zespołach, z którymi pracowałem #wielkaszkoda.

Patrząc z perspektywy czasu, uważam Story Mapping za technikę, która zmienia grę jeśli chodzi o software dewelopment i nie ukrywam, że jestem jej wielkim fanem. Ubogaca oraz wizualizuje dyskusje produktowe. Buduje wspólne zrozumienie produktu pośród zainteresowanych. Pomaga w zrozumieniu, co tak naprawdę jest do zrealizowania na teraz, a co może poczekać. Pomaga skupić się na rozwiązaniach end-to-end oraz dostarczaniu realnej wartości dla użytkownika. Całkiem sporo, jak na jedno narzędzie, prawda?

Co myślisz o Story Mappingu? Jakie są Twoje doświadczenia? Nie zawahaj się podzielić się swoim komentarzem!

Share on Facebook38Tweet about this on TwitterShare on LinkedIn117Share on Google+0

4 myśli nt. „Budowanie wspólnego zrozumienia #storymapping

  1. Cześć!
    Podzielam fascynację prostotą i skutecznością. Sam autor pokreśla, że to nic innowacyjnego i że wiele osób na różny sposób próbowało realizować ten sam cel w podobny, warsztatowy sposób. Może zatem skuteczność i prostota są wynikiem naturalności tej metody?
    Trafne spostrzeżenie odnośnie komplementarności z UX. Dobry pomysł wspólnego budowania backlogu z mapy. Super sprzężenie ze Sprint Review. Ja w ogóle mam wrażenie że budowabie tych map wyzwala w ludziach zrozumienie mechanizmów Scrum i np. celowości wydarzeń – niektórzy jakby nagle zrozumieli sens.
    Również bardzo lubię, książka jeszcze przede mną, z mną kilka podejść praktycznych. Przykładowo – warto pomyśleć jak na mapie pokazywać wymagania niefunkcjonalne (jak na rysunku), czy UX etc.
    Dzięki za ten tekst.

    • Cześć Radek!

      Dzięki za komentarz. Kupuję to co mówisz o skuteczności i prostocie.

      Myślę też, że siła tkwi w tym, że to, co budujemy, jest fizycznie zwizualizowane, więc można pokazać konkretny element palcem, przesunąć go, widać też całość jak staniemy odpowiednio daleko (czego nie można uzyskać w zadowalający sposób używając narzędzi online).

      Napisałbyś coś więcej, co masz na myśli pisząc, że budowanie Story Map pomaga w zrozumieniu mechanizmów Scruma?

  2. Dla mnie kluczem do sukcesu jest zapewnienie, aby artefakt story mapy żył. Niestety póki co moje doświadczenia zebrane podczas robienia około 5-7 story map są takie, że żadna nie przetrwała próby czasu. I tu moje przemyślenia idą w 2 kierunkach:

    1. Konsekwencja – jeśli w zespole jest osoba bądź osoby, które potrafią być konsekwentne i trzymać story mapę żywą, to tworzy się przestrzeń na te wszystkie fajne rzeczy, o których piszesz.

    2. Wtórność narzędzia – jeśli w zespole jest ogólnie panujący duch konsekwencji i chęci wspólnego rozumienia produktu, story mapa staje się jedynie narzędziem wspomagającym ten już istniejący w zespole proces.

    To trochę podobnie jak z wdrażaniem zwinnych podejść. Jeśli jest pewien podstawowy zestaw wartości, którymi kierują się członkowie zespołu i ów zestaw jest zbliżony do tych zwinnych, np. scrumowych, metodyka wchodzi jak w masło. Jeśli wartości są rozbieżne „you are doomed” :p

    • Dzięki PiMa za podzielenie się przemyśleniami.

      W temacie konsekwencji, to w tym zespole, gdzie Story Mapa „żyje” podczas Sprint Review, temat zainicjował Scrum Master i sprzedał temat Product Ownerowi. Dodatkowo, przez to, że zespół zdecydował się na rotacyjne prowadzenie Sprint Review przez członków zespołów, każdy de facto zapoznał się ze Story Mapą, bo jest ona szkieletem tego spotkania.

      I myślę – płynnie przechodząc do pkt. 2 – że w tym przypadku „DNA” zespołu było faktycznie otwarte na tego rodzaju narzędzie ze względu na ich dojrzałość i niejako naturalną chęć ulepszania się.

      I tak. Co byśmy nie robili, na końcu docieramy do wartości :) #kurtyna

Dodaj komentarz

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