Wprowadzenie

29 Lipca 2018 r. w Sopocie miało miejsce pierwsze popołudniowe spotkanie “Analiza Biznesowa 3 miasto” zorganizowane wspólnie z portalem Analiza.IT  a celem było “Stary analityk odpowiada na pytania młodych” 🙂

W ramach podsumowania spotkania zebraliśmy pytania zdobywających doświadczenie analityków, wspólnie uznane za reprezentatywne dla całego spotkania.

Oto one i moje odpowiedzi. Starałem się niczego nie ukrywać, traktujcie to jak szczere koleżeńskie rady,  obciążone moim 20-letnim doświadczeniem i subiektywizmem.

Znajdziecie tu i troszkę inżynierii i technologii, i troszkę filozofii i troszkę etyki zawodu…

Artykuł zawiera Brief Analityka Biznesowego do pobrania. Pod artykułem odpowiadam na pytania.

Zapraszam

Jarek Żeliński

F.A.Q. czyli Analityk Biznesowy Pyta

Nowy analityk w korporacji, jak ma się zachować gdy wchodzi w nieuporządkowany projekt i niezbyt uporządkowane, chaotycznie tworzone “papiery”?

To chyba najtrudniejsze pytanie i najprostsza odpowiedź: ma być uczciwy względem siebie. Jeżeli wszedł w miejsce poprzednika by go po prostu zastąpić (analityk przyjął złożoną mu ofertę pracy), to pozostaje mu tego poprzednika zastąpić w sferze tego jak ten pracował i jakie dokumenty tworzył. Jeżeli ktoś został zatrudniony bo pracodawca uznał, że poprzednik robił coś gorzej a nowy pracownik ma wiedzę by poprawić dotychczasową jakość pracy, i być może wdrożyć nowe i lepsze praktyki, to znaczy że ma spełnić tę obietnicę ;).

Tu ważna uwaga: nie da się reformować firmy bez wiedzy i zgody jej zarządu a projektu bez wiedzy i zgody Kierownika Projektu. Można owszem “świecić przykładem”,  ale należy przy tym pamiętać, że to nie to samo co “robienie inaczej i lepiej niż inni”, bo tak można rozsadzić firmę (projekt) od środka.

Tak więc podejmując się nowej pracy należy przyjąć na siebie wszelkie wynikające z tego obowiązki, naprawianie świata należy robić zawsze za wiedzą i zgodą zwierzchników :). Jednak podstawowym, moralnym i etycznym zadaniem każdego z nas, jest informowanie przełożonych o dostrzeżonych ryzykach.

Czego i jak się uczyć, żeby zacząć pracować w analizie

Analiza biznesowa (analiza systemowa organizacji) i szukanie rozwiązań problemów, to praca bardzo podobna do pracy naukowej. Przyjęcie analizy systemowej jako fundamentu metod pracy, pozwala nie tylko uporządkować prace analityczne, ale także uporządkować cały proces szukania rozwiązania. Każdemu, kto ma ochotę się rozwijać, polecam osiągnięcia myślicieli z obszaru filozofii nauki (patrz artykuł Wiedza a nauka i prawda). […] Tu także inny artykuł zaczynający się od słów:

Analiza systemowa, ogólna teoria systemów, świat to chaos czy złożoność? Biznes i jego otoczenie to złożoność, która dla wielu jest chaosem. (Źródło: Wszystkie drogi prowadzą do Rzymu | | Jarosław Żeliński IT-Consulting).

Uogólniając, warto się oswoić z filozofią analityczną i logiką, bo na niej między innymi oparte są fundamenty notacji takich jak UML, BPMN i nie tylko. Warto nauczyć się zapisywać zdobytą wiedzę o analizowanej organizacji z pomocą schematów blokowych i formalnych notacji, zgodnie z maksymą:

jeżeli czegoś nie potrafisz poprawnie narysować to znaczy, że jeszcze tego nie rozumiesz…

Ważna rzecz: gdy tylko to możliwe, czytać cudze dokumenty i analizować ich wady, w szczególności wszystko to, co okazało się niejasne i niejednoznaczne, to co było przyczyną porażki projektu, bo to te wady dokumentów, które należy usuwać w swojej własnej pracy.

I podstawa: nie być konformistą (ponad 3/4 projektów IT to wtopy a nie sukcesy…. wiec większość nie ma racji). Na tej Stronie (mój blog) znajdziecie recenzje wybranych książek, które polecam.

Czy są gotowe zestawy dokumentów, w oparciu o które można napisać specyfikację

Osobiście nie spotkałem takich i nie polecam ich szukania… Każda analizowana firma jest inna, więc każda analiza będzie miała inną wynikową treść. Można mówić o ramie, czyli kluczowych etapach analizy i tym samym o kluczowych rozdziałach specyfikacji:

