Event Storming to warsztat, na którym osoby znające biznes i osoby budujące produkt układają na wspólnej osi czasu zdarzenia zachodzące w procesie, zapisane na karteczkach. Po sesji zostaje mapa, na której widać, co dzieje się po kolei, kto za co odpowiada i w których miejscach zespół się nie zgadza. Metoda ma sens przed nowym modułem, przy przejęciu produktu po innym zespole i wtedy, gdy działy spierają się o zakres.
Co to jest Event Storming?
Metodę opisał Alberto Brandolini w tekście z 18 listopada 2013 r. jako format warsztatu do szybkiego poznawania złożonych domen biznesowych. Podstawową jednostką jest zdarzenie domenowe, czyli fakt ważny dla biznesu, zapisany w czasie przeszłym: „Zamówienie zostało opłacone”, „Paczka została nadana”.
Event Storming wyrósł ze środowiska Domain-Driven Design (DDD), czyli podejścia, w którym struktura oprogramowania odwzorowuje język i podział biznesu. Brandolini wskazywał, że model z warsztatu pozwala szybko wyznaczyć granice kontekstów i agregatów. Do pracy nad produktem nie trzeba jednak znać DDD: mapa zdarzeń jest czytelna dla osoby ze sprzedaży tak samo jak dla programisty.
Celem nie jest kompletny model. Autor metody zaleca pogodzić się z niekompletnością, bo warsztat służy temu, żeby w najkrótszym czasie dowiedzieć się jak najwięcej.
Kiedy Event Storming pomaga w rozwoju produktu?
Problemy wychodzą wcześniej
Rozbieżności, które w dokumentacji ujawniają się po tygodniach, na ścianie widać od razu: dwa działy opisują to samo zdarzenie inaczej albo nikt nie potrafi powiedzieć, co dzieje się między płatnością a wysyłką. Zmiana na karteczce kosztuje minutę, ta sama zmiana po wdrożeniu wymaga pracy programistów i testów.
Wiedza przestaje być w głowach pojedynczych osób
W jednym pomieszczeniu pracują osoby, które zwykle rozmawiają przez zgłoszenia: obsługa klienta, operacje, produkt, programiści. Każdy dokłada karteczki samodzielnie, więc głos osoby z magazynu waży tyle samo, co głos dyrektora. Wiedza tych osób o klientach przydaje się potem przy spisywaniu person i proto-person.
Zakres opiera się na procesie, a nie na liście życzeń
Gdy cały proces jest na ścianie, decyzja o tym, co wchodzi do pierwszej wersji, dotyczy konkretnych zdarzeń, a nie haseł. To dobry punkt wyjścia do ustalenia zakresu MVP i do późniejszego rozrysowania ścieżek użytkownika.
Jakie są poziomy Event Stormingu i pełna notacja?
Metoda ma trzy poziomy szczegółowości, opisane między innymi w słowniku społeczności DDD Crew:
- Big Picture. Obraz całego obszaru biznesu. Służy ocenie, jak działa organizacja albo czy pomysł na nowy produkt się broni. Bierze w nim udział nawet 10 do 30 osób.
- Process Modelling. Jeden proces rozpisany dokładnie: kto podejmuje decyzję, na podstawie jakich informacji i jaka reguła działa automatycznie. Pozwala znaleźć wąskie gardła.
- Software Design. Model, z którego zespół programistów wyprowadza strukturę systemu opartego na zdarzeniach.
Na niższych poziomach dochodzą kolejne elementy, każdy z własnym kolorem:
| Element | Kolor karteczki | Co oznacza |
|---|---|---|
| Zdarzenie domenowe | Pomarańczowy | Fakt ważny dla biznesu, w czasie przeszłym |
| Komenda | Niebieski | Decyzja lub działanie, które wywołuje zdarzenie |
| Aktor | Żółty, mała karteczka | Osoba, zespół lub dział wykonujący komendę |
| Agregat lub ograniczenie | Żółty, duża karteczka | Reguła biznesowa, która musi być spełniona przy komendzie |
| Polityka | Liliowy | Reakcja: „zawsze gdy zdarzy się X, robimy Y” |
| System zewnętrzny | Różowy | System IT, z którego proces korzysta |
| Model odczytu | Zielony, mała karteczka | Informacja potrzebna aktorowi do decyzji |
| Hot spot | Jaskraworóżowy | Konflikt, pytanie lub problem do wyjaśnienia |
W warsztatach produktowych i warsztatach UX, w których połowa sali nie jest techniczna, używamy w Squares notacji uproszczonej. Opisujemy ją niżej i zaznaczamy, gdzie odbiega od oryginału, żeby osoby znające metodę nie uznały różnic za pomyłkę.
Jak przeprowadzić Event Storming krok po kroku?
Krok 1: przygotowanie
- Miejsce. Długa ściana albo kilka metrów papieru, tak żeby wszyscy mogli stać przy mapie jednocześnie. W wersji zdalnej tę rolę pełni tablica online, na przykład Miro albo FigJam.
- Materiały. Karteczki w kilku kolorach, markery dla każdego uczestnika i legenda kolorów widoczna przez cały czas.
- Skład. Osoby, które znają odpowiedzi, i osoby, które umieją zadawać pytania. Brandolini w pierwszym opisie metody podawał 6 do 8 osób. Brak osoby z operacji albo obsługi klienta oznacza luki, których nikt na sali nie zauważy.
Krok 2: cel i zakres sesji
Prowadzący zaczyna od jednego zdania o tym, jaki proces jest mapowany i co ma być wynikiem, na przykład „przeprojektowanie ścieżki zakupowej” albo „zakres pierwszej wersji aplikacji”. Bez tego mapa rozrasta się w kierunkach, które nikomu nie są potrzebne.
Krok 3: zdarzenia na osi czasu
Uczestnicy zapisują zdarzenia na pomarańczowych karteczkach, jedno zdarzenie na jednej karteczce, w czasie przeszłym, i układają je chronologicznie. Dla sklepu internetowego:
- Klient dodał produkt do koszyka
- Sklep potwierdził dostępność produktu
- Klient opłacił zamówienie
- Pracownik magazynu spakował produkt
- Kurier odebrał paczkę
- Paczka dotarła do kupującego
Karteczki można przesuwać i poprawiać przez cały warsztat. Spór o kolejność dwóch zdarzeń jest informacją, a nie zakłóceniem.
Krok 4: role, etapy i miejsca sporne w notacji uproszczonej
Po ułożeniu zdarzeń dokładamy kolejne warstwy. To nasz wariant na potrzeby warsztatu produktowego:
- Niebieskie: role. Kto bierze udział w procesie: kupujący, pracownik sklepu, kurier. W notacji Brandoliniego niebieski oznacza komendę, a aktorów zapisuje się na małych żółtych karteczkach.
- Żółte: etapy. Nazwy faz procesu, pod którymi grupujemy zdarzenia: wybór, zamówienie, płatność, wysyłka, dostawa. W oryginale żółty oznacza agregat.
- Różowe: hot spoty. Miejsca, w których proces jest wrażliwy na błędy albo uczestnicy się nie zgadzają. W sklepie będzie to weryfikacja dostępności (co się dzieje, gdy system pokaże błędny stan) i nieudana płatność.
- Zielone: szanse. Pomysły na usprawnienie, na przykład śledzenie paczki albo polecanie podobnych produktów.
- Białe: tematy odłożone. Pytania i pomysły spoza zakresu sesji, zapisane po to, żeby nie blokowały pracy.
- Czerwone: problemy. Opcjonalnie: to, co dziś nie działa, na przykład długi czas odpowiedzi obsługi klienta albo powtarzające się błędy płatności.
Komendy, polityki i systemy zewnętrzne dodajemy wtedy, gdy mapa ma posłużyć zespołowi programistów do zaprojektowania modułu.
Krok 5: wnioski i decyzje
Sesja kończy się przejściem całej mapy od początku do końca i spisaniem trzech rzeczy: które hot spoty trzeba rozstrzygnąć przed startem prac, które szanse wchodzą do zakresu i kto odpowiada za każdy otwarty temat.
Event Storming od końca: kiedy zacząć od wyniku?
W Squares często prowadzimy sesję wstecz. Zamiast od pierwszego zdarzenia zespół zaczyna od stanu końcowego, na przykład „Paczka dotarła do kupującego” albo „Pacjent otrzymał wynik badania”, i cofa się, odpowiadając za każdym razem na pytanie, co musiało się wydarzyć bezpośrednio wcześniej.
Ten wariant sprawdza się, gdy uczestnicy zgadzają się co do celu, a różnią w opisie drogi do niego, oraz gdy proces ma wiele możliwych początków. Praca od końca odcina też zdarzenia, które do wyniku nie prowadzą, więc mapa jest krótsza i łatwiej z niej wyprowadzić zakres. Z naszego doświadczenia daje lepsze rezultaty niż układanie zdarzeń od początku, zwłaszcza w zespołach, które robią to pierwszy raz.
Jak przeprowadzić Event Storming zdalnie?
Zasady są te same, zmienia się rytm. Na tablicy online każdy pisze równolegle, więc pierwsza faza trwa krócej, ale trudniej zauważyć, że ktoś przestał uczestniczyć. Pomagają trzy rzeczy: gotowa legenda kolorów i oś czasu przygotowane przed sesją, krótsze bloki z przerwami zamiast jednego długiego spotkania oraz druga osoba prowadząca, która porządkuje tablicę, gdy pierwsza moderuje rozmowę.
Co dzieje się z mapą po warsztacie?
Mapa sama nie jest wynikiem. Zdarzenia zamieniają się w pozycje backlogu, hot spoty w listę decyzji do podjęcia, a etapy procesu w podział na wydania. Na tej podstawie ustala się zakres pierwszej wersji, do czego przydaje się priorytetyzacja MoSCoW, i przygotowuje wycenę wdrożenia opartą na procesie, a nie na szacunkach z rozmowy. Kolejne kroki opisujemy we wpisie o tym, jak wygląda proces wdrażania oprogramowania.
Event Storming jako część warsztatu produktowego
W Squares Event Storming jest jedną z technik warsztatu produktowego, który trwa 1-2 tygodnie i kończy się dokumentem z zakresem, decyzjami i następnym krokiem. W projekcie aplikacji Daily Effect wnioski z warsztatów i event stormingu zostały przełożone na wymagania i zakres pierwszej wersji produktu. Warsztat ma stałą cenę ustalaną przed rozpoczęciem prac. Gdy pytanie dotyczy samego rozwiązania, a nie procesu, lepszym formatem bywa design sprint.
Najczęstsze pytania
Ile osób powinno brać udział w Event Stormingu?
Autor metody, Alberto Brandolini, w pierwszym opisie z 2013 r. podawał 6 do 8 osób: te, które znają odpowiedzi, i te, które umieją zadawać pytania. Sesje na poziomie Big Picture, obejmujące cały obszar biznesu, gromadzą nawet 10 do 30 uczestników. Ważniejszy od liczby jest skład: biznes, operacje i zespół techniczny razem.
Ile trwa Event Storming?
Czas zależy od poziomu i zakresu: mapa jednego procesu wymaga mniej czasu niż obraz całego obszaru biznesu. W Squares Event Storming jest częścią warsztatu produktowego, który trwa 1-2 tygodnie razem z zebraniem kontekstu przed sesjami i spisaniem wniosków po nich. Same sesje z zespołem zajmują część tego okresu.
Czy Event Storming można przeprowadzić zdalnie?
Tak. Ścianę i karteczki zastępuje tablica online, na przykład Miro albo FigJam. Wersja zdalna wymaga więcej przygotowania: legendy kolorów i osi czasu gotowych przed sesją, krótszych bloków z przerwami oraz drugiej osoby prowadzącej, która porządkuje tablicę. Zaletą jest to, że mapa od razu istnieje w formie cyfrowej i nie trzeba jej przepisywać.
Czym Event Storming różni się od mapy podróży klienta?
Mapa podróży klienta pokazuje proces oczami jednej osoby: jej kroki, emocje i punkty styku z firmą. Event Storming pokazuje wszystko, co dzieje się w procesie, także to, czego klient nie widzi: decyzje pracowników, reguły automatyczne i systemy w tle. Pierwsza technika służy projektowaniu doświadczenia, druga ustaleniu zakresu i logiki produktu.
Czy do Event Stormingu trzeba znać Domain-Driven Design?
Nie. Metoda wywodzi się ze środowiska DDD i na poziomie Software Design prowadzi do pojęć takich jak agregat i kontekst, ale poziomy Big Picture i Process Modelling opierają się na zdarzeniach zapisanych zwykłym językiem. Uczestnik musi znać swój fragment procesu, a nie notację. Legendę kolorów prowadzący wyjaśnia na początku sesji.
