Od jakiegoś czasu prowadzę szkolenia dla analityków będących na wczesnym etapie drogi zawodowej. Takie szkolenia prowadzi mi się dość trudno, ponieważ moim ulubionym zabiegiem trenerskim jest snucie opowieści zaczynając od jakiegoś konkretnego problemu, z którym spotkali się uczestnicy. Kłopot polega na tym, że jeżeli jesteś na początku drogi, to nie masz jeszcze problemów, a ja nie mam od czego zacząć.
Na takie okazje stosuję pewien trik: proszę uczestników, aby przed szkoleniem przeszli jeden z podstawowych kursów online z zakresu analizy biznesowej. Ot, tak - żeby mieć płaszczyznę porozumienia.
Taki wprowadzający kurs daje mapę zagadnień, po której uczestnicy już nieco lepiej wiedzą, czego chcą. Zazwyczaj pierwszy kłopot, jaki mają, gdy starają się w jakiś sposób zweryfikować nabyte informacje w praktyce brzmi: to mi nie działa.
Jasne jest, że wiedza teoretyczna i wiedza stosowana to dwie różne rzeczy, lecz akurat w obszarze analizy jest jeden konkretny powód, który mocno komplikuje zastosowanie wiedzy zdobytej w trakcie kursów i szkoleń.
Proces analizy
Proces analizy biznesowej wg Bartyzela wygląda następująco:
Nazwy niektórych etapów tego procesu być może rozpoznajesz, gdyż poświęciłem im niektóre newslettery. Ja to tak właśnie widzę: zaczynamy od wczesnych etapów, od presales, a kończymy rozliczeniem. Późniejszy support i ewentualna dosprzedaż to dla mnie osobne kawałki.
Otóż, wspomniany we wstępie kłopot polega na tym, w jaki sposób - jako analityk - przechodzisz przez poszczególne etapy procesu analizy.
Tak w teorii pracuje analityk
Niemym założeniem osób będących na początku drogi zawodowej jest, że przez proces analizy biznesowej przechodzimy sekwencyjnie. Najpierw presales, potem definiowanie potrzeb biznesowych, potem rozpoznanie interesariuszy, itd. Otóż, tak się nigdy nie dzieje.
No, dobra prawie nigdy. Taki, jak powyższy sposób przechodzenia przez proces analizy, ma miejsce w następujących przypadkach:
- w książkach,
- w projektach ćwiczebnych robionych na zaliczenie,
- w projektach, które już się zakończyły, ale przyglądamy się im retrospektywnie, aby się czegoś nauczyć (wiadomo, że analiza wstecz zawsze działa dobrze).
W powyższych przypadkach można patrzeć na analizę jak na sekwencję etapów i wszystko trzyma się kupy, a końcowe efekty początkowych działań są oczywiste.
Tak od czasu do czasu pracuje analityk
Czasem proces analizy przebiega tak:
Ten artystyczny rysunek ma pokazać, że dość często przebiegasz przez ten proces, ale w wąskim zakresie. Robisz kawałek presales, kawałek definiowania potrzeb, kawałek rozpoznania interesariuszy, a potem wszystko od początku.
Pracujesz w sposób iteracyjny, czyli w kolejnych przebiegach dostarczasz kolejne porcje analizy. Pracujesz również w sposób inkrementacyjny, czyli w kolejnych przebiegach ulepszasz analizę dostarczoną wcześniej.
Tak przeważnie pracuje analityk
Jednak bardzo, bardzo często analiza wygląda tak:
W takiej sytuacji wpadasz w sam środek projektu i kążą Ci coś robić. Nie wiesz dla kogo, nie wiesz po co, może i nawet nie wiesz co jest do zrobienia. W takiej sytuacji sytuacji musisz się cofnąć do wcześniejszych etapów procesu analizy.
Mając rozpędzony zespół wypuszczający kolejne wersje softu, zaczynasz analizować, kto właściwie będzie używał tego oprogramowania i czyje problemy ma ono rozwiązywać. Takie rzeczy dzieją się naprawdę. Promis!
Analiza nie jest procesem
Zwróć uwagę jak bardzo komplikuje sprawę kurczowe trzymanie się definicji jakoby analiza była procesem. Im bardziej upieramy się, żeby postrzegać analizę jako proces, tym bardziej musimy się nagimnastykować, aby pokazać, że wzorcowy proces to jedno, a życie to drugie.
Wyjaśniając proces analizy nowym jej adeptom, trzeba się mocno nagimnastykować stwarzając dodatkowe pojęcie "sposób przechodzenia" przez ten proces. Potem trzeba wytłumaczyć, że w zależności od okoliczności i charakteru projektu czasem zaczynamy od etapu pierwszego, czasem od czwartego, a czasem od siódmego i piątego jednocześnie. Dokładnie takie rozumowanie opisywałem w poprzednich akapitach.
Tak, proszę Państwa, to jest realna trudność w wyjaśnianiu, w jaki sposób "działa" analiza i jak należy ją prowadzić. Zazwyczaj jednak, jeśli mamy do czynienia z jakąś trudnością, to zamiast ją rozwiązywać, warto znaleźć taki sposób myślenia, w którym ta trudność nie występuje.
I teraz uwaga, bo będę kwestionował wszystkie znane Ci autorytety...
Jeśli tylko pozbędziemy się tego - przyjętego właściwie a priori - założenia, że analiza jest procesem, to możemy ją wyjaśnić o wiele prościej. Mianowicie tak (rysunek dla miłośników Event Stormingu):
Otóż analiza nie jest procesem. Analiza jest obsługą określonego typu zdarzeń. Gdy wystąpi odpowiednie zdarzenie, Ty jako analityk, musisz umieć podjąć decyzję, jaką akcję musisz wykonać: akcję presales albo akcję rozpoznania interesariuszy, a może akcję opracowania specyfikacji lub jej fragmentu. Akcje, które wykonasz wygenerują kolejne zdarzenia, które znowu obsłużysz. I tak ciągle, aż do zdarzenia SoftwareAccepted, po którym odpoczniesz. Proste?
W tych newsletterach, w moich książkach, kursach online i szkoleniach uczę po pierwsze tego, co jest ukryte pod fioletową karteczką. Uczę, jak rozpoznać, co się wokół Ciebie dzieje i jakie decyzje musisz podjąć. A potem uczę jak wykonywać rzeczy z niebieskich karteczek. Uczę myślenia nieliniowego, poza schematami i proaktywnego. Właśnie dlatego powinniśmy się spotkać na warsztacie w Twojej organizacji.
