Czym zajmuje się analityk IT

Transkrypcja

Dziś moim gościem jest Marta Balcer. Marta opowie nam o tym, kim jest analityk IT, na czym polega jego praca i jak można nim zostać. Marto, dziękuję, że przyjęłaś moje zaproszenie na rozmowę.

Dziękuję również za zaproszenie. Bardzo mi miło u Ciebie gościć, tym bardziej, że jestem wielką fanką Twojego podcastu.

Bardzo dziękuję.

To może zaczniemy od Twojej osoby. Powiedz nam, co łączy Cię z branżą IT.

Aktualnie z branżą łączy mnie przede wszystkim rola analityka w dwóch projektach, które w tej chwili realizuję. Jeden z nich jest dla organizacji międzynarodowej z siedzibą w Brukseli, a drugi dla firmy z sektora telekom, działającego głównie w obszarze EMEA, czyli Europy, Afryki i Bliskiego Wschodu. Dodatkowo wspieram projekt dla branży finansowej będący w początkowej fazie inkubacji. Jest to już taki poboczny projekt, którym zajmuję się po godzinach – czyli nie jest to jakby kwestia zawodowa.

Ponadto skupiam się na szkoleniu osób, które chciałyby zacząć swoją pracę w branż IT. Początkowo zaczynałam od znajomych i osób z mojego otoczenia, które interesowały się branżą – pokazywałam im, jak taka rola działa. Aktualnie pracuję nad rozszerzeniem tej części działalności.

To teraz powiedz nam, proszę, kim jest analityk biznesowy i czym zajmuje się na co dzień. Słowo analityk kojarzy nam się z analizowaniem danych, może z matematyką, statystyką. Czy prawidłowo?

Część pracy analityka dotyczy aspektów związanych z kwestiami matematyki czy statystyki. Pod pojęciem analizy biznesowej znajdziemy sporo tematów, technik, metodologii, które odnoszą się do analizy finansowej czy analizy danych.

Jednakże analityk IT to głównie rola, jaką członek zespołu pełni w projektach IT. To nie musi być oddzielna rola, to nie musi być oddzielna osoba. Często rolę tę może pełnić chociażby programista czy Scrum Master. Coraz częściej jednak jest to zupełnie odrębny specjalista dedykowany pod ten cel w projekcie.

Może jeszcze dopytam Ciebie o dwie rzeczy. Na początku wspomniałaś, że mamy tutaj analizę finansową, więc od razu w głowie zapaliła mi się lampka: czy księgowy to dobry materiał na analityka IT?

Wydaje mi się, że zdecydowanie tak. Księgowi często mają już dużo zdolności związanych z pracą analityczną, które wykorzystują na co dzień. Są to też osoby bardzo skrupulatne i dokładne w pracy, którą wykonują. Jednocześnie często muszą rozwiązywać bieżące problemy, w szczególności z perspektywy zmian podatkowych, które obecnie w Polsce następują. Wydaje mi się więc, że księgowy jest świetną rolą do tego, żeby móc i być w stanie przebranżowić się na analityka IT.

Najlepszym określeniem roli analityka w projekcie jest porównanie do swoistego mostu łączącego zespół biznesowy czy klienta oraz użytkownika (tego, jakie on ma potrzeby i oczekiwania) z zespołem technicznym, który będzie pracował nad konkretnym rozwiązaniem. To, czy analityk skupiać się będzie bardziej na stronie zrozumienia potrzeb i celów jako analityk biznesowy, czy na tej stronie technicznej jako analityk systemowy, czy na obydwu aspektach jednocześnie jako analityk IT, będzie określało, jakie regularne zadania ten analityk będzie miał do wykonania.

To może od razu zapytam: czym różni się analityk IT od project managera?

Analityk IT głównie skupia się na rozpisaniu zadań, czyli zrozumieniu najpierw tych potrzeb, o których wspomniałam wcześniej, na zrozumieniu celu biznesowego. Na tej podstawie rozpisuje konkretne zadania, które będą później do wykonania dla zespołu projektowego.

Project manager natomiast bardziej skupia się na rozplanowaniu tych zadań; na nadaniu im priorytetu; na zrozumieniu, jak te zadania, które są do dostarczenia, będą wpływały na budżet, jak będą wpływały na czas realizacji projektu. Jest to więc troszeczkę inna funkcja, taka bardziej odnosząca się do kwestii zarządczych w projekcie, a nie kwestii skupiania się na elementach pracy, które są do dostarczenia – a którymi przede wszystkim interesuje się analityk.

Trzeba tylko pamiętać o tym (i tak często jest), że analityk IT jest rolą wspierającą dla project managera. Niektóre rzeczy związane właśnie z pracą analityka – czyli skupienie na zadaniach – pomagają mu we wspieraniu roli project managera czy product ownera. Często jest też tak, że product manager bądź analityk mają de facto dwie role w projekcie – wówczas jest to rola łączona.

A czy analityk wyszedł z roli project managera, który miał za dużo na głowie? Czy dlatego pojawiło się nowe stanowisko: analityk?

Wydaje mi się, że analityk wyszedł bardziej z biznesu. W momencie kiedy projekt próbował dowiedzieć się, jakie są potrzeby, to albo szedł do jakiegoś zespołu operacyjnego, żeby zapytać o system, który jest potrzebny, albo szedł do klienta, żeby zapytać o rozwiązanie, które miałoby zostać dostarczone. Zawsze była wyznaczona jakaś osoba z tego zespołu operacyjnego, jakaś osoba wyznaczona do roli klienta, który miałby te informacje prześwietlić. Wydaje mi się więc, że rola analityka bardziej wyszła z tych zespołów operacyjnych, od użytkowników czy od klienta niż z roli project managera.

Często było tak, że project manager faktycznie zbierał informacje dotyczące zadań po to, żeby móc je później priorytetyzować i przekazywać do wykonania. Jest to więc troszeczkę takie połączenie – czyli z jednej strony analityk wyszedł właśnie od zespołu biznesowego, ale poniekąd też na pewno miał dużo wspólnego z project managerem i na pewno zabrał część rzeczy i zadań, które na co dzień wykonywał project manager.

Mówisz, że analityk jest po stronie biznesu. Czy wynagrodzenie płaci mu biznes i to on go szuka, czy raczej analityk jest częścią zespołu programistycznego? O tym pewnie jeszcze będziemy mówić, ale tak zrozumiałem z Twojej wypowiedzi – że jest to raczej przedstawiciel biznesu, czyli osób, które czegoś potrzebują, chcą coś zrealizować przez zespół projektowy.

Wydaje mi się, że odpowiedź na wiele pytań, które zadasz, będzie brzmiała: to zależy – jako taki standard, jeżeli chodzi o odpowiedzi w IT. To zależy w dużej mierze od projektu i od tego, jak on jest realizowany. Może to być osoba, która wychodzi czysto od biznesu – nie będzie to więc analityk pracujący na co dzień z zespołem projektowym, lecz będzie on finansowany zdecydowanie przez stronę biznesową, przez zespoły organizacyjne.

Może to też być analityk, który będzie częścią zespołu projektowego, będzie w budżecie zespołu projektowego, a do zespołów biznesowych, użytkownika czy do klienta będzie on jakby wysyłany lub będzie organizował spotkania z częścią biznesową. Nie będzie jednak częścią zespołu biznesowego. Wiele zależy od tego, jakiego rodzaju jest to projekt, jak jest realizowany i jak jest rozplanowany budżet na tego typu przedsięwzięcie.

