Jako programista doświadczyłem w swojej karierze zawodowej różnych sytuacji. Na pewno w pozytywny sposób mogę opisać pracę z analitykami – zwłaszcza z tymi, którzy nie mają żadnego doświadczenia w programowaniu. To osoby, które są w stanie przygotować proces biznesowy solidnie, bez zbędnej ingerencji w elementy związane z programowaniem i architekturą. aplikacji. Bez większego problemu są w stanie uzgodnić z zespołem programistycznym elementy które mogą zostać wykonane łatwiej, albo zmienić proces biznesowy, tak by jego utrzymanie było bardziej elastyczne i prostsze w przyszłości. Z takimi ludźmi aż chce się pracować. Metodyki zwinne dodatkowo pomagają nam w tym, pozwalając na bieżąco pracować jak i z procesem biznesowym tak i z jego usprawnianiem. Niemalże w 99 procentach projektów początkowa wizja ulega zmianie, a elementy systemu często niezmienne i stałe trzeba jednak ostatecznie modyfikować, bo założenia biznesowe się zmieniły.

Niejednokrotnie doświadczyłem takich przypadków jak: „zróbmy to najprościej, ja nie będę tam nic zmieniać, te dane nigdy nie będą aktualizowane”, które po 3 miesiącach, po roku lub dwóch przekształcały się w: „musimy to zmienić, rozbudować ten proces, nie będziemy wysyłać tylko e-maili, klient chce również wiadomości SMS i powiadomienia w aplikacji webowej”. Jest też druga strona medalu, którą w wielkim skrócie można zarysować tak:

początkujący programista z niewielką wiedzą (może 2 lata doświadczenia) stwierdza, że praca z kodem nie jest dla niego. Uważa, że kompletnie nie ogarnia algorytmów, wzorca programistycznego ifeton’u i pisanie kolejnych linijek kodu kompletnie do niego nie przemawia.

Postanawia zostać analitykiem.

W jego umyśle kształtuje się prosty obraz sytuacji:

„Będę analitykiem. Będę opisywał biznes i pisał specyfikację, rysował diagramy, mówił co i jak pozostałe osoby z zespołu powinny programować. Przecież byłem programistą i nie jeden już system zaimplementowałem podczas swojej kariery.”

Taki ”analityk” uważa, że może bez problemu decydować w kwestiach programistycznych zespołu takich jak:

odpytywanie zespołu dlaczego zadanie będzie wykonywane 40 godzin po co te wszystkie testy jednostkowe i integracyjne czemu to tyle czasu zajmuje, po co ciągła integracja… przecież wystarczy zrobić tylko inserty do bazy! To z pewnością nie zajmie tych 40 godzin pracy. Niestety wydaje mi się że tego typu sytuacji jest naprawdę dużo. Nawet o wiele za dużo jak na naszą branżę. Moim zdaniem częściej możemy to spotkać w korporacjach, ale takie sytuacje mają miejsce również w mniejszych firmach. Może to wynikać z faktu, że takie osoby próbują być równocześnie liderami technicznymi i analitykami w zespołach, co stawia ich na pozycji „samca alfy” lub alfy i omegi.

Oczywiście są ludzie, którzy z powodzeniem realizują obie te funkcję, jednak świat IT idzie wciąż

do przodu. Aby być dobrym programistą nie wystarczy już odbębnić ośmiu godzin w pracy. Praca idzie z nami do domu wypierając klasyczny wypoczynek z piwem przed telewizorem. Musisz orientować się zarówno we vlog- jak i w blog-sferze, uczestniczyć w konferencjach, rozmawiać z kolegami z pracy o ich systemach czy używanych technologiach.

Analogicznie sytuacja wygląda z byciem analitykiem. Skup się na swojej funkcji i rób to dobrze. W małych projektach często to właśnie analityk staje się managerem projektu, jednak jego praca powinna nadal skupić się na rzeczach niezwiązanych z programowaniem i technologią. Wydaje mi się ze żadna szkoła nie przygotuje Cię do zawodu analityka systemowego. Doświadczenie programistyczne nie jest niezbędne, aby dobrze pełnić swoją funkcję. Ba, można posunąć się nawet do stwierdzenia, że zadaniem analityka nie jest rozwiązywanie problemów jako takich (projekty informatyczne można bowiem spokojnie nazwać problemami z jakimi mierzy się klient-zleceniodawca). Analityk skupia się przede wszystkim na rozwiązaniach biznesowych, polegających przede wszystkim na opisaniu problemów. Nie zawsze będziesz dobrym analitykiem, jeśli zdecydowałeś się na pełnienie tej roli w zespole tylko dlatego, że z jakiegoś powodu nie rozwinąłeś skrzydeł jako programista.

Na zakończenie pozwolę sobie na mały apel:

Analityku opanuj się, wyluzuj.

Nie rozwiązuj problemów programistycznych, nie decyduj o rozwiązaniach architektury aplikacji.

Skup się na swoich zadaniach, a wszystko będzie dobrze.