Kto powinien być analitykiem systemowym, informatyk, czy znawca badanej dziedziny? Jaką uczelnię powinien skończyć, aby poprawnie wywiązywać się ze swoich zadań? Powinien reprezentować interesariuszy biznesowych, a może zespół informatyczny, który będzie wykonywał prace projektowe. Gdzie w ogóle uczą bycia analitykiem systemowym? Hm, sporo tych pytań i nie bardzo wiadomo jak na nie odpowiedzieć. Ja jednak spróbuje to zrobić w tym artykule.
Wróćmy na początek do definicji. Wygląda na to, że analityk systemowy powinien przynajmniej być w stanie zrozumieć daną dziedzinę biznesową, bo inaczej jak by miał analizować „złożone problemy organizacji”. Tę tezę potwierdza również fakt, że musi to wszystko później opisać ludziom, którzy będą implementować jego rozwiązania w systemie informatycznym. Musi to zrobić w taki sposób, aby nie powtórzyła się znana historyjka z huśtawką (gdzie huśtawka spełnia wszystkie wymagania, ale nie da się na niej huśtać).
A więc analityk systemowy nie tylko musi zebrać wymagania i przetłumaczyć je na język bardziej strawny przez informatyków, ale również dopilnować, aby jego intencje zostały zrealizowane we właściwy sposób przez zespół informatyczny.
Spójrzmy na sprawę z jeszcze innej perspektywy. Co będzie jeśli wymagania są zebrane, system w połowie zaimplementowany, a rząd wprowadzi nową ustawę, która całkowicie wywróci projekt do góry nogami? Albo co będzie jak sprawdzi się powszechna opinia, że użytkownicy biznesowi sami nie wiedzą czego chcą dopóki czegoś nie zobaczą? Kto wtedy będzie odpowiedzialny za wyprostowanie sprawy?
Kto powinien być analitykiem systemowym?
Najlepiej jakby była to osoba z doświadczeniem. Wynika to z tego, że rzadko uczy się na uczelniach analizy systemowej. Na informatyce jest to elementem inżynierii oprogramowania i uczą tego zwykle informatycy. Z kolei na uczelniach dziedzinowych gorzej jest z nauczaniem elementów „twardej” wiedzy informatycznej (oczywiście pewnie znajda się wyjątki). A tymczasem analityk powinien być dość zaawansowany technicznie, aby wiedział co się da zrobić, a czego nie. Z drugiej strony powinien umieć słuchać i nie bać się pytać, gdy czegoś nie rozumie. Parafrazując znaną maksymę „analityk ma dwoje uszu, a tylko jedne usta po to, aby dwa razy więcej słuchać niż mówić”. Jednak mówić powinien, szczególnie wypytać o wszystko czego nie rozumie, więc nieśmiałość i poczucie wstydu z byle powodu odpada.
Dodatkowo bardzo przydatne jest, jeśli analityk zna się na dziedzinie, której problemy analizuje. Analityk będzie dużo rozmawiał z biznesem i jeśli będzie ciągle zadawał pytania w stylu „co to jest prolongata” doprowadzi do irytacji swoich rozmówców. Ale i tak lepsze to niż udawać, że się wszystko rozumie.
Rola i odpowiedzialność w projekcie
Z grubsza rzecz biorąc, rolą analityka systemowego w projekcie jest zbieranie i zarządzanie wymaganiami. Aby tego dokonać analityk musi zadbać o to, aby znane mu były przynajmniej te procesy biznesowe, które mają jakąś interakcję z budowanym systemem.
Po zrozumieniu niezbędnych procesów biznesowych, analityk systemowy zajmuje się wydobywaniem wymagań na system. Musi zatem zlokalizować miejsca styku procesów biznesowych z systemem i opisać to, jak w poszczególnych procesach biznesowych wykorzystywany będzie system i kto z niego będzie w tych miejscach korzystał. Do opisywania tej części rzeczywistości, analityk na szczęście ma stosowne narzędzia, a na ich czele stoi UML (ang. Unified Modeling Language).
W następnym etapie, analityk musi opisać jak dana interakcja z systemem (przypadek użycia) będzie obsługiwana przez system.
Warsztat łącznika dwóch światów
Procesy biznesowe – niby nie jest niezbędne ich rozumienie, zawsze można skupić się na wymaganiach funkcjonalnych i zapomnieć o zrozumieniu merytoryki procesów biznesowych. Jednak użytkownicy, którzy opowiadają o swoich wymaganiach zwykli o czymś zapominać. Ponieważ lepiej żeby sobie przypomnieli już na samym początku, podczas rozmów o tym jak pracują i próby zrozumienia procesów biznesowych, można ograniczyć przeoczenia, czy niedociągnięcia. Trzeba też pamiętać, że ludzie biznesu nie robią tego złośliwie, raczej niektóre rzeczy wydają się tak oczywiste, że „nie warto o nich wspominać”. Do modelowania procesów biznesowych można wykorzystać diagramy aktywności w UML. Są też bardziej dedykowane notacje, jak BPMN (ang. Business Process Modeling Notation).
Funkcjonalność systemu – do modelowania funkcjonalności używa się zwykle diagramu przypadków użycia (ang. Use Case Diagram). Są na nim dwa główne artefakty. Pierwszy z nich – Aktor – obrazuje osobę lub urządzenie korzystające z systemu. Drugi artefakt, to Przypadek użycia (ang. Use Case) odzwierciedla on funkcję systemu, którą wykorzystuje Aktor. Należy zaznaczyć, że aktor jest zawsze na zewnątrz Systemu, a Przypadek użycia obrazuje to, co się dzieje wewnątrz.
Realizacja funkcji systemu – aby dowiedzieć się jak działa dana funkcja systemu niezbędny jest opis danego przypadku użycia. Służą do tego scenariusze. Można je opisywać za pomocą języka naturalnego, lub skorzystać z części UML jaką są diagramy aktywności.
Narzędzi informatycznych wspierających opisywanie systemów za pomocą języka UML jest mnóstwo. Niektóre próbują nawet (z lepszym lub gorszym skutkiem) z takiego opisu generować gotowy kod systemu lub przynajmniej szkielet kodu, który później programista może uzupełnić.
Ciekawa nisza
Z punktu widzenia planowania kariery zawodowej, niewątpliwie warto rozważyć karierę analityka systemowego. Jeśli już przepracujemy przed ekranem monitora wiele godzin i przejdzie nam ochota na poznawanie kolejnego rewolucyjnego języka programowania warto rozważyć pracę bliżej biznesu. Dzięki temu można poznać wielu ciekawych ludzi, a charakter tej pracy da nam również możliwość poznania wielu dziedzin biznesowych, bo przygotowując wymagania na system informatyczny można naprawdę dużo dowiedzieć się o tym jak działają nawet najbardziej złożone organizacje.
Jeśli więc lubisz technologię i nie chcesz się z nią całkowicie rozstawać, a jednocześnie chciałbyś poszerzać swoje horyzonty, polecam zajęcie analityka systemowego. Może się okazać, że z czasem zagniesz swoją wiedzą o bankowości niejednego bankowca, a o księgowości niejednego księgowego.