Może przejdźmy przez te podstawowe informacje, a potem jeszcze będę uzupełniał tę listę pytań, więc, proszę, kontynuuj.

Jasne. Wracając do roli analityka biznesowego – będzie on głównie skupiał się na zebraniu wymagań dotyczących końcowego rozwiązania czy docelowego produktu. Będzie rozmawiał z zespołami firmy, które mogą mieć swoje oczekiwania; z użytkownikami, którzy będą na co dzień korzystać z rozwiązania czy z klientami, dla których będzie ono tworzone.

Istotne jest zrozumienie, jakie cele ma każda z tych grup. Te grupy nazywamy w projektach potocznie interesariuszami i tutaj istotną kwestią jest zrozumienie, jak wyobrażają sobie oni rozwiązanie, które będzie dostarczone.

Analityk biznesowy skupia się tutaj głównie na zebraniu informacji, na ich syntetyzowaniu i dokumentowaniu, tak żeby na podstawie tych wszystkich informacji można było stworzyć optymalne rozwiązanie, które zrealizuje założone na samym początku cele.

Analityk systemowy natomiast skupia się bardziej na proponowaniu i tworzeniu konkretnego rozwiązania na podstawie wcześniej zebranych wymagań biznesowych oraz aspektów architektury określonej dla danego rozwiązania. Na pewno musi mieć on zrozumienie części technicznej – oczywiście do pewnego poziomu abstrakcji – tak żeby móc na przykład przygotować dla zespołu programistów konkretne zadania techniczne.

Natomiast analityk IT łączy w sobie obie role, więc jest w stanie zarówno przeprowadzić proces zbierania wymagań od etapu ich pozyskania, jak i wyznaczyć konkretne zadania na poziomie technicznym dla developera. Nie wszystkie projekty mają analityków będących w stanie wejść w obie role, dlatego bardzo często zdarza się, że część związaną z analizą czysto biznesową przekazuje się w firmie do zespołów operacyjnych. Nie ma tam wyznaczonego analityka. Często jest to grupa kilku osób, które bazują na zbieraniu wymagań, więc nie ma osobnej roli utworzonej pod ten cel.

Może być też tak, że to programiści wchodzą w rolę analityków systemowych (najczęściej systemowych, bo mają zaplecze techniczne dotyczące projektów i opisują techniczne zadania dla zespołu). Tak dzieje się najczęściej wtedy, gdy projekt dostarcza jedynie analityka biznesowego, który pracuje po po stronie wymagań.

W czasie opisywania tych wszystkich rzeczy dużo razy pojawiły się umiejętności techniczne. Czy analityk musi umieć programować, a jak nie, to jakie umiejętności techniczne i miękkie są wymagane w tym zawodzie?

Analityk nie musi umieć programować, ale jest to zdecydowanie przydatna umiejętność, w szczególności w roli analityka systemowego. Natomiast ogólne rozumienie aspektów związanych z tym, czym właściwie jest programowanie, na przykład umiejętność zidentyfikowania kwestii dotyczących front endu i back endu; różnic pomiędzy poszczególnymi językami programowania; rozumienie integracji systemów; ogólne rozumienie architektury; tak samo proces dostarczania kodu czy kwestie środowisk produkcyjnych – to często jest już wiedza konieczna, aby być w stanie funkcjonować w roli analityka systemowego.

Do tego dochodzą aspekty związane z rozumieniem pojęć, takich jak bazy danych, API, diagramy UML, które dokumentują działanie systemu i są często wymieniane jako główne umiejętności na tym stanowisku w ogłoszeniach o pracę dla analityka systemowego.

Jeżeli chodzi o analityka biznesowego, to są to głównie umiejętności związane z technikami zbierania i dokumentowania wymagań; prowadzenie warsztatów; metody analizy czy dokumentowania procesów przy użyciu chociażby BPM. Jest to sposób, w którym można graficznie przedstawić dany proces, tak żeby łatwiej było go omówić na spotkaniach, na warsztatach – zarówno z biznesem, jak i z zespołem technicznym. Mamy tutaj też takie metody, jak już wspomniana wcześniej analiza strategiczna, analiza finansowa czy analiza SWOT oraz takie rzeczy jak dekompozycja funkcjonalna, która dotyczy już czysto tematyki wymagań.

Do tego oczywiście dochodzą umiejętności ogólne, takie jak komunikacja, umiejętność pracy w zespole, chęć doskonalenia się czy umiejętność syntetyzowania informacji. Kwestia doskonalenia się jest istotna w szczególności jeżeli chodzi o aspekt bardzo dynamicznie rozwijającej się branży IT i pojawiania się ciągle nowych metodologii oraz technik, które są i mogą być wykorzystywane w pracy analityka.

Muszę przyznać, że lista jest bardzo rozbudowana. Jeżeli miałbym iść w stronę analityka i ktoś by mi to przedstawił, to bym się trochę albo nawet bardzo zraził. Czy to faktycznie jest takie trudne, jak brzmi? Możesz podać przykład osoby, która była w stanie się tego nauczyć i znaleźć pracę?

Tak, jak najbardziej. Sama de facto przeszłam drogę przebranżowienia, wychodząc z roli operacyjnej w bankowości. Przeszłam przez naukę wszystkich aspektów związanych zarówno z analizą biznesową, jak i z analizą systemową, więc jest to idealny przykład. Mam wrażenie, że wiele osób, które wchodzą w rolę analityków, często zaczynało jako specjaliści w zupełnie innej branży, dzięki temu, że znało domenę, że miało wiedzę na temat produktów i aspektów związanych ze specyfiką pracy czy narzędzi na konkretnym stanowisku w konkretnej branży. To umożliwiło im łatwiejsze zrozumienie potrzeb i dopracowanie wiedzy technicznej, metodologii i wszystkich technik potrzebnych do tego, żeby zostać analitykiem.

W ten oto sposób delikatnie przechodzimy do następnego pytania.

Jak zostaje się analitykiem IT? Wspomniałaś o tym, że warto przejść w jednej firmie z jednego działu do drugiego i to jest fajna ścieżka. Może masz jeszcze kilka innych dróg, które pozwolą zostać analitykiem IT.

Tak jak wspomniałam, wydaje mi się, że to przejście w ramach jednego biznesu – jednej firmy czy jednej branży – jest takim klasycznym modelem wykorzystywanym przez osoby, które przebranżawiają się na analityka IT. Ale nie jest to oczywiście jedyna opcja. Na pewno posiadanie doświadczenia w konkretnej branży pomaga znacznie obniżyć próg wejścia i umożliwia zmianę roli znacznie niższym nakładem sił.

Branż umożliwiających taką tranzycję jest sporo: finanse, administracja, coraz częściej motoryzacja – w szczególności jeżeli chodzi o nowe rozwiązania techniczne dla samochodów elektrycznych. W ostatnim czasie również gastronomia mocno się rozwija od strony technicznej czy chociażby branża beauty. We wszystkich tych branżach są prowadzone projekty, które usprawniają pracę, wprowadzają nowe produkty czy systemy, więc dają one możliwości na właśnie taką tranzycję, gdy ma się wiedzę z zakresu działalności tych branż.

