|
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
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.
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.
„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.
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.
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.
|