Funkcja analityka biznesowego w firmach oraz projektach IT w Polsce pojawiła się dość niedawno. Zakres obowiązków na tym stanowisku oraz możliwe ścieżki rozwoju zależą w dużej mierze od specyfiki firmy i danego projektu, w jaki jest się zaangażowanym. Wielu analityków, jakich znam, nie wywodzi się z sektora IT, ale trafili do niego w wyniku przebranżowienia się. Skoro analitykami zostają osoby z rozmaitym wykształceniem i pochodzące z różnych obszarów rynku, to w jaki sposób można stwierdzić czy dany człowiek sprawdza się w tej roli? Może by tak certyfikat ECBA?
Kluczowe dla analityka jest właściwie udzielane informacje zwrotne od klienta oraz zespołu. Jakie kryteria oceny przyjąć oraz na co zwracać uwagę? Co do zasady, praca analityka jest dobrze wykonywana, jeżeli:
- zna on potrzeby klienta, któremu podpowiada możliwe rozwiązania, a jednocześnie skutecznie komunikuje je (specyfikuje wymagania) zespołowi,
- praca porusza się do przodu w założonym harmonogramie oraz budżecie.
Nie istnieje uniwersalne podejście do realizacji projektu. Nie wymyślono też sposobu działania, który odpowiadałby na wszystkie potrzeby jednocześnie. Dlatego jestem przeciwnikiem pracy tylko jedną metodą. W podejściu do klienta trzeba wykazywać się dużą elastycznością, czerpać z wielu filozofii, wybierając najbardziej optymalne elementy.
Od czego zacząć?
Stawiając pierwsze kroki zawodowe przyjąłem, że należy stale poszerzać swoją wiedzę. Tak poprzez sięganie po fachową literaturę, jak i uczestniczenie w konferencjach i szkoleniach i – jeżeli tylko jest taka możliwość – weryfikując wiedzę podczas egzaminów certyfikujących. Człowiek uczy się poprzez stosowanie różnych technik: słuchania, pisania, mówienia i wykonywania ćwiczeń. I tak też staram się działać. Od czego zacząć? Osobiście lubię zacząć od poznania literatury na dany temat, następnie zgłębiając temat podczas konferencji czy szkolenia, by otrzymać dawkę praktycznych uwag i dopytać o pewne kwestie.
Nie ma też złotego środka czy przepisu na to, jak stać się analitykiem w branży IT. Wszystko zależy od projektu i firmy, ale też bagażu doświadczeń danej osoby. Moją osobistą przygodę rozpocząłem od czytania blogów eksperckich, co skierowało moją uwagę początkowo na zagadnienie inżynierii wymagań, a następnie analizy. Po drodze odkrywałem takie obszary, jak Scrum, UX czy marketing.
Kolejne kroki
O istnieniu inżynierii wymagań dowiedziałem się w trakcie szkolenia na certyfikat ISTQB (Poziom Podstawowy). Chciałem zgłębić ten temat, stawiając pierwsze kroki jako tester oprogramowaniu – udałem się zatem na szkolenie przygotowujące do certyfikatu