Oczywiście nie jest to jedyna ścieżka. Można skupić się na budowaniu wiedzy z zakresu analizy już na początku swojej ścieżki zawodowej. Są studia kierunkowe zarówno pierwszego oraz drugiego stopnia (mam na myśli licencjat i studia magisterskie), jak i studia podyplomowe. Wtedy skupiamy się zwykle na poznaniu teorii, opanowaniu technik i metodologii, bo wiadomo, że ciężko jest wówczas wypracować jeszcze doświadczenie w konkretnej branży. Daje to podejście trochę bardziej agnostyczne, jeżeli chodzi o późniejsze wejście na rynek i wybór konkretnego kierunku, konkretnej branży.

To może jeszcze dopytam Cię o studia, bo moje doświadczenie i osób, z którymi rozmawiam, jeśli chodzi o branżę IT, to studia zazwyczaj nie nadążają. Program zmienia się za wolno, często kadra też niechętnie podchodzi do zmian, ma inne rzeczy na głowie. Czy tutaj występuje podobny problem i takie studia niekoniecznie przygotują nas do zawodu? Program jest przygotowany raz, a realia na rynku pracy już dawno się zmieniły.

Często tak jest. Przykładem z życia są studia ekonomiczne, które sama kończyłam. Omawialiśmy przykładowo modele ekonomiczne, które miały zastosowanie piętnaście czy dziesięć lat temu, a które w ogóle były nie do przyłożenia do obecnej sytuacji. Trzeba pamiętać o tym, że IT rozwija się dużo szybciej niż inne kierunki.

Jeżeli chodzi o nienadążanie, to myślę, że przede wszystkim dotyczy to studiów pierwszego i drugiego stopnia, czyli licencjatu i magisterki, bo to często jest ta kadra, która de facto nie pracuje na bieżąco w projektach. To są osoby, które zdobyły wiedzę, oczywiście fajnie są w stanie przekazać podstawy dotyczące tego, jak wygląda branża czy czym jest programowanie, oraz te podstawowe aspekty związane z technikaliami, nie wiem, niskopoziomowymi, jeżeli chodzi o języki programowania, ale często już nie są w stanie dostarczyć nowych rozwiązań, nowych frameworków. Nie są w stanie omówić nowych języków czy rozwiązań architektonicznych, które pozwalają na zoptymalizowanie procesu dostarczania oprogramowania. To samo dotyczy właśnie analizy. Trzeba pamiętać, że są to rzeczy bardzo mocno ze sobą połączone.

Inaczej jest na studiach podyplomowych. Mam wrażenie, że tam się dużo bardziej stawia na praktyków. Wiedzę przekazują osoby, które nawet na co dzień pracują w projektach – jest to dla nich zajęcie dodatkowe i dzięki temu mają bieżącą wiedzę na temat tego, jak wyglądają projekty, co się w nich dzieje, jakie są nowe metody. Często są to osoby, które same dosyć mocno się rozwijają. Jeżeli więc chodzi o zdobywanie wiedzy związanej z analizą czy innymi aspektami technicznymi, to wydaje mi się, że studia podyplomowe są takim najfajniejszym kierunkiem.

A czy z innych ról w IT możemy przechodzić na analityka IT?

Tak. Wydaje mi się, że takim najbardziej popularnym kierunkiem jest kierunek z testera na analityka. Mam wrażenie, że wiele zadań, które realizuje analityk, często opiera się też o aspekty związane z testowaniem. To taka najbardziej tradycyjna ścieżka, którą widziałam, chociaż są oczywiście również programiści, którzy zdecydowali się przejść do roli analityka systemowego. Tak samo project managerowie czy Scrum Masterzy, którzy zdecydowali, że jednak bardziej interesuje ich praca z zespołem i z wymaganiami niż kwestie związane z zarządzaniem projektami. Tak że różnie.

Są to na pewno troszkę rzadsze sytuacje – w szczególności jeżeli chodzi o programistów przechodzących do roli analityków – ale taka tranzycja jest jak najbardziej możliwa. Wydaje mi się, że tranzycja z innej roli w projekcie IT na analityka jest często łatwiejsza niż w drugą stronę.

Do tej pory rozmawialiśmy raczej o takiej formie, że analityk był częścią zespołu, czyli tak naprawdę pracował dla kogoś. A czy może być freelancerem? Jak to wygląda i czy w ogóle praca w takiej formie ma sens? Czy to jakoś się różni od pracy na etacie?

Tak, jak najbardziej aktualnie analitycy coraz częściej decydują się na pracę na kontrakcie, preferując to ponad klasyczną umowę o pracę. Większość firm w tej chwili umożliwia taką opcję, wiele oferuje wybór między etatem a freelancingiem. Chociaż to też jest tak, że freelancer często de facto może być częścią zespołu projektowego i realizuje podobną liczbę godzin jak na etacie. Nie jest może częścią firmy, nie jest zatrudniony bezpośrednio przez firmę, tylko właśnie na tym tak zwanym business to business, ale mimo wszystko jest traktowany jako pełnoprawny członek zespołu projektowego, podobnie jak byłaby traktowana osoba na etacie – to też chciałabym zaznaczyć.

Trzeba pamiętać, że praca jako freelancer oznacza potrzebę założenia i prowadzenia własnej firmy, działalności. Z jednej strony oznacza to optymalizację podatkową, bo pozwala na zatrzymanie większej ilości przychodu. Dodatkowo możemy wymienić tutaj na przykład kwestie większej elastyczności, jeżeli chodzi o projekty, w które dany specjalista się angażuje. Freelancing pozwala też na podjęcie większej liczby projektów, bo nie trzeba mieć pełnego etatu, czterdziestu godzin tygodniowo poświęconych na jeden projekt, tylko można się zaangażować w kilka różnych, fajnych projektów.

Freelancerzy nie mają też ograniczeń, jeżeli chodzi o działalność pozaprojektową, którą mogą podejmować – oczywiście biorąc pod uwagę ograniczenia kontraktowe czy konkurencyjne dla firm, z którymi współpracują. Mogą też zlecać zadania podwykonawcom, jeżeli oczywiście biznes czy firmy, z którymi współpracują, zgodzą się na to od strony projektu. Freelancing więc na pewno pozwala na dużo większą optymalizację i elastyczność, jeżeli chodzi o zarządzanie swoim czasem i realizację projektów, które są fajne, w których można się rozwijać i optymalizować zarobki.

Z drugiej strony jest to na pewno większa odpowiedzialność – zarówno za efekty pracy, jak i jej potencjalne negatywne skutki. Dodatkowo, będąc przedsiębiorstwem, będąc firmą, pracując w ramach działalności gospodarczej, trzeba wziąć na siebie podatki, umowy czy kwestie prawne. Odpowiadamy wtedy za to samodzielnie bądź z działem księgowym czy podatkowym, z którym współpracujemy.

Każda z obu tych opcji ma swoje plusy i minusy. Wydaje mi się, że początkujący analitycy powinni starać się szukać raczej opcji etatowych. Kwestie finansowe nie będą znacząco się różniły między etatem a freelancingiem, a odpowiedzialność mimo wszystko – w szczególności na początku, kiedy ta wiedza jeszcze nie jest rozbudowana – może być zbyt duża. Przeniesienie tej odpowiedzialności na freelancera może niestety nie być optymalną opcją. Etat pozwala spokojnie się rozwijać, zdobywać wiedzę i budować pewność działań w roli analityka IT.

To teraz przejdźmy do kolejnego etapu. Wiemy, że freelancer może pracować zarówno sam dla siebie, jak i dla kogoś. A czy współpracuje bezpośrednio z programistami? Jeśli tak, to czego programista może oczekiwać od dobrego analityka?