1. wprowadzenie czyli cel biznesowy podmiotu analizowanego, także to (opis) jak sprawdzimy, że firma ten cel (po zakończeniu projektu) zrealizowała (tu przydaje się notacja BMM),
2. model działania podmiotu analizowanego pokazuje w jaki sposób organizacja działa, należy przede wszystkim zbadać i pokazać jak powstają dokumenty i ich treść, co powoduje (jakie fakty), że te dokumenty w ogóle powstają (tu modele procesów biznesowych, szablony dokumentów, słowniki i reguły biznesowe, głównie notacje BPMN, SBVR, tu ewentualnie UML jako narzędzie dokumentowania aktualnego stanu IT w organizacji),
3. projekt rozwiązania problemu, czyli opis stanu docelowego: jakie rozwiązanie (zmiany organizacyjne, nowe systemy IT, inne) należy wdrożyć by zrealizować cel biznesowy; to etap napisania wymagań na nowe rozwiązanie, jeżeli zapada decyzja że będzie to nowe lub aktualizowane oprogramowanie, piszemy wymagania:
   1. jeżeli ryzyko projektu jest niezbyt duże, opisać je tradycyjnie czyli cechami oczekiwanymi, np. zgodnie z normą IEEE Std 830-1998,
   2. jeżeli okaże się, że opis metodą cech zewnętrznych jest zbyt ryzykowny (czyli w zasadzie każdy nietrywialny system), idziemy w MDA/MDE (model PIM w UML, INCOSE/SysML) opisywane na tym blogu nie raz bo w tym się specjalizuję.

Dokumentacja w procesach prowadzonych zwinnie – czy jest potrzebna, jak dokładna powinna być, kiedy powinna być tworzona, kiedy się przydaje?

O zwinności w IT zapisano tony papieru :).

Każdy kto poszedł do sklepu i wrócił z niego bez ważnych sprawunków, wie po co piszemy listy zakupów: nie mamy aż tak dobrej pamięci. Generalnie brak dokumentacji ma takie same skutki jak jej nadmiar: bardzo szkodzi w projekcie i podnosi koszty. Dokumentacja to komunikacja między uczestnikami projektu i samemu z sobą (przeczytajcie swoje dokumenty z przed kilku miesięcy, a nawet tylko z przed tygodni).

Co do zasady, dokumentować należy wszystkie decyzje, w szczególności architektoniczne. Decyzjami są w szczególności zatwierdzone wymagania (klient zdecydował, że chce TO mieć).  Podstawowym celem tworzenia dokumentacji jest potrzeba wiedzy o tym CO ZOSTAŁO ZAMÓWIONE oraz CO ZOSTAŁO ZROBIONE i DLACZEGO TAK.

Pod pojęciem zwinności rozumiem takie prowadzenie projektu i dokumentacji, by nie powstawały treści (dokumenty) zbędne, czyli przede wszystkim nie powinny powstawać opisy zawierające:

1. szybko dezaktualizujące się detale, projekt trwa w czasie a czas to zmiana otoczenia rynkowego czyli także  wymagań,
2. zapisy treści spotkań, zupełnie wystarczy pierwotny dokument wymagań (patrz wyżej produkt analizy) i bieżące aktualizowanie go na podstawie zgłoszonych żądanych zmian lub pytań o kolejne szczegóły.

Tu podam przykład: dokumentacja wymagań dla Senatu miała w momencie rozpoczęcia prac developera (wymagania na dzień ogłoszenie przetargu) 35 stron (wartość oferty na wykonanie tego co w niej opisano to ok. 250 tys.). Plan komunikacji wyglądał tak, że odpowiedzią na każde pytanie developera była odpowiedź (nadzór autorski) w postaci zaktualizowanej w odpowiednim miejscu dokumentacji z początku projektu. Developer musiał z góry deklarować wszystkie swoje bieżące techniczne decyzje (koncepcja wdrożenia), które były także nanoszone w dokumentacji.  W efekcie w dniu zakończenia tworzenia oprogramowania istniała kompletna jego dokumentacja: miała 84 strony. Reszta to detale w kodzie i dokument Koncepcji Wdrożenia czyli to co opracował i wykonał developer (ja się na to tylko powołuję).

Nie jest też prawdą, że dokumentacja jest (liniowo?) tym większa im większa aplikacja ma powstać. Im większa aplikacja tym dłużej w czasie trwa jej powstawanie, dlatego im większy projekt tym dokumentacja jest bardziej polityką budowy systemu, jego architektura i koncepcja, niż detalicznym projektem, co oczywiście wcale nie znaczy, że jej powstanie nie będzie kosztowniejsze: do przeanalizowania jest duża organizacja i duży projekt.

