Event Storming, czyli jak bez przemocy wyciągnąć informacje od biznesu

Są dwa powody, które przyczyniły się do zorganizowania przeze mnie pierwszego w życiu Event Stormingu. Pewnie większość programistów zna bardzo dobrze rozpropagowany kurs DNA (Droga Nowoczesnego Architekta). W IDEMIA skorzystało z niego bardzo wielu developerów. Wspominam o tym, ponieważ to właśnie tam pierwszy raz usłyszałem o Event Stormingu. Prowadzący rozpływali się nad tym, jak bardzo ułatwia on życie i dlaczego powinniśmy go stosować. Właśnie to, w jaki sposób sprzedali ten nurt, spowodowało, że zacząłem się tym bardziej interesować. 

Większość z nas wie, że jeżeli jesteśmy w jakimś projekcie, to ciężko jest znaleźć czas na jakieś nowe technologie, zastosowanie nowego podejścia, itp. Dlatego nie spodziewałem się, że za 2 miesiące będę już po swoich pierwszych warsztatach. Dzięki mojej przynależności do gildii Agile w IDEMIA, dowiedziałem się, że jeden ze Scrum Masterów będzie organizował takie spotkanie. Poszedłem więc popatrzeć, jak to wygląda. Piotr Sielski, bo o nim mowa, zapytał  mnie, czy mam w planach zrobić taką sesję. Powiedziałem, że pewnie kiedyś tak. „Czemu nie teraz?” zapytał. Poczułem, że rzucił mi wyzwanie i już nie miałem wyboru, musiałem zająć się jej przygotowaniem. 

Potrzebny był jednak konkretny powód. Na szczęście, nasz zespół dojrzał do tego, żeby zamienić Cassandrę na relacyjną bazę danych, ponieważ w naszym projekcie była ona źle wykorzystywana. Stwierdziliśmy wtedy, że nie będziemy bezmyślnie przepisywali tego samego modelu popełniając kolejne błędy. Chcieliśmy zrobić to poprawnie, od samego początku. Podjęliśmy decyzję, że zorganizujemy nasz pierwszy Big Picture Event Storming. Właśnie po to, aby dobrze zabrać się za projektowanie domen i modelu od samego początku. 

Co to jest Event Storming? 

We wcześniejszym akapicie wspomniałem już, że Event Storming to swego rodzaju warsztaty oraz, że wspomagają modelowanie systemu. Nie chciałbym rozpisywać się długo na ten temat. Autor tego rozwiązania robi to lepiej, o czym można poczytać tutaj i tutaj. Wspomnę tylko o tym, co jest najważniejsze dla zrozumienia całej historii.   

Event Storming to rodzaj warsztatów, po raz pierwszy opisanych przez Alberto Brandoliniego, który skupia się na tym, aby za pomocą prostych narzędzi i zrozumiałych zasad zwizualizować nawet najbardziej skomplikowane procesy i systemy. Dzięki temu, możemy wykorzystać potencjał naszego całego zespołu developerskiego i osób, które znają proces od podszewki. Pozwoli nam to (o czym wspomnę jeszcze później) na skrócenie fazy analizy, a co ważniejsze – unikniemy wielu nieporozumień na linii biznes – programiści. 

Gdy już wiemy, jaki proces będziemy wizualizować (w naszym przypadku był to: „Proces dostarczania wirtualnych kart SIM”), musimy zebrać osoby, które mają na jego temat pytania i tych, którzy znają na nie odpowiedzi. Najczęściej „po jednej stronie barykady” stoją programiści, a po drugiej tzw. biznes. Barykada w tym przypadku jest w ogromnym cudzysłowie, ponieważ, jak żadne inne warsztaty, te bardzo zbliżają wspomniane dwa światy i powodują, że zaczynają rozmawiać tym samym językiem na temat jednego procesu. Dodatkowo, każda ze stron rozumie, o czym mówi ta druga. Rzadko spotykana rzecz w świecie IT. 

Jak już mamy wszystkich „zamkniętych” w jednym pokoju, to dajemy im różnokolorowe karteczki i prosimy, aby wszystkie zdarzenia zapisali na nich i przyklejali na „niekończącej” się przestrzeni procesu. Jest to bardzo proste, dzięki czemu każdy rozumie, co należy zrobić. Dodatkowo przynosi to wymierne efekty. 