Tak. Analitycy bardzo często współpracują z programistami. Zakres tej współpracy może się oczywiście różnić w zależności od tego, czy myślimy o roli analityka biznesowego czy systemowego, ale generalnie obydwie role najczęściej pracują wspólnie nad dostarczeniem produktu w obrębie zespołu projektowego.

Programista przede wszystkim powinien oczekiwać od analityka rozumienia problemów, które są do rozwiązania przez zespół projektowy oraz zrozumienia celów i wymagań, które będą musiały być realizowane jako wynik działania zespołu projektowego. Programista nie powinien mieć wątpliwości co do tego, co jest do dostarczenia. Powinien mieć wszystkie potrzebne informacje, szczegółową i zsyntetyzowaną dokumentację.

Dla programisty analityk powinien być przede wszystkim głównym kontaktem w celu zrozumienia, co ma on do zrobienia, wyjaśnienia wątpliwości czy komunikacji na temat ograniczeń systemu czy zespołu projektowego…

Może tutaj się wtrącę i dopytam, jak to jest. Czy taki analityk ma wystarczającą wiedzę, żeby stwierdzić, czy coś się da, czy się nie da zrobić w określonym czasie? Kto ostatecznie decyduje o tym, czy robimy coś, czy tego nie robimy? Wydaje mi się, że to nie jest jasno określone i chciałbym się od Ciebie dowiedzieć, kto tu ma tak naprawdę ostatnie zdanie.

Analityk na pewno może mieć wiedzę – zarówno techniczną, jak i biznesową – pozwalającą na podjęcie decyzji. Mimo wszystko i tak nie powinien podejmować decyzji sam. Mam wrażenie, że najbardziej wartościową kwestią pracy w zespole projektowym jest to, że można się wymienić doświadczeniami dotyczącymi tego, jak podejść do konkretnego problemu i jaką decyzję najlepiej podjąć.

Często analitycy mogą nie mieć pełnego obrazu rzeczy związanych z aspektami technicznymi czy komponentami, które są problematyczne i które będą do dostarczenia. Często mogą też nie mieć wiedzy dotyczącej ograniczeń budżetu, którą znowu będzie miał project manager. Jeżeli więc chodzi o kwestie tego, co ostatecznie jest do zrobienia i kto podejmuje decyzję, to najlepiej, by była to wspólna decyzja zespołu technicznego czyli developerów, architektów, project managera oraz analityka – tak żeby mieć pewność, że wszystkie aspekty były wzięte pod uwagę i decyzja, która została podjęta, jest tą najbardziej optymalną opcją.

Przy czym i tak w projektach – przynajmniej w tych, w których ja miałam okazję pracować – najczęściej ostateczne zdanie miał project manager. Myślę, że to jest ta osoba, która bierze na siebie największą odpowiedzialność, jeżeli chodzi o realizację projektu, dlatego też podejmowanie ostatecznej decyzji będzie leżało po stronie project managera.

Jeżeli dobrze Cię zrozumiałem, to wygląda to w ten sposób, że rolą analityka jest rozmowa z biznesem i określanie zadań. Powiedzmy, że mamy te zadania już rozpisane. Wówczas następuje kontakt z project managerem, z którym konsultujemy, czy jest to do zrobienia w określonym czasie, w określonym budżecie. Wtedy to idzie do programistów. Czy tak to wygląda?

Najpierw mimo wszystko mamy rozmowę z programistami, żeby zrozumieć, ile czasu to zajmie. Analityk tylko do pewnego stopnia jest w stanie określić, jaki jest poziom skomplikowania konkretnego elementu, który będzie do dostarczenia przez programistę. W związku z tym zawsze warto skonsultować to z programistą i dopiero z wiedzą dotyczącą tego, jaki mamy cel i ile czasu mniej więcej to powinno zająć, idziemy do project managera. Wówczas ustalamy, czy faktycznie mamy zasoby pozwalające na dostarczenie tego – czy mamy budżet i czy faktycznie to, co chcemy dostarczyć, pokrywa się z ogólnymi celami biznesowymi, nad których realizacją najczęściej czuwa project manager.

Czy w trakcie określania tych zadań i czasu są negocjacje, typu: OK, musimy zrobić to to i to, ale nie wyrobimy się. Może zrezygnujemy z testów albo napiszemy to na razie tak, żeby było, a potem będziemy dalej kombinować i refaktoryzować? (Czytaj: możliwe, że nigdy).

Chciałabym powiedzieć, że tak się nigdy nie dzieje, wszystko jest oczywiście realizowane, nigdy nie pomijamy testów i nigdy nie testujemy na produkcji. Niestety realia są różne i często pada decyzja: dobra, mamy tutaj do dostarczenia pewną liczbę komponentów, to może zrobilibyśmy na razie takie MVP (Minimum Viable Product, czyli produkt, który ma minimalną liczbę funkcjonalności, żeby był użyteczny), a później będziemy kombinować, co tutaj do tego produktu dołożyć, żeby to faktycznie miało ręce i nogi.

Często kończy się to tak, że to tymczasowe rozwiązanie jest rozwiązaniem docelowym. Jest takie powiedzenie: there is nothing more permanent than a temporary solution, co oznacza dokładnie tyle, że nie ma nic bardziej stałego niż tymczasowe rozwiązanie – i często jest tak, że z tym wszystkim, co zostaje dostarczone jakby troszeczkę na kolanie po to, żeby zmieścić się w czasie czy w budżecie, zostajemy na dłużej albo właśnie decydujemy się na to, żeby może testy przynieść na produkcję, co najczęściej nie kończy się najlepiej.

Dla programisty analityk powinien być przede wszystkim głównym kontaktem. Często jest tak, że programiści nie mają bezpośrednio kontaktu z zespołami biznesowymi, co też pozwala programiście skupić się na dostarczaniu kodu, a nie na negocjacjach czy kwestiach związanych z wymianą informacji pomiędzy poszczególnymi działami. Analityk powinien więc być łącznikiem pomiędzy programistą a zespołem, który zajmuje się dostarczaniem konkretnych wymagań. Dzięki temu programista ma jedną osobę, z którą może omówić to, co jest do zrobienia; może wyjaśnić wątpliwości czy komunikować się na temat ograniczeń.

To analityk będzie opisywał konkretne zadania dla programistów, więc to też jest ważne – aby przekazywane informacje były jasne, zrozumiałe oraz kompletne i przede wszystkim, żeby ta komunikacja była konkretna. Z im większą liczbą osób programista będzie musiał się komunikować, tym będzie to trudniejsze i będzie odciągało go od tej podstawowej pracy, którą ma do wykonania, czyli tak naprawdę napisania kodu. W związku z tym posiadanie jednej osoby, która tą komunikacją się zajmie i będzie dostarczała wszystkich dodatkowych informacji, jest zdecydowanie optymalne. Analityk powinien tę rolę wziąć na siebie.

Analityk powinien też wchodzić w rolę negocjatora i tworzyć kanał przepływu informacji pomiędzy biznesem a zespołem projektowym, pozwalając programiście skupić się de facto na kluczowych aspektach jego roli.

Wspomniałaś, że analityk wspiera programistę, więc chciałbym się teraz dowiedzieć, jak wygląda praca analityka na różnych etapach rozwoju projektu. Czy jego udział rozpoczyna się na etapie ustalania z klientem wymagań czy może wcześniej?

