
Analiza systemowa zdalnie
Całkiem niedawno wpadł mi w oczy artykuł na temat zdalnego prowadzenia analizy, ostatni jego akapit brzmi:
Virtual communication and facilitation skills will remain a key competency for BAs for years to come. Stop torturing your stakeholders with boring, ineffective conference calls. Find new and creative ways to alleviate the common pain points. Please share your virtual facilitation tips in the comments below! (Business Analyst | Virtual Requirements Meetings: Painful or Practical?).
(w uproszczeniu: zdalnie prowadzona analiza to kluczowa przyszła kompetencja analityków, warto przestać torturować ludzi wielogodzinnymi nudnymi spotkaniami, znajdź inna kreatywną drogę…).
Nie ja pierwszy odkryłem, że spotkania i warsztaty, to po pierwsze ogromny koszt (jeden dzień takich warsztatów to łączny koszt dniówek wszystkich obecnych na spotkaniu). Po drugie, takie zbiorowe dyskusje najczęściej niestety są nudne i męczące, szybko zmieniają się w niekończące się negocjacje, a zatwierdzanie notatek z takich spotkań to kolejna droga przez mękę (wysłane do wszystkich obecnych wracają z uwagami, te trzeba nanieść i rozesłać dokument jeszcze raz…).
Tak zwane warsztaty wymagań (tak zwane [[sesje JAD]]) to jedna z najbardziej wynaturzonych form tych spotkań, bo ich uczestnicy walczą jak o ogień by zdobyć zapis sankcjonujących ich (nieraz bardzo pobożne) życzenia, każdy zgłasza swoje pomysły na implementację, coraz to nowe fajerwerki, pseudo udogodnienia i oczywiście uprawnienia dla siebie w nowej aplikacji. Złośliwi mawiają, że objętość specyfikacji wymagań jest wprost proporcjonalna do czasu trwania (ilości) takich warsztatów. Konsultanci zarabiają też proporcjonalnie (koszt dnia pracy) a przyszli użytkownicy zgłaszają coraz to nowsze pomysły (z czasem coraz bardziej z poza zakresu projektu).
Alternatywą dla tych zjadających czas i pieniądze warsztatów jest analiza dokumentów operacyjnych. Zawierają one z reguły ok. 80% wszystkich istotnych informacji (organizacji z zasady dokumentują istotne dla nich rzeczy), w toku pracy nad tymi dokumentami można wychwycić ewentualne braki (to co jest realizowane nieformalnie a warto jednak zacząć dokumentować) oraz niepotrzebne już dokumenty (zmieniono procedury a nie wycofano wzorów dokumentów). Wszelkie wątpliwości można wyjaśniać telefonicznie lub na krótkich spotkaniach „w cztery oczy” z konkretną osobą, ekspertem z danej dziedziny, kierownikiem działu itp. Co ciekawe, tą metodą można analizę z góry wycenić (liczba dokumentów do analizy jest skończona więc zakres pracy także) i podpisać z analitykiem umowę „fixed price”.
Pracując w ten sposób unikamy także wszelkich nacisków ze strony uczestników spotkań. W trakcie typowych zbiorowych warsztatów i burz mózgów, bardzo często niestety mają miejsce, ze strony uczestników tych spotkań, udane próby przemycania dodatkowych nieuzasadnionych uprawnień, obrona status quo na swoim stanowisku itp. Badanie dokumentów operacyjnych jest wolne od tego ryzyka. Wyjaśnianiu podlegają wyłącznie nieścisłości w dokumentach. Na ich podstawie powstają modele procesów biznesowych, wzory dokumentów w tych procesach itp. Zgłaszanie uwag do powstającej dokumentacji analitycznej jest znacznie efektywniejsze niż walka o każde jej zdanie w trakcie warsztatów, jest także znacznie tańsze, bo tak zwani eksperci dziedzinowi klienta oraz przyszli użytkownicy, pracują nad swoimi uwagami w chwilach wolnych (nie są to narzucone terminy spotkań) i zajmuj im to znaczne mniej czasu (nie musza z nikim się spierać). Dodatkową zaletą jest pisemny ślad po każdej zmianie, po każdym nowym zgłoszeniu (każdy sam spisuje swoje uwagi i propozycje).
Owszem, w wielu organizacjach jest ogromna niechęć do takiej pracy ale zaryzykuję tezę, że jedynym powodem tej niechęci jest nielubiana przez część ludzi odpowiedzialność za każde swoje słowo. Ta metoda pracy wyklucza zbiorową odpowiedzialność za wyniki zbiorowo prowadzonej analizy wymagań.
Tą metoda pracuje już kilka lat, korzystając z elektronicznego repozytorium dokumentów i systemu obiegu dokumentów i treści (nie korzystam z poczty elektronicznej do prowadzenia projektów z uwagi na bałagan jaki wprowadza!).
Od około dwóch lat dysponują bardzo dobrym narzędziem, które pozwala na płynną zdalną interaktywną pracę, już nie na poziomie kolejnych wersji wysyłanej wynikowej analizy, a na poziomie pojedynczych diagramów i ich opisów. Jest to bezpieczne oprogramowanie pozwalające mi, analitykowi, zdalnie prezentować bieżące efekty pracy i przyjmować na bieżąco uwagi. Narzędzia te opisałem tu:
Dla utrzymania wysokiej jakości efektów pracy stosuję sprawdzone na rynku oprogramowanie firmy Visual-Paradigm. W moich projektach nie są wykorzystywane do pracy żadne bezpłatne czy społecznościowe zasoby Internetu, gdyż dostawcy tych usług nie biorą za nie odpowiedzialności, ograniczają, a nie raz przejmują, prawa do przetrzymywanych tam dokumentów i treści. Z oprogramowania firmy Visual-Paradigm korzystają największe koncerny na świecie (lista wybranych użytkowników pakietu Visual-Paradigm. Nagrody dla Visual Paradigm). (Źródło: Analiza Biznesowa – narzędzia CASE, Visual-Paradigm | Jarosław Żeliński IT-Consulting)
Okazuje się, że można prowadzić zwinnie nawet takie analizy, oszczędzić czas członków zespołu i innych uczestników projektu (także interesariuszy, którzy mogą brać udział w takiej pracy). Zalety opisane w cytowanym na początku artykule mogę tylko potwierdzić. Owszem nie raz spotykam się z firmami, których pracownicy preferują spotkania nad pisanie.
Kluczowym powodem niechęci do pisania jest utrata możliwości nacisku na analityka, w celu pozyskania korzystnych dla siebie, a nie koniecznie dla sponsora projektu, zapisów w dokumentacji. Po drugie grupowe spotkania i warsztaty drastycznie rozmywają odpowiedzialność za udzielane informacje.
Opór przed pisaniem to najczęściej niechęć do pozostawiania śladów po swoich uwagach i propozycjach. W wielu firmach i instytucjach publicznych spotykam się z ogromną niechęcią do takiej pracy. Zbiorowe spotkania i warsztaty pozostawiają po sobie listę życzeń, pod nią listę obecności ale nie wiadomo kto co zgłosił, a to prowadzi do zupełnego braku odpowiedzialności uczestników takich warsztatów za treść notatek jakie na nich powstają.
Tak, metodami zbiorowych warsztatów, powstają z reguły dokumenty bardzo niskiej jakości, bardzo pracochłonne, będące mało merytorycznym zgniłym kompromisem, zawierają masę niespójności, są strasznie nadmiarowe. Nie raz są to dokumenty mające, po ok. roku albo i więcej pracy! nawet kilka tysięcy stron!… których z reguły już nikt nigdy nie czyta!
Dobra dokumentacja analityka biznesowego w tym wymagania, to ok. 50 – 100 stron (największe moje projekty to ok. 200 str. w tym ponad 50% to diagramy) zawierające opis (modele) logiki działania organizacji i logiki jaką ma realizować przyszłe oprogramowanie. Szczegóły techniczne (w tym model danych!) powinien opracować dopiero wykonawca, na etapie analizy wymagań (koncepcja implementacji i wdrożenia), nie ma sensu zbyt wczesne „żądanie” konkretnych technologii, technologia jest konsekwencją wymagań poza-funkcjonalnych. Przypomnę, że wymagania to warunki jakie ma spełnić oprogramowanie a nie detaliczny projekt. Owszem logika działania biznesu, w postaci modelu dziedziny, jak najbardziej powinna powstać, bo to jest wymaganie: „taki ma być mechanizm działania” zamawianej aplikacji.
Mam świadomość, że nie wszędzie zastosowanie zdalnej pracy jest możliwe ale takich przypadków jest mało. Podstawą i wystarczającym elementem jest wola po stronie zamawiającego taką usługę, mam tu na myśli sponsora projektu czyli zarząd firmy. Zapraszam do kontaktu.
Inne artykuły na podobny temat
- Plansza do gry w szachy czyli analiza i projektowanie
- Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy
- Proces zbierania i analizy wymagań u developera
- Rentowność projektu czyli jego wizja i wykonywalność – należy planować
- Agile w PZP

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
warto zajrzeć:
https://mfiles.pl/pl/index.php/Analiza_systemowa