Trzeba dodać, że nie wydałem ani jednego grosza na jakąkolwiek reklamę.

Muszę się przyznać, że tworząc darmowy kurs UML robiłem to początkowo z myślą o studentach, bo UML się przydaje na moich zajęciach, które prowadzę na MIM UW. Potęga “marketingu szeptanego” przeszła jednak moje najśmielsze oczekiwania.

Początkowa motywacja.

Jak wspomniałem, prowadzę na wydziale Matematyki Informatyki i Mechaniki Uniwersytetu Warszawskiego, zajęcia z inżynierii oprogramowania. Są to konkretnie laboratoria z Inżynierii Oprogramowania i mają za zadanie przećwiczyć (z grubsza rzecz biorąc) proces tworzenia oprogramowania. Równolegle do laboratorium jest prowadzony wykład, który ma dać podstawę teoretyczną i to bogactwo wiedzy mogłoby być wykorzystane na laboratorium od strony praktycznej. Pojawia się jednak mały problem, bo jedno i drugie (wykład i laboratorium) jest prowadzone równolegle i wykład czasami nie nadąża.
Nauczony doświadczeniem z poprzedniego roku postanowiłem się wysilić i wrzucić trochę wiedzy, która mogłaby pomóc i przygotować zawczasu przynajmniej tych studentów, którzy chcą coś robić więcej poza tym co muszą.

Co było dalej

Ponieważ z natury jestem (zdrowo ) leniwy potrzebuję dodatkowych bodźców. Na szczęście potrafię sobie te bodźce sam zapewnić i w myśl zasady “jak chcesz coś zrobić powiedz o tym wszystkim, a to zrobisz”, zrobiłem stronę służącą do zapisywania się na kurs i pochwaliłem sie paru znajomym. Między innymi mój stary kolega Jacek Laskowski, którego bloga gorąco polecam wszystkim pasjonatom JAVA i nie tylko, napisał o moim kursie na tymże blogu. Wcześniej dałem jeszcze link na goldenline.pl i się zaczęło.

Forma kursu

Długo zastanawiałem się nad formą i nad tym jak zdopingować ludzi do systematycznej pracy. Ostatecznie stanęło na wideo w odcinkach ze zdrową porcją wiedzy. Odcinki są podzielone odstępami około 3 dni, co wydawało mi się dobrym czasem na przetrawienie materiału i zrobienie ćwiczeń. Jednak jak zrobić, aby każdy uczestnik szedł swoim trybem (przecież nie wszyscy się zapisali równocześnie). Z pomocą przyszło tu narzędzie, które pozwala na automatyczne wysyłanie maili w określonych odstępach czasu.
W każdym mailu, staram się zwracać do uczestników w dość osobisty sposób tak, aby zapanowała dość luźna atmosfera i aby nawiązać ciekawą relację, bo przecież po drugiej stronie jest wartościowy człowiek. To przyniosło ciekawe efekty, ale o tym za chwilę.

Co się dzieje teraz

Od czasu opublikowania kursu cały czas przybywają nowi subskrybenci. Nazbierało się ich do dziś dnia prawie sześciuset. Ale to nie wszystko. Z wieloma nawiązałem ciekawą relację. Ludzie odpisują mi na maile, dziękują, dają cenne wskazówki i czekają na więcej.

Nic nie wskazuje na to, aby liczba subskrybentów przestała kiedykolwiek rosnąć, codziennie zapisuje się kilkadziesiąt nowych osób i wypada tylko się cieszyć, że z niczego wyszło tak wiele.

Jeśli zatem Ty również chcesz skorzystać, zapraszam !!!

Słownikowa definicja analityka systemowego mówi, że jest to osoba, która potrafi analizować złożone problemy organizacji w celu opisania tych problemów i przedstawienia ich w formie możliwej do przetwarzania przez systemy informatyczne. No dobrze, ale co to tak naprawdę znaczy? 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.

Autor książki jest mi wyjątkowo bliski. Nie dlatego, że znam go osobiście, ale ujawniają się tutaj lokalne sentymenty. Pochodzi z Kodnia, który leży 14 km od mojej rodzinnej miejscowości. Dokładnie wiem gdzie to jest i byłem tam wiele razy.
Ale nie to w tej książce jest najważniejsze. Przede wszystkim, ta pozycja trafia idealnie w “moją” tematykę. Dotyczy tworzenia biznesów od zera, a w dodatku są to biznesy technologiczne. Pozytywne również jest to, że Autor nie miał łatwego startu, a mimo to przez wytrwałość i konsekwencję zawsze dochodził do celu.
O skuteczności mówią same za siebie osiągnięcia autora: 3 biznesy = 3 sukcesy, dwie z firm wprowadzone na giełdę amerykańską.
Pomimo tego, że większość interesów autor prowadził w USA, w książce znajdziemy silny wątek polski. Dwa z projektów, stworzonych przez autora były prowadzone w Polsce. Oba zostały sprzedane i stanowią w tej chwili polskie filie firm Intel i Compuware, czy potrzeba nam lepszych przykładów?

Książkę można kupić np. na stronie wydawcy.

A oto prolog, który może lepiej zachęci niż cała ta moja pisanina:

Już w trzy dni od debiutu nasze akcje poszybowały na 14 dolarów za udział. My wprawdzie dostaniemy za nie tylko po sześć dolarów, ale satysfakcja jest ogromna. Siedzimy z Richem i mnożymy, ile też jesteśmy teraz warci. Wyszło, że po 14 milionów. Każdy! Za głowę się złapałem. Dla faceta, który przyjechał tu kilkanaście lat temu z zabitej dechami Polski, gdzie chodził w połatanych spodniach i podartych butach, który w Ameryce mieszka w tanim apartamencie czynszowym, a za najdroższy garnitur zapłacił kilkanaście dolarów na przecenie ? zostać milionerem to szok. Tym bardziej, że od razu stałem się multimilionerem!
Miałem trzydzieści trzy lata. Jak na ten wiek całkiem nieźle ? myślałem, sycąc się dusznym, choć ożywczym powietrzem Wall Street.