Często już nawet wcześniej, na etapie chociażby tworzenia strategii czy analizowania aktualnych problemów, z którymi będzie mierzył się projekt w późniejszych etapach. Praca analityka ma na celu zrozumienie biznesu, jego wyzwań, ograniczeń – tak naprawdę współpracę z biznesem w celu ustalenia kierunku rozwoju i wprowadzania zmian.

To nie zawsze oznacza, że pojawi się potrzeba wystartowania kilkuletniego projektu, którego rezultatem może być przykładowo nowy system. Z wniosków analizy może wyniknąć, że firma – aby osiągnąć swój zamierzony cel – potrzebuje tak naprawdę jedynie drobnych zmian w procesach, które aktualnie są zaimplementowane. Na tym etapie analityk skupia się przede wszystkim na określeniu, jaki jest stan obecny; jak aktualnie działa firma; jak przebiegają wszystkie procesy, przykładowo proces sprzedaży czy proces wsparcia posprzedażowego już istniejących klientów. Dopiero na tej podstawie można określić, gdzie znajdują się przestoje, wąskie gardła i na którym etapie następuje największy odpływ klientów, co może mieć wpływ na finanse firmy.

Dopiero to pozwala na wyodrębnienie aspektów, które są lub mogą być problematyczne; na wyznaczenie celów i określenie kroków do ich realizacji. Często po analizie okazuje się, że problemy, które ma biznes na danym etapie, leżą w zupełnie innym miejscu, niż zakładano na początku, bądź są dużo bardziej złożone albo dużo prostsze od tego, co się wszystkim na początku wydawało.

Praca analityka może więc się zacząć już w fazie przedprojektowej, co często pozwala uniknąć niepotrzebnych kosztów w dalszym etapie i jasno sformalizować cele. Nie jest to jednak standard. Często analitycy są wprowadzani do projektu wtedy, gdy ten ma już gotowe wysokopoziomowe cele, budżet i wstępnie określoną architekturę rozwiązania, które jest do dostarczenia. To jest ten moment, kiedy jeszcze nie ma w pełni ukształtowanych zespołów od strony technicznej.

Praca analityka i to, co wytworzy na tym etapie (czyli gdy mamy już te wysokopoziomowe cele, budżet i wstępnie określoną architekturę), będą kluczowe dla podjęcia kolejnych kroków. Czyli – jeśli nie zrobiono tego wcześniej – ważne, żeby określić, jaki jest stan początkowy oraz podstawowe wymagania i reguły biznesowe, które wynikają ze specyfiki procesu, procedury czy chociażby branży.

Przykładowo, jeżeli chcemy usprawnić proces otwierania konta w banku, to nie możemy zapomnieć o takich aspektach jak: weryfikacja, tożsamości, kwestie bezpieczeństwa, nadawanie loginów i haseł czy sprawdzania klienta pod kątem potencjalnego ryzyka związanego chociażby z nielegalną działalnością, którą może prowadzić. To są kwestie narzucone przez regulacje prawne, które po prostu dotyczą branży bankowej. Powinny być one przeanalizowane i uwzględnione już na początkowym etapie, zanim zaczniemy się zastanawiać nad innymi funkcjonalnościami i specyfiką systemu, który będzie dostarczany.

Poza tym na tym etapie jest jeszcze często wiele niewiadomych co do kierunku. Czy będziemy usprawniać istniejący system, czy budować nowy, czy wdrażać jakieś rozwiązanie rynkowe? To jest ten moment, kiedy możemy określić wszystkich interesariuszy, intensywnie zbierać wymagania, analizować dostępną dokumentację, prowadzić warsztaty i na bieżąco prowadzić obserwacje procesów z osobami, które te procesy wykonują.

To jest też moment tworzenia wstępnej dokumentacji, takiej jak mapy procesowe czy makiety. Oczywiście – szczególnie w podejściu zwinnym – będą to też artefakty, które będą się zmieniały i rozwijały w czasie, często wraz z projektem. Ważne, żeby zdefiniować to jeszcze zanim zacznie się praca związana z kodowaniem – po to, żeby mieć bazę do dalszej pracy, zmian, usprawnień oraz ogólne rozumienie sytuacji, w której na początkowym etapie znajduje się zespół projektowy; tak żeby wyznaczyć jasne i konkretne zadania i cele.

Kolejne etapy pracy odbywają się już w trakcie trwania projektu. Nacisk na poszczególne zadania będzie bardzo mocno zależał tak naprawdę od cyklu życia. W początkowym etapie będzie to skupienie bardziej na wymaganiach, ich pozyskaniu, doprecyzowaniu, zweryfikowaniu i później oczywiście akceptacji oraz zarządzaniu zmianą; oczywiście również na przekształceniu ich w konkretne zadania dla zespołu developerskiego.

Z czasem nacisk może stopniowo się przynieść na wsparcie, zarządzanie incydentami, kwestie związane z negocjacjami, wymaganiami, które powstały we wcześniejszym etapie projektu, czy chociażby wsparcie merytoryczne zespołu developerskiego z wiedzy biznesowej czy doprecyzowanie konkretnych aspektów wdrażonego systemu.

Pewnie w zależności od tego, jak projekt jest prowadzony, rola analityka w zespole może wyglądać trochę inaczej. Czy jesteś w stanie nam powiedzieć, jak na przykład w takiej metodologii zwinnej typu Scrum wygląda rola analityka? Czy analityk spotyka się codziennie z programistami, jest uczestnikiem daily, czy jest na release’ach?

Z mojego doświadczenia: analityk jak najbardziej jest na daily, na stand upach, uczestniczy w wymianie informacji dotyczącej tego, co zostało wykonane i jakie mamy potencjalnie blokady. To też jest wartościowe, dlatego że na daily często programiści podnoszą jakieś ograniczenia, które mają na bieżąco, które często dotyczą wymagań czy dokumentacji – że jest coś, co analityk może na podstawie tych blokad zrobić. Na pewno więc uczestniczenie analityka w spotkaniach jest jak najbardziej wartościowe dla zrozumienia tego, co się dzieje w projekcie i jak analityk może pomóc zespołowi projektowemu w radzeniu sobie z obecnymi przeszkodami.

Jeżeli chodzi o taką regularną pracę w cyklu życia projektu, to na pewno na bieżąco pojawiają się nowe wymagania, często właśnie w tych projektach czysto agile’owych. W każdym lub w większości sprintów pojawiają się oczekiwania dotyczące kolejnych rozmów z biznesem, które muszą zostać przeprowadzone po to, żeby zrozumieć nowe wymagania albo jakiś enhancement, który jest do dostarczenia do wcześniejszych wymagań. Ten proces analityczny tak naprawdę więc nie ustaje.

Jeżeli chodzi o samo dostarczenie kodu na produkcję, czyli release, to często analitycy uczestniczą w części związanej z akceptacją biznesową dostarczanego rozwiązania. Często też uczestniczą w testach dotyczących user acceptance czy w potwierdzeniu, że wszystko, co zostało wypuszczone na produkcję, działa poprawnie według założeń biznesu. Wydaje mi się więc, że w całym etapie projektowym analityk jak najbardziej uczestniczy bądź powinien uczestniczyć, tak żeby wspierać aspekty zarówno biznesowe, jak i techniczne.

Wydaje się to mocno obciążające, dlatego zastanawiam się, czy faktycznie można prowadzić kilka projektów jednocześnie.

