W tym poście planuję Cię ustrzec przed trzeba błędami, w które prawie napewno możesz popaść prowadząc warsztat Event storming. Wiesz, jak to jest, ja się będę starał przedstawić tematy możliwie zrozumiale, ale to czy w wpadniesz w poniższe pułapki ostatecznie zależy od Ciebie :)
Systemami się myśli
Rozpracowywanie anatomii biznesu dla nowego projektu, gdy oprogramowanie jeszcze nie istnieje, to marzenie chyba każdego inżyniera. Idziemy wtedy krok po kroku i odkrywamy złożoność danej domeny.
Ja przeważnie pracuję z biznesami, w których już działają jakieś systemy informatyczne i należy dodać nowe funkcjonalności, usprawnić działanie procesu lub - jak w naszym przypadku - przepisać któryś z istniejących modułów.
Jeśli będziesz mieć do czynienia z podobnymi sytuacjami, to pamiętaj, że długotrwałe korzystanie z jakiegoś oprogramowania sprawia, że eksperci biznesowi zaczynają "myśleć systemem". Oprogramowanie, z którego korzystają w swojej pracy oraz sam proces biznesowy, w którym biorą dział stają się jednym i tym samym.
Gdy zapytasz tych osób, jakie fakty istnieją w procesie, będą mówić:
- Typ klienta wybrany,
- Raport wygenerowany,
- Zdjęcie wyświetlone,
- Dokument pobrany.
Powyższe fakty związane są klikaniem po interfejsie użytkownika. Dla osób, które od dłuższego czasu korzystają z oprogramowania, proces biznesowy oraz system informatyczny stają się tym samym. Interfejs użytkownika staje się jedyną reprezentacją procesu biznesowego. Ta sytuacja ma conajmniej jeden bardzo poważy minus. Utożsamiając oprogramowanie z procesem biznesowym, Twoja grupa warsztatowa nie będzie w stanie "wyskoczyć" poza ograniczenia danego systemu. Będą podążali utartymi i znanymi z własnej codzienności ścieżkami. Co więcej, w każdym systemie użytkownicy wymyślają różnego rodzaju "obejścia" np. ekran raportu trzeba odświeżyć trzy razy i dopiero wtedy załadują się poprawne dane (serio :)), czy coś podobnego. Ostatecznie, jeśli nic nie zrobisz z grupą warsztatową, która myśli w ten sposób, efektem Waszego Event Stormingu będzie mapa ścieżek funkcjonalnych całego systemu wraz ze wszystkimi niedoskonałościami aktualnie wdrożonej wersji oprogramowania.
Gdy zorientujesz się, że uczestnicy warsztatu "jadą po interfejsie", musisz ich jak najszybciej wybić z tego stanu. Przeważnie łatwo to zrobić. Powiedz im: "Wyobraźcie sobie, że oprogramowanie, którego używacie na codzień nie istnieje. Piszcie fakty tak, jakby wszystkie sprawy były załatwiane za pomocą papierowych dokumentów, telefonów i bezpośrednich rozmów". Wystarczy to kilka razy powtórzyć, wskazać palcem fakty, które są nie takie jak trzeba, a grupa załapie to bardzo szybko i zacznie tworzyć wartościową mapę.
Odpuść moduły konfiguracyjne
W niemal każdym działającym systemie systemie jest coś takiego jak moduł konfiguracyjny. Zostaw w spokoju moduły konfiguracyjne. Przeważnie są one tworzone przez architektów oprogramowania i zbierają w jednym miejscu wszystkie parametry systemu, które mogą modyfikować jego zachowanie. W większości przypadków, za modułami konfiguracyjnymi nie ma żadnej wiedzy dziedzinowej do odkrycia, a jedynie same technikalia. Rozmyślania nad nimi można pomiąć bez większej szkody dla całości prac.
Proces nie jest tym, co myślisz
Poniższy obrazek ilustruje często występujący błąd podczas wydzielania podprocesów w trakcie Event Stormingu:
Wyklejanka stara się pokazać, że mamy część zbierania danych rejestracyjnych, a następnie przygotowanie umowy. Jeśli umowa zostanie odrzucona, to ponownie zaczynamy zbieranie danych rejestracyjnych. Na tym obrazku połączyły się dwie rzeczy:
- funkcjonalne działanie oprogramowania - brak akceptacji umowy skutkuje przekierowaniem do zbierania danych rejestracyjnych,
- logika działania tego biznesu - czyli, co po czym następuje.
Nie rób tak. Końcowym efektem takiego stormingowania będzie cała masa karteczek i plątanina strzałek łączących wszystko ze wszystkim, a więc bałagan. Z poprzednich artykułów z tej serii wiesz już, że w metodach warsztatowych nie lubimy bałaganu. Zatem STOP!. Czytaj poniżej, jak zrobić to poprawnie.
Jeśli jesteś programistą/ką, to strzałki, o których wspomniałem możesz utożsamiać z zależnościami. Plątanina strzałek oznacza, że zależności jest dużo. Tak dużo, że trudno się połapać, o co chodzi w mapowanym biznesie. Pamiętaj, że zależności powstają przede wszystkim tam, gdzie nachodzą na siebie różne koncepty (ang. concerns). Gdy logika miesza się z interfejsem, dane z procesami, gdy dwie poddomeny sklejają się w jedną, gdy technikalia przenikają się z logiką biznesową itp. Mieszanie się konceptów to najczęstsza przyczyna powstawania zależności. Recepta na to zjawisko jest zawsze taka sama: separacja konceptów (ang. separation of concerns) i dekompozycja.
Na powyższym obrazku zmieszał się koncept funkcjonalny systemu z konceptem logiki biznesowej. Trzeba je od siebie oddzielić. Jeśli chcesz pokazać działanie funkcjonalności - narysuj makietę ekranów użytkownika. Natomiast efektem Event Stormingu ma być zrozumienie tego, jak działa ten biznes niezależnie od tego, czy mamy tam jakieś systemy, czy nie.
Gdy dzielisz fakty na podprocesy, pamiętaj, że podproces to coś, co ma początek i koniec. Na początku podprocesu są jakieś informacje, gdy podproces się zakończy również "zostawia" po sobie jakieś informacje. Tym, co zmienia stan początkowy informacji w stan końcowy są następujące po sobie fakty.
Powyższy bałaganiarski rysunek zamieniłbym na coś takiego:
To, co się dzieje na interfejsie pokazałem za pomocą ekranów. Natomiast fakty, które reprezentują logikę działania biznesu przedstawiłem za pomocą karteczek. Dalej zacząłbym się zastanawiać, jak to się dzieje, że umowa zostaje wygenerowana, jakie są kryteria generowania umowy, czy generowanie umowy zależy od tego, że znamy już tego klienta, czy nie, czy istnieją jakieś wyjątki w generowaniu umowy. Wszystkie te rzeczy, to logika działania tego biznesu, bebechy tej domeny. Nie za bardzo da się je pokazać na ekranach, więc wtedy łapiemy za karteczki i robimy Event Storming. Ma to dla Ciebie sens? :)
