W 2013 roku Alberto Brandolini opracował technikę warsztatową do modelowania procesów biznesowych, którą nazwał Event Storming. Chciał on stworzyć bardziej intuicyjny i oparty na współpracy sposób rozumienia złożonych systemów. Jak działa Event Storming w praktyce? Prześledźmy ten proces.
Event storming jest pomocny, kiedy:
- Tworzymy model biznesowy dla rozwoju projektu/usługi,
- Chcemy mieć obraz złożoności modelu produktowego,
- Potrzebujemy burzy mózgów dotyczącej alternatywnych rozwiązań,
- Szukamy wąskich gardeł w dojrzałych produktach.
Krok 1: Przygotowanie
Wyobraźmy sobie, że pracujemy dla firmy zajmującej się przejazdami na życzenie i chcemy zorganizować warsztat poświęcony rozwojowi naszej aplikacji. Dobrze, by na takim spotkaniu pojawiło się jak najwięcej specjalistów z różnych działów, takich jak programiści, specjaliści IT, product ownerzy, a także osoby z działu wsparcia klienta, marketingu i designerzy.
Warsztat zaczynamy od przedstawienia celu i zasad Event Stormingu. To bardzo ważne, ponieważ sesja może wydawać się dość nieformalna. Ma jednak swoją strukturę i zadaniem facylitatora jest tego porządku pilnować. Przedstawiony jest również temat, nad którym będzie pracować zespół. Naszym celem może być np. zrozumienie wyzwań, przed którymi stoimy, znalezienie rozwiązań, by wyróżnić się od konkurencji lub często zgłaszany przez użytkowników problem.
Na początek każdy z uczestników otrzymuje pomarańczowe karteczki i coś do pisania. Kolor karteczek ma znaczenie, ponieważ każda faza warsztatu ma swój kolor i w miarę upływu czasu nasza tablica, na której przyklejamy postity, robi się coraz barwniejsza. Dzięki temu nasz model jest naturalnie podzielony i łatwiej będzie go uporządkować.
Takich karteczek będziemy potrzebowali na sesję Event Stormingu.
Krok 2: Zacznijmy od Big Picture
Prosimy uczestników, aby na karteczkach spisali istotne zdarzenia (eventy) dziejące się w systemie. Przez eventy rozumiemy różne istotne wydarzenia lub zmiany w procesie. Reprezentują one momenty, które coś zmieniają
w aplikacji lub mają znaczenie biznesowe. Dla specjalistów z różnych działów istotne mogą być kompletnie inne zdarzenia i wszystkie powinny pojawić się na tablicy.
Co ważne, eventy zapisujemy w czasie przeszłym. Dlaczego właśnie tak? W Event Stormingu przedstawiamy je jako faktyczne i już zaistniałe zdarzenia, a nie abstrakcyjne koncepcje. Takie podejście zwiększa klarowność, pomaga uniknąć niejednoznaczności i dokumentować historię działania systemu/procesu. Forma dokonana eventu wymusza na uczestnikach pewien sposób myślenia – nie interesuje nas event „szukanie przejazdu”, tylko „zamówienie przejazdu” lub „znalezienie samochodu”.
Jako pierwsze, najważniejsze zdarzenie zaproponujmy więc „zamówienie przejazdu”. To podstawowy event, wokół którego kręci się nasz biznes. Możemy wskazać zdarzenia jako potencjalnie pierwsze i potencjalnie ostanie w systemie
i dalej wyszukiwać wszystkich pozostałych dziejących się pomiędzy nimi.
Przykładowe wyjściowe eventy w systemie zamawiania przejazdów.
Dodawanie eventów to tak zwana eksploracja. Ta kreatywna sesja przypomina burzę mózgów i stanowi podstawę do dalszej pracy. Czasem podczas warsztatów może dojść do ożywionych dyskusji. Zderzenie różnych perspektyw jest nieodłączną częścią Event Stormingu. Rolą facylitatora jest zadbanie o rozładowanie napięcia i umiejętne pokierowanie dyskusją tak, aby wydobyć wartościowe informacje. Ważne jest, by pozwolić na swobodną wymianę opinii, jednocześnie zachowując strukturę warsztatów.
Jednym ze sposobów na zażegnanie kwestii spornych, jest użycie hotspotów, czyli czerwonych karteczek. Hotspoty oznaczają problematyczną kwestię, którą chcemy zaparkować, by wrócić do niej później. Przykładowym hotspotem może być zaproponowanie dodatkowych usług podczas przejazdu, np. przy evencie „Wybrano miejsce odbioru” przylepiamy karteczkę z informacją „Jeśli miejsce odbioru jest w pobliżu przedszkola lub szkoły, zaproponuj pasażerowi fotelik dla dziecka”.
Warto kolekcjonować pomysły, żeby później móc do nich wrócić.
Hotspoty mogą być też używane do identyfikacji obszarów wymagających szczególnej uwagi, wskazywania kluczowych problemów, które wymagają dalszych analiz, a także do zaznaczania potencjalnych zagrożeń lub szans.
Krok 3: Porządkowanie karteczek
Najpierw sprawdźmy, czy eventy, które mamy na tablicy są poprawne i się nie powtarzają. Często jest tak, że niektóre zdarzenia można połączyć lub zrobić z nich jeden, dużo lepszy event. Kiedy mamy już porządek w karteczkach, czas znaleźć ten właściwy event rozpoczynający naszą ścieżkę. Prowadzący nie musi tego wiedzieć, ale musi wydobyć odpowiednią wiedzę od uczestników warsztatu.
Na tablicy mogą pojawić się duplikaty lub te same zdarzenia opisane innym językiem.
Zdarzenia układamy na osi czasu tak, jak występują kolejno po sobie. Te same eventy mogą wystąpić na tablicy więcej niż jeden raz. Nie oznacza to błędu, ale pokazuje, że mogą się one zadziać na różnych etapach.
Często po pierwszym uporządkowaniu eventów stosuje się technikę reverse narrative. Polega ona na przejściu ścieżki od końca i sprawdzeniu, czy zadziało się wszystko, aby mogły nastąpić poszczególne zdarzenia. To pozwala na odkrycie brakujących ogniw np. eventów, które wydawały się zbyt oczywiste i dlatego je pominęliśmy. Warto je dodać na tym etapie.
Podczas porządkowania eventów zaczynają tworzyć się niezależne linie, na przykład te związane bezpośrednio z przejazdem i kierowcą. Porządkowanie eventów to również moment, gdy możemy przedyskutować hotspoty.
Tak na tablicy wyglądają uporządkowane eventy, które rozchodzą się na niezależne ścieżki.
Krok 4: Czas na aktorów i systemy
Po uporządkowaniu eventów zaczynamy dodawać na tablicy małe żółte karteczki symbolizujące aktorów. Pomagają one zdefiniować osoby, które wywołują poszczególne zdarzenia: klienta, kierowcę, admina, itp. Aktor oznacza więc rolę w naszym systemie. Następnie dodajemy różowe karteczki, które wskazują usługi i systemy użyte w aplikacji takie jak ścieżka rezerwacji czy system powiadomień. Mogą być one zarówno wewnętrzne, jak i zewnętrzne.
Początkowa ścieżka klienta z oznaczonymi punktami i systemami.
Krok 5: Czas poszukać problemów lub… okazji
Kiedy już wiemy wszystko o naszej usłudze, czas na cofnięcie się do samego początku spotkania i przypomnienie sobie jego celu. Jeśli okaże się, że znaleźliśmy więcej niż jeden problem lub okazję, warto wybrać jedno kluczowe zaganianie. Żeby to zrobić, należy podejść do wyboru dalszych kroków konstruktywnie. Możemy zaangażować wszystkich uczestników i przeprowadzić głosowanie. Zanim to nastąpi, warto posiłkować się wiedzą osób z działów obsługi klienta. To one stoją na pierwszej linii frontu i przyjmują zgłoszenia bezpośrednio od użytkowników – dobrze wysłuchać, co mają do powiedzenia. Możemy też zapytać Product Ownera, jak widzi dalsze kroki, bo to on będzie zajmował się rozwojem/poprawą usługi.
W ten sposób zakończyliśmy sesję Big Picture. Przechodzimy do głębszej analizy.
Krok 6: Proces Level Event Storming
Ten etap ma nas zbliżyć do rozwiązania zagadnienia, które wybraliśmy. Sesję process level zaczynamy od wybrania konkretnego miejsca w naszym systemie i zdefiniowania komend. Pomogą nam w tym niebieskie karteczki oznaczające komendy, czyli intencje, które stoją za danym eventem w ścieżce. Komendy są wydawane w trybie rozkazującym przez aktorów.
Żeby komendy zostały pozytywnie obsłużone, niezbędne jest wprowadzenie do systemu reguł biznesowych (fioletowe karteczki). Reguła może dotyczyć historii przejazdów, ocen otrzymanych od kierowców czy warunków anulowania. W naszym przypadku jest to reguła, która generuje ofertę po zamówieniu przejazdu. Pozytywna weryfikacja pozwala działać komendzie.
Początkowa ścieżka klienta z oznaczonymi komendami i regułami biznesowymi.
Po tym etapie zostaje nam już tylko Design Level Event Storming, czyli stworzenie docelowego modelu, który przeniesiemy 1:1 do naszego systemu czy aplikacji. W tę część angażują się już głównie osoby techniczne, które wdrażają rozwiązanie do kodu.
Na początku artykułu zaprezentowane były wszystkie karteczki, których używa się podczas sesji Event Stormingu. Niektórych z nich – białych oznaczających definicje i żółtych, które są miejscem na komentarz – nie uwzględniliśmy w naszych przykładach, co nie oznacza, że są mniej ważne. Wręcz przeciwnie, warto co jakiś czas zastanowić się, co mamy na myśli, używając danego słowa lub sformułowania, zapisać je i umieścić na tablicy tak, żeby wszyscy uczestnicy warsztatu tak samo rozumieli dany element. Tak samo jest z komentarzami – można je dodać, kiedy mamy istotną uwagę lub myśl dotyczącą zdarzenia czy miejsca w procesie.
Podsumowanie
Podczas tworzenia produktu ważne jest, aby zespół programistów był dobrze zorientowany w domenie biznesowej,
w której działa produkt. Warsztaty takie jak Event Storming mogą poprawić ogólną współpracę między zespołami biznesowymi i produktowymi.
Do najważniejszych zalet sesji Event Stormingowych zaliczamy:
- Szybkość: Większość technik modelowania procesów biznesowych wymaga zagłębiania się
w operacjach biznesowych. Tym samym wiążą się one z wykorzystaniem złożonych modeli danych i mogą zająć tygodnie. Event Storming to zazwyczaj jednodniowe wydarzenie, podczas którego kompletny proces biznesowy może zostać zmapowany w ciągu kilku godzin. - Wspólne zrozumienie: Event Storming pokazuje proces biznesowy, który można łatwo zrozumieć bez wcześniejszej wiedzy technicznej. To most łączący interesariuszy technicznych z nietechnicznymi.
- Współpraca: Podstawową koncepcją Event Stormingu jest zachęcenie do uczestnictwa
i interakcji między ekspertami z różnych dziedzin. Tworzy to naturalne środowisko do tworzenia modeli biznesowych i prowadzi do odkrycia wartościowych spostrzeżeń. - Skuteczność: Zespoły mogą wykorzystać wiedzę zdobytą podczas warsztatów do przyszłych procesów modelowania i tworzenia produktów lub po prostu, by lepiej zrozumieć procesy biznesowe i podejmować lepsze decyzje w przyszłości.