To też pewnie zależy od tego, jak, w jakim zakresie analityk wspiera te konkretne projekty. Są projekty, gdzie rolą analityka jest de facto tylko dokumentowanie pewnych rzeczy – czyli jest bardzo mocno rozbudowany zespół po stronie biznesowej, który zajmuje się wymaganiami, ale może nie mieć wiedzy związanej właśnie czysto z aspektami dokumentowania i przekazywania tego później do zespołu projektowego. Część kompetencji, które normalnie w innych projektach ma analityk, może więc zostać przeniesiona na inne role. To pozwala analitykowi skupić się na bardzo wąskiej specjalizacji w danym projekcie i nie zajmuje bardzo dużo czasu.

To mocno zależy od tego, jakie oczekiwania ma dany projekt względem analityka. Nie każdy projekt będzie potrzebował analityka w całym cyklu czy we wszystkich kompetencjach, które może on dostarczyć. Jest więc duża możliwość, że w jednym projekcie analityk podejmuje tylko kilka działań, np. związanych z komunikacją, prowadzeniem warsztatów czy zbieraniem wymagań, a dokumentowaniem zajmuje się już ktoś inny. Można mieć wówczas inny projekt, w którym od początku do końca (czyli end-to-end) analityk zajmuje się wszystkimi aspektami.

W zależności więc od tego, w jakich projektach bierze się udział, można próbować mieć więcej niż jeden projekt. Czasami są to role wspierające albo nawet szkoleniowe dotyczące innych analityków, co też nie zajmuje pełnego etatu i pozwala na uczestniczenie w tych inicjatywach. Jeżeli są to pełne projekty, to na pewno jest to skomplikowane. Jeżeli są to projekty, w których analityk musi faktycznie przeprowadzić cały proces analizy, to na pewno posiadanie więcej niż jednego projektu może być bardzo mocno wymagające i obciążające.

OK, to wróćmy jeszcze do pracy analityka na różnych etapach rozwoju projektu. Czy chciałabyś coś dodać?

Trzeba pamiętać, że każdy projekt może mieć trochę inne podejście do zadania, które wykonują analitycy, o czym wspomniałam wcześniej. Część będzie oczekiwała czynnego uczestnictwa w testach i raportowania błędów, co też jest jednym z etapów projektowych.

Dla analityka systemowego może pojawić się więcej aspektów związanych z analizą samych systemów, ich integracji. Mogą się pojawić kwestie związane z bazami danych, tworzeniem modeli, analizowaniem i zarządzaniem danymi.

To, czego na pewno można się spodziewać po tej roli, to duża ilość komunikacji (właściwie na każdym etapie) i kwestia rozwiązywania na bieżąco pojawiających się problemów.

W związku z tym analityk potrzebuje pewnie dużo narzędzi. Jakich używa na co dzień?

To w dużej mierze zależy od projektu i tego, w jakiej roli do projektu wchodzi analityk. Czy jest to bardziej strona biznesowa czy systemowa? Mamy tutaj na przykład Jirę i Confluence. Są to narzędzia z tej samej rodziny produktowej – Jira służy do zarządzania projektami, a Confluence do zarządzania dokumentacją. Teraz coraz częściej są one zastępowane przez inne produkty, takie jak ClickUp, Notion czy Miro, ale nadal są mocno zakorzenione w codziennym użytku projektowym. Są to w sumie narzędzia jakby agnostyczne, jeżeli chodzi o rolę w projektach IT, bo dotyczą nie tylko analityka, ale również każdego członka zespołu projektowego.

Jeżeli chodzi o tematy specyficzne dla analityka, to być może nietypowo, ale zacznę od starego dobrego Excela i Worda. Nikt może się do tego nie przyzna, ale wydaje mi się, że nadal są to najczęściej używane narzędzia przez wszystkich analityków.

Dalej mamy już bardziej narzędzia kierunkowe, takie jak Enterprise Architect. To jest potężne narzędzie mogące wspierać projekty właściwie end-to-end. Z perspektywy analityka mam wrażenie, że głównie używane jest do dokumentowania, modelowania czy zarządzania wersjami i zmianą, co ułatwia formalizację tej części projektu.

Dalej mamy draw.io, Visio, Lucidchart czy wspomniane wcześniej Miro. Te narzędzia skupiają się dużo bardziej na dokumentowaniu i modelowaniu – głównie mapowania procesów czy tworzeniu diagramów UML bądź ERD.

To może od razu bym zapytał o diagramy UML i programistów, z którymi współpracujesz – czy dla nich jest to zrozumiałe i normalne, że na co dzień operuje się na diagramach UML? Czy są oni w stanie przekształcić je na działający kod, czy raczej widzisz, że nie do końca?

Są programiści, którzy jak najbardziej są w stanie czytać i tworzyć diagramy UML oraz rozmawiać o nich i o dokumentacji technicznej w formie diagramów. Nie są to wszyscy programiści. Mam wrażenie, że w większości są to programiści z dłuższym doświadczeniem – raczej seniorzy i oczywiście architekci, bo diagramy są dużo bardziej związane z architekturą niż z samym programowaniem.

Mam jednak wrażenie, że mimo wszystko wprowadzenie diagramów UML i próba pracy z programistami na możliwościach graficznego przedstawienia tego, jak ma działać system – nawet jeżeli początkowo nie mają oni wiedzy o diagramach – na pewno w dłuższej perspektywie usprawnia pracę.

Nawet jeżeli to nie był standard, to z mojego doświadczenia wynika, że wprowadzenie diagramów UML i próba rozmawiania o systemie właśnie na podstawie tego typu dokumentacji, w dłuższej perspektywie dawało zdecydowanie fajniejsze rezultaty. Później wręcz dochodziliśmy do tego, że były to rzeczy oczekiwane przez programistów bardziej niż taki pisany tekst. Mimo wszystko dużo łatwiej omawia się pewne rzeczy, patrząc na obrazek, na coś, co jest rozrysowane, niż na dokumentację rozpisaną na dwadzieścia stron i tysiąc słów.

OK, to wróćmy do narzędzi.

Jeśli w grę wchodzi praca z danymi, to poza wspomnianym wcześniej Excelem mamy tutaj takie rozwiązania jak Tableau czy Power BI służące do integracji czy wizualizacji danych. Jeśli chodzi o makiety, to zależy, czy analityk będzie pracował z makietami, bo często są do tego wyznaczone oddzielne role, zdarzało mi się jednak spotykać z takimi oczekiwaniami względem analityka. Mamy tutaj takie rozwiązania jak Pencil czy Balsamiq. Pozwalają one na stworzenie i opisanie projektów ekranów dla użytkowników.

Dalej – już tak naprawdę z zależności do roli w projekcie – mogą to też być przykładowo Oracle SQL Developer bądź SQL Server. Jeśli analityk dużo bardziej pracuje z bazami danych, jeżeli pracuje z API, to najczęściej spotykałam się z narzędziem Postman. Są też oczywiście inne narzędzia do tego celu, ale mam wrażenie, że Postman nadal jest najbardziej popularny.

No i oczywiście zestaw narzędzi do komunikacji. Tutaj podstawowo mamy takie narzędzia jak Outlook, Teams czy Zoom. Może się wydawać, że jest tego dosyć sporo, ale tak naprawdę wiele narzędzi jest aktualnie coraz bardziej intuicyjnych i przy de facto niewielkim nakładzie sił można spokojnie opanować obsługę pozwalającą na swobodne korzystanie z tych narzędzi – może poza takimi narzędziami jak Enterprise Architect, który jest już dosyć mocno rozbudowaną kolubryną, jeżeli chodzi o kwestie zarządzania projektami i dokumentacją. Tak naprawdę mam wrażenie, że jeżeli ma się wiedzę dotyczącą technik, metodologii stosowanych w analizie, to przeniesienie tego na różne dostępne narzędzia jest dużo łatwiejsze i dużo sprawniejsze.

