W poprzednim artykule rozpocząłem temat przepisywania modułu w systemie. Ostatecznie dobrnęliśmy do tego, że zaczynamy od zdefiniowania stanu ASIS i użyjemy do tego Event Stormingu. O tym dzisiaj.
Dlaczego Event Storming?
Przeglądając różnego rodzaju blogi możesz zauważyć, że istnieją dwie frakcje, jeśli chodzi o metody analizy. Pierwsza to zwolennicy metod w stylu UML, BPMN, SRS. Druga grupa to, ci którzy zakochali się w kolorowo-karteczkowych metodach typu User Story Mapping, Impact Mapping albo wspomniany Event Storming. Każda z grup precyzyjnie argumentuje, że ich ulubione metody są lepsze, łatwiejsze lub co gorsza bardziej adżajlowe.
Wyobraźmy sobie, że analiza biznesowa to wielki słoń i każda z wymienionych frakcji gapi się na tego słonia, z tym że jedna na głowę, a drugą na... Każdy opisuje to, co widzi i każdy ma rację i jednocześnie jej nie ma. Ja to widzę jeszcze inaczej :)
Zacznijmy od podstawowego pytania, skąd pierwotnie pochodzą: wiedza o biznesie, technikaliach, procesach, wymaganiach, skąd się biorą decyzje? Gdzie to wszystko ma swoje źródło, zanim pojawi się w dokumentach, specyfikacjach i notatkach ze spotkań? Otóż, to wszystko jest w głowach ludzi.
W związku z powyższym muszą istnieć dwie grupy metod analizy. Pierwsza grupa służy do wyciągania z głów ludzi wiedzy i decyzji, do tego aby skonfrontować ze sobą różne perspektywy i oczekiwania i wykuć w miarę jednolite stanowisko. Ponieważ wspomniane wiedza, decyzyjność i perspektywy są rozproszone między ludzi o różnych doświadczeniach czy znajomości technologii, to metody których chcemy używać na tym etapie, muszą być łatwe. Ściślej mówiąc muszą mieć niski koszt wejścia, niezbyt dużo zasad, nie mogą męczyć. Powód jest prosty: używana metoda nie może zasłonić celu, w którym jej używamy. Na tym etapie genialnie wręcz sprawdzają się metody kolorowo-karteczkowe.
Z drugiej strony, gdy już wszystko to, co jest potrzebne do dalszych prac zostanie skutecznie "wyciągnięte" z głów ludzi, pojawia się inna potrzeba. Po pierwsze należy uporządkować i utrwalić wszystkie zebrane informacje. Utrwalić w taki sposób, aby po - w założeniu - dowolnie długim czasie móc powiedzieć: kto? co? jak? i dlaczego? Takie informacje potrzebne są do wdrażania nowych pracowników, do dalszego rozwoju oprogramowania, a czasem potrzebne są w sądzie. Na tym etapie doskonale sprawdzają się metody analizy, które można by nazwać klasycznymi: UML, BPMN, SRS, formalne specyfikacje, ustandaryzowane dokumenty.
Jak widzisz, wszystko jest potrzebne tylko we właściwym momencie i we właściwej proporcji. Te dwie grupy metod analizy, które opisałem nie wykluczają się, ani się nie zastępują, Event Storming nie jest zamiast BMPN, a user story nie jest zamiast przypadków użycia. OK, czasem bywa tak, że w małej skali albo na niektórych etapach prac, zespoły sobie karteczkują, potem robią zdjęcie karteczek i to jest ich "dokumentacja". Na dłuższą metę jednak to się nie sprawdza, gdyż metody karteczkowe pomagają zbudować wspólne zrozumienie danego zagadnienia. To zrozumienie ponownie mieszka w głowach ludzi, natomiast karteczkowa wyklejanka stanowi "memo", które przypomina im to, co wspólnie ustalili. W większości projektów będziesz potrzebować i karteczek i dobrze opracowanej dokumentacji.
Zaplanuj sesje z klientem
W poprzednim artykule wspomniałem, że do przeprowadzenia warsztatu Event Storming w kontekście przepisywania modułu w systemie, potrzebujesz conajmniej eksperta/kę biznesowego i technicznego. Dwie lub trzy osoby to wystarczająco.
Ile to potrwa? Na część przygotowywania stanu ASIS zarezerwuj z ekspertami spotkania dwa razy w tygodniu po 2-3 godziny. Całość potrwa 5-8 tygodni, czyli 30-48 godzin pracy z klientem plus Twoje prace porządkowe i przygotowawcze między spotkaniami. Te porządki zajmą dodatkowo średnio 1h/tydzień.
Spodziewałeś/aś się mniej czasu? Bywa, że ktoś oczekuje od siebie, że zrozumie biznes klienta w trakcie 1-2 spotkań. Nie rozumie. Pamiętaj, że Twój klient jest po uszy zatopiony swoich sprawach i swoich systemach, zna to wszystko. Ty dopiero przyswajasz sobie tą wiedzę, to trwa. Nie miej więc oporów przed zaproponowaniem takich spotkań. Najlepiej zrób to już na etapie przedsprzedażowym - shift left :)
Sugeruję Ci pracować klientem i prowadzić warsztaty w 2 osoby. Jeśli masz już za sobą doświadczenie takiej pracy, to pewnie wiesz, że trudno jednocześnie być uczestnikiem warsztatu oraz prowadzącym. Albo skupiasz się na zrozumieniu domeny albo na facylitacji procesu. Nie mówię, że łączenie tych ról jest niemożliwe, jest po prostu bardzo trudne.
Obserwuję od czasu pandemii, że sporo tego typu warsztatów odbywa się zdalnie. Moja osobista preferencja jest taka, że pierwsze warsztaty albo któreś z kolejnych robimy fizycznie w sali, żeby się zapoznać i przybić piątkę. Natomiast pozostałe proponuję prowadzić zdalnie. Nie chcę dyskutować z minusami spotkań zdalnych, bo wiadomo, że je mają. Z resztą picie zwykłej, wody też ma minusy, bo może prowadzić do przewodnienia i wypłukiwania elektrolitów z organizmu :) Ostatecznie chodzi o rozsądne proporcje i ogólne wyczucie sytuacji.
Jako narzędzia używam i rekomenduję Miro. Wersja darmowa jest wystarczająca na początek. Jeśli masz jakąś ulubioną alternatywę i posługujesz się nią sprawnie, to też OK.
Gdy pracujesz dla klienta zewnętrznego
W przypadku klienta zewnętrznego pojawia się dodatkowa zmienna - koszty. Każda godzina Twojej pracy jest rozliczana. Ważkie pytanie brzmi: kto płaci za tę analizę, za opracowanie stanu ASIS? Ja uważam, że klient. To jest konkretna praca, której efektem będą:
- wytyczne do opracowania stanu TOBE - docelowego,
- zidentyfikowane błędy w zaprojektowaniu obecnego modułu,
- wyspecyfikowane miejsca optymalizacji procesu,
- wykryte i uspójnione niekonsekwencje w działaniu procesu biznesowego,
- zidentyfikowane braki wiedzy/kompetencji biznesowych/technicznych,
- zidentyfikowane wyjątkowo kosztowe albo dochodowo istotne miejsca w procesie,
- lista krytycznych decyzji, które należy podjąć, aby zapewnić ciągłość działania biznesu,
- czasem identyfikowane są takie aktualne bądź przyszłe uwarunkowania, które sprawiają, że w ogóle nie opłaca się przepisywać tego modułu.
Nie przesadzę zbytnio, jeśli powiem, że zdefiniowanie stanu ASIS, można nazwać małym audytem. Jest to praca warta zapłaty. Moim zdaniem należy tę cześć jawnie ująć w ofercie oraz podać cenę. Powodem jest to, że mając wyspecyfikowane ww. rzeczy, klient mógłby iść do innego wykonawcy. Zatem część analizy powinna zakończyć się jakimś konkretnym artefaktem (rzeczą :)). Oczywiście przeważnie klient będzie chciał kontynuować współpracę, aż do szczęśliwego wdrożenia. Wtedy wszystkie punkty wymienione powyżej, będą rozsypane po karteczkach i podsumowane w jakimś nieformalnym dokumencie. Nie będziesz przygotowywać żadnego formalnego raportu. Jednak wiedz, że czasem zdarzają się sytuacje, w których studium wykonalności przygotowuje jedna firma, analizę druga, projekt techniczny kolejna, a wykonanie powierza się jeszcze innej.
Podsumowując: czy z perspektywy Twojej organizacji oraz Twojego klienta opłaca się, aby w event stormingu brał udział cały zespół wykonawczy? Na tym etapie nie. Czy opłaca się prowadzić analizę ASIS w 2 osoby? Tak.
Żeby już całkowicie wyczerpać paletę możliwości, z którymi się spotkałem, dodam jeszcze jedno. Bywa, że z powodów prawnych np. wytyczne do przetargu, nie można wykazać analizy jako osobnego punktu w budżecie i należy podać cenę za całość prac. Wtedy nie ma rady i tak trzeba zrobić. Co do zasady jednak pokazuj przejrzyście analizę jako osobny etap współpracy.
Gdy pracujesz dla klienta wewnętrznego
W przypadku klienta wewnętrznego oczywiście koszt prac jest również ważny i jest liczony. Tylko nazywa się on wtedy - mendej, 1MD. Oczywiście zawsze wiadomo, że 1M pracy IT w organizacji kosztuje tyle a tyle złotówek. Jednak o złotówkach rozmawiają najczęściej ci, którzy przydzielają i rozliczają budżety. Natomiast mendej jest zwyczajową jednostką rozliczeniową, którą ludzie posługują się na codzień, i o której rozmawiają.
Dlaczego o tym mówię? Otóż mendej nie jest tak wymowny jak złotówka, spalanie mendeja nie boli tak, jak wydawanie pieniędzy. To sprawia, że próśb do IT o analizy, opinie i wykonanie pracy będzie więcej, niż byłoby w relacji b2b. A to z kolei sprawia, że może być Ci trudniej pozyskać do współpracy odpowiednich ekspertów na odpowiedni czas, gdyż są oni zazwyczaj zajęci swoimi mendejami.
W przypadku klienta wewnętrznego kluczem do sukcesu jest odpowiednio umocowany sponsor przedsięwzięcia. Może to być Product Owner, Project Manger, Produkt Manager. Ktoś, kto potrafi zorganizować Ci czas pożądanych ekspertów. Namierzenie kogoś takiego jest zadaniem warsztatu Stakeholder Mapping.
W następnym odcinku
Kolejny mail poświęcę pierwszej sesji Event Stormingu z ekspertami. Dowiesz się:
- Jak wytłumaczyć uczestnikom warsztatu, czym jest Event Storming?
- Jak rozpocząć z nimi etap Big Picture warsztatu?
- Jak sobie poradzić, gdy narzekają: ...a co tak długo? ...a ile to jeszcze zajmie...? ...a nie można szybciej? ...a przecież już to wiemy?
