Sybena Consulting

Analiza systemów informacyjnych

Strona główna

Doświadczenie

Usługi

Wiedza

Relaks!

Kontakt

Projekty publiczne

Kilka słów na początek

Analitykiem może być każdy

Klient nie ma czasu na współpracę z analitykami

Praca analityków jest wykonywana powierzchownie

Praca analityków jest lekceważona

Bo klient mi nie powiedział

Mikrostandardy

 

Kilka słów na początek

Analiza systemów informacyjnych to temat potężny; nie mam zamiaru podawać tutaj pełnego wykładu o rodzajach analizy (systemowa, biznesowa, szczegółowa specyfikacja aplikacji...), podejściu („odwieczny” spór: obiektowo czy strukturalnie), modelach, językach, modelerach. To wymagałoby napisania (i późniejszego przeczytania przez Państwa) kilku książek – chociaż może kiedyś.... W tym materiale podaję kilka uwag dotyczących głównie organizacji procesu analizy. Ich celem nie jest systematyczne przedstawienie czegokolwiek. Na początek sformułuję tylko jedną uwagę: ważniejszą kwestią od tych wszystkich ważnych spraw, które wymieniłem na początku, jest rzetelne zrozumienie przez analityka dziedziny, w której pracuje i poważne traktowanie urobku analityków przez realizatorów następnych faz procesu technologicznego.

Analitykiem może być każdy

Pewien prominentny informatyk, gdy kompletowałem zespół analityków powiedział niedawno: „analitykiem może być każdy”.

Wiadomo, że branża informatyczna przeżywa w Polsce kryzys. Wydatki na tworzenie nowych systemów spadają dramatycznie. Systemy nie przynoszą zapowiadanych korzyści.

Według mnie zasadniczym powodem niespełniania nadziei przez wdrażane systemy jest przeświadczenie, że „analitykiem może być każdy”. Dopełnieniem tego stwierdzenia jest przeświadczenie, że zasadniczą rolę przy tworzeniu systemów odgrywają ich architekci – ci, którzy podejmują decyzje o podziale funkcji na moduły, wykorzystywanych technologiach, rozproszeniu systemu, zestawach baz danych.... Rzeczywiście – projekt architektoniczny decyduje o sprawności systemu. System źle zaprojektowany na wysokim poziomie ogólności nie może być sprawny. Ale co ma ten system robić? Na to zasadnicze pytanie może odpowiedzieć tylko sprawnie i fachowo wykonana analiza.

Klient nie ma czasu na współpracę z analitykami

„Odwiecznym” problemem przy organizacji pracy zespołu wykonującego duży projekt jest zapewnienie sobie współpracy z klientem. Trzeba pamiętać, że zawsze dla pracownika firmy wyższy priorytet mają jego podstawowe zadania służbowe. Osoba odpowiedzialna za księgowość musi w określonym terminie sporządzić obrotówkę czy bilans. Osoby zarządzające firmą naprawdę zawsze są zajęte do granic możliwości. A współpraca z ludźmi tworzącymi system – choćby w przyszłości system ten zaoszczędził przepracowanym ludziom połowy pracy i kłopotów – jest tylko zajęciem dodatkowym. W związku z tym do pracochłonnych zajęć związanych z analizą często są delegowani pracownicy bez których codzienne procedury firmy mogą w miarę sprawnie funkcjonować. Zdarza się, że są to osoby mniej rozeznane w analizowanych zagadnieniach, mniej sprawne. Praca z takimi ludźmi może spowodować nieuzyskanie wglądu w zasadnicze problemy. Efektem takiej sytuacji jest niewłaściwa specyfikacja systemu, nie trafianie w podstawowe potrzeby firmy.