Dużo wspominaliśmy o tym, że analityk na co dzień komunikuje się z programistą, a czy bierze też udział w rekrutacji programistów? Jeśli tak, to co u takiego kandydata jest dla niego najważniejsze?

Akurat z tym spotykałam się bardzo rzadko. Mam wrażenie, że to są często dwie rozdzielne role i w ten sposób są traktowane. Na rekrutacjach na analityków raczej rzadko spotyka się programistów, tak samo na rekrutacjach programistów rzadko spotyka się analityków.

Sama brałam udział w takiej rekrutacji dwukrotnie, ale jedynie w roli słuchacza. Przyznam, że ostatecznie dla mnie najważniejsze aspekty, na które zwracałam uwagę, to były kwestie związane z komunikacją i umiejętnością rozwiązywania problemów. Na tego typu rozmowach są osoby techniczne, które mają dużo większe kompetencje, żeby ocenić aspekty techniczne. Jeżeli natomiast chodzi o kwestie relacji analityk–programista, to najważniejsze będzie to, czy będziemy umieli znaleźć wspólny język i wypracować rozwiązanie jakiegoś problemu.

Jakie predyspozycje Twoim zdaniem powinna mieć osoba, która chce zostać analitykiem?

Nie wiem, czy jest zestaw jakichś wrodzonych predyspozycji, które trzeba mieć, żeby zostać analitykiem. Każdy z aspektów, który jest ważny na tym stanowisku, jest do wypracowania, tak jak każda inna kompetencja. To nie jest zawodowa koszykówka, gdzie trzeba mieć pewien wzrost, żeby łatwiej się było realizować w tym sporcie. Oczywiście są pewne aspekty, które jeśli ktoś ma już wypracowane, to będzie mu po prostu łatwiej, bo będzie musiał włożyć mniej pracy w rozwój tych kompetencji.

Na pewno są to kwestie związane z komunikacją. To jest ten aspekt, który moim zdaniem jest kluczowy, jeżeli chodzi o rolę analityka. Tutaj wchodzą takie rzeczy jak prowadzenie negocjacji, umiejętność pracy z konfliktem. Posiadanie tych umiejętności pozwala na łatwiejsze wejście w tę rolę i uzyskanie tego, co w projektach jest najważniejsze – czyli wiedzy o tym, co jest potrzebne, żeby rozwiązać czyjś problem.

Kolejny aspekt to jest oczywiście umiejętność analitycznego myślenia. Często jest to wymieniane jako pierwsza i najważniejsza kompetencja, ale mi się wydaje, że komunikacja jednak w tym wszystkim jest dużo ważniejsza. Jeżeli chodzi o samą część analityczną, to tutaj na pewno zwróciłabym uwagę na syntetyzowanie wiedzy czy umiejętność wyciągania wniosków. Często spotykam się ze stwierdzeniem, że analityczne myślenie to jest ta jedna mityczna predyspozycja, z którą trzeba się urodzić, żeby w ogóle ruszać w kierunku IT. Oczywiście posiadanie tych cech daje dużą przewagę, ale nadal można się tego nauczyć, zmienić schematy i ukierunkować się na rozwiązywanie problemów.

Może nietypowo wymienię tutaj również cierpliwość. Projekty są często dynamiczne, cele bardzo szybko się zmieniają, komunikacja bywa trudna i ważne jest to, żeby nie tracić z oczu tego, co najważniejsze – czyli dostarczenia realnej wartości. Cierpliwość na pewno więc będzie bardzo wartościowa, jeżeli chodzi o tę pracę.

I na koniec: chęć rozwoju. Wiedzy jest bardzo dużo, branża cały czas jest dynamiczna, pojawiają się ciągle nowe narzędzia, techniki, technologia cały czas idzie do przodu. Warto interesować się i dokształcać, żeby budować coraz to nowe kompetencje.

Zastanawiam się też, czy to nie jest tak, że powinniśmy mieć dużą odporność na różne naciski. Z tego, co sobie do tej pory powiedzieliśmy, analityk jest mostem, który łączy biznes i programistów. Nie zawsze obydwie strony muszą mieć te same cele. Czy to nie jest tak, że jeżeli coś nie wyjdzie, to jest to zwalane na analityka?

Odpowiedzialność jest na pewno rozłożona pomiędzy poszczególne role. Oczywiście są też aspekty, za które analitycy jak najbardziej muszą wziąć odpowiedzialność. Jeżeli to, co dostarczają jako artefakty do programistów, nie jest odpowiednio zdefiniowane i konkretne, to na pewno będzie to coś, co będzie wpływało na jakość dostarczonego kodu, ale oczywiście nie zawsze jest to wina analityka.

Trzeba pamiętać o tym, że cały zespół bierze odpowiedzialność za jakość dostarczonego rozwiązania i każda ze stron powinna brać odpowiedzialność za aspekty, nad którymi pracuje. Ale oczywiście odpowiedzialności często szuka się w innym miejscu, czyli analitycy u programistów a programiści u analityków, jednak wydaje mi się, że problem jest troszeczkę bardziej złożony, że to nigdy nie jest tak, że to jest wina jednej ze stron. To też jest powód, dla którego warto wiele rzeczy doprecyzowywać i rozmawiać – żeby mieć pewność, że to, nad czym pracujemy, jest faktycznie tym, co jest oczekiwane.

Wróćmy jeszcze na chwilę do programistów. Jeżeli taki programista chciałby zostać analitykiem, to co byś mu poradziła?

Wydaje mi się, że nie jest to typowy kierunek rozwoju (o czym już chyba wcześniej rozmawialiśmy), ale zdecydowanie podstawy wiedzy developerskiej mogą dawać bardzo dużo wartości dla roli analityka. Analityk nie zawsze musi być osobnym specjalistą w projekcie. Jego rolę może de facto pełnić inny członek zespołu projektowego i to też może być jeden z developerów.

To wydaje mi się takim najczęstszym i najsensowniejszym krokiem w celu rozwoju w tym kierunku – czyli próba wejścia w rolę analityka jako dodatkowa rola obok pisania kodu i roli technicznej, którą programista ma na co dzień. Wydaje mi się, że właśnie wiedza i doświadczenie związane z aspektami technicznymi projektu na pewno ułatwią developerowi wejście w rolę analityka, szczególnie od strony analizy systemowej.

Powiedz nam, proszę, jakich zarobków możemy się spodziewać na tym stanowisku.

Odpowiem znowu branżowo: to zależy. Zależy od tego, czy będzie to praca na umowę o pracę czy na kontrakcie. Jeśli to drugie, to też zależy, ilu klientów faktycznie będzie miał taki analityk. Oczywiście przekłada się to też na liczbę lat doświadczenia, na to, jakie kompetencje twarde analityk przynosi ze sobą do projektu oraz jakie ma stanowisko – czy jest juniorem, midem, seniorem, ekspertem, leadem czy być może managerem.

Kolejna rzecz to kwestia tego, czy będzie to firma z sektora państwowego czy może z branży prywatnej; czy kapitał jest polski czy zagraniczny; czy firma ma siedziby w Polsce czy będzie to praca na rzecz klienta z innego kraju i w innej walucie. Tych aspektów do wzięcia pod uwagę jest na pewno bardzo dużo. Zarobki pomiędzy skrajnymi aspektami tego samego tematu mogą się znacząco różnić. Do tego zarobki w IT zmieniają się bardzo dynamicznie. Ważne, żeby mieć rękę na pulsie. Zdecydowanie polecam raporty branżowe, które prowadzą regularne ankiety i pokazują bardzo fajne podsumowanie tego, jak te zarobki są rozdystrybuowane.

