Dzisiaj spotykamy się w trochę większym gronie: naszym gościem jest Mariusz Gil, specjalista od event stormingu i podcaster “Better Software Design”. Rozmawiamy o event stormingu od a do z - czyli od definicji, przez cały proces, aż po narzędzia.
Przemaglowaliśmy Mariusza dość dokładnie, więc można powiedzieć, że ten odcinek Pato to takie kompendium event stormingu. Enjoy!
Słuchasz Patoarchitektów dzięki Protopii. Sprawdź, jak Patoarchitekci i Protopia mogą Ci pomóc ➡️ protopia.tech
Linki i ciekawe znaleziska:
Szymon Warda: Cześć, słuchacie Patoarchitektów. Prowadzą Szymon Warda.
Łukasz Kałużny: I Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na Patoarchitekci.io albo klasycznie gdzieś tu na dole. Dobra Szymonie. To co dzisiaj?
Szymon Warda: Pokażę zanim, to pato to the moon generalnie, czyli czy poshare’owanie pato babci, cioci, koledze, itd. A dzisiaj weryfikujemy czy share’ujecie. Mariuszu, czy ty poshare’owałeś Pato dzisiaj?
Mariusz Gil No jeszcze nie, jeszcze nie.
Szymon Warda: To od razu wyjaśnimy. Mamy dzisiaj gościa, chcieliśmy porozmawiać o event stormingu. No i tak się złożyło, że Google jakoś, jak się wpisuje “event storming Polska” to przekierowuje od razu na stronę Mariusza, bo oczywiście rozmawiamy z Mariuszem Gilem.
Mariusz Gil Dzień dobry, witam wszystkich.
Szymon Warda: Tak. Człowiek, który właściwie jest synonimem event stormingu, jeżeli chodzi o Polskę i nie tylko, podejrzewamy. I też nasza wspaniała konkurencja/niekonkurencja właściwie podcastowa. No i będziemy dzisiaj rozmawiali właśnie o tym z czego Mariusz słynie właśnie, czyli z eventstormingu, a też przy okazji trochę o softwarze i innych rzeczach tak naprawdę.
Łukasz Kałużny: Dobra, to co, ja może zacznę, słuchaj Mariuszu, od razu z grubej rury. Jak ktoś chce poznać Mariusza bardziej to Better Software Design Podcast, czyli to gdzie my się uzupełniamy, czyli Mariusz bardziej oprogramowanie, my bardziej twarda architektura. I słuchaj, zacznijmy może Mariusz od takiej rzeczy, jak mamy rozmawiać o event stormingu, bo może nie wszyscy nasi słuchacze wiedzą co to jest. Jakbyś mógł to wyjaśnić, tak jak dziesięciolatce, jak to Szymon określił, czyli w najprostszych możliwych słowach zanim zaczniemy wchodzić głębiej.
Mariusz Gil Czym to jest? No to trudne zadanie na początek stawiacie. A że nagrywamy ten podcast o pewnej zbrodniczej porze, to zadanie jest jeszcze trudniejsze. Czym jest event storming? Ja bym powiedział, że po kilku latach stosowania tej techniki tak w boju, to jest to po prostu pewien sposób prowadzenia rozmowy, który opiera się o tym, że zaczynamy od tak zwanych zdarzeń, czyli ważnych rzeczy, które się wydarzyły i zobaczymy, gdzie nas to doprowadzi. I tu mógłbym postawić kropkę. Podobno nawet ostatnio definicja Alberto Brandolini, czyli twórca tej techniki, gdzieś tam przedstawił, bo faktycznie na początku takiego warsztatu, to tutaj nie wiadomo, jak to się skończy bardzo często. Więc porozmawiajmy o zdarzeniach, wyjdźmy od tego, zobaczmy, co ciekawego się dzieje w naszej aplikacji, w naszym procesie biznesowym i zobaczmy, gdzie jest problem, który musimy zaatakować.
Szymon Warda: No dobra, ok, dałeś taką trochę ogólną definicję. Porozmawiajmy, pogadajmy. Event storming jest taką jedną z tych technik, która ewidentnie się udała. Znaczy jest to technika nośna, o której większość ludzi przynajmniej słyszało.Teraz pytanie, czemu właściwie, czemu event stormingowi się udało?
Mariusz Gil Chyba tutaj troszeczkę bym najpierw dodał kontekstu do tego ‘udało się’, bo faktycznie, jeżeli popatrzymy na nasz polski tutaj krajobraz, na nasz polski rynek, to faktycznie event storming jest bardzo znaną techniką. Jeżeli popatrzymy sobie na inne kraje, na Europę, gdzieś tam na Stany, powiedzmy gdzieś tam na Daleki Wschód, to sytuacja delikatnie inaczej wygląda. To zachęcam każdego do wpisania do Google Trends hasła event storming i zobaczenia jaką wyspą jest nasz piękny kraj.
Szymon Warda: Ciekawe dzięki komu.
Mariusz Gil Jeżeli mogłem do tego dołożyć tam swoje trzy grosze to jest super. Ale faktycznie tutaj w Polsce przyjęło się to bardzo, bardzo mocno. A dlaczego? Bo myślę, że ta technika tak naprawdę, ona ma bardzo niski próg wejścia i przy okazji można ją połączyć z innymi narzędziami. Jak tak popatrzę na moje warsztaty, na moje spotkania takie właśnie event stormingowe, to tam takiego czystego event stormingu to już dawno nie było, bo tą technikę bardzo łatwo jest obudować innymi narzędziami. Czy to jest DDD, czy to jest jakiś tam example mapping, czy są jakieś inne techniki wspomagające takie metody warsztatowe, to to się naprawdę świetnie połączy. A że przy okazji właśnie ten próg wejścia takiego warsztatu jest bardzo niski, bo jedyne co trzeba na początku zrozumieć, to jest w jaki sposób i o jakich zdarzeniach jest warto porozmawiać w projekcie, to tak naprawdę jest to świetny punkt startowy do wielu tematów. A że przy okazji, tak jak wspomniałem, że ten punkt startowy jest relatywnie nisko zawieszony, to łatwo wskoczyć i to każdemu. Nieważne, czy ktoś jest powiedzmy architektem, programistą, czy też w ogóle z IT nie ma nic wspólnego, bo jest przykładowo tym mitycznym ekspertem domenowym.
Szymon Warda: Ale tak praktyczniej, żeby trochę to uporządkować. Zrobiłeś pewnie najwięcej sesji w Polsce, jeżeli chodzi o sesję event stormingu. To teraz ułóżmy tak jak już chronologicznie. Ktoś Cię angażuje do facylitacji takiej sesji, czyli jak to wygląda od startu do końca, od spotkania, przez jego zakończenie, jakieś czynności wcześniej, jak to wygląda?
Mariusz Gil Właśnie, bo tutaj powiedzmy takie samo spotkanie, to wydaje mi się, że jest chyba w środku takiego procesu. Bo na początku to oczywiście warto zauważyć i sprawdzić, czy ta technika warsztatowa oparta o analizę zdarzeń jest właściwa dla danego problemu. Bo jakkolwiek pięknie to wygląda na konferencjach, to event storming nie jest żadnym silver bullet. Nie było i nie będzie w naszej branży techniki, która rozwiązuje każdy problem. Więc na początku staram się zazwyczaj porozmawiać i zobaczyć z jakimi problemami w danym projekcie się zderzamy. Bo jeżeli to jest np. faktycznie jakiś problem procesowy, który wymaga jakiegoś tam zamodelowania, no to jest duża szansa faktycznie, że ten event storming będzie tutaj właściwy. Jeżeli to, powiedzmy, zagadnieniem projektu jest, wiecie, przekładanie danych z punktu A do punktu B w dużych ilościach licząc w terabajtach, to można mieć tutaj wątpliwości. Więc to jest taki w ogóle pierwszy research gdzieś tam na początku, zanim się spotkamy. Jak już wiemy, że faktycznie ta technika mogłaby znaleźć zastosowania w takim warsztacie, no to trzeba się zastanowić, kto powinien wziąć udział w takim spotkaniu. Bo wiecie, gdzieś tam krąży taka historyczna opinia, gdzieś tam w internetach, że w tym spotkaniu powinni wziąć udział wszyscy, wszyscy zaangażowani w projekt. Tylko tak jak popatrzymy na to od strony stricte ekonomicznej, no to to spotkanie…
Szymon Warda: To wyjdzie drogo.
Mariusz Gil Tak, właśnie, to spotkanie się robi drogie. Jeżeli się to jeszcze przemnoży przez liczbę np. dni, bo często to nie jest jednodniowy warsztat, to się to robi jeszcze bardziej drogie. Więc tutaj trzebaby się zastanowić, kto powinien wziąć udział. Nie wiem, czy to będzie architekt, czy to będzie programista, czy to będzie właśnie osoba, która ma to know how, może tester, tak żeby ta rozmowa też była, dało się po prostu prowadzić, bo nie chcielibyście być w pokoju, gdzie rozmawia nagle 30 osób…
Łukasz Kałużny: Wiesz co Mariuszu, i teraz tak, bo rzuciłeś tester, architekt, programista, a często mówi się jeszcze, że event storming jest techniką, którą biznes rozumie. Jak z tym jest w Twojej praktyce i facylitacji takich sesji?
Mariusz Gil Powiedziałbym, że wiesz co, 95% osób nie ma problemów z identyfikowaniem zdarzeń takich, które właśnie pozwalają tą konwersację prowadzić. Te pozostałe 5% to są osoby, które są bardzo mocno przyklejone do interfejsu użytkownika i to są wtedy trudne warsztaty, bo zamiast opowiadać właśnie o procesach biznesowych, to mówimy o tym, że: a tu się coś wyświetliło, tutaj się coś kliknęło. I ta rozmowa, o ile ona jest oczywiście bardzo wartościowa w projekcie, to takich rzeczy architektonicznych do jakiegoś wyznaczania granic usług, kontekstów, itd., to nie jest do końca przydatne. W sensie trzeba tam faktycznie troszeczkę takiej pracy przyłożyć, żeby poodkrywać te rzeczy, które są znacznie, znacznie ważniejsze. Ale ogólnie jakbym miał tak popatrzeć na przekrój takich warsztatów, to dla większości osób, zdecydowanej nawet większości nie stanowi to większego problemu. Wystarczy, że wrzucicie pierwszy, drugi, trzeci, czwarty przykład i łatwo jest podążać za takimi przykładami łatwo jest też naśladować kogoś i w ten sposób, nawet nie znając techniki, zasadniczo być w samym centrum tego warsztatu.
Szymon Warda: OK, czyli zanim właściwie się zaczną sesje, tak naprawdę, warsztaty, to jest określenie, kogo w ogóle zapraszasz. Wiadomo, szeroki przekrój, ale minimalizujemy, żeby to nie był spęd? Dobra, potem dalej idziemy. Jakie sesje?
Mariusz Gil No właśnie, bo sama technika event stormingu oferuje trzy takie typowe poziomy, tzw. storming big picture, process level i design level czy też software design, bo to ma tam różne nazwy. I na tym ostatnim poziomie często jest najwięcej takich, powiedzmy, zagwozdek - co tam się właściwie dzieje? Bo tutaj też, jak tak popatrzy się na różne osoby, jest już nawet tak powiedzmy ze światowego IT, to też te warsztaty wyglądają czasami… No są jakieś różnice między nimi. Ale zanim jeszcze tutaj wrócimy, można przejść do tych poziomów, to też warto się zastanowić w jakim celu my w ogóle ten warsztat robimy. Bo z jednej strony, jak wspomniałem, możemy, powiedzmy, myśleć właśnie o podziale systemu na jakieś jego usługi, na jakiś tam bullet contexty, itd. A możemy chcieć np. taki, wiecie, taki warsztat zrobić w formule powiedzmy, retro. Chcemy tak na przykład przeanalizować jakiś proces, np. wytwarzania oprogramowania w naszym zespole i żeby zobaczyć, jakie tam usprawnienia można zaaplikować i ta formuła też się nada. Moglibyśmy sobie popatrzeć tylko powiedzmy od strony takiego user experience z naszych procesów i się okaże, że event storming też się nada.
Mariusz Gil Może nie każdy poziom, ale przynajmniej te pierwsze etapy tego stormingu big picture jak najbardziej będą miały zastosowanie. Jak ktoś gdzieś tam może w przeszłości czytał jeszcze nieskończoną książkę Alberto Brandoliniego, tu już od razu Szymon uśmiecha się, bo ta książka to już tam na tapecie wisi nieskończona już nawet nie wiem jak długo.
Szymon Warda: Ja ci mogę powiedzieć - 10 lat.
Łukasz Kałużny: Mariusz, to mamy jedno pytanie, miało być gdzieś dalej, czy wiesz kiedy Brandolini może, bo jako że masz corocznie się spotykacie jako praktycy event stormingu, czy napomniał coś o planach skończenia tej książki?
Mariusz Gil Też tego tematu nie poruszam z nim. Zawsze było to, jest to pewnie też temat niekomfortowy dla niego i jak ostatnio z nim rozmawiałem na ten temat gdzieś tam we Włoszech, to wspominał, że po pandemii tyle nowych wątków się otworzyło, które chciał przetestować gdzieś tam na spotkaniach z klientem, czy tam z klientami, że gdzieś tam to jest wstrzymane. Zresztą Alberto brał udział w napisaniu takiej książki o Domain-Driven Design, gdzieś tam we włoskim community, więc podejrzewam, że to też mu tam zajęło czas procesora i gdzieś ta książka na pubie gdzieś tam zeszła na drugi plan. Ale nie znam jeszcze jakiejś konkretnej daty. Zresztą wydaje mi się, że takie najistotniejsze rzeczy zostały w tej książce opisane. Brakuje chyba tych takich rozdziałów, na które czekają osoby, które ten storming robią już dłuższy czas, właśnie o takiej pogłębionej analizie, gdzieś tam o facylitacji, to tego gdzieś tam chyba brakuje jeszcze.
Szymon Warda: To ja będę tym, który naprowadza rozmowę na tory.Mówiliśmy o typach, jak z tymi typami wygląda, w sensie które warto, które nie warto, w jakiej kolejności i jak mniej więcej to wygląda?
Mariusz Gil Wszystko zależy od… Jak zwykle, w naszej branży to zależy. Ja też nie wszystkie te formaty warsztatowe mam potrzebę prowadzić, bo powiedzmy na takich tematach retro to to jest taka praca codzienna z zespołem i to świetnie się np. scrum masterzy w tym odnajdują. A jeżeli chodzi właśnie o takie warsztaty sfokusowane na analizę domeny i na wyznaczanie właśnie granic usług czy kontekstów z Domain-Driven Design, to faktycznie mi się to świetnie sprawdza. I właśnie w takiej formule warsztatowej najczęściej mam okazję przeprowadzać event storming i wtedy przez takie trzy poziomy faktycznie bardzo fajnie się przechodzi, to co wspomniałem, czyli big picture, process level i design level. I gdzie na każdym z tych poziomów tak naprawdę nasza uwaga jest zwrócona w delikatnie inne zagadnienia.I to jest ten moment, kiedy moglibyśmy przejść do tych poziomów, opisać to. Jeżeli ktoś wcześniej nie miał okazji się spotkać, bo na tym pierwszym poziomie, czyli na tym stormingu big picture, to naszym zadaniem jest tak naprawdę rzucenie oka na problem, z którym się zderzamy. Gdzieś tam się pojawiają pierwsze zdarzenia, zaczynamy je sobie układać na osi czasu, czy ta oś jest wirtualna czy taka papierowa to też zależy w jakiej formule się spotkaliśmy. Są oczywiście różnice między takimi warsztatami, ale powiedzmy, tutaj na potrzeby naszej rozmowy przyjmijmy mamy oś czasu i umieszczamy sobie te zdarzenia. I dookoła nich zaczynają się różne rzeczy, bo te zdarzenia z czegoś wynikają, ktoś je produkuje, nagle się ujawniają jakieś problemy, o których musimy porozmawiać. No i po chwili zazwyczaj, nie wiem, bo może po godzinie, dwóch, trzech gdzieś ten board zaczyna odzwierciedlać to, co się dzieje w tym procesie. Widzimy zdarzenia, możemy podejść, możemy pokazać paluchem: o, tu jest takie miejsce, o którym chciałem porozmawiać. I wtedy zazwyczaj jesteśmy gotowi do tego, żeby zacząć schodzić głębiej, bo już widać np. na tej osi czasu, które miejsca są na tyle, nie wiem, może problematyczne, może wymagające większej uwagi, że tam się warto zanurzyć tymi niższymi poziomami stormingu. I tam się zaczyna troszeczkę więcej magii, bo zaczyna się rozmowa o tym, z czego te zdarzenia wynikają. Bo można tutaj pokazać, że one często pochodzą od działań człowieka, mogą polegać na tym, że to system sam sobie zleca jakieś zadanie, bo coś w nim zaszło, itd.
Mariusz Gil Zaczyna się rozmowa o procesach biznesowych. I ten board zaczyna być wizualnie bardziej kolorowy. A dzieje się tak, ponieważ każdy element, który jest tam wprowadzany, ma jakąś taką swoją reprezentację graficzną. I na początku te wszystkie zdarzenia są, powiedzmy tak historycznie też pokazywane na pomarańczowych post it’ach, a dookoła tego pomarańczu zaczyna się powiedzmy inna kolorystyka. Przed eventem np. pokaże się niebieska komenda, która pokazuje jakąś intencję biznesową użytkownika, który korzysta z tego procesu. Gdzieś tam pokażą się jakieś polityki, które będą automatycznie reagowały na te zdarzenia i generowały kolejne komendy. I tak nagle zobaczymy, że w tym takim chaosie tych kartek z tego pierwszego etapu nagle ujawniają się jakieś konkretne takie linie przepływów biznesowych i tam można wyłuskiwać jakieś procesy biznesowe. Można zacząć wyłuskiwać granice subdomen zastanawiając się, że przykładowo dany ciąg zdarzeń może być wykonany z innego powodu, ma to jakąś wartość, itd. I z kolei taki etap kończymy właśnie z bardzo takim dokładnym, powiedzmy rozrysowaniem jednego, dwóch, dziesięciu procesów biznesowych. I że też czasami warto zauważyć, że tutaj wspomniałem, że w zależności od tego, kto ten warsztat wykonuje, to ten etap, w sensie ten artefakt końcowy może być inny.
Mariusz Gil Bo przykładowo tutaj w Polsce stosujemy pewne rozszerzenia stormingu. Nie pamiętam, chyba w 2018 roku, jeżeli pamięć mnie nie myli, prowadziłem na GitHubie awesome eventstorming, propozycję takiego elementu, jakieś reguły, który się gdzieś tam przyjął, bo też inne osoby gdzieś tam prawdopodobnie w tym samym czasie nad tym gdzieś tam pracowały. I to jest element, który uzupełnia tą notację stormingową, a pozwala dostrzegać jeszcze większą głębię w tych procesach biznesowych, którą potem można przełożyć na software. I z taką wiedzą o tych procesach biznesowych, o granicach, o tych przebiegach tych wszystkich ścieżek, o zasadach, którymi się to wszystko rządzi, wtedy można przejść do tego ostatniego etapu, czyli tak naprawdę projektowania jakiegoś już zadania takiego technicznego. Możemy już wtedy porozmawiać o jakiś już agregatach, możemy porozmawiać o jakichś modelach, które będą żyły gdzieś tam w tych naszych bullet contextach. I na końcu to wszystko trafi gdzieś tam prawdopodobnie do kodu. Ja zrobiłem taki bardzo szybki overview.
Łukasz Kałużny: Ale całość jak popatrzymy procesami, krótko to podsumowując, czyli lecimy sobie od ogółu do szczegółu implementacyjnego. Jeżeli popatrzymy na model całości naszego rozwiązania, czyli patrzymy jak to wygląda, potem jak wygląda proces, a potem jak wygląda implementacja tego procesu.
Mariusz Gil Tak, jak wygląda ten model, który możemy zaimplementować. Jeżeli ktoś, powiedzmy, wie, jak to można przełożyć tak naprawdę w kod, to bardzo często ten model, który jest taki wizualny, który pokazuje zasadę działania tego fragmentu oprogramowania jest wszystkim, co potrzebujemy, żeby implementować. Ja często tak lubię takie pytanie zadawać gdzieś tam pod koniec warsztatu zespołom, kiedy już mamy taki model właśnie wypracowany, to jak szacują trudność i złożoność implementacji w takiej skali od 1 do 5, gdzie jedynka to jest no brain, siadam i przepisuję to, bo jeszcze mogę z poprzednich etapów mieć przykładowo testy do tego takie biznesowe. A piątka to oznacza: wybaczcie, ale nie wiem o czym my rozmawiamy. I zaskakujące jest to, że tak w 95% średnio to jest, myślę, że półtora.
Łukasz Kałużny: A jeszcze jedno mi się narzuca, bo niektórzy podchodzą, że event storming daje mało sformalizowane artefakty na koniec i właśnie czy masz jakieś praktyki potem przeniesienia tego końcowego artefaktu, żeby był czytelny dla wszystkich, którzy nie uczestniczyli de facto w workshopach i dając to jakiś sposób przenieść na potem, żeby to nie była trochę wiedza plemienna ze zdjęciem takich boardów i grafów.
Mariusz Gil Bardzo trudne pytanie wrzucacie o te artefakty. Ale zanim to, to jeszcze komentarz do poprzedniego wątku, bo gdzieś mi to tam uciekło. Tak jak wspomniałeś Łukasz o przechodzeniu przez te poziomy, to tutaj dosyć ciekawe jest to, że można tu przerwać w dowolnym momencie i to będzie wartościowe. I to jak daleko chcemy zejść, to zależy od konkretnego przypadku. Bo czasem wartościowe w projekcie może być tylko zrobienie takiej sesji big picture. Dowiemy się czego nie wiemy i nagle się okaże, że to są takie blokery, że nie da rady pójść dalej po prostu, bo tej wiedzy brakuje. Czasami proces może być wystarczający, bo implementacja to dokładnie wiemy jak należy zrobić, bo to zrobiliśmy 10 tys. razy w tym projekcie. A czasami pomysł jest na tyle skomplikowany, że trzeba tamten ostatni poziom zrobić. Ale jeżeli mówimy o tych artefaktach, bo przykładowo bardzo częstym takim artefaktem z poziomu procesowego jest nie tyle sam przebieg, bo to oczywiście można tam jakieś zdjęcie zrobić, wrzucić na Confluence’a czy gdzieś innego Slacka, ale faktycznie bez takiego kontekstu tej rozmowy, która doprowadziła do tego, to może być bardzo trudne w odbiorze.
Mariusz Gil Więc przykładowo kiedy zależy mi na tym, żeby sobie udokumentowywać pewne rzeczy, to zazwyczaj sam ten board nie jest jakimś tam super szczególnym dokumentem. Bo gdybyśmy nawet mieli to zrobić ponownie, to zrobimy to szybciej, lepiej, dokładniej, itd. Ale jeżeli np. sobie z tego wyekstrahuję, powiedzmy, zarysy kryteriów akceptacyjnych do poszczególnych procesów, takich miejsc, które są problematyczne, albo wyekstrahuję sobie np. maszynę stanów przejścia tej maszyny, albo przykładowo sobie wyekstrahuję jakiś układ subdomen i ich zależności np. między dwoma kontekstami, to to jest coś, co faktycznie da się świetnie udokumentowywać, bo np. mamy tam jakieś standardy do tego. Nie wiem, mogę sięgnąć po Context Mappera, mogę sięgnąć po Specification by Example i taki artefakt będzie żył. Bo często widzę, że jest taka chęć: zostawmy tego boarda czy to na Miro czy w takiej wersji offline’owej, wrócimy do niego za pół roku. Życie mówi: nie, nie wrócimy do tego, niestety. Kiedyś nawet pamiętam, że robiliśmy takie eksperymenty z zespołami, jak zaczynałem się w ogóle zajmować tym tematem, że po takich warsztatach często właśnie te boardy zwijaliśmy, wkładaliśmy sobie na górę, na jakąś szafę na open space’ie i tak średnio po pół roku mniej więcej, po sześciu miesiącach z tej szafy bum do kubła, bo się zakurzyło, a nigdy do tego nie wróciliśmy.
Mariusz Gil Ale nawet jak trzeba było do tego wrócić, to się okazywało, że praktycznie szybciej i wygodniej było odtworzyć dany fragment, bo też się dużo pozmieniało, a nikt nie będzie tracił czasu na utrzymywanie wiecie kompatybilności wstecznej tego modelu. Zresztą nawet jeżeli ktoś bierze takie repo na GitHubie awesome eventstorming, tam są takie dwa timelapse’y nagrane, one pochodzą z prawdziwych projektów, tylko są zeskalowane, żeby nie było widać zdarzeń. Jeden z tych timelapse’u pokazuje właśnie taką sesję, gdzie została odtworzona na początku w przeciągu dosłownie może 15 minut taki setup elementu takiego miejsca w procesie, o którym musieliśmy porozmawiać. To była taka akcja, gdzie użytkownik wykonywał jedno kliknięcie, a tam ze 150 eventów powstawało. I okazało się, że cała sesja trwała półtorej godziny, z czego w sumie pierwsze 10 minut to było odtworzenie tego modelu. Jakby wygodniej było tak zrobić niż wracać do artefaktu tam z kiedyś.
Łukasz Kałużny: Dlatego się zapytałem, bo właśnie jest takie w podejściach ludzi, że diagram wystarczy i to będzie tym, że obraz jest wart tysiąca słów.
Mariusz Gil No bez kontekstu, bez komentarza to czasami tutaj bym już nie był taki pewny. Ale mogę Wam powiedzieć co robiliśmy niedawno w projekcie po takich warsztatach. Sięgaliśmy sobie np. po jakieś inne takie dokumenty czy też takie matryce spisywania dokumentacji i sobie uzupełniliśmy te dokumenty na podstawie tej wiedzy, którą pozyskaliśmy stormingami. Czyli np. nie wiem, jeżeli tam był powiedzmy jakiś schemat do kontekstów, to uzupełnialiśmy go sobie informacjami, które zdobyliśmy w takich warsztatach. No i to już jest taka dokumentacja, może nie taka też znowu super formalna, ale nie jest taka trudna w odbiorze jak taki board bez komentarzy.
Szymon Warda: Okej, ale to tak w sumie trochę ruszyłeś taki temat trzymania tych wszystkich danych, ale też temat obok. Bo kiedyś, jak siedzieliśmy na warsztatach, to twierdziłeś, że robienie event stormingu online, w sensie z nie wszystkimi osobami obecnymi po prostu w miejscu, nie ma żadnego sensu. Więc w takim razie jak się to podejście w ogóle zmieniło, czy to dalej ma sens, czy jednak COVID sporo pozmieniał i jednak umiemy, nauczyliśmy się robić te rzeczy online tak naprawdę.
Mariusz Gil Myślę, że te wszystkie właśnie tweety i te komentarze online’owe w stormingu to się bardzo źle zestarzało w ostatnich kilku latach. Pandemia dosyć dużo zmieniła. Powiedziałbym, że nawet bardzo dużo i na plus i na minus. Na plus należy tutaj oczywiście zaliczyć to, że nagle uzyskaliśmy dostęp do osób, do których wcześniej tego dostępu nie mieliśmy. Dzisiaj nie jest problemem wiecie zorganizować spotkanie z klientem na drugiej stronie globu, bo to jest po prostu już praktycznie w DNA każdej firmy, możemy się spotkać. Kwestia tylko narzędzi i przeprowadzenie takiego warsztatu. Jeżeli miałbym wybierać pomiędzy takim warsztatem online’owym, offline’owym, to bym jeszcze się tylko dopytał jaki jest kontekst tego warsztatu. Bo jeżeli to jest takie jednorazowe, że musimy coś przeanalizować i nawet nie wiadomo gdzie dojdziemy, to pewnie wygodnie dalej byłoby się spotkać w offlinie, żeby móc sobie chwilę porozmawiać. Jeżeli to byłaby powiedzmy taka sesja cykliczna, gdzie możemy do tego tematu wrócić i możemy sobie też to rozciągnąć na kilka dni, bo tu z kolei wiecie, trudno jest wysiedzieć przy komputerze 8 godzin non stop w skupieniu, to można to spokojnie rozciągnąć.
Mariusz Gil Powiem Wam, że jak pandemia wybuchła, to ja w ogóle przestałem robić stormingi, bo nie znałem sposobu jak to można zrobić w onlinie. No i tak chyba z 3 czy 4 miesiące gdzieś tam mi wyciekło z życiorysu takiego publicznego, a w tym czasie gdzieś tam w gronie kilku osób z Dolnego Śląska spotykaliśmy się właśnie na takich online’owych spotkaniach i zastanawialiśmy się, ćwiczyliśmy sobie jak można taką formułę w ogóle przenieść gdzieś tam do internetu. No i po kilku miesiącach wydaje mi się, że znalazłem jakiś taki sposób, na tyle angażujący dla uczestników, że pandemia to potem przeleciała mi bardzo, bardzo szybko. Aczkolwiek temat narzędzi tutaj jest nagle dosyć istotny. Bo przykładowo takim jednym z checków, który do mojej takiej checklisty doszedł przed takim warsztatem, jest pytanie, czy dane, które np. powstaną w takim warsztacie, bo gdzieś tam te zapisy tego boarda przekładają się na koniec na jakieś rekordy w bazie danych, tutaj pękła wirtualna karteczka, ale tam w bazie, come on, jakiś insercik update’cik, to się na końcu pojawi, czy te dane mogą być w Unii Europejskiej.
Mariusz Gil Bo nagle się czasami okazuje, że z powodu jakichś wymogów korporacyjnych nie. No i nagle takie popularne narzędzia, które gdzieś tutaj, nie wiem czy chcemy nazwami rzucać, ale odpadają.
Szymon Warda: Rzucajmy, jak najbardziej, zawsze się przydadzą.
Mariusz Gil Tutaj chodziło mi o Miro. Miro ma gdzieś tam serwery zlokalizowane zadaje się w Stanach Zjednoczonych i jeżeli ktoś korzysta powiedzmy, czy chce przeprowadzić taki warsztat w organizacji, która ma wymóg posiadania danych w Unii Europejskiej, to niestety z tej aplikacji nie może korzystać. Kiedy się dowiedziałem na godzinę przed warsztatem, że niestety to narzędzie odpada, na szczęście miałem przygotowany setup na drugim narzędziu, na Muralu, który ma akurat serwery, może mieć serwery w Unii Europejskiej i nie było to problemem. Ale wiecie, tak jakby ktoś mi nagle pół ręki zabrał jeżeli chodzi o ergonomię używania tego systemu, bo Miro jest dla mnie takim moim narzędziem pierwszego wyboru.
Szymon Warda: Faktycznie jest fajny.
Łukasz Kałużny: Miro, tak. Przy czym to tak dla wszystkich słuchaczy, jeżeli chodzi o Miro, to dla płacących pozwalają już wybrać rezydencję danych, tylko że niestety jest to per całe konto.
Mariusz Gil To widzisz, a ja korzystam z tej wersji płatnej już długo i jeszcze tego nie znalazłem. W sensie nigdy tego nie dostałem jeszcze od nich.
Łukasz Kałużny: Tak, gdzieś to było by request, czy w którymś miejscu to się wybierało. Teraz Ci nie powiem w którym, ale jest taka funkcjonalność.
Mariusz Gil Ale powiem Wam szczerze, że byłem pod wrażeniem jak mocno Miro się zmieniało w czasie pandemii, bo praktycznie co warsztat, jak się logowałem, to tylko było popup i zobaczcie co mamy nowego, zobaczcie co mamy nowego. W tym momencie stwierdziłem, że tam chyba jakieś błędy są tej aplikacji, bo coś mi cookiesy nie działają dobrze, ale faktycznie z taką szybkością się zmieniali. Ale też pokazuje fajnie jak software development może nadążać za zmieniającym się światem.
Łukasz Kałużny: Słuchaj, a przy tym remote’cie jakieś takie Twoje rzeczy, którymi możesz się podzielić przy takiej facylitacji, które… Albo jedną rzeczą, którą uważasz, że jest takim must have poza stosem narzędziowym w tym wypadku?
Mariusz Gil Jeżeli miałbym wybierać jedną rzecz, to bym powiedział, że chyba umiejętność podzielenia tego spotkania na potoki. Bo w momencie kiedy byśmy się spotkali w 12 osób w jednym pomieszczeniu, znam tą liczbę, bo to często jest taka liczba u mnie osób na warsztacie, to w onlinie to działa tak jak my tu teraz rozmawiamy, jedna osoba mówi i pozostałe muszą słuchać. Co tak naprawdę gwałtownie zmniejsza liczbę tych potoków komunikacji. Jeżeli byśmy chcieli, żeby to spotkanie był efektywne i wartościowe, a tematów do przedyskutowania jest dużo, to musimy właśnie zadbać o to, żeby tych ścieżek komunikacji było dużo, jakoś dzielić się na grupy, analizować różne fragmenty, scalać się. To jest często wyzwanie, żeby właśnie sobie przeprowadzić ten warsztat. Bo czasami możemy jedną grupą rozmawiać na temat, powiedzmy, dosyć złożony wszyscy, bo też wszyscy potrzebujemy tej wiedzy. A w rzeczywistości są takie warsztaty, gdzie można się podzielić na podgrupy, co wtedy bardzo mocno podnosi, powiedzmy, poprzeczkę dla osoby prowadzącej, bo zamiast ogarnąć jedną grupę, to musi jednocześnie ogarniać trzy grupy. Tak podam dla kontrastu, że jeden z większych warsztatów, które miałem okazję współprowadzić w pandemii, gdzie mieliśmy na spotkaniu 30 osób, bo to była duża organizacja, to trzeba było dotknąć przekrojowo bardzo takiego trudnego problemu, to na tym spotkaniu było sześciu facylitatorów, łącznie ze mną. I ten wysiłek kosztowo-organizacyjny spłacił się z nawiązką i to jeszcze z drugą nawiązką i trzecią nawiązką, bo odkryto takie rzeczy, których wcześniej ktoś nie widział.
Szymon Warda: To właśnie jest siła event stormingu, że faktycznie ciekawe rzeczy wychodzą.
Łukasz Kałużny: Ja sam mam historię, gdzie oszczędziliśmy sobie latania do 50 tys. urządzeń, bo się grupy wreszcie dogadały.
Mariusz Gil Takich historii to myślę, że każdy ma gdzieś tam na pęczki. Jednym z takich moich ciekawszych osiągnięć było to, że w ciągu jednego dnia wypracowaliśmy w projekcie oszczędność na poziomie miliona złotych. Wystarczyło jedną rzecz tylko w procesie pozmieniać, której wcześniej z jakiegoś powodu ktoś nie widział. Wystarczyło mieć, zobaczyć na ścianie, chwilę porozmawiać i wszyscy na końcu byli zadowoleni.
Łukasz Kałużny: Dobra, słuchaj, bo tak sobie rozmawiamy i dotknąłeś jednego takiego ciekawego kontekstu, że zaproponowałeś wprowadzenie nowego elementu w event stormingu, który gdzieś się przyjął. I ogólnie cały wpis, cały event storming ma już 10 lat praktycznie, bo to 2013 rok bodajże początek tego. I słuchaj, gdybyś mógł nam powiedzieć jak to w czasie ewoluowało, co się zmieniło w event stormingu od tego czasu? W jaką stronę to poszło?
Mariusz Gil Ta formuła, którą tam opisał Alberto w książce, ja bym powiedział, że ona się nie zmieniła. To zasadniczo kod tego narzędzia tworzą te same elementy. To co się natomiast zmieniło, to też powiedzmy możliwości zaaplikowania tej formuły i różne warianty tej receptury. No bo tak fajnie też jest postrzegać właśnie event storming, że to jest taka receptura na pizzę, taka bazowa, ale jeżeli coś ci w tej pizzy nie pasuje, to możesz sobie tego przysłowiowego ananasa położyć. I kilka takich właśnie rozszerzeń w postaci jakieś tam reguły, alertu, metryki to gdzieś tam na przestrzeni miesięcy czy tam lat, na samym początku gdzieś tam wprowadzaliśmy. Natomiast to, co teraz widzę, zwłaszcza u Alberto Brandoliniego, to jest taka chęć właśnie eksploracji rzeczy dookoła, gdzie tą technikę jeszcze można zaaplikować. I to jak ktoś tam go uważnie śledzi, to takie hasło jak Rivers Road Mapping czy też Model Storming, to są takie może próby uogólnienia tej formuły warsztatowej, które może zahaczają też o wprowadzanie innych elementów, ale zasadniczo wszystko znowu ma gdzieś tam początek w tych zdarzeniach.
Mariusz Gil Więc powiedziałbym może, że sama technika może za bardzo się nie zmieniła, ale pojawiły się jakieś specyficzne formaty i zaaplikowania. Chciałbym odesłać do książki, ale w tym momencie dobrze, że Alberto nie będzie mógł posłuchać tego odcinka, bo by mi kiedyś dojechał, chyba że mu ktoś doniesie.
Łukasz Kałużny: Dzięki AI-owi przetłumaczymy go na włoski.
Szymon Warda: Zobaczymy, zobaczymy.
Łukasz Kałużny: Czyli mówisz, że kierujemy się w tym, że po prostu gdzie indziej ta technika, jest próba jej aplikacji. A są jakieś rzeczy, które się nie sprawdziły w całości z tego pierwotnego konceptu?
Mariusz Gil Nie wiem czy nie sprawdziły, tylko że może często nie mają zastosowania, tak bym powiedział. A jednocześnie, jeżeli ktoś to stosuje, tak powiedzmy by the book, to czasami się może sparzyć. Bo jeżeli tak się weźmie tą oryginalną recepturę, zwłaszcza na tym poziomie stormingu big picture i zobaczy, że tam właśnie mamy te kroki typu chaotyczna eksploracja, układanie timeline’u, narracja wsteczna, itd., to jest tam taki krok, który sprowadza się do tego, że mapujemy wartości, przypływy wartości pieniężnych, finansowych, niematerialnych, jak one w tym procesie się zmieniają. I taki krok jest opisany w książce i gdzieś tam jest proponowany w tej formule warsztatowej. Ja go kiedyś dosyć często wykonywałem, a od chyba dwóch lat, nawet nie pytam, kiedy ostatni raz po to sięgałem, bo to są niektóre z tych powiedzmy etapów tego warsztatu. One chyba mają takie specyficzne uwarunkowania, że to musi być konkretna grupa osób, żeby o tym móc porozmawiać, konkretne jakby miejsce w projekcie. Wyobraźcie sobie coś takiego, że spotykamy się w gronie osób technicznych, mapujemy sobie taki proces bez eksperta, bo załóżmy, stwierdziliśmy taki wariant chcemy wykonać, mapujemy sobie przypływy wartości materialnych, niematerialnych i przechodzimy do kolejnego etapu, czyli mapowania jakichś takich usprawnień. Jakbyśmy ten podzespół usprawniali?
Mariusz Gil I mamy masę fajnych pomysłów, takich biznesowych, jak ten proces możemy sprawić, że będzie jeszcze lepszy, jeszcze wydajniejszy, jeszcze więcej pieniędzy przyniesie itd. Poświęciliśmy na to pół dnia. Idziemy do naszych kolegów i koleżanek z biznesu i mówimy jakie fajne pomysły mamy. I nagle się odbijamy od nich jak od muru z komentarzem: nikt Was o to nie prosił, na to nie ma czasu. I wiecie, efekt jest odwrotny od oczekiwanego. Bo miało być pięknie, a nagle zostaliśmy sprowadzeni do szarej codzienności backloga. Nagle musimy zrobić pewne rzeczy w projekcie i o tych usprawnieniach, o których sobie rozmawialiśmy i o tej wizji, którą każdy być może miał w głowie, to należy zapomnieć, przynajmniej np. na pół roku.
Szymon Warda: Wydaje mi się, że dotknąłeś jednej fajnej części eventstormingu. To jest to, że nagle biznes i wszyscy techniczni, wszyscy nagle czują się zaangażowani i tacy empowered, że tak powiem ładnie po angielsku, że właśnie oni nagle zaangażują się i chcą coś zmienić. I to jest też taka chęć, że nagle ci ludzie, którzy stali w różnych grupach, za różnymi granicami, nagle są w jednej całości, nagle jest chęć zmiany. W tym przypadku, który opisałeś jest tak, że nagle idziemy do wniosków i mówimy: jesteśmy mądrzejsi, zamiast prostu zrobić storming z nimi. Więc to, co gdzieś tam wspomniałeś, że odpowiednia grupa jest kluczowa. Jest kluczowa faktycznie.
Mariusz Gil Więc Łukaszu, odpowiadając na to pytanie tak, bo to bym wskazał, że czasami niektóre etapy powinniśmy po prostu dobierać do danego problemu, danej sytuacji z tej receptury, a nie wykonywać jak to niestety bardzo często ma miejsce, by the book, bez patrzenia na kontekst. Bo mi się też np. czasami zdarza przez ten big picture przelecieć bardzo szybko, bo wiem, że w danym problemie to te niższe poziomy będą znacznie bardziej wartościowe. A gdyby ktoś tak jechał, tak jak wspomniałem, zgodnie z tą recepturą, to poświęci kupę czasu i uwagi na te pierwsze etapy i być może przepali czas. Więc trzeba tutaj umieć to dobierać. I to chyba się tak pozmieniało dosyć mocno, przynajmniej dla mnie.
Szymon Warda: Jak często do których etapu dochodzi? Bo zaczynasz od… Wiadomo, ale tak mniej więcej procentowo, jak często schodzisz na jeszcze niższy, jeszcze niższy etap?
Mariusz Gil Obecnie niemal zawsze, ale niedawno jeszcze miałem… Niedawno, przed pandemią, tak to ujmijmy, zauważyłem, że praktycznie przez dwa lata to rzadko kiedy robiłem te warsztaty procesowe, bo sam big picture był na tyle wartościowy dla zespołu, że nawet nie trzeba było iść dalej, bo większość problemów została rozwiązana, a teraz jest odwrotnie. Ale to zależy, moim zdaniem, od specyfiki projektu. Projekty, w których ja uczestniczę obecnie, troszkę się zmieniły.
Szymon Warda: OK, dobra, a co dalej z event stormingiem? Gdzie będzie się rozwijał? W którym obszarze idzie? Bo trochę tego dotknąłeś, że Brandolini trochę kombinuje, myśli gdzie dalej to umieścić. Ale jakbyś mógł rozwinąć?
Mariusz Gil Gdzie idzie technika? Myślę, że sama technika jest już na tyle kompletna, w sensie ta taka powiedzmy standardowa receptura, że bardzo trudno jest tam coś zasadniczo nowego dodać. To, że tutaj, gdzieś tam w tym naszym polskim światku stosujemy jeszcze ten koncept tej reguły, co też jest tutaj dosyć czasami problematyczne do wytłumaczenia o jakie reguły chodzi, ale to jest jedyny element, którego chyba gdzieś tam brakowało. Może tak na siłę jeszcze też drugi element gdzieś tam się czasami pojawia właśnie w warsztatach Alberto. To jest element, który mapuje zespoły. Bo jak wspomniałem, że sama technika wydaje mi się na tyle kompletna, ale jej łączenie z innymi narzędziami daje czasami teraz fajne osiągnięcia. I teraz jak tak popatrzy się na ten światek, wiecie, w którym gdzieś tam się mam okazję obracać, czyli ten związany z Domain-Driven Design, to jest tam od dłuższego czasu taki bardzo widoczny trend łączenia, powiedzmy, tych konceptów zaproponowanych w Team Topologies. Czyli właśnie struktur zespołów mapowania, jakby relacji między nimi, żeby te granice zespołów dopasować tak naprawdę do granic kontekstów, itd. Więc często na takich warsztatach ostatnio wprowadza się element reprezentujący zespół, żeby zobaczyć, który z tych zespołów, które mamy w organizacji, działają na których częściach tego procesu i na których częściach rozwiązania.
Mariusz Gil I to bardzo fajnie pomaga właśnie przy modelowaniu i patrzeniu, czy te granice się pokrywają. No bo sytuacja, w której wiecie, istnieje jakiś model pojmowania, jakieś tam agregaty, jakieś tam relacje między nimi i nagle za połowę jakiegoś agregatu odpowiada jeden zespół, a za połowę drugą inny, bo to są rzeczy, które na koniec dnia kończą się po prostu konfliktami, wręcz, wiecie, requestami wzajemnymi, itd., blokowanie sobie wzajemnych realise’ów. Więc z punktu widzenia takiego punktu operacyjnego, to to ma dużo sensu, żeby zacząć też o tym rozmawiać. I tak jak wspomniałem, jakby nie jest to powiedzmy modyfikacja samej techniki, ale i łączenia z innymi, Team Topologies, Wardley Mapping, tego rodzaju rzeczy gdzieś tam się pojawiają. Tutaj jak ktoś byłby zainteresowany to zachęcam do tego, żeby zerknąć na tematy z zeszłorocznej konferencji Kanadyjskiej 2020 drugi rok. I to pokazuje jak to spektrum tematu dookoła, może nawet nie tylko event stormingu, ale DDD gdzieś tam wciąga inne tematy. No i tak naprawdę to fajnie się łączy wszystko na karteczkach.
Łukasz Kałużny: Mówisz trochę o tych rozszerzeniach. Mi się czasami trafiało, nie wiem czy to znasz czy nie, jeszcze pojęcie event modelingu, który miał być niby on top efektów event stormingu.
Mariusz Gil Zapuszczamy się w niebezpieczne odmęty rozmowy.
Mariusz Gil Wiem, bo to jest trudny temat. Dlaczego? Ja nie jestem przekonany do event modelingu? Ale disclaimer, bo ja jeszcze pamiętam, jak event modeling nazywał się single flow event storming gdzieś tam kilka lat temu. Z różnych powodów, tutaj nie wnikajmy, nastąpiło przemianowanie tej techniki. I o ile wydaje mi się, że event modeling pozwala łatwo prowadzić rozmowę, bo jeszcze narzuca kilka dodatkowych coinstraintów w postaci jednego flow, zmniejszenia liczby tych elementów, bo tam się zasadniczo posługuje trzema rodzajami - komendą, widokiem i eventem, to o tyle dla programisty czy też programistki, architekta i architektki, to wydaje mi się, że ta technika nie daje takiego całego spektrum możliwości i wiedzy. Ona świetnie, wydaje mi się, że może działać dla kogoś kto jest biznesowy, kto tylko ma zobaczyć jak działa flow. To też da się w samym czystym event stormingu pokazać by the way, ale nie dostarcza, przynajmniej mi, tej wiedzy takiej implementacyjnej. Od razu komentarz. Być może to wynika z tego, że też nie miałem okazji uczestniczyć w poprawnie poprowadzonej sesji event modelingu. Jakbyście się mnie zapytali za rok, za dwa, za trzy, kiedy takie doświadczenie, mam nadzieję, że gdzieś mnie kiedyś spotka, to może jakąś opinię będę miał inną. Na ten moment, tam jest za dużo magii.
Łukasz Kałużny: Zdaję sobie sprawę, znając tego historię, że jest to odłam, że tak powiem, który miał na celu pewnie komercjalizację kolejną narzędzi, ale byłem ciekaw Twojej opinii całości tej układanki.
Mariusz Gil Oczywiście, jeżeli to komuś pomaga, taka rozmowa, to why not? W sensie taka formuła. Wydaje mi się, że to jest, dla mnie to jest taki uproszczony process level event storming. Uproszczony, bo nie ma tego elementu, którego ja często stosuję, tej reguły i pewne rzeczy potem wymagają jakiegoś dodatkowego przedyskutowania. Ale to może też nie miałem jeszcze okazji uczestniczyć w takim prawdziwym warsztacie. W sumie tutaj może request do Waszej słuchaczy, jeżeli ktoś taki warsztat umie poprowadzić, to ja z przyjemnością kiedyś dołączę.
Łukasz Kałużny: Jako wizytator.
Mariusz Gil Nie, ale jako osoba autentycznie zainteresowana. Bo jakby ja też często staram się zobaczyć inne techniki, zobaczyć tak naprawdę gdzie one się uzupełniają, gdzie one są. Jedna ma jakąś przewagę nad drugą. Bo tak na koniec to chyba dla każdej osoby, która się zajmuje takimi rzeczami, to budowa takiego własnego toolboxa to jest po prostu must have. I nie mogę, nie można przyjść na warsztat z jednym narzędziem, bo się okaże, że problem kurczę jest troszkę inny i może inne narzędzie będzie lepsze.
Szymon Warda: Do tego tematu wrócę generalnie, żeby to ułożyć, bo poruszyłeś trochę temat odpowiadając co jest potem, jak się sesja kończy odnośnie przechowywania. Gdzie trzymać tą całą wartość?
Mariusz Gil Odpowiedź brzmi: w kuble. Jeżeli chodzi o te kartki.
Szymon Warda: Trochę tak, ale tak teraz mówisz właśnie o kolejnych technikach, które można do tego dopasować.To teraz mamy sesję, powiedzmy 2 dni zużyliśmy i w takim razie gdzieś dalej, w sensie jakieś do tego techniki dobudowywać, załóżmy jak np. UI itd.Które obszary, jak już mamy tych ludzi, możemy pokryć i gdzie dalej możemy rozwijać tą wiedzę, żeby pogłębić, itd?
Mariusz Gil Oczywiście, to taki przypadek wyciągnę z jednego z projektów, w którym miałem okazję uczestniczyć z mega naprawdę fantastycznym zespołem, gdzie po takim warsztacie kończyliśmy big picture, bo to było w zasadzie wystarczające. Następnego dnia do tego modelu podeszli UX designerzy. I oni patrząc na to, co się dzieje w tym procesie, bo też uczestniczyli w tym warsztacie, zaczęli ten model uzupełniać tak naprawdę o wireframe’y. W tym miejscu potrzebujemy takiej masy graficznej, tutaj takiej, tutaj muszą być takie informacje. Zespół sobie zaczynał wyciągać informacje, skąd możemy to szybko pozyskać, jak te informacje można przemielić. I ten board zaczął się rozbudowywać o takie kwestie wizualne. Po kilku dniach te wireframe’y zostały zmienione na wizualizację, jak to będzie naprawdę wyglądało. Zaczęły podchodzić do tego modelu osoby, które nie uczestniczyły w warsztacie. Zaczęli to zmieniać, zaczęli komentować, że czegoś nie rozumieją. I tak step by step ten model zaczynał gdzieś tam sobie żyć.A na końcu jeszcze przyciągnęliśmy pod ten model do tego conference roomu, w salce konferencyjnej było, przyciągnęliśmy laptopy i zaczęliśmy sobie przepisywać zarysy testów akceptacyjnych po prostu do unit testów, do kodu i zaczęliśmy przepisywać te rzeczy.
Mariusz Gil Jakaś maszyna stanu, która gdzieś tam była narysowana, gdzieś tam na jakieś kartce, na jakiejś notatce, bo bardzo często ten model dla mnie jest taki adnotowany, tam jest masa informacji, nie tylko w tych eventach, tylko w postaci po prostu notatek. Zresztą znowu zachęcam do tego event storming, zobaczenia jak dużo takich właśnie karteczek adnotacyjnych z jakimiś definicjami, z jakimiś komentarzami może na takim modelu wylądować. I zaczęliśmy to przepisywać w kod i zaczęliśmy tworzyć tak naprawdę rozwiązanie. Więc jakby rzeczy, które się mogą wydarzyć, w zależności od etapu projektu, w tej samej organizacji, po innym warsztacie, gdzie z biznesem sobie rozpracowaliśmy pewien model i zgodziliśmy się, że ten problem może być tak rozwiązany i to będzie dla interesariuszy biznesowych całkowicie akceptowalne, to następnego dnia się wydarzyła sesja mob programmingu, gdzie pod tą kartkę na ścianie przyciągnęliśmy wielgachny telewizor na kółkach, jedną klawiaturę i w 5 osób po 10 minut wymienialiśmy się klawiaturą i przepisaliśmy wszystko do kodu i stworzyliśmy działającą aplikację. Oczywiście bez UI-a, mówię o tych rzeczach powiedzmy tych biznesowych pod spodem i to był ten następny krok. Ale tutaj jak mówię, zależy też od tego, na jakim etapie jest projekt i co tak naprawdę trzeba zrobić.
Mariusz Gil Czy mamy greenfielda, czy mamy, wiecie, legacy. Tutaj jak zwykle, it depends.
Szymon Warda: Będziemy chyba powoli się zbierali do końca. Też takie pytanie porządkujące, jakieś tips and trick, narzędzia? Co byś polecał jako takie rzeczy oczywiste, jako rzeczy konieczne z doświadczenia, które warto wiedzieć, warto ruszyć zanim się sesję zrobi, albo żeby swoje sesje poprawić?
Mariusz Gil A to bym polecił taką chyba event stormingową katę. Znależć sobie taki własny temat, który można przeanalizować jako powiedzmy z jednym, drugim, trzecim zespołem i go faktycznie zrealizować z jednym, drugim, trzecim zespołem. Bo to pozwoli szlifować warsztat. Będzie można zobaczyć ten sam problem z różnymi zespołami, z różnymi typami osobowości, z różnymi wiecie sytuacjami go zderzyć w życiu. I gwarantuję, że za każdym razem w tym problemie biznesowym dostrzeże się coś głębiej. Jak to zwykle przy katach. Jeżeli ktoś mnie tam gdzieś dosyć mocno śledzi, to kojarzy, że ja tam sobie paczkomaty tak upatrzyłem. To jest naprawdę świetny problem. Wydaje mi się, że obecnie jestem już sprowadzić 95% problemów z dowolnego projektu do problemów, które występują w paczkomatach i tak [niesłyszalne 00:35:12]. A jak się ten problem rozbierze na czynniki pierwsze to naprawdę fantastyczne rzeczy tam wychodzą. I to jest sposób, w jaki można by fajnie budować sobie kompetencje - zrobić coś, co można powtarzać raz, drugi, trzeci, dziesiąty i w ten sposób wzmacniać swoje doświadczenie. Bo to też pozwoli potem te doświadczenia porównywać, zderzać różne sytuacje i uzyskiwać jakby widok na tą głębie, która tam jest.
Mariusz Gil To tak na chwilę odskoczę do innego wątku. Ale kiedyś miałem okazję poprowadzić pewne dużej korporacji cykl szkoleń ze wzorców projektowych. I tak na początku zastanawiałem się: okej, to jakby to szkolenie będzie wartościowe dla uczestników, ale pytanie jak ja mogę zrobić, żeby to było też wartościowe dla mnie? Wiecie, 10 razy opowiedzieć o wzorcu strategii, co tam może być ciekawego? I po trzech takich iteracjach nagle zobaczyłem: kurczę, ja na te problemy nigdy nie patrzyłem z tej perspektywy. I kolejne warsztaty, mam nadzieję, że były jeszcze lepsze. Więc to byłby chyba taki trick, do którego bym zachęcał - znaleźć sobie ludzi, z którymi można to zrobić. Ale to wiecie, co jest czasem takie dla mnie też niezrozumiałe, że ktoś mówi: kurczę, no ja nie mam kogoś, z kim mogę sobie taki warsztat przeprowadzić. Nie, po prostu się nie postarałeś. Napisz na Twitterze, że chcesz zrobić sobie taki warsztat i zobacz, ile osób do Ciebie się odezwie, żeby w czymś takim uczestniczyć. Wydaje mi się, że taki effort, takie minimalne, powiedzmy, włożenie wysiłku niesamowicie się opłaci.
Szymon Warda: Dobra, to teraz w takim razie skoro ruszyłeś temat właśnie kat, ruszyłeś temat jak rozwijać swój warsztat, to tak naprawdę pytanie kolejne - gdzie uczyć się w ogóle event stormingu? Jak uczyć się event stormingu?
Mariusz Gil Chciałbym odesłać do książki, ale…
Łukasz Kałużny: Ale ją też podlinkujemy.
Mariusz Gil Jak najbardziej. Wiecie, to już jakby taki branżowy dowcip się zrobił z tej książki, abstrahując od tego, że jest tam naprawdę bardzo fajna wiedza. Ale wydaje mi się, że takim najlepszym sposobem nauczenia się event stormingu jest learning by do it. Przykładowo, jeżeli ja prowadzę jakieś szkolenia z eventstormingu, ja nie posiadam żadnej prezentacji. To nie jest miejsce na takim warsztacie, gdzie można sobie oglądać jakieś slajdy i się nauczyć tego, wiecie, z prezentacji. Wziąć do ręki czy to myszkę, żeby postawić tego wirtualnego post ita, czy po prostu marker i jakiś bloczek tych karteczek i po prostu to zrobić. Jeżeli za pierwszym razem nie wyjdzie, kurcze, nic się złego nie stanie, po prostu będę miał drugie podejście, trzecie podejście, czwarte podejście. Taki learning by doing. Da się tego nauczyć. Wydaje mi się, że wiecie, po pandemii troszeczkę wracają znowu grupy Domain-Driven Design w Krakowie, w Warszawie, na Śląsku, mam nadzieję, że w końcu się Silesia rozkręci. Trójmiasto, Wrocław się tutaj znowu gdzieś tam aktywizuje. I na tych grupach też często są właśnie meet up’y, w których często się pojawia event storming. I wystarczy tylko tam gdzieś śledzić, nie wiem czy na Meetupie, czy na Facebooku, czy gdzieś na Twitterze informacje, że takie coś jest.
Mariusz Gil Pójść, zobaczyć, a potem spróbować samemu to zrobić. To jest chyba takie najlepsze miejsce. Bo jeżeli ktoś tego nigdy nie widział, nie uczestniczył, to zrobienie tego samemu: okay, to będzie trudne, po prostu będzie trudne. Ale pójść do kogoś na taki otwarty warsztat, żeby sobie zobaczyć i móc coś przeanalizować, zobaczyć, czy to jest dla mnie i czy mi to pomoże w projekcie, to chyba byłby taki pierwszy krok, który można zrobić. Bo prezentacja prezentacją, gdzieś tam na YouTubie, itd. Ale takie doświadczenie, wiecie, z własnego życia, żeby doświadczyć tego jak to może pomóc, to jest coś, to zostaje niezatarte w pamięci. My tak sobie rozmawiamy, przynajmniej Wy jesteście tutaj, u siebie, każdy z nas w tym jest u siebie dzisiaj, bo nagrywamy zdalnie. Ja tak kątem oka patrzę, mam tutaj oprawioną w antyramie, nie będę teraz tego przynosił, ale musicie mi na słowo uwierzyć, mam oprawiony w antyramie ten taki picture, który powstał, już nawet nie wiem ile lat temu na warsztacie, w którym ja uczestniczyłem u Alberto Brandoliniego i to był moment, gdzie ja poszedłem tam po to, żeby pozyskać wiedzę o DDD, a event storming mi to w sumie jak tam coś zobaczę to będzie super. Ale w czasie tego warsztatu miałem taki moment, że czułem jak mi się neurony inaczej kleją w głowie. I to było takie doświadczenie, że jak ja teraz o tym opowiadam, to ja mam teraz ciarki i słowo daję. I po tym warsztacie, jak doświadczyłem tego ‘AHA’ momentu, że mi się pokleiły powiedzmy kropki i zacząłem rozumieć, że ja mogę kurczę na software patrzeć z zupełnie innej strony, że zanim siądę do klawiatury, to ja mogę mieć wszystko przepracowane i nawet w takim, wiecie, głupim modelu karteczkowym wszystko udowodnione. To po tym warsztacie pamiętam, że podszedłem do Alberto i mówię, wziąłem tego flipcharta, gdzie jest ten rysunek i mówię: Alberto, jakbyś mógł mi to podpisać to ja bym chętnie tą kartkę zabrał, bo ona będzie wisieć u mnie w biurze. Po tylu latach ona dalej wisi, tylko że wszystkie te kolory wyblakły. Ale właśnie doświadczenie tego ‘AHA’ momentu, to będzie trudno zrobić, wiecie, oglądając prezentację, czytając książkę. Po prostu trzeba pójść i to zrobić.
Mariusz Gil I to jest taki mój action point dla słuchaczy - pójście do kogoś na jakiś otwarty warsztat i sami tego doświadczcie.
Szymon Warda: Trochę ruszyliśmy temat, który jest dość ważny, tak naprawdę, jak się przekonałem nawet osobiście. W takim razie z jakiej marki karteczek korzystasz?
Mariusz Gil To będzie kolejny dowcip branżowy. Był taki, że jak się storming pojawił, to wszyscy tam szli do Alberto z pytaniem - ile akcji 3M-a kupił, bo 3M jest chyba właścicielem marki Post It.
Szymon Warda: To naprawdę robi różnicę między kartkami 3M a cała reszta.
Mariusz Gil W takim codziennym tak, to potrafi zrobić różnicę. Ja pamiętam taki warsztat, bo obecnie się przesiadam z powrotem na te oryginalne post ity. Nie są tanie, ale mają czasami fajną cechę, że są takie po prostu grubsze i po prostu się wygodnie z nich korzysta. Nie taki aspekt stricte ekonomiczny. Ale pamiętam kiedyś, nie pamiętam czy to było w jakimś hotelu czy gdzieś, ale sięgnęliśmy też po takie karteczki, które były na miejscu i one się okazało, że miały bardzo słaby klej i nie wytrzymały nocy na tym naszym modelu papierowym na ścianie. I przychodzimy następnego dnia na kontynuację warsztatu, a tu połowa tych kartek leży na ziemi. Na szczęście spadły mniej więcej w takich okolicach, że wiedzieliśmy jak to odbudować następnego dnia przed warsztatem.
Szymon Warda: To taka pierdoła, ale potrafi warsztat bardzo rozwalić, jak nagle część ludzi skupia się na tym, żeby poprzyklejać karteczki i poprawiać. To jest nagle takie totalne rozkojarzenie.
Mariusz Gil Tak, to są takie, wiecie, rzeczy mocno mechaniczne, żeby tam gdzieś przyjść, faktycznie mieć tego nadmiar. A taka głupia rzecz jak: kurcze, nie przyniosłeś wystarczająco dużo karteczek ze sobą, nagle się okazuje, że to ci zabije sesję, bo nie jesteś w stanie kontynuować. Więc ja zazwyczaj gdzieś tam, jak przychodzę na taki warsztat, to mam tego naprawdę czasami kilka tysięcy w plecaku różnych kolorów, co ok, jest tam jakiś kilogram rzeczy do przyniesienia, ale lepiej mieć za dużo niż za mało. Kiedyś, pamiętam, że w Warszawie też musiałem biec w przerwie pomiędzy jakimiś tam etapami tej sesji uzupełniać zapasy, bo problem, z którym się zetknęliśmy, był naprawdę nietrywialny. Podam Wam takie dwa skrajne przypadki. Na jednej sesji okazało się, że cały problem, jakkolwiek on był skomplikowanie przedstawiany, to na koniec było 10 zdarzeń, autentycznie 10 zdarzeń, tylko po prostu ktoś dobudował do tego, wiecie, jakąś piękną teorię i za dużo mówił o interfejsie, a biznesowo tam faktycznie niewiele się działo w takim, powiedzmy, głębszym modelu. Ale na drugiej sesji, to stoi na biegunie drugim, 3,5 tys. eventów i każdy no sense.
Mariusz Gil Największa sesja, którą miałem okazję współprowadzić, zresztą właśnie z Alberto, 3,5 tys. eventów, 3 dni, 30 osób. Wyglądało, jakby wiecie, w hurtowni papierniczej coś eksplodowało i po prostu obkleiło ściany. Ale zaskakujące, że dużo osób było w stanie identyfikować w przeciągu dosłownie 10 sekund, gdzie jest dany event. Chcemy rozmawiać o tym? Dobra, tam.
Łukasz Kałużny: Spisanie brzmi tego potem przerażająco.
Mariusz Gil Na szczęście te nowoczesne narzędzia mają to Sticky Recognition, więc jeżeli ktoś tam chce przenosić, to dzisiaj ma troszeczkę robotę ułatwioną. Ale tak jak Szymon zapytałeś o te marki, ale to nie jest żaden product placement. Ale ja osobiście korzystam obecnie właśnie z trzech. To jest dla mnie taki zestaw kombo.
Szymon Warda: Popieram. Jest różnica i naprawdę warto.
Mariusz Gil Ale to jeszcze anegdotę wam tylko wrzucę, bo właśnie pamiętam, że kiedyś byłem w Warszawie i stwierdziłem: już jestem tutaj, jest taki duży sklep papierniczy. Obecnie już go nie ma, bo tam zaorali tą przestrzeń pod jakiś biurowiec ale był taki duży sklep papierniczy gdzieś tam w centrum i poszedłem się zaopatrzyć. No i faktycznie stwierdziłem: to jak już jestem, to wezmę sobie tam na kolejny jakiś tam czas. I wziąłem faktycznie sporo tego. Pani w kasie tak na mnie patrzy się i pyta: pan na rok tego kupuje? Ja: nie, nie, widzimy się za miesiąc. Bo faktycznie to są po prostu takie rzeczy, to są, wiecie, to są tylko po prostu materiały, które gdzieś tam będą schodziły. Jeżeli nie można tego zrobić online.
Szymon Warda: Dobrze, właśnie, wolisz robić obecnie online czy jednak offline?
Mariusz Gil Tutaj wspomniałem, że to jest taki problem, że naprawdę nie wiadomo gdzie zacząć. To chyba ten początek. Fajnie byłoby zrobić jednak face to face. Ale jakąś kontynuację, wydaje mi się, i to jeszcze w małym gronie, nie widzę już jakiegoś przeciwskazania, żeby to można było zrobić w onlinie. Teraz też jestem w projekcie, gdzie od kilku miesięcy spotykamy się tam raz czy dwa powiedzmy w tygodniu i sobie gdzieś tam kawałeczek tej domeny, bardzo skomplikowanej i olbrzymiej, gdzieś tam analizujemy i jakby online jest całkowicie wystarczający. Bo też tak trudno byłoby się tam, wiecie, gdzieś tam transportować na drugi koniec kraju, tam na 4 godziny co 2 tygodnie. I to jest ten aspekt, że to się nagle stało możliwe. Wcześniej jakieś inne podejścia do tego wszyscy mieliśmy.
Szymon Warda: Dobrze, to będziemy powoli zbierali się. To jeszcze pytanie do Ciebie takie - czy o coś jeszcze powinniśmy zapytać, o czymś jeszcze powinniśmy wiedzieć, coś jeszcze nam tu brakuje w tym odcinku?
Mariusz Gil I ja na koniec często takich warsztatów, takich typowo szkoleniowych, to staram się tylko pokazać jeszcze jedną rzecz. To nie jest technika, która rozwiązuje każdy problem. I też często właśnie zadaję takie pytanie uczestnikom takich warsztatów - to gdzie widzą, że to się nie sprawdzi? Bo uważam, że są obszary, w których to nie jest najlepsza technika. Przykładowo, jeżeli omawiamy jakiś algorytm obliczania jakichś tam rzeczy w systemie, jakiegoś rootowania przesyłek, itd., ale mówimy, z tych takich rzeczy algorytmicznych, to da się to pokazać zdarzeniami? Da się. Czy to będzie wartościowe? Może w jakimś stopniu. Czy to będzie dokładne? Nie sądzę. Może się okazać, że tak naprawdę wiecie, że sięgnięcie po schemat blokowy, mnie schematów blokowych nauczyli tam w pierwszej klasie liceum na pewnym przedmiocie, to to jest narzędzie znacznie skuteczniejsze i to jeszcze jest dokładne, itd. Żeby się zastanowić, każdemu tak sumie chciałbym to polecić, zastanowić się, gdzie ta technika nie ma racji bytu, żeby nie przepalać czasu. Bo nie ma nic, wiecie, chyba smutniejszego jak zakończenie takiej sesji I nagle ktoś zadaje pytanie: co my w sumie osiągnęliśmy?
Mariusz Gil Jeżeli odpowiedź brzmi: mamy piękny model na ścianie, który możemy wiecie, wrzucić na Instagrama czy tam na Tweetera, piękną fotę sesji, to chyba nie tędy droga. Musi być jakiś outcome, który tak naprawdę będzie do zastosowania w projekcie. A czasami tego outcome’u, jeżeli jest problem niedopasowany, to trudno go znaleźć.
Szymon Warda: Dobra, to jest fajne zakończenie generalnie, że nie można każdego problemu przez eventstorming rozwiązać. Fajnie, dobra, to chyba kończymy. Żegnamy się. Trzymajcie się. Dzięki Mariuszu.
Łukasz Kałużny: Na razie. Dzięki Mariusz.
Mariusz Gil Do usłyszenia. Trzymajcie się. Cześć!