Krótko o domenie 

„Proces dostarczania wirtualnych kart SIM” brzmi skomplikowanie. O co konkretnie chodzi? Mój zespół projektowy jest częścią większej jednostki organizacyjnej o nazwie Connectivity, która zajmuje się obsługą szeroko pojętego rynku dostarczania wirtualnych kart SIM. Zespoły, które brały udział w warsztatach, są odpowiedzialne za stworzenie milionów takich profili oraz dostarczeniu na Wasze smartwatche, telefony albo do samochodów czy innych urządzeń, do których zwykle człowiek nie ma dostępu. Współpracujemy z największymi gigantami telekomunikacyjnymi na świecie, dlatego proces, który tworzymy, musi być jak najlepiej przystosowany do dostarczania takich profili.  

Kogo zaprosiliśmy? 

Wspomniałem już, że najlepsza implementacja Event Stormingu wymaga, żeby zaprosić na takie warsztaty wszystkich zainteresowanych. Organizator takiego spotkania, wraz z zespołem, któremu najbardziej zależy na tej inicjatywie (najczęściej jest to zespół programistów), powinien ustalić kim są osoby, które potencjalnie znają odpowiedzi na pytania zespołu developerskiego. Można zaryzykować stwierdzenie, że dobór osób na spotkanie jest najważniejszym czynnikiem, wpływającym na powodzenie całej misji. 

Zdaję sobie sprawę, że nie jest to łatwe zadanie, natomiast dzięki temu, że IDEMIA wspiera takie inicjatywy, to nie był to żaden problem. Ludzie są najważniejszym elementem tej układanki i gdy będziemy eksplorować nasz proces to „Biznes” jest obowiązkowy. 

Wspomniałem już o naszej dosyć skomplikowanej domenie, więc pytanie - kogo zaprosiliśmy? 

W warsztatach wzięli udział: 

• Wszyscy Developerzy systemu, QA Engineer oraz Team Leader – to są Ci ludzie, którzy zazwyczaj mają pytania.
• Product Ownernaszego projektu – osoba, która teoretycznie powinna wszystko wiedzieć, ale okazało się, że razem z innymi ekspertami mogła doprecyzować szczegóły bardziej skomplikowanych części procesu. Warto nadmienić, że PO był kiedyś klientem naszego rozwiązania i również zna ten proces bardzo dobrze. 
• Użytkownikjednego z naszych systemów – ktoś, kto bardzo często rozmawia z klientem i obsługuje jego zamówienia. Część procesu wykonuje w tworzonym przez nas systemie. 
• Technical Consultant– osoba, która świetnie zna cały proces. Można powiedzieć, że zjadła na nim zęby. To właśnie on wniósł lwią część opisu całego systemu. W naszej firmie Technical Consultant (co również uszczegółowiliśmy podczas Event Stormingu), zajmuje się przygotowaniem i sprawdzeniem technicznej części profilu dla wirtualnej karty SIM. To on zbiera wymagania bezpośrednio od klienta, to on zna wszystkie specyfikacje i jest w stanie przetłumaczyć wymagania klienta na język techniczny. Warto dodać, że akurat z tą grupą ludzi nasz zespół ma najmniejszy kontakt, dlatego bardzo się cieszymy, że wyraził chęć pomocy i dołączył do warsztatów. 
• Ex-Technical Consultant – aktualnie Product Owner innego produktu z tej samej domeny, z którym również się integrujemy. Osoba ta nadal ma ogromną wiedzę dotyczącą całego procesu. 
• Product Owner systemu, z którym się integrujemy– dzięki takiej osobie byliśmy w stanie zwizualizować cały proces. Również to, co się dzieje w momencie, gdy my już „kończymy” swoją pracę. 
• Analityk Funkcjonalnyz tego samego zespołu, co Product Owner wyżej. Jej znajomość systemu i całej specyfikacji wpływającej na proces, była czymś, co również odmieniło losy naszego Event Stormingu. 

Biorąc pod uwagę, że zespół developerski składa się z 6 osób, a jedna z nich nie mogła uczestniczyć w warsztatach, to „fronty” były wyrównane. I ponownie po zastanowieniu się stwierdzam, że to były właśnie te osoby, których wtedy potrzebowaliśmy. 