Szczególnie ważnym problemem jest współpraca z decydentami odpowiedzialnymi za funkcjonowanie całości biznesu, dla którego system jest tworzony. Analitycy muszą mieć dostatecznie dużo czasu na rozmowy z osobami, które wiedzą, jakie są globalne nierozwiązane problemy biznesu. W trakcie analizy osoby te muszą podejmować decyzje o mniejszych lub większych zmianach procedur pracy – wprowadzanie zaawansowanych technologii zawsze stwarza wiele nowych możliwości ulepszenia sposobów działania. Decyzji takich nie mogą podejmować szeregowi, operacyjni pracownicy. Analiza często bywa blokowana przez oczekiwanie na akceptację proponowanych ulepszeń. Problem ten występuje szczególnie ostro w dużych firmach o rozbudowanej strukturze zarządczej.

Decydenci muszą sobie zdawać sprawę, że są jedynym źródłem podstawowych wymagań biznesowych. Brak właściwej współpracy decydentów przy formułowaniu problemów zarządczych, które mają być rozwiązywane przez wdrażany system, jest zapewne zasadniczym źródłem późniejszego rozczarowania tych samych decydentów słabymi wynikami wdrożeń. Rozwiązane mogą być tylko te problemy, które – przy aktywnej współpracy analityków – zostaną sformułowane przez decydentów.

Praca analityków jest wykonywana powierzchownie

Co może powiedzieć projektantowi systemu przypadek użycia, w którym mówi się, że „System produkuje raport dotyczący <tu tytuł raportu>. Analityk biznesu analizuje raport.” (autentyczny przypadek z analizy robionej dla hurtowni danych w dużej firmie telekomunikacyjnej). Wartość dodana wynikająca z takiego opisu jest żadna. To że raporty są produkowane i analizowane jest stwierdzeniem tak oczywistym, że nie warto na ich opisywanie poświęcić ani minuty czasu.

Analityk musi w swojej pracy koncentrować się na wyszukiwaniu i wspomaganiu rozwiązywania problemów, z którymi mają do czynienia przyszli użytkownicy. Wszystkie tworzone specyfikacje muszą dokumentować sposoby rozwiązywania tych problemów. Istnieją metodyki – na przykład metodyka popularnej w Polsce kilka lat temu firmy LBMS – akcentujące ciąg:

problem – wymaganie – rozwiązanie – realizacja rozwiązania.

Specyfikacja funkcji czy modelu danych w tym podejściu jest realizacją skonstruowanego przez analityka sposobu rozwiązania problemu. Głównym zadaniem nie może być tworzenie modelu czy opracowanie dokumentacji. Rozwiązania muszą, oczywiście być udokumentowane, ale praca ta jest wtórna w stosunku do podstawowej pracy myślowej analityka, którą jest rozwiązywanie problemów użytkownika. Gdy przyjmowałem do pracy analityków, zawsze mówiłem im, że nieporównywalnie większym grzechem jest brak znajomości dziedziny, brak wiedzy o sposobie rozwiązania problemów klienta niż mankamenty w sposobie dokumentowania wyników pracy.

Praca analityków jest lekceważona

Z moich obserwacji wynika, że najbardziej powszechny jest następujący sposób tworzenia systemów. Analitycy tworzą specyfikacje. Rozmawiają z klientem, z przyszłymi użytkownikami, czytają materiały dotyczące analizowanej dziedziny. Na tej podstawie powstają dokumenty: model danych, model procesów, model zdarzeń, czasami model wymagań czy inny model przypadków użycia albo model klas. Wyniki analizy przejmują następnie projektanci. Życzliwie patrzą na produkty analityków, starają się zrozumieć co tam jest napisane, zadają pytania analitykom. I na tej podstawie wyrabiają sobie swój własny obraz tego co ma być zrobione. I projektują. Ale projekt powstaje nie ściśle według „rozporządzeń” analityków, lecz według wyobrażeń projektantów. Zwykle nie istnieje w trakcie pracy projektantów ścisła dyscyplina. Nie jest tak, że biorą oni analityczny zapis po zapisie i starają się wymyślić implementację dla niego. Co najwyżej po wykonaniu projektu odbywa się sprawdzenie, czy projekt realizuje wyniki analizy. Następnie do pracy wchodzą deweloperzy. Ale to też ambitni ludzie – muszą włożyć w swoją pracę jak najwięcej inicjatywy. I znów sytuacja się powtarza. Programiści mniej lub bardziej życzliwie starają się zrozumieć o co chodziło projektantom – i robią swoje. Też wykonują powtórnie część pracy, którą już dawno zrobili analitycy. I rzeczywisty model tworzenia systemu można opisać stwierdzeniem: kto ma klawiaturę ten ma władzę. Jeżeli w proces tworzenia systemu włączeni są ludzie zajmujący się zapewnieniem jakości, to, w szczególności we wczesnych fazach starają się wyłapywać niespójności między fazami. Ale po pewnym czasie, pod presją czasu i budżetu, kierownictwo projektu coraz mniej chętnie słucha tych, którzy „przeszkadzają w szybkiej i sprawnej pracy innych zespołów”. W ostatecznym kształcie systemu trudno jest wyśledzić stwierdzenia zawarte w analitycznej specyfikacji.