Jakość tworzonej dokumentacji (temat omawiamy przy okazji wspomnienia o instrukcji wyłączenia kontroli składni w EA)

O jakości dokumentacji decyduje w 100% jej zrozumiałość (w tym także więc jednoznaczność), spójność  i kompletność (nie mylić z jakością samego opisanego w niej projektu). To zaś oznacza, że wszelkie odstępstwa od standardów to pogorszenie jakości. Ideałem jest taki dokument, który został w całości przeczytany przez jego adresata developera (a więc niezbyt obszerny) i nie wymaga kontaktu z jego autorem to by zrozumieć jego treść i jednoznacznie ją zinterpretować. W przetargach miernikiem jakości jest np. liczba pytań oferentów do treści wymagań a w każdym projekcie ilość wprowadzanych zmian (ale nie rozszerzeń). Tak więc odstępstwa od zasad stosowania użytych notacji, stosowanie slangu w treści, stosowanie niestandardowych i zamkniętych  licencjami metod i notacji, brak słownika pojęć, to wszystko powoduje, że dokumentacja staje się sama z siebie problemem w projekcie.

Jedną z najgorszych rzeczy jest niestety łamanie zasad użytej notacji, a nie raz po prostu nieumiejętne (niezamierzone) jej stosowanie. W jednej z książek na temat użycia UML, jej autor słusznie zauważa we wstępie:

Wielu autorów dokumentów projektowych używa UML (BPMN, itp.) nie jak sformalizowanych systemów notacyjnych a jak biblioteki symboli w Power Poincie, jest to tragedia tych autorów.

(o walidacji w EA niedawno pisałem więcej)

Narzędzia wspomagające pracę analityka – visual paradigm (VP) a enterprise architect (EA), co lepsze, jak dokonać wyboru

To klasyczne pytanie o narzędzia. Pierwsza rzecz: narzędzie, które znasz jest zawsze lepsze od tego, którego nie znasz. Warto też wiedzieć, że na rynku pracy standardem de facto jest nadal EA (wystarczy spojrzeć na ogłoszenia o pracę). Od tego momentu będzie subiektywnie ;):

• EA jest relatywnie tani, dość powszechny, ale też mało ergonomiczny i bardzo pracochłonny, nadal dominuje w korporacjach i dużych firmach  IT bo tu liczy się dostępność kompetencji na rynku pracy zaś koszt  projektów spada na drugi plan bo klienci i tak zapłacą za “mendejsy”.
• VP jest droższy od EA, zaczyna jednak dominować w małych firmach o małej rotacji pracowników i u freelancerów, bo jest ergonomiczny, ma bardzo dobre wsparcie dla sformalizowanych notacji a także dla metodyk zwinnych, ma wersje polską (w tym polską kontrolę ortografii), pozwala tworzyć w locie dokumentację bez potrzeby korzystania z pakietów biurowych i programowania SQL; VP daje bardzo wysokiej jakości usługi w chmurze jakimi są serwer wersjonujący projekty i narzędzia do zdalnej komunikacji z klientami (1 GB na projekty w cenie licencji).

Ja używam VP od 2005 r., na warsztatach zaś nadal regularnie miewam uczestników z EA, zawsze mają jakieś z tworzeniem diagramów w zgodzie z notacją i metodami takim jak śladowanie i zawsze tworzenie diagramów trwa dłużej niż i mnie z użyciem VP.

Od prawie 10 lat nie używam pakietów biurowych (edytorów tekstów i arkuszy kalkulacyjnych) do tworzenia dokumentacji (wyżej wskazana dokumentacja dla Senatu  powstała w 100% z użyciem VP).

Sami więc musicie wybrać…

Czy “logowanie” jest przypadkiem użycia ( )

Logowanie nie jest powodem zakupu oprogramowania, logowanie to jedna z możliwych implementacji wymagania ?tylko autoryzowany użytkownik może korzystać z aplikacji?, co nie przeszkadza większości amatorów używania tych diagramów (w tym autorów książek) potraktowania logowania jako przypadku użycia aplikacji. Dobrym testem sensu umieszczania takich rzeczy na diagramach przypadków użycia jest zadawanie sobie pytania: ?czy kupił byś tę aplikację tylko dla tego jednego przypadku użycia??

Tyle cytat z mojego artykułu Ile przypadków użycia? | | Jarosław Żeliński IT-Consulting (polecam lekturę całego).  Wiele nieporozumień tworzy książka Alistaira Cockburn’a Stosowanie przypadków użycia: jego książka nie ma nic wspólnego z UML. Jeżeli powyższe jednak pytanie o przypadki użycia dotyczy diagramów w UML, to przypadek użycia jest tam definiowany jako “usługa dla aktora świadczona przez system, dla której to usługi został on kupiony/stworzony”.  Mam świadomość ile jest tego rodzaju przykładów (logowanie jako przypadek użycia) w sieci, ale warto tu nie być konformistą…

Przypomnę, że także opcja w menu każdego oprogramowania [Exit/Zakończ/Wyloguj] jest klikana, ma dialog [czy jesteś pewien TAK/NIE] i mimo to nie jest przypadkiem użycia tego oprogramowania.

Jaka jest różnica między analitykiem biznesowym a analitykiem systemowym

Na to pytanie nie ma odpowiedzi, bo te pojęcia nie mają ścisłej definicji. Zwyczajowo się przyjmuje w wielu firmach podział na:

• analityk biznesowy zbiera i porządkuje wymagania (elicitation),
• analityk systemowy coś projektuje w UML (system description).

Patrząc na wcześniejsze moje odpowiedzi:

• często analitykiem biznesowym nazywa się osobę tworzącą SRS (System Requirements Specification, specyfikacja wymagań), najczęściej zgodnie z IEEE Std 830-1998,
• często analitykiem systemowych nazywa się architekta oprogramowania (co nie do końca jest zgodne z prawdą i faktami),
• ale w MDA powstają modele: CIM, PIM PSM, analityk biznesowy (patrz także IIBA) powinien być autorem modeli CIM i PIM, developer (wykonawca) wykona implementację i być może wykona także model PSM; rola tak zwanego analityk systemowego zanika, nie tylko w literaturze, jako sztuczna rola pomiędzy tymi dwiema (analityk projektant i developer czyli wykonawca).

Cel biznesowy w dokumentacji – co zrobić, gdy: brak jasno sprecyzowanego celu biznesowego; cele biznesowe wykluczają się nawzajem; cele biznesowe wykraczają poza obszar projektu

To będzie krótka odpowiedź: nie realizować takiego projektu. Wiem, że pracodawcy analityka może się taka odpowiedź nie spodobać, ale podtrzymuję swoje zdanie. Jeżeli nie uda się zamawiającego namówić na usunięcie tej wady projektu, uczciwy analityk się wycofa… W przeciwnym wypadku ktoś w końcu powie głośno: dostaliśmy dokładnie to co chcieliśmy i zupełnie nie to czego potrzebujemy.

Czy rejestrować funkcjonalności, których realizacja została wykluczona podczas specyfikowania

Najlepszą znaną mi metodą zarządzania wymaganiami jest zarządzanie ich statusami (w tym status: poza zakresem projektu), więc nie usuwamy ich ze specyfikacji. To pomaga później przypomnieć innym, że wymaganie było i dlaczego zostało usunięte z zakresu. Czasem jest ono przesuwane do kolejnej nowszej wersji. Dobrą praktyką jest zapisanie dla każdego wymagania: właściciela czyli osoby zgłaszającego wymaganie po stronie zamawiającego, szacowanego kosztu implementacji, bieżącego statusu.

Czy zawsze warto analizować organizacje i otoczenie biznesowe projektu

Zawsze :). Bez tego nie wiemy nic o sense i celu projektu 🙂  … Tu uwaga: dobry analityk to nie najemnik, który jak mu zapłacą zrobi każda głupotę… patrz wyżej pytanie o realizację projektu mającego źle sformułowane cele.

Jak rejestrować uprawnienia użytkowników – macierz uprawnień?

Obecnie macierz to chyba (poza rzadkimi wyjątkami) najgorsza metoda. Zarówno z powodu zmienności uprawnień w trakcie życia organizacji jak i nie raz ogromnych rozmiarów takiej macierzy. Uprawnienia dokumentujemy i zarządzamy nimi w aplikacjach z użyciem reguł biznesowych. To pozwala by aplikacja sama dynamicznie tym uprawnieniami zarządzała, np. “prawa dostępu do treści dokumentu ma tylko osoba prowadząca sprawę związaną z tym dokumentem oraz jej bezpośredni przełożony”. Zmiany kadrowe, przekazanie sprawy innej osobie, nie przełożą się na jakąkolwiek pracochłonność związaną z prawami dostępu do dokumentu, administrator systemu jest wyłączony z ingerowania te w prawa co dodatkowo podnosi bezpieczeństwo całości systemu.

Jedną, z chyba najgorszych, metod dokumentowania uprawnień jest diagram przypadków użycia, który dzięki temu natychmiast staje się nie raz monstrualnie rozbudowany (czyli nieczytelny).

I Ty zadaj pytanie…

Zachęcam do zadawania kolejnych pytań i dyskusji pod tym artykułem, szczególnie tych którzy nie znaleźli tu odpowiedzi na nurtujące ich pytania, a chcą poznać moje zdanie ;), i pamiętaj: zanim zadasz pytanie, upewnij się, że chcesz poznać odpowiedź ;).