Patrząc na mediany dla analityków, którzy mają już jakieś doświadczenie komercyjne poparte realizacją konkretnych projektów i decydują się na B2B w pracy dla sektora prywatnego, ten poziom mitycznego „do piętnastu tysięcy netto miesięcznie” jest jak najbardziej realny – oczywiście z uwzględnieniem, że nie jest to stawka na start dla juniora i że trzeba włożyć pracę w to, żeby na tym poziomie się uplasować.

Trzeba też pamiętać, że to nie jest górna granica i że inwestycja w rozwój na pewno zwraca się w perspektywie kilku lat. W szczególności w ostatnich latach to mocno skoczyło do góry. Kilka ostatnich raportów branżowych zdecydowanie pokazuje, że różnica jest spora. Mam wrażenie, że ta mediana jeszcze kilka lat temu plasowała się na granicy około dziesięciu-dwunastu tysięcy złotych, a w tej chwili dla seniorów to kwoty zdecydowanie bliżej dwudziestu tysięcy. Juniorzy tak naprawdę już też się mogą plasować około dwunastu, ale myślę, że większość (wracając do mediany) plasuje się właśnie w okolicach tych piętnastu tysięcy.

A co według Ciebie stanowi największe wyzwanie pracy analityka biznesowego?

Zdecydowanie komunikacja. I znowu: najważniejsza kompetencja jest tutaj też największym wyzwaniem. Rozkładam sobie na czynniki pierwsze, co jest u źródła wszystkich niepowodzeń i fakapów, które miałam okazję obserwować, w których miałam okazję uczestniczyć, i dochodzę do tego samego wniosku: brak poprawnej komunikacji jest tutaj zawsze głównym powodem.

Trzeba pamiętać, że wyzwaniem nie jest tutaj to, że ludzie chcą się źle komunikować, zataić jakieś wymagania czy problem, z którym się borykają. To też nie jest tak, że analityk celowo na przykład nie dopytuje, nie szuka drugiego dna i nie chce zrozumieć danego problemu. Czasem po prostu nie wiemy, że czegoś nie wiemy, albo wydaje nam się, że coś zrozumieliśmy, a jesteśmy bardzo daleko od tego, co druga strona chciała nam przekazać.

Posiadanie więc tej chęci, żeby zawsze zadać to jedno dodatkowe pytanie, poprosić o powtórzenie; przyznanie się do tego, że czegoś nie rozumiemy; parafrazowanie tego, co usłyszeliśmy jest często bardzo trudne. To są też rzeczy, nad którymi praca praktycznie nie będzie ustawać i będzie największym wyzwaniem i największą blokadą w pracy analityka.

Oczywiście każda osoba, projekt i firma mają inne metody komunikacji, co też utrudnia ten aspekt. Jest to więc niekończące się wyzwanie i jego skutki mogą być niestety opłakane dla systemu czy budżetu. Mogą też oczywiście powodować mijanie się z głównymi założonymi celami projektowymi.

OK, powiedzieliśmy sobie o wyzwaniach, to teraz powiedzmy o satysfakcji. Co przynosi największą satysfakcję w pracy analityka?

Myślę, że ten pozytywny feedback, to zadowolenie klienta. Tutaj tak naprawdę nie jest istotne, czy klientem jest biznes czy użytkownik systemu, ale to poczucie, że zostało wytworzone i dostarczone coś, co przynosi wartość, i że osoba, która otrzymała ten produkt, jest zadowolona z efektów pracy. Oczywiście jest to satysfakcja bardzo mocno oddalona w czasie, bo często dostarczenie tego ostatecznego produktu jest mierzone w miesiącach albo nawet latach, ale fajne jest to, że de facto często tworzy się coś z niczego.

A gdy nagle się okazuje, że finansowo to się nie zgadza, to czy jako analityk uznajesz to za sukces czy za porażkę?

To, że finansowo coś się nie zgadza, nie jest do końca odpowiedzialnością analityka. To jest znowu kwestia podziału ról w projekcie. To, czy coś się spina budżetowo, to jest kwestia sponsora, kalkulacji kosztów i określenia potencjalnych przychodów. Jest to więc bardziej od strony finansowej projektu niż od strony analitycznej.

Super, jeżeli realizacja projektu faktycznie przynosi też zamierzone cele finansowe, bo to również trzeba brać pod uwagę, ale analityk często nie zajmuje się kalkulacją aspektów związanych z tym, czy dany projekt będzie opłacalny. Patrzę więc na to z perspektywy dużo bardziej użytkowej – bardziej na funkcjonalności niż na te aspekty finansowe w projekcie.

Oczywiście, jeżeli moja rola w projekcie dotyczyłaby również aspektów finansowych, czyli byłby to jakiś rodzaj analizy finansowej, to na pewno ten aspekt byłby dla mnie ważny. W większości projektów jest to jednak zdecydowanie strona użytkowa.

Jaką książkę polecisz osobie, która chce być dobrym analitykiem IT?

Myślę, że takim klasykiem jest BABOK Guide, czyli The Guide to the Business Analysis Body of Knowledge. To jest właściwie standard branżowy, jeżeli chodzi o sformalizowaną metodologię, i warto przysiąść do tej pozycji na którymś etapie rozwoju w roli analityka. Nie wiem, czy byłby to początek. Ja, zmieniając branżę, zainwestowałam się tą pozycją jako opcją na start i przyznam, że w tamtym czasie nie dobrnęłam do brzegu, porzuciłam ją na rzecz innych materiałów. Jest to bardzo bogaty zestaw technik, wiedzy, ale wydaje mi się, że na początku to zdecydowanie jest zbyt skomplikowane.

A czy jest polska wersja językowa?

Niestety nie ma. Tak dodatkowo od siebie mogę polecić Analizę biznesową. Praktyczne modelowanie organizacji Jarosława Żelińskiego – przede wszystkim ze względu na praktyczne podejście do tematu i skupienie się na bardzo wielu konkretach. To nadal pozycja, którą pewnie zaproponowałabym po wcześniejszym zrozumieniu podstaw, ale to bardzo mocna pozycja do uzupełnienia i usystematyzowania wiedzy.

To tak na koniec: gdzie możemy Cię znaleźć w sieci, jeżeli ktoś chciałby się o coś podpytać?

Sukcesywnie rozwijam social media. Teraz mocno skupiamy się mocno na tworzeniu wartościowego contentu z zakresu analizy na kilka kolejnych miesięcy. Są też plany na bloga czy kanał na YouTubie, o czym informacja będzie również na profilu. Jeżeli interesuje Was analiza na każdym poziomie, ciekawostki ze świata IT, fakty i mity z pracy w projektach oczywiście z perspektywy analityka i właściwie wszystkie tematy okołoprojektowe, to zapraszam serdecznie na Marta Balcer around IT.

Zapraszamy wszystkich. Rozumiem, że pod tą nazwą możemy szukać właśnie na social mediach, tak?

Tak, dokładnie.

Super. To, Marto, bardzo dziękuję Ci za dzisiejszą rozmowę i podzielenie się swoimi doświadczeniami.

Również dziękuję za zaproszenie. Pozdrawiam wszystkich.