Bo klient mi nie powiedział

Zdarza się, że po stwierdzeniu braków w analizie analityk twierdzi: „Tego nie ma w specyfikacji, bo osoby, z którymi rozmawiałem nic mi o tym nie powiedziały”. Z takim stwierdzeniem można zrobić kilka rzeczy. Na pewno można przerzucić winę za zaistniałą sytuację na użytkownika. Pozornie jest to słuszne i najwygodniejsze wyjście. Jasne, jeżeli użytkownik czegoś nie powiedział, to analityk nie może uzurpować sobie prawa do dodawania niczego do specyfikacji. Ale jeżeli systemu nie uda się wdrożyć, albo użytkownicy nie będą chcieli się nim posługiwać (co w sumie na jedno wychodzi), to nigdy ostateczna odpowiedzialność za niepowodzenie nie zostanie przypisana klientowi. W kartotece wytwórcy pozostanie nieudana próba. I nikt nie będzie się zastanawiał czy błąd popełnił kierownik projektu (który, oczywiście, jest odpowiedzialny zawsze za całość projektu), kierownik analityków czy analityk, który nie potrafił zidentyfikować problemów klienta. Analityk musi, używając wszystkich dostępnych sposobów, dowiedzieć się o co chodzi klientowi. Jeżeli klient nie chce rozmawiać z analitykiem, albo analityk nie potrafi zrozumieć języka klienta, to z punktu widzenia kierownictwa projektu jest to problem analityka. W skrajnych przypadkach analityk musi rozpoznać, czy druga strona współpracuje w dobrej wierze, czy rzeczywiście jest zaangażowana w sukces projektu. Wszyscy pozostali członkowie zespołu projektowego – architekci, testerzy, deweloperzy muszą mieć pełne merytoryczne zaufanie do analityków. Z ich punktu widzenia to właśnie analityk podejmuje decyzje o rozwiązaniach biznesowych. Podkreślam – z ich punktu widzenia, z wnętrza projektu – gdyż w rzeczywistości decyzje biznesowe muszą być podejmowane przed odpowiedzialnych przedstawicieli klienta. Ale ci przedstawiciele nie mogą być partnerami do rozmów dla osób nie pełniących w projekcie roli analitycznych.

Takie postawienie sprawy wcale nie oznacza, że analityk musi pokonywać wszystkie problemy związane z wykonywaniem analizy. Kwestie organizacyjne: zapewnienie dostępności ludzi, wygospodarowanie ich czasu na współpracę, uczynienie ich odpowiedzialnymi za możliwość współpracy z naszym zespołem, leżą po stronie osób odpowiedzialnych za realizację projektu po obydwu stronach: klienta i wykonawcy.

Mikrostandardy

Tworzenie dużych systemów wymaga stosowania dobrze określonych metodyk. Każda metodyka opisuje zestaw faz, które mają doprowadzić do szczęśliwego wdrożenia systemu. Zbierane są wymagania. Wymagania są analizowane. Na podstawie wymagań wykonywana jest specyfikacja systemu, na podstawie specyfikacji.... Fazy składają się z zadań, zadania z czynności. Każda czynność musi być udokumentowana.