Jak wyglądały warsztaty? 

Same warsztaty zaplanowaliśmy z miesięcznym wyprzedzeniem. Mimo panującej pandemii (która w tamtym czasie wydawała się być w odwrocie), chcieliśmy spotkać się na żywo, w jednym miejscu. Podjęliśmy taką decyzję, ponieważ był to nasz pierwszy Event Storming, ale też dlatego, że chcieliśmy lepiej poznać wszystkie zaproszone osoby. Dodatkowo, zdecydowanie łatwiej zauważyć ludzkie gesty, mimikę, podejść, podyskutować na temat jednej karteczki (tak się działo bardzo często), gdy jesteśmy wszyscy razem, niż próbować zaprząc do tego MS Teams. To, że sam Alberto Brandolini twierdzi, że najlepiej jest spotkać się osobiście, tylko umocniło naszą decyzję.

Nie twierdzę, że zdalny Event Storming nie jest możliwy (w naszej firmie takie inicjatywy również są aktualnie prowadzone). Twierdzę, że jeżeli jest to nasz pierwszy Event Storming, to najlepiej jest to zorganizować na miejscu i wspólnie ze wszystkimi zainteresowanymi.  

Zaplanowaliśmy sobie około 6 godzin na takie warsztaty. Na pierwszy rzut oka wydawało się, że to dużo czasu, ale okazało się, że i tak nie zdążyliśmy zrobić jednego z zaplanowanych punktów programu. Nie chcieliśmy natomiast zmuszać naszych gości do nocowania w Łodzi. Tak, nasi goście nie pracują z nami w jednym biurze, a i tak zgodzili się wziąć udział w spotkaniu. I to jest duch, jakiego potrzeba w takich warsztatach! 

Zaczęliśmy więc od wstępnego wprowadzenia do tematu oraz tego, co chcemy osiągnąć. Jako prowadzący to spotkanie, musiałem wyjaśnić najważniejsze zasady i opowiedzieć o kolorach karteczek wykorzystywanych podczas warsztatów. To właśnie karteczki są najważniejszym narzędziem, jeśli chodzi o modelowanie. Każdy kolor oznacza coś innego np. pomarańczowe oznaczają jakieś zdarzenie, różowe oznaczają system zewnętrzny, a żółte aktorów. Oczywiście tych oznaczeń i kolorów jest trochę więcej, szczegółowy opis można znaleźć tutaj.

Coś, co według mnie było dobrym pomysłem, to wprowadzanie większej ilości szczegółów – dodatkowych kolorów karteczek opisujących zdarzenia, aktorów, itp. dopiero w momencie, kiedy były potrzebne. Nie zdradziłem wszystkiego na samym początku.  

Przysłuchiwałem się rozmowom i starałem się na bieżąco wprowadzać usprawnienia do tego, co już pojawiło się na ścianie. 

Jedną z ważniejszych rzeczy, o której musieliśmy pamiętać to usunięcie wszystkich krzeseł z sali konferencyjnej. Spowodowało to, że ludzie przez pierwsze 1,5h cały czas stali przy ścianach i starali się zrozumieć, ulepszyć proces, który wspólnie rysowaliśmy. Powodowało to, że bardzo często pojawiały się dyskusje. Dyskusje te, okazywały się bardzo przydatne. Wiele razy osoba, która zna proces od podszewki, przeklejała nam karteczki z miejsca na miejsce, bo twierdziła, że tak być nie może. Dzięki temu, że byliśmy wszyscy w jednym miejscu i dużo dyskutowaliśmy o procesie, to poznaliśmy wiele ciekawostek o nim.  

Nie wchodząc w szczegóły czasowe, warsztaty 8-godzinne podzieliliśmy na kilka części: 

