This is post 8 of 8 in the series “Przepisujemy moduł w systemie”
- Przepisujemy moduł w systemie odc. 1
- Przepisujemy moduł w systemie odc. 2
- Przepisujemy moduł w systemie odc. 3
- Przepisujemy moduł w systemie. Odc. 4.: porządkowanie
- Przepisujemy moduł w systemie. Odc. 5. Twórz język, nie słownik
- Przepisujemy moduł w systemie. Odc. 6.: Oddziel UI od modelu
- Przepisujemy moduł w systemie. Odc. 7.: Pytanie od Czytelnika
- Usprawnienia w procesie biznesowym. Odcinek 8.
Przeszliśmy mozolną drogę mapowania stanu ASIS. W kolejnych mailach opisałem, co po kolei należy zrobić i jak uniknąć pułapek używając metody Event Storming. Dzisiaj domykamy proces ASIS i zaczynamy wprowadzać ulepszenia w procesie biznesowym. Nie martw się, to jeszcze nie jest koniec cyklu, ale domknięcie etapu.
Dążymy stanu, który poglądowo można wyrazić poniższym obrazkiem.
Mamy zatem: zampowaną domenę, wydzielone i nazwane podprocesy. ale cóż to są za nowe karteczki w kolorze…(nie jestem pewny) morskiej zieleni? To są propozycje usprawnień.
Poszukiwanie usprawnień w procesie biznesowym
W trakcie Event Stormingu, który opisałem, uczestnicy ze strony Twojego klienta, będą aż kipieć chęcią rozmowy nad tym, jak powinien działać ich biznes, po wprowadzeniu zmian. To zrozumiałe – są zmęczeni stanem obecnym, dlatego zatrudnili Ciebie lub firmę, w której pracujesz.
Z drugiej strony pisałem również, iż aby przepisać ten moduł (na tym się wszak teraz skupiamy), potrzebujesz mieć punkt odniesienia w postaci stanu ASIS – jak jest teraz. Jednoczesne analizowanie perspektyw ASIS oraz TOBE, nie wychodzi na zdrowie.
Z trzeciej strony, uczestniczy się będą się niecierpliwić, bo chcą się podzielić swoim pomysłami. W tym momencie w sukurs przychodzi karteczka w kolorze morskiej zieleni – usprawnienia. Piszę o niej dopiero teraz, żeby zachować w tekście elementarny porządek, ale Ty gdy tylko zauważysz, iż uczestnicy warsztatu zaczynają zmierzać w stronę procesu TOBE, powiedz, iż „za pomocą pomarańczowych faktów wyklejamy proces takim, jaki on jest teraz. Jednak na zielonkowych kartkach zamieszczajcie swoje pomysły i wskazówki na temat tego, jak inaczej i lepiej powinien on działać”.
Taka informacja przeważnie wystarczy. Co jakiś czas sprawdzaj tylko, czy zielonkawych karteczek nie robi się czasem więcej niż pomarańczowych. Prosty zabieg z zapisywaniem usprawnień pomaga przeprowadzać Event Storming w sposób bardziej płynny.
Potwierdź ASIS z klientem
Ostatecznym klepnięciem, iż mamy stan ASIS wraz z propozycjami usprawnień jest potwierdzenie przez klienta. jeżeli jednak przeprowadziłeś proces analizy w sposób, który opisałem w tym i poprzednich mailach, potwierdzenie już wydarzyło. Osoby ze strony klienta uczestniczyły w warsztatach, są na bieżąco, rozumieją o co chodzi i niecierpliwie czekają na dalsze efekty.
Karteczki usprawnień w procesie biznesowym to nie dokumentacja
A co z dokumentacją? No, przecież zwykle przy tego typu przedsięwzięciach trzeba przygotować jakiś dokument do akceptu, projekt techniczny, studium wykonalności, itd.
Pamiętaj proszę, iż karteczkowa wyklejanka z Event Stormingu to nie jest dokumentacja projektowa. Event Storming to metoda warsztatowa, która ułatwia współpracę z klientem i angażuje go do tej współpracy. Spotykam klientów, którzy wprost tego rodzaju współpracy oczekują. No, może nie powiedzą wprost, iż chodzi im o Event Storming, ale powiedzą, iż chcą współpracować: po partnersku, blisko, z zaangażowaniem, ewentualnie: zwinnie, adżajlowo
Ja spotkałem się z tym, iż klienci cenią sobie ten rodzaj współpracy. Przede wszystkim wyraźnie mówią, iż karteczkową wyklejankę rozumieją, natomiast dokumentację projektową niekoniecznie.
Może się jednak zdarzyć, iż w przypadku:
- projektów publicznych,
- uwarunkowań przetargu,
- oczekiwania klienta,
- wymagań regulatora z konkretnych branż np. bankowość, lotnictwo, automotive
opisane ulepszenia w procesie biznesowym nie wystarczy i dokumentacja techniczna będzie potrzebna. Wtedy trzeba ją przygotować i jest to osobny artefakt. Użytecznym szablonem do przygotowania takiej dokumentacji jest Software Requirements Specification, który możesz pobrać tu.
Dobrze jest, dopóki jest dobrze
Nieformalne podejście, którą opisuję, nie opiera się na wykazie dostarczonych produktów projektu, ale na stylu współpracy, zaangażowaniu, zaufaniu oraz końcowym efekcie, który będzie wartościowy dla klienta. Ten rodzaj relacji można krótko streścić jako: Jest dobrze, dopóki jest dobrze.
Oznacza to, iż w przypadku trudności, opóźnień i różnego rodzaju nieprzewidzianych sytuacji, klienci mogą zachowywać się różnie – w zależności od swoich doświadczeń, kultury organizacyjnej i potencjalnego ryzyka wynikającego z zaistniałych trudności. Trudno to przewidzieć. Dlatego najprawdopodobniej Key Account Manager, Project Manager, członek zarządu, czy ktokolwiek kto jest odpowiedzialny za relację z tym klientem, będzie nalegać na zachowanie pewnych formalności. Formalnościami mogą być spotkania odbioru, oficjalne maile potwierdzające zakończenie etapu prac, itp. Zgódź się na to, pamiętając iż jest to element zarządzania ryzykiem, a priorytetem zawsze pozostaje wartość dostarczona klientowi.
W kolejnych odcinkach skupię się na tym od czego zacząć prace, jak wybrać priorytety, jak zaplanować kolejne etapy dostarczania.
Pisane w Gdyni, tuż po spotkaniu na meetupie dla analityków