Każda metodyka musi być dostosowana do warunków realizowanego projektu. Można opracowywać model zdarzeń albo nie opracowywać go. Można wykonać analizę obszarów krytycznych albo jej nie wykonywać. Jeśli system jest złożony, to muszą być uwzględniane problemy związane z podziałem pracy na mniejsze jednostki – na przykład według obszarów działania przyszłego systemu. Istnienie takiego podziału rzutuje na metodę pracy.

Powyższe decyzje są przykładem „dużych” decyzji metodycznych. Ale decyzje takie nie są jedyną pracą, która musi być wykonana przy określaniu sposobu pracy. Żeby zapewnić jednorodność wyników analizy należy opracować tzw. „mikrostandardy”. Pojęcie mikrostandardu najłatwiej jest wytłumaczyć na przykładzie pól typu „Opis”. W narzędziach wspomagających metodyki strukturalne dla każdej encji zwykle trzeba wypełnić pole tego typu. Predefiniowana metodyka rzadko kiedy mówi jaka ma być zawartość takiego pola. Jeśli nie opiszemy szczegółowo jego zawartości, to może się zdarzyć anegdotyczna sytuacja jak przy próbie opisu encji „pies”. Opis ten brzmiał: „Pani rano wyprowadza psa na smyczy”. Mikrostandard jednoznacznie precyzuje zawartość pól, które nie zostały zdefiniowane wcześniej. Dla pola „opis” w specyfikacji encji mikrostandard taki może nakazywać umieszczenie w nim następujących elementów:

·         Pierwsze zdanie musi mieć postać: „<nazwa encji> jest to....”. Na podstawie takiego zdania musi istnieć możliwość stwierdzenia, czy coś jest instancją (egzemplarzem, wcieleniem) encji.

·         Następne zdania powinny opisywać inne zasadnicze własności encji.

·         Sekcja DYNAMIKA ENCJI powinna zawierać informacje o tym, w jakiej sytuacji biznesowej encja jest tworzona; kiedy jest modyfikowana i ewentualnie usuwana.

·         Sekcja ŹRÓDŁO INFORMACJI powinna zawierać odniesienie do dokumentu lub osoby, która przekazała informacje będące podstawą do wyspecyfikowania encji.

Mikrostandardy pełnią bardzo ważną rolę w standardyzacji procesu analizy. Bez rygorystycznego stosowania mikrostandardów każdy analityk będzie produkował inne specyfikacje. Jeśli nie nakażemy analitykom stosowania się do nich, to istnieje niebezpieczeństwo, że w wielu miejscach przekażą reszcie zespołu projektowego wyłącznie informacje, które było łatwo im uzyskać – a nie te wszystkie, które rzeczywiście są potrzebne. 

Co zrobić z ustawą Prawo Zamówień Publicznych?

Co zrobić z Urzędem Zamówień Publicznych?

Kto ma wygrywać publiczne przetargi?

Czy najniższa cena oferty gwarantuje najniższy koszt?

Program rozwoju sportu

Wiedza o projektach

Model zarządzania wiedzą o projektach

Wiedza o projektach

Zarządzanie projektami nastawione na wiedzę

Agregaty projektów

Rodziny projektów

Agregaty projektów

Jednolity model zarządzania portfelami

Podstawy zarządzania portfelami

Modele dojrzałości

Dojrzałość systemów zarządzania projektami  

Dojrzałość metodyk zarządzania projektami

Meta-dojrzałość zarządzania projektami

Standardy i metodyki

Analiza ISO 21500 i porównanie z PMBoK® Guide

Siedem głównych standardów zarządzania projektami

Ogólne porównanie PMBoK, Prince 2 i CMMI

Szczegółowe porównanie PMBoK, Prince 2 i CMMI

Standardy PMI – spojrzenie krytyczne

Narzędzia Primavera a PMBoK

Zarządzanie jakością

Jakość w projektach informatycznych

Jakość dokumentów

Analiza

Analiza strategiczna

Analiza

Tworzenie tekstów analitycznych