Jak dokumentować chaotyczny projekt?
Wielokrotnie zostawałem rzucany na głęboką wodę, gdzie miałem napisać dokumentację do istniejącego projektu do którego dołączam.
Po krótkim zapoznaniu się z tematem często okazywało się, że w projekcie panuje ogromny chaos.
Ciężko zacząć tworzyć dokumentację bo nie wiadomo nawet czy aktualne działanie to bug czy feature 😉
Często też osoby, które znają wymagania i założenia logiczne projektu – nie mają czasu o nich porozmawiać.
Brzmi znajomo? Mam nadzieję, że nie. Ale jeśli miałeś podobny problem to zapraszam do lektury 🙂
Jak poznać istniejący projekt?
Przedstawię Ci metodę, z której korzystam w sytuacji gdy mam napisać dokumentację do projektu, który istnieje, ja do niego dołączam więc nie znam pierwotnych założeń.
Metoda, którą Ci zajawkowo przedstawię nazywa się Event Storming.
Event storming to warsztat, w którym chodzi o poznanie prawdziwych procesów projektowych i przepływu w nim.
Celowo użyłem zwrotu, że poznajemy „prawdziwe procesy” – bo często jest tak, że wydaje nam się, że wiemy jak wyglądają procesy, gdy tak naprawdę mogą wyglądać zupełnie inaczej gdy spojrzymy na nie w szerszym obrazku.
Piszę tutaj o „procesach” – oczywiście jest to skrót myślowy. W Event Stormingu, bazuje się (jak sama nazwa mówi) na zdarzeniach projektowych, które ułożone w sekwencje mogą tworzyć procesy.
Przechodząc do sedna – opiszę Ci przebieg spotkania (w wersji skrótowej).
Krok 1 – zorganizuj spotkanie
Dołączając do istniejącego projektu, pewnie będziesz się mierzył z tym, że większość założeń mają członkowie zespołu w swoich głowach i nie będą mieli czasu o nich rozmawiać.
Zbierz kluczowe osoby znające projekt i umów się z nimi na spotkanie ok. 2-3h.
Przekonaj ich tym, że to będzie bardziej produktywne niż miałbyś zaczepiać ich co 20 minut przez dwa tygodnie 🙂
Do spotkania będzie Wam potrzebne:
- miejsce do naklejania karteczek (może być ściana ok. 3-4m szerokości)
- żółte karteczki
- markery
Na początku spotkania poinformuj o celu spotkania, chodzi o poznanie PRAWDZIWYCH procesów w aplikacji (Twoja edukacja może być efektem ubocznym:) ).
Możesz również odbyć w warsztat zdalnie, w wersji cyfrowej – polecam narzędzie miro.com.
Krok 2 – Eksploracja zdarzeń
Rozdaj karteczki i poproś uczestników o wypisanie zdarzeń na karteczkach, które są istotne z ich punktu widzenia.
Uprzedź o pisaniu w czasie przeszłym czyli „wystawiono fakturę” zamiast „wystawianie faktury”.
Daj uczestnikom trochę czasu – prawdopodobnie każdy wypisze kilka, kilkanaście istotnych zdarzeń projektowych.
Uzyskasz efekt, że każdy wypisze zdarzenia, które dotyczą jego fragmentu odpowiedzialności. Kolejnym krokiem będzie ułożenie tego w całość.
Krok 3 – uporządkowanie zdarzeń
Krok trzeci, jest krokiem porządkującym. Należy nakleić karteczki z wypisanymi zdarzeniami i uporządkować je według osi czasu (od lewej strony do prawej), w takiej kolejności jak występują.
Stworzy nam się mniej/więcej coś na wzór diagramu czynności w wersji analogowej.
W tym kroku usuń duplikaty kartek (gdyby dwie osoby wypisały te same zdarzenie).
Jeśli zdarzeń jest dużo i są „z różnych obszarów” – możesz uporządkować je w swimelines.
Czyli np. na górze umieszczać proces dotyczący aplikacji A, poniżej proces dotyczący CRM itp.
Warto w tym kroku oznaczać elementy trudne/krytyczne lub wymagające doprecyzowania później – bo nie chodzi aby wykonać analizę podczas spotkania.
Pain point, który zdiagnozujesz zapamiętaj – nie staraj się poświęcać na niego więcej niż kilka minut. Wrócisz do niego po spotkaniu.
Dbaj o dynamikę spotkania (okiem uczestników).
Krok 4 – weryfikacja zdarzeń
W kolejnym kroku należy zastanowić się czy procesy zdarzeń, które ułożyliśmy są na pewno poprawne.
Pomaga tutaj zastanowienie się z uczestnikami nad danym procesem od końca. Czyli analizujemy proces od elementu ostatniego i zastanawiamy się czy po drodze czegoś nie zgubiliśmy.
Opowieść od końca pozwoli nam pomyśleć o procesie w inny sposób – bo zawsze myśleliśmy o nim od początku i niektóre kroki mogły się wydawać tak oczywiste, że je pomineliśmy. Opowiadając proces od końca możemy takie braki wyłapać.
Jeśli między zdarzeniami jest „duża luka” – można zadać pytania pomocnicze, żeby uzupełnić zdarzenia:
- co jeszcze musiało się stać, żeby Y się stało?
- czy między X i Y dzieje się coś jeszcze?
- co jeśli X by się nie powiodło?
Odpowiedzi na powyższe pytania pewnie dadzą Ci dodatkowe zdarzenia do naklejenia.
Krok 5 – aktorzy zdarzeń
W kroku piątym chodzi o ustalenie aktorów zdarzeń. Często aktorem może być:
- człowiek (pracownik) – który korzysta z aplikacji, lub wykonuje elementy ręcznie lub poza aplikacją
- system – część rzeczy dzieje się przez napisane funkcje, np wysyłka maili, automatyczna akceptacja faktur (you name it).
- zewnętrzne systemy/aplikacje – różnego rodzaju dropboxy, programy zewnętrzne, które integrują się z naszym projektem. Wszelkie third part.
Warto dokleić do naszych kartek ze zdarzeniami „języczki” w postaci różnych kolorów co jest aktorem danego zdarzenia.
Oczywiście nie wszystkie zdarzenia muszą mieć przypisanego aktora.
Ilość aktorów możesz dostosować pod siebie – ja często wyodrębniam wśród pracowników oddzielne grupy aktorów, np jedna dla administratorów, druga dla osób z księgowości itp.
Wiedza o Dokumentacji IT na twój adres e-mail?
Krok 6 – bolączki
Taki warsztat to idealny moment, żeby zdefiniować bolączki projektowe i okazje (co można usprawnić). Kursanci Dokumentacja.Pro, wiedzą, że takie rzeczy warto opisywać w dokumentacji.
W kroku 6 oznaczcie karteczki, w których występują problemy, a w których okazje do usprawnienia.
Nie musicie wymyślać na spotkaniu rozwiązań – chodzi o zdiagnozowanie pain points.
Jeśli przeprowadzasz Event Storming z programistami i ukrytym celem warsztatu jest również zrobienie road mapy produktu, możecie od razu spróbować wycenić pracochłonność naprawy problemów i wprowadzenia usprawnień (okazje).
Wszyscy boją się deklaracji (tym bardziej publicznych), więc dla ułatwienia możecie wyceniać w walucie:
- chwilę
- pół dnia
- dzień
- trzy dni
- tydzień
- wieczność
Krok 7 – archiwizacja
Ostatnim krokiem warsztatu jest jego archiwizacja. Jeśli pracowaliście nad warsztatem zdalnie to będzie prościej bo karteczki zostają w aplikacji.
Jeśli pracowaliście analogowo to polecam Ci zrobić zdjęcia karteczek – jedno główne całości + kilka zdjęć „zoom” na mniejsze fragmenty.
Chodzi o to, aby móc odtworzyć sobie procesy podczas pisania dokumentacji.
Event Storming, a dokumentacja
Od Event Stormingu, do napisania dokumentacji jest jeszcze długa droga.
Ale na pewno warsztat pomoże Ci poznać ogół projektu, wiedzieć do jakiej osoby możesz napisać w razie pytania z konkretnego fragmentu projektu.
To co poleciłbym Ci zrobić po warsztacie to ułożyć diagramy UML. O tym jakie diagramy warto tworzyć na początku mówiłem w swoim podcaście 002 – Jakie diagramy w dokumentacji?.
Kolejnie opisuj najbardziej zawiłe i problematyczne fragmenty projektu.
Nie nastawiaj się, że napiszesz wszystko „od razu”. Potraktuj dokumentację jako żyjący dokument, który będziesz rozwijał wraz z poznawaniem zakresu projektu.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