• Wypisanie wszystkich zdarzeń, aktorów, swimlane, systemów zewnętrznych.
• Zgrubne przeanalizowanie, czy wszystko związane z procesem jest już na ścianie. Przez to, że byliśmy tam wszyscy razem i rozmawialiśmy na ten temat, to zajęło to mniej więcej tyle samo, co pierwsza część. Co więcej, ilość karteczek oraz zmian, również była podobna. 
• Posprzątanie niepotrzebnych zdarzeń, wprowadzenie dodatkowych wizualizacji, dzięki którym rozwialiśmy wszystkie wątpliwości na temat spójności procesu. 
• Wprowadzenie, a raczej sprawdzenie harmonogramu i powiązania czasowego poszczególnych zdarzeń. Tutaj ponownie okazało się, że mieliśmy bardzo wiele zmian. 
• Przeczytanie historii od początku do końca w „podziale na głosy” i z zachowaniem chronologii zdarzeń. 
• Punkt, którego nie udało się zrobić to: przeczytanie tego wszystkiego jeszcze raz, ale od końca. Tak zwana wsteczna narracja. Dzięki temu, że zdarzenia były w czasie przeszłym dokonanym (i nie może być inaczej!), to moglibyśmy przeczytać to od tyłu i znaleźć miejsca, w których jedno zdarzenie się zadziało, ale nie wiemy, dlaczego. Innymi słowy tutaj mielibyśmy jeszcze jedno upewnienie się, czy nie mamy luk w procesie. 

Jakie były największe wyzwania? 

Do warsztatów potrzebna jest: nieograniczona przestrzeń do naklejania karteczek (w naszym przypadku sprawdził się papier do plotera), bardzo duża ilość karteczek w różnych kolorach i kształtach, taśma malarska do nadawania nazw fragmentom procesów i duża ilość markerów. Dzięki temu, że w IDEMIA Piotr Sielski już wcześniej organizował takie warsztaty, mieliśmy już potrzebne materiały.  

Kolejnym wyzwaniem mogła być bariera językowa. Mimo że w IDEMIA wszyscy mówią po angielsku, to jednak rozmawianie o dosyć skomplikowanym procesie wytwarzania kart SIM jest dużo łatwiejsze w ojczystym języku. Zawsze mógł pojawić się problem ze zrozumieniem jednego słowa, nawet przez native speakerów. Jak już wcześniej zaznaczyłem, nasza „drużyna” składała się z ludzi z Łodzi oraz Warszawy, mieliśmy jednak jedną osobę, która pochodzi z Francji, ale mieszka w Polsce. To mógł być największy problem, ale okazało się, że wszyscy mówimy po Polsku i nie będzie problemu bariery językowej. Jak się jednak później okazało, wszyscy rozmawiali po polsku i angielsku naprzemiennie. Było to bardzo ciekawe doświadczenie, zobaczyć jak mózg automatycznie dostosowuje język do rozmówcy.  

Z punktu widzenia prowadzącego dużym wyzwaniem było utrzymanie skupienia i energii ludzi podczas całych warsztatów. Przerwy i lunche są bardzo pomocne w tym aspekcie. 

Mogłoby się wydawać, że to, że większość ludzi nie miało wcześniej styczności z takimi zajęciami będzie problemem, że nieznajomość zasad może niekorzystnie wpływać na te warsztaty. Nic bardziej mylnego. Dzięki temu, że zasady są bardzo proste, ryzyko to zdematerializowało się zaraz po kilku pierwszych przyklejonych kartkach. 

Co osiągnęliśmy?  

Nie zebraliśmy prawie 12 osób tylko po to, żeby sobie porozmawiać. Zależało nam na rezultacie naszej pracy. Efekt, który chcieliśmy uzyskać, i go osiągnęliśmy, to ułożenie wiedzy jaką mamy, zebranie od prawdziwych ekspertów informacji jak działa ten proces. Chcieliśmy znaleźć miejsca, w których stworzony przez nas proces nie jest tym, czego oczekują klienci. 

Na purpurowo (hot-spot) zaznaczyliśmy miejsca w których zgadzamy się, że proces jest do zmiany. Mimo, że byliśmy (Developerzy) pewni tego rozwiązania i nigdy nie poddawaliśmy w wątpliwość, że system wspiera proces tak jak powinien, skończyliśmy z 4 „grubymi” miejscami które należy zmienić lub dołożyć funkcjonalność. 

Przez 2 lata nie chcieliśmy zrobić jednej funkcji, bo twierdziliśmy, że jest bez sensu. Developerzy skutecznie blokowali tę zmianę. Po tych warsztatach funkcjonalność bardzo awansowała, jeśli chodzi o priorytet i aktualnie jest naszym następnym celem. Wszystko to dzięki temu, że eksperci domenowi wskazali palcem na ścianie i powiedzieli: „Tutaj czegoś brakuje!”, „To nie pomaga nam w naszej pracy”. 

Dołożyliśmy coś do roadmapy, ale też mieliśmy okazję z niej coś wyjąć. Podczas warsztatów zebraliśmy informacje o tym, że nasze najnowsze pomysły, naszym zdaniem zmieniające świat, są czymś, co nigdy nie zostanie wykorzystane. Dostaliśmy informację zwrotną wcześniej, niż się tego spodziewaliśmy. Tak, usunęliśmy naszą implementację zanim się do niej zabraliśmy, a na pewno daliśmy sobie czas na ponowne jej przemyślenie. 

Nieoczekiwanym, ale bardzo dobrym rezultatem była synchronizacja wszystkich PO projektów biorących udział w tym procesie. Na całe szczęście nasza domena ściśle ze sobą współpracuje, więc informacje wpływające na projekty są przekazywane bezproblemowo. Mimo to, po naszkicowaniu całego procesu na ścianie i przeczytaniu go w całości, Ci sami ludzie, którzy się bardzo często synchronizują stwierdzili, że są jeszcze miejsca tego całego procesu które były dla nich czarną magią. Podkreślam słowo były, ponieważ po całodniowym warsztacie wszyscy wyszli z dodatkową wiedzą i czarna magia stała się już zwykłą magią. 

Podsumowując zużyte materiały, to zalepiliśmy 10m ściany karteczkami samoprzylepnymi. Wyprodukowaliśmy ich około 150 i dodatkowo około 50 zostało komisyjnie zniszczonych, ponieważ nie były dokładne i nie pasowały do procesu. W materiał można również wliczyć ciastka, które znikały jak ciepłe bułeczki oraz lizaki, które podobno pobudzają naszą kreatywność przypominając czasy, kiedy byliśmy najbardziej kreatywni, czyli nasze dzieciństwo.  

Co zrobiliśmy później? 

Tę sekcję możemy podzielić na dwie części – oficjalną i nieoficjalną. Podczas integracyjne części nieoficjalnej poznaliśmy lepiej naszych ekspertów, zaprosiliśmy ich na nasze Sprint Demo. Teraz już wiemy do kogo kierować swoje pytania, gdy będziemy mieli problem ze zrozumieniem procesu. 

Część oficjalna, to po pierwsze, przelanie tej wiedzy na formę cyfrową, tak, żeby móc się nią podzielić ze wszystkimi, którzy byli zainteresowani wynikiem. Po drugie, przeniesienie naszego dzieła w wersji papierowej do naszego pokoju, tak, żeby każdy je widział i żebyśmy, mając z czymś problem, mogli mieć pod ręką „ściągę” (oczywiście przez aktualną sytuację epidemiczną jest to trochę utrudnione, ale mamy wersję cyfrową). 

Jak już wspominałem, jeden z Hot-Spotów już został zaadresowany, a kolejne, znajdują się na naszej roadmapie w niedalekiej przyszłości. 

Podsumowanie 

Najważniejsze pytanie, które można sobie zadać po przeczytaniu tego artykułu to: Czy warto to robić? Odpowiedź jest prosta Zawsze. Rozmowa z ekspertami, wizualizacja procesu w jasny sposób, bardzo pomaga podczas tworzenia systemu. Kolejne pytanie Czy Event Storming jest trudny? Odpowiedź brzmi Nie. A jak masz wątpliwości, to my już wiemy, jak to robić. 

Wiemy też, że na tym nie poprzestaniemy i jak już wszyscy wrócimy do bezpiecznego biura, a sytuacja w Polsce się polepszy, to będziemy chcieli eksplorować głębiej to, co sobie narysowaliśmy. Zgodnie ze sztuką po Big Picture Event Storming powinien przyjść Design Level Event Storming – i to też jest na naszej roadmapie. 

Następnym razem, gdy będziesz pobierać subskrypcję na swój nowy telefon z wbudowaną kartą SIM, albo na swój zegarek, żeby mieć stałe połączenie do Internetu – to jest duża szansa, że to właśnie nasze systemy są w to zamieszane. A Ty już wiesz, jaką wagę przykładamy do jakości procesu, który dostarczamy.