Wprowadzenie

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ę…).

tak więc 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…).

Artykuł ten napisałem w 2015 roku, teraz (2022) Podobnie jak wielu analityków na świecie, dawno już zrezygnowałem z wywiadów i cyklicznych grupowych warsztatów w lokalizacji klienta, na rzecz zdalnej pracy opartej na przekazanych mi materiałach (dokumentach) a także (patrz: niska efektywność spotkań i ich ogromne koszty), zaś standardowo zdalna praca (w tym tele konferencje) w moich projektach to obecnie 100%.

Dzięki temu łączna pracochłonność (szczególnie po stronie kadr zamawiającego) i koszt projektu analitycznego, są nawet o 70% niższe, w porównaniu z cyklicznymi spotkaniami i używaniem oprogramowania biurowego (email, edytor tekstu, arkusz kalkulacyjny) do komunikacji i wymiany treści! (przeczytaj też: Dlaczego nie używam poczty elektronicznej do przekazywania materiałów).

Warsztaty

Ludzie i ich pra­ca to infor­ma­cje i ich wymia­na. Komputer i opro­gra­mo­wa­nie to mecha­nizm prze­twa­rza­nia danych repre­zen­tu­ją­cych te infor­ma­cje. Projektowanie opro­gra­mo­wa­nia pole­ga na zro­zu­mie­niu i opi­sa­niu tego mecha­ni­zmu, tego jakie to dane i jak są (ana­li­za) lub powin­ny być (pro­jek­to­wa­nie) prze­twa­rza­ne. Aby to zro­bić ana­li­zu­je­my doku­men­ty, nie robi­my wywiadów. Jeżeli ktoś tego nie potra­fi i nie rozu­mie, zaczy­na orga­ni­zo­wać wywia­dy i kodo­wać to, co ludzie postrze­ga­ją ze swo­jej per­spek­ty­wy. Tak powsta­je naj­gor­sze oprogramowanie. 

źr.: Produkt analizy jako twierdzenie naukowe – Jarosław Żeliński IT-Consulting

Tak zwane warsztaty wymagań (kiedyś zwane sesjami JAD, ang. Joint Application Development) to jedna z najbardziej nieefektywnych form zbierania wymagań, bo ich uczestnicy zgłaszają subiektywne oczekiwania oparte na swoim dotychczasowym doświadczeniu. Nie raz zgłaszają swoje techniczne pomysły na implementację funkcjonalności, co rzadko bywa faktycznie optymalnym rozwiązaniem. Rzecz w tym, że te zapisy są oparte na subiektywnych odczuciach pracowników, często nie popartych faktami, są niespójne, niekompletne i niejednoznaczne co potwierdzają badania tak powstałych specyfikacji . Niestety częstym zjawiskiem jest zgłaszanie wymagań łamiących zasady bezpieczeństwa, najczęściej spotykane to ekspert danych na zewnętrzne nośniki, przenoszenie treści wprost z ekranu do popularnych pakietów biurowych).

Analiza oparta na faktach

Alternatywą dla tych zjadających czas i pieniądze warsztatów jest analiza dokumentów operacyjnych . Zawierają one z reguły ok. 80-90% wszystkich istotnych informacji (organizacje 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 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”.

Oprogramowanie biznesowe to system przetwarzania danych o tym co robi firma (organizacja). Te dane to dokumenty, opis faktów czyli tego co zachodzi w organizacji. Dlatego przedmiotem analizy jest “System informacyjny” jako zestaw dokumentów i formularzy oraz ich treść oraz mechanizm ich przetwarzania, a nie “maszyny, urządzenia i ludzie” (Środowisko lokalne organizacji).

To rolą pracowników organizacji jest umiejętność użycia lokalnego wyposażenia. Jednym z jego elementów jest komputer i jego Oprogramowanie (system informacyjny), który realizuje funkcje dotyczące przetwarzania danych wprowadzanych do niego.

Dlatego celem analizy i projektowania jest udokumentowanie Systemu Informacyjnego i mechanizmu przetwarzania danych, a nie audyt pomieszczeń biurowych i hal fabrycznych. Opis Mechanizmu przetwarzania informacji stanowią potem Wymagania na oprogramowanie (przetwarzanie danych).

Pracując  w ten sposób (praca na dokumentach) unikamy także wszelkich nacisków ze strony uczestników spotkań. 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.  Pisemne 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, kadry kierownicze Zamawiającego oraz przyszli użytkownicy, pracują nad swoimi uwagami w chwilach wolnych (nie są to narzucone terminy spotkań) i zajmuje im to znaczne mniej czasu (nie musza z nikim się spierać). Dodatkową zaletą jest pisemna historia zmian (każdy sam spisuje swoje uwagi i propozycje). Badania projektów pokazują, że tak prowadzone analizy przedwdrożeniowe systemów ERP, realizowane metodami zorientowanymi na fakty, dają znacznie lepsze efekty .

Zdalnie czyli jak?

Od wielu lat pracuję korzystając z elektronicznego systemu zarządzania procesem analizy i recenzowania. Jest to repozytorium powstających modeli i treści, zebranych dokumentów oraz narzędzie komunikacji (nie korzystam z poczty elektronicznej do prowadzenia projektów z uwagi na bałagan jaki wprowadza!).

Dysponują bardzo dobrym narzędziem (patrz Postmania), które pozwala na płynną zdalną interaktywną pracę, już nie tylko na poziomie draftu całego dokumentu analizy, ale 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 (2,5 min, można oglądać bez dźwięku): 

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: Komunikacja w projekcie)

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 bywa, że biorę udział w spotkaniach, gdy pracownicy preferują spotkania nad pisanie, jednak to bardzo wydłuża cały proces i znacznie podnosi koszty.

Więc skąd ten opór?

W wielu organizacjach jest ogromna niechęć do pracy polegającej na pisaniu, jednak ta metoda pracy wyklucza zbiorową odpowiedzialność za wyniki zbiorowo prowadzonej analizy wymagań . Analityk jest często traktowany jak sekretarz, na co wielu autorów na świecie zwraca uwagę. Jest to efekt braku doświadczenia z pracą inną niż spotkania oraz przekonanie, że “inaczej nie można bo wszyscy tak robią”, a fakty są takie, że analizy i projektowanie są na świecie coraz częściej prowadzone, podobnie jak prace programistyczne i audytorskie: zdalnie i w oparciu o dokumenty.

Podsumowanie

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” (Design by committee is a pejorative term for a project that has many designers involved but no unifying plan or vision.), zawierają masę niespójności, są strasznie nadmiarowe. Nie raz są to dokumenty powstające po ok. roku albo i więcej pracy! Mają nie raz setki 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% ich treści to diagramy) zawierające opis i modele logiki działania organizacji i logiki jaką ma realizować przyszłe oprogramowanie (mechanizm działania). Szczegóły techniczne implementacji powinien opracować wykonawca na etapie przygotowania implementacji (koncepcja implementacji i wdrożenia), nie ma sensu zbyt wczesne “żądanie”  konkretnych technologii, technologia jest konsekwencją wymagań poza-funkcjonalnych. Przypomnę, że wymagania to warunki (logika, architektura biznesowa) jakie ma spełnić oprogramowanie a nie detaliczny projekt. Owszem logika działania biznesu, w postaci modelu procesów i modeli dziedziny systemu, 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 bardzo 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.

Źródła