Patrząc na ścianę pokrytą wieloma pomarańczowymi post-itami po intensywnej sesji Big Picture, łatwo ulec złudzeniu, że każde zdarzenie ma taką samą wagę. Nic bardziej mylnego. Występują bowiem momenty, które dla biznesu znaczą o wiele więcej niż tylko kolejne odhaczone zadanie na liście. To właśnie one nadają strukturę całej opowieści o systemie i to na nich powinniśmy skupić naszą uwagę w pierwszej kolejności.

Większość odkrytych eventów to po prostu logiczne następstwa poprzednich akcji – są niezbędne dla ciągłości procesu, ale same w sobie nie stanowią trzęsienia ziemi. Istnieje jednak specyficzna grupa zdarzeń, które drastycznie zmieniają kontekst, zamykają jeden rozdział biznesowej historii i otwierają kolejny, lub też stanowią punkt styku dla wielu niezależnych subdomen. W terminologii EventStormingu określamy je mianem Pivotal Events.

Wyłapanie różnicy między zwykłym zdarzeniem a Pivotal Eventem to jedna z cenniejszych umiejętności przy projektowaniu architektury. Te kluczowe zdarzenia to bowiem świetni kandydaci na granice naszych modułów i Bounded Contexts. Jeśli nauczysz się je poprawnie identyfikować, w chaotycznej chmury zdarzeń zobaczysz czytelną strukturę, która niemal sama podpowiada, jak podzielić system.

Czym są Pivotal Events?

Najprościej rzecz ujmując, Pivotal Event to kamień milowy w procesie biznesowym. Jeśli wyobrazimy sobie nasz system jako książkę, a zwykłe zdarzenia są kolejnymi zdaniami, to Pivotal Event jest kropką kończącą cały rozdział. To moment, w którym jedna faza procesu definitywnie się kończy i zaczyna się kolejna, często przekazując przy tym inicjatywę w procesie w zupełnie inne ręce.

Cechy charakterystyczne Pivotal Events

Zwykle Pivotal Events posiadają kilka cech, dzięki którym można je łatwo odróżnić od innych zdarzeń:

• Wysoka ranga biznesowa, to kluczowe fakty, które ze względu na swoją wagę trafiają do raportów zarządczych i interesują osoby spoza zespołu technicznego
• Krok milowy procesu, bez niego cały proces nie jest możliwy do wykonania, traci swój biznesowy sens
• Zmiana języka, od tego momentu wykorzystywane w procesie słownictwo wyraźnie się zmienia, pojawiają się nowe terminy, a niektóre przestają być używane
• Nieodwracalność lub trudna odwracalność skutków, wystąpienie tego zdarzenia jest wiążące, a jego ewentualne wycofanie nie jest operacją prostą, wymaga uruchomienia osobnej procedury kompensacyjnej
• Przekazanie odpowiedzialności, jest to wyraźny punkt styku, w którym inicjatywa oraz odpowiedzialność za dalsze losy procesu przechodzą z rąk jednego aktora do drugiego
• Zmiana fazy cyklu życia, to moment działający jak klamra, która definitywnie domyka jeden etap prac i oficjalnie otwiera kolejny rozdział w życiu procesu

Zdarzenia pivotalne nie muszą posiadać wszystkich tych cech. W końcu nie w każdym procesie dochodzi np. do przekazywania odpowiedzialności pomiędzy aktorami. W praktyce jednak Pivotal Events posiadają ich większość.

Pivotal Event vs normalne zdarzenie w praktyce

Wyobraź sobie początek przejazdu zamawianą taksówką. Można go opisać przykładowo w następujący sposób:

W tym procesie każde ze zdarzeń można łatwo odwrócić. Zmiana miejsca odbioru? Proszę bardzo, nawet w innym mieście. Zmiana klasy pojazdu? Nie ma problemu, przecież żaden kierowca po Ciebie jeszcze nie jedzie. Żadne z przedstawionych eventów nie jest też interesujące z perspektywy operacyjnej firmy, nie wpływa na jej finanse, zasoby czy inne aspekty związane z bieżącą działalnością. Co więcej, cały proces może być w dowolnym momencie porzucony, w zasadzie bez żadnych konsekwencji.

Sytuacja zmienia się jednak wraz ze zdarzeniem:

Zdarzenie Ride Requested uruchamia bowiem cały proces realizacji złożonego zamówienia, w ramach którego m.in. blokowane są środki na podpiętej karcie, czy wyszukiwany jest odpowiedni dla przyjazdu kierowca. Zmiana miejsca odbioru? Tak, ale tylko w niedużej odległości od pierwotnie wybranego, aby przypadkowo nie wysłać kierowcy na drugi koniec miasta. Rezygnacja z zamówionego przejazdu? Możliwe, ale trzeba jeszcze rozliczyć założone blokady środków, potrącając być może opłatę karną, nie zapominając też odwołaniu samego kierowcy, który być może właśnie dojeżdża pod wskazany adres.

Jak widać, zdarzenie zdarzeniu nierówne.

Odkrywanie Pivotal Events

W pewnym wymiarze EventStorming jest techniką zadawania właściwych pytań właściwym osobom. Warto mieć w swoim facylitacyjnym toolboksie kilka pytań wspomagających odkrywanie takich właśnie zdarzeń.

• Czy ktoś w innym dziale czeka na tę informację?
• Czy to zdarzenie zmienia nazwę tego, nad czym pracujemy?
• Czy ktoś to zobaczy w raporcie?
• Czy możemy się w tym miejscu cofnąć bez żadnych konsekwencji?

I moje ulubione pytanie, które często jest dobrym początkiem eksploracyjnej sesji Big Picture?

• Bez jakich 4-5 najważniejszych zdarzeń ten proces jest bezużyteczny?