<p data-line="2" dir="auto">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, iż o ile jesteś na początku drogi, to nie masz jeszcze problemów, a ja nie mam od czego zacząć.</p><p data-line="4" dir="auto">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.</p><p data-line="6" dir="auto">Taki wprowadzający kurs daje mapę zagadnień, po której uczestnicy już nieco lepiej wiedzą, czego chcą. zwykle pierwszy kłopot, jaki mają, gdy starają się w jakiś sposób zweryfikować nabyte informacje w praktyce brzmi: <em>to mi nie działa</em>.</p><p data-line="8" dir="auto">Jasne jest, iż wiedza teoretyczna i wiedza stosowana to dwie różne rzeczy, ale akurat w obszarze analizy jest jeden konkretny powód, który mocno komplikuje zastosowanie wiedzy zdobytej w trakcie kursów i szkoleń.</p><h2 data-line="10" dir="auto">Proces analizy</h2><p data-line="12" dir="auto">Proces analizy biznesowej wg Bartyzela wygląda następująco:</p><figure><img src="https://editor.blogstatic.io/web/assets/uploads/c6b3c1f3b9ec39c4f12835fc0a0a2087.png" id="/tmp/phpOEXk8w" data-image="/tmp/phpOEXk8w"></figure><p data-line="16" dir="auto">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 <em>presales</em>, a kończymy rozliczeniem. Późniejszy support i ewentualna dosprzedaż to dla mnie osobne kawałki.</p><p data-line="18" dir="auto">Otóż, wspomniany we wstępie kłopot polega na tym, w jaki sposób - jako analityk - przechodzisz przez poszczególne etapy procesu analizy.</p><h2 data-line="20" dir="auto">Prawie nigdy</h2><p data-line="22" dir="auto">Niemym założeniem osób będących na początku drogi zawodowej jest, iż przez proces analizy biznesowej przechodzimy sekwencyjnie. Najpierw <em>presales</em>, potem definiowanie potrzeb biznesowych, potem rozpoznanie interesariuszy, itd. Otóż, tak się nigdy nie dzieje.</p><figure><img src="https://editor.blogstatic.io/web/assets/uploads/01f50bb9c5880e48e4be67278868c87b.png" id="/tmp/phpAMWsbS" data-image="/tmp/phpAMWsbS"></figure><p data-line="26" dir="auto">No, dobra prawie nigdy. Taki, jak powyższy sposób przechodzenia przez proces analizy, ma miejsce w następujących przypadkach:</p><ul data-line="28" dir="auto"><li data-line="28" dir="auto">w książkach,</li><li data-line="29" dir="auto">w projektach ćwiczebnych robionych na zaliczenie,</li><li data-line="30" dir="auto">w projektach, które już się zakończyły, ale przyglądamy się im retrospektywnie, aby się czegoś nauczyć (wiadomo, iż analiza wstecz zawsze działa dobrze).</li></ul><p data-line="32" dir="auto">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.</p><h2 data-line="34" dir="auto">Od czasu do czasu</h2><p data-line="36" dir="auto">Czasem proces analizy przebiega tak:</p><figure><img src="https://editor.blogstatic.io/web/assets/uploads/5228c352a1f8186c0913e9b85e45e12a.png" id="/tmp/php4YnENE" data-image="/tmp/php4YnENE"></figure><p data-line="40" dir="auto">Ten artystyczny rysunek ma pokazać, iż dość często przebiegasz przez ten proces, ale w wąskim zakresie. Robisz kawałek <em>presales</em>, kawałek definiowania potrzeb, kawałek rozpoznania interesariuszy, a potem wszystko od początku.</p><p data-line="42" dir="auto">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.</p><h2 data-line="44" dir="auto">Zazwyczaj</h2><p data-line="46" dir="auto">Jednak bardzo, bardzo często analiza wygląda tak:</p><figure><img src="https://editor.blogstatic.io/web/assets/uploads/b0aa1de9e85ab3ae0f05728d72f2c8cc.png" id="/tmp/phpcAsrYw" data-image="/tmp/phpcAsrYw"></figure><p data-line="50" dir="auto">W takiej sytuacji wpadasz w sam środek projektu i kążą Ci coś robić. Nie wiesz <em>dla kogo</em>, nie wiesz <em>po co</em>, może i choćby nie wiesz <em>co jest do zrobienia</em>. W takiej sytuacji sytuacji musisz się cofnąć do wcześniejszych etapów procesu analizy.</p><p data-line="52" dir="auto">Mając rozpędzony zespół wypuszczający kolejne wersje softu, zaczynasz analizować, kto adekwatnie będzie używał tego systemu i czyje problemy ma ono rozwiązywać. Takie rzeczy dzieją się naprawdę. Promis!</p><h2 data-line="54" dir="auto">Analiza nie jest procesem</h2><p data-line="56" dir="auto">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ć, iż wzorcowy proces to jedno, a życie to drugie.</p><p data-line="58" dir="auto">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ć, iż 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.</p><p data-line="60" dir="auto">Tak, proszę Państwa, to jest realna trudność w wyjaśnianiu, w jaki sposób "działa" analiza i jak należy ją prowadzić. zwykle jednak, jeżeli 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.</p><p data-line="62" dir="auto">I teraz uwaga, bo będę kwestionował wszystkie znane Ci autorytety...</p><p data-line="64" dir="auto">Jeśli tylko pozbędziemy się tego - przyjętego adekwatnie a priori - założenia, iż analiza jest procesem, to możemy ją wyjaśnić o wiele prościej. Mianowicie tak (rysunek dla miłośników <a href="https://michalbartyzel.pl/blog/przepisujemy-modul-w-systemie-odc-2">Event Stormingu)</a>:</p><figure><img src="https://editor.blogstatic.io/web/assets/uploads/a9a40417b90f479cfa4874b261978aa7.png" id="/tmp/php2K5ACR" data-image="/tmp/php2K5ACR"></figure><p data-line="68" dir="auto">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ę <em>presales</em> 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 <em>SoftwareAccepted</em>, po którym odpoczniesz. Proste?</p><p data-line="70" dir="auto">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 <a href="https://michalbartyzel.pl/#oferta" target="_blank">warsztacie w Twojej organizacji</a>.</p>