Cześć, wystartowaliśmy z nowym cyklem podcastów Comarch Careeres. W każdym odcinku nie tylko przekazujemy Wam porcję informacji o różnych stanowiskach, ale także opowiadamy o ścieżkach kariery, projektach i możliwościach. Słuchając nas, dowiecie się, jakie umiejętności i doświadczenie warto posiadać. Tematem dzisiejszego podcastu będzie rola i obowiązki analityka w branży IT, a swoją wiedzą i doświadczeniem podzieli się z Wami Dominik Szczechla.

Dominik Szczechla: Cześć wszystkim! Nazywam się Dominik Szczechla, od pięciu lat pracuję w Comarch. Zaczynałem jako programista, a od trzech lat jestem analitykiem w sektorze BSS.

Mój zespół w naszym całym produkcie, jakim jest Comarch BSS, czyli Business support system produkuje jeden z modułów, jakim jest self-care, czyli taka aplikacja do samoobsługi klientów końcowych oraz sklep internetowy. Są one skierowane, jak większość produktów w naszym sektorze, do klientów z branży telekomunikacyjnej, do dużych telekomów. Mamy takich klientów jak np. Orange, którego całe wdrożenie robimy  właśnie my. Polega na wdrożeniu wszystkich systemów, modułów potrzebnych do obsługi takiego klienta. Od billingu, przez CRM, aplikacje dla back office, dla pracowników obsługi klienta, aż właśnie po sklep internetowy, czy taką samoobsługę, dla klientów końcowych.

Jako analityk zajmuję się całym przekrojem zadań, w zależności od tego, jakie są aktualnie potrzeby projektowe i jaki jest stan dojrzałości projektu. Analiza, jako część IT do Polski dotarła stosunkowo niedawno. Zaczyna być dopiero strukturyzowana, zaczynają się na takich portalach, jak NoFluffJobs pojawiać oferty pracy dla analityków, obok pracy dla programistów czy IT-opsów. Można powiedzieć więc, że Comarch jest tutaj takim trochę pionierem. A to dlatego, że tworzy własne produkty. W wielu firmach zachodnich stanowisko analityka w polskich oddziałach nie istnieje, ponieważ cała analiza biznesowa czy systemowa powstaje w zachodniej centrali, a w Polsce jest realizowana tylko produkcja kodu.

Analityk biznesowy jest osobą, która analizuje biznes klienta. Pomaga dojść od obecnego stadium tego biznesu, do docelowego, pożądanego stadium. Do takiego stanu, który klienta by bardziej satysfakcjonował. Pilnuje tej zmiany. Żeby tego dokonać, analityk biznesowy poznaje biznes klienta, poznaje jego problemy i procesy biznesowe, jakie w kiego firmie są wykorzystywane i szuka metod, żeby je usprawnić. Czy to poprzez wywiady, rozmowy, warsztaty z klientami, czy to bazując na swojej wiedzy dziedzinowej. Różnymi metodami facylitacji pozyskuje, dekomponuje i opisuje takie wymagania biznesowe. Analityk biznesowy nie wtrąca się w ogóle i nie zastanawia się jeszcze nad tym, jak dane rozwiązanie miałoby zostać zaimplementowane w jakimkolwiek systemie informatycznym.

Takimi sprawami zajmuje się zwykle właśnie analityk systemowy. Czasem jest to po prostu programista, który pełni takie obowiązki. Biorąc wymaganie biznesowe zastanawia się, w jaki sposób do architektury systemów, która jest, do produktu, który mamy, można odnieść te wymagania, z czym należy się połączyć, zintegrować, w jaki sposób to wszystko zrobić, żeby te cele biznesowe spełnić. Ta granica jest dosyć płynna, ponieważ my jako analitycy w Telco powinniśmy mieć wiedzę w obu tych środowiskach, w obu tych dziedzinach analizy. Możemy wziąć taki przykład: Comarch wdraża swoje własne rozwiązania, mamy już systemy, które są gotowe i działające, więc przykładowo nasz klient życzy sobie, żeby mieć jakąś możliwość zapraszania swoich znajomych, zbierania jakichś punktów i wymiany na dodatkowe pakiety danych, żeby móc korzystać z nich w ramach swojej subskrypcji. Analityk biznesowy zbiera to wymaganie i stwierdza, że ono składa się z kilku części tzn. że należy mieć jakiś komponent do wysyłania tych zaproszeń, należy mieć możliwość odbierania tych linków np. od dostawcy. Klient później po kliknięciu w takie linki musi mieć jakieś punkty, więc potrzebny mi system, który te punkty zlicza. Potrzebny nam jest model tych wszystkich zniżek, czy dodatkowych produktów, jakie ma za to dostać i tak dalej. Analityk systemowy, mając takie wymagania zastanowiłbym się, w jakich modułach naszego BSS, czy korzystając, z jakich istniejących rozwiązań można tu skorzystać. Czy potrzebujemy zaprogramować coś zupełnie nowego, czy możemy to skonfigurować w obecnych produktach, czy może jest jakieś gotowe rozwiązanie na rynku, z którym należałoby się zintegrować, żeby takie wymaganie spełnić, zrealizować?

Takimi właśnie rzeczami zajmuję się właściwie na co dzień w swojej pracy. Tzn. na różnych etapach zastanawiam się, jak te wszystkie wymagania klienta wdrożyć i wprowadzić w życie. Jak to zrobić w taki sposób, żeby przy okazji zadbać o to, by zespół programistów, z którymi cały czas pracuję nie „zawarczał” mnie na śmierć: „Co to jest wymyślone?”, „Tego się nie da u nas zrobić”. W zależności od etapu, na jakim jesteśmy, na początku projektu jest taka praca przygotowawcza, można powiedzieć managementowa, tzn. zbieramy się, zbieramy cały zespół, organizujemy jakieś materiały, które posiadamy i które mamy dostępne. Umawiamy się z klientami, omawiamy, jaka będzie agenda spotkań, jakie mamy podejście w ogóle do analizy, ponieważ każdy projekt też się różni. Różnią się kontrakty, różne rzeczy zostają sprzedane. Jak również mamy różny input, różny punkt wyjścia. Niektórzy klienci dokładnie wiedzą czego chcą, wiedzą jak to chcą zrealizować i chcą, żeby Comarch tylko to dostarczył. Inni klienci nie za bardzo wiedzą czego chcą, nie wiedzą z kim się integrować i oczekują, że to my zarządzimy całym procesem. Tak więc za każdym razem wygląda to troszeczkę inaczej.

Po takim etapie wstępnym, mamy często jakieś prezentacje systemu. Czasem takie prezentacje analitycy już wspierają na etapie pre-sales, zanim kontrakt zostanie podpisany. Mając doświadczenie z poprzednich wdrożeń, możemy pokazać, jakieś istniejące rozwiązania, przykładowe konfiguracje. Takie dema też zwykle prowadzimy na początku projektu, który zaczyna wchodzić w fazę analizy. Omawiamy to, co mamy dostępne, omawiamy te wymagania, które nam klient przedstawia, dyskutujemy nad rozwiązaniami i piszemy dokumenty. W Telco typowym podejściem do analizy jest to, że mamy takie etapy gdzie mamy analizę high level i mamy analizę low level. Najpierw zastanawiamy się, co właściwie zostanie dostarczone w ramach projektu, później zastanawiamy się już dokładniej, jak to ma być zrealizowane. Im dalej idziemy w ten etap low level, tym więcej potrzeba wiedzy specjalistycznej. Tym bardziej przydaje się wiedza dziedzinowa nie tylko konkretnie z tego modułu, w którym się pracuje, ale też ze wszystkich modułów pokrewnych, z którymi się integrujemy. Self-care i ashops są takimi modułami bardzo interdyscyplinarnymi, ponieważ są otoczone, korzystają z bardzo wielu innych modułów, które są wykorzystywane w całym rozwiązaniu BSS. A tu musimy sięgnąć do billingu po jakieś faktury dla klienta, musimy się zintegrować z systemem płatności, żeby klient mógł te faktury opłacić. W sklepie mamy katalogi produktów, które klient przegląda, tworzymy jakieś zamówienie, pilnujemy całej ścieżki tego zamówienia. Po zamówieniu produktu korzystamy z niego, czyli też korzystamy z wielu akcji produktowych, biznes requestów, które wpływają na różne moduły, które na backendzie zarządzają naszymi subskrypcjami.

Później, kiedy już ta analiza się zakończy należy, spisać wszystkie wyniki tej analizy, zbudować takie dokumenty, które opisują to co zostanie klientowi dostarczone. Takie dokumenty trzeba później omówić z klientem, ustalić, czy to jest dokładnie to, czego chcieli, czego oczekiwali. Po akceptacji rozpoczyna się implementacja. W czasie implementacji analityk zmienia się bardziej w analityka systemowego i współpracuje z programistami, rozwiązując problemy, które się pojawiają na bieżąco, w czasie implementacji. ypowo w czasie projektu, na podstawie tych dokumentów analitycznych definiuje się konkretne zadania dla programistów. Czy to w formie historyjek, use casów, user storiesów czy też dostarcza się jakieś pliki z konfiguracją, które potem zostają przełożone na gotowe wdrożenie. Zostają załadowane, bądź przepisane przez programistów, bądź przerobione jakimś skryptem i załadowne do naszych systemów.

W czasie takich projektów często musimy na bieżąco prezentować postęp działań, więc analityk, jako osoba, która rozumie i zarządza powiedzmy całym takim zakresem rozwiązań dla danego modułu, jest dobrą osobą, do tego, żeby śledzić postęp prac. Żeby raportować, jak idzie, czy są jakieś trudności. Może postarać się o dodatkowe wsparcie z innych modułów jeżeli brakuje tej wiedzy. Więc to jest takie wsparcie dla Project Managera ze strony analityka. Również należy cały czas trzymać kontakt z klientem. To jest bardzo ważne, aby ten kontakt nie zginął po etapie analizy, kiedy z nim bardzo często rozmawiamy, właściwie codziennie, tylko żeby był kontynuowany. Żeby wymagania można było doprecyzowywać jeżeli nie zostały doprecyzowane, żeby informować klienta o tym, jaki jest postęp, aby móc od czasu do czasu zaprezentować coś nowego, co w systemie powstało. Takie dema, treningi to też jest część obowiązków analityka w Comarch, w module BSS. 

Dużym wyzwaniem jest czasem właśnie komunikacja z klientami, ponieważ mamy klientów z całego świata. To jest taki przywilej pracy analityka, że może się spotykać i pracować z ludźmi naprawdę z innych kontynentów. Miałem przyjemność pracować we wdrożeniach dla Luksemburga, ale także dla wyspy Reunion- francuskiej kolonii na Oceanie Indyjskim. Obecnie uczestniczę w projekcie, który jest realizowany dla Nowej Zelandii. W każdym z tych środowisk mamy do czynienia z zupełnie innymi ludźmi. Rzecz jasna, trzeba złapać jakiś kontakt więc znajomość języków, przynajmniej angielskiego, jest tutaj nieodzowna. Teraz oczywiście, w czasie pandemii, wyjazdy do klientów są ograniczone, ale analityk ma okazję pojechać, spotkać się na miejscu z klientem. Uczestniczyć w różnych eventach, czy to kick offach, zebraniach, kolacjach biznesowych. Więc jeśli komuś marzy się takie życie podróżnicze, delegacyjne no to jak najbardziej analityk i sprzedawca to są dwa takie stanowiska, które oferują taką możliwość. To jest arcyważne, aby móc stanąć przed klientem, móc nawiązać z nim kontakt, dogadywać się z nim po prostu. To jest główne zadanie, ponieważ tak czasem się mówi, że analityk jest pośrednikiem pomiędzy klientem a programistą. Jest to prawda, czasami analityk jest też pośrednikiem pomiędzy programistą a programistą. Szczególnie jeśli mowa tutaj o programistach, którzy są fizycznie w innych miejscach, wykonują zadania w innych modułach.

To nie jest tak, że programiści nigdy nie chcą, czy nigdy nie powinni kontaktować się z klientami, a analityk jest tutaj takim jedynym punktem kontaktu. Na pewno jest to osoba, z którą od pierwszego dnia projektu klienci się zapoznają, z którą być może mogą się zaprzyjaźnić, zakolegować i do której będą pisać, jeżeli będzie jakiś problem. To właśnie analityk jest osobą, która zebrała te wymagania, więc jeżeli zachodzi potrzeba, żeby coś wyjaśnić, doprecyzować czy poprawić, bo również zdarzają się błędy. Czasem programista zgłasza, że coś w wymaganiach jest sprzecznego, więc analityk takie rzeczy oczywiście wyjaśnia.

Ja w swojej pracy staram się, jak najmocniej angażować też kolegów, którzy mają lepszą wiedzę w konkretnych dziedzinach. Więc tutaj współpracujemy również z grafikami, zespołem UX. Współpracujemy z osobami odpowiedzialnymi za integracje, z DevOpsami. Te wszystkie osoby, nie zawsze osobiście uczestniczą w spotkaniach z klientem, ale czasami są zapraszane przez mnie, czy przez moich kolegów analityków innych modułów na spotkania, żeby podzielić się najbardziej szczegółową wiedzą, której my osobiście nie posiadamy. Tutaj to pośrednictwo to czasami taka facylitacja tych spotkań. To organizowanie, jakby doprowadzanie, do sytuacji, w której takie sprawy mogą być wyjaśnione bezpośrednio, bez takiego przekaźnika. Analityk nie powinien być takim proxy, które tylko przyjmuje informacje i podaje je dalej. Raczej tutaj następuje coś więcej. Jeżeli nie ma w tym dodanej wartości, jeżeli analityk nie jest w stanie czegoś dodać, uporządkować w tych informacjach, które przekazuje to czasem lepiej, żeby nie pośredniczył w ogóle. Czasem lepiej jest dać się dogadać.

Czy będąc analitykiem potrzebne jest w ogóle informatyczne wykształcenie? Czy do tego, żeby mieć ten kontakt z klientem, żeby analizować te wymagania trzeba mieć jakieś specjalnie umiejętności, czy chodzi tylko o umiejętności miękkie? To jest ważne, żeby mieć umiejętności miękkie. Powiedziałbym, że jest to najważniejsze w pracy analityka, żeby mieć możliwość takiego swobodnego kontaktu. Wspominałem o tej barierze językowej. Potrzebne też trochę śmiałości, żeby w pierwszym szeregu, zaraz na froncie projektowym pojechać do klienta. Często gdzieś daleko, za granicę w nieznane tereny i tam pracować nad projektem, zbierać te wymagania. Natomiast wykształcenie i umiejętności twarde im dalej idziemy w las, tym większa odgrywają rolę.

Analiza biznesowa to nie jest coś, co polega wyłącznie na tym, żeby się dobrze dogadywać. To jest dziedzina wiedzy. Są różne certyfikaty np. IQBBA, które zbierają normy analizy biznesowej. To jak powinna być ona prowadzona, jakie powinny być artefakty, wyniki przeprowadzanej analizy biznesowej. Jest to dziedzina, w której cały czas dużo nowych wynalazków, nowych teorii, tak samo zresztą jak w teorii inżynierii oprogramowania czy różnych metodykach programowania powstaje. Powiększa się cały czas zasób tej wiedzy. Analityk podobnie, jak programista powinien być gotowy do tego, żeby tę wiedzę cały czas zdobywać. I to nie tylko wiedzę o tym, jak przeprowadzać analizę, ale także wiedzę typową techniczną. Nie są u nas analitykami, tylko, ani nawet chyba w większości osoby, które mają wykształcenie typowo informatyczne, programistyczne. Akurat ja ukończyłem informatykę, natomiast wśród moich kolegów bardzo często spotkamy osoby po telekomunikacji. To dosyć oczywiste, biorąc pod uwagę, że pracuję w Telco BSS. Również wszystkie inne specjalności, czy to jeśli chodzi o językowe, czy to jeśli chodzi o jakieś bardziej techniczne. Wszystkie takie osoby z wykształceniem i odpowiednim podejściem, myślę, że spokojnie mogą spróbować swoich sił w analizie. 

Tutaj nie ma takiego dużego stosu technologicznego, który analityk musi mieć opanowany. Na tych etapach analizy biznesowej, w zależności znowu od tego z kim pracujemy, często przydaje się możliwość rysowania diagramów w UML i BPMN. Na pewno konieczna jest możliwość, żeby takie diagramy zrozumieć. Natomiast jeżeli przejdziemy do tych późniejszych etapów, do tej analizy niskopoziomowej, do tej która się dzieje już po zamknięciu etapu analizy, wtedy mamy zebrany cały zakres projektu i próbujemy umieścić te wszystkie klocki gdzieś tam w naszym systemie. Kiedy dyskutujemy z programistami, no to tutaj nie ma tak naprawdę wiedzy technicznej, która będzie nieprzydatna zupełnie w takiej sytuacji. Najważniejsza część tej wiedzy, czyli wiedza o naszym produkcie, wiedza o tym, jak działa billing, jak działa katalog produktów, jak działa CRM, to jest coś, czego nie nauczmy się na studiach. To trzeba poznać, pracując tutaj. Stąd, ja zaczynając, jako programista miałem o tyle prościej, że już miałem pewną wiedzę w tych dziedzinach. Wiedziałem, jak się w tym poruszać. Ta wiedza jednak może być uzupełniana. To znaczy, nie mając jej na początku, ale współpracując z programistami, polegając na tym, jakie oni mają zdanie, jaką oni mają wiedzę, możemy kroczek po kroczku, klocek po klocku składać sobie tę wiedzę.

Ważne, jest to, żeby śledzić nowinki, to co się dzieje na rynku. Wiedzieć, jakie bazy danych, czy API restowe jest obecnie wykorzystywane. Jak w ogóle jest zbudowane takie API, mieć podstawową wiedzę o tym, jak taka baza danych może działać. To pomaga często w nieoczekiwanych sytuacjach. Nawet nie tylko, kiedy już zastanawiamy się nad rozwiązaniem wraz z programistami, ale czasem do takiego przełamania lodów, do załapania wspólnego języka z osobą techniczną od strony klienta, która dzięki temu mając z nami wspólny język, potrafi nam lepiej przekazać jakieś szczegóły np. dotyczące skomplikowanej integracji, którą próbujemy zamodelować w czasie analizy.

Taka ścieżka rozwoju, jako analityk to jest znów podobnie jak ścieżka kariery programisty ciągły rozwój. Wiąże się to z tym, żeby pogłębiać swoją wiedzę odnośnie modułów, w których się pracuje. Pogłębiać wiedzę odnośnie innych modułów, tak żeby móc komunikować się w ramach całego szerokiego rozwiązania, ale także trzeba śledzić nowinki na rynku, ponieważ analityk to osoba, która decyduje troszeczkę o kierunku, w jakim idzie cała firma i w jakim rozwija się cały produkt. Często jest tak, że klienci oczekują, że to my będziemy proponować innowacyjne rozwiązania. Coś, czego nikt inny nie ma. Co da im jakąś przewagę. Zatem analityk powinien wiedzieć, jakie są typowe rozwiązania różnych problemów. Powinien śledzić, co nowego wychodzi, co nowego oferuje konkurencja, tak żeby Comarch jako firma mógł pozostawać konkurencyjny. Mógł prezentować coś, co jest świeże, a co przynajmniej nie odstaje od rozwiązań konkurencyjnych.

Jako analityk, później jest otwarta droga do tego, że jeśli czujemy się w tej pracy z klientem dobrze i interesuje nas to, analitycy często zostają później konsultantami, bądź też sprzedawcami i już później, jakby żyją z tego, że mają tę łatwość nawiązywania tych kontaktów. Inni stawiają raczej na to, żeby zostać przy tych bardziej technicznych aspektach, jeżeli nie umieli programować. Czasami analityk uczy się programować i staje się później programistą/ analitykiem systemowym. Niektórzy moi znajomi w Comarch są architektami, zarządzają dużymi wdrożeniami, korzystając z tego, że właśnie poznali więcej, niż to swoje własne poletko, że mieli szansę wyjść na szersze pole. Dowiedzieć się, jak działają inne moduły, z którymi ich moduł się komunikuje i są w stanie zarządzać wymaganiami, które dotykają wielu modułów. Takie osoby są bardzo potrzebne w każdym dużym projekcie.

No i w końcu jeżeli ktoś ma taki dryg do zarządzania, do managementu, to bycie analitykiem to jest dobra szansa do tego, aby poznać wiele osób i być może spróbować gdzieś w przyszłości poprowadzić projekt. Więc praca analityka daje  bardzo dużo możliwości i to nie tylko możliwości do tego, żeby podróżować, czy poznawać ludzi. Nie tylko możliwości do tego, żeby się uczyć, ale także, żeby później swoją karierę prowadzić w bardzo różnych kierunkach. To jest taka rada ode mnie. Jeżeli ktoś chciałby zacząć karierę w IT, nie zamykajcie się na bycie programistą, ponieważ cały biznes IT, cały przemysł IT to nie jest tylko programowanie. Można powiedzieć, że programowanie to jest takie rzemiosło, to jest taka podstawa, na której zbudowany jest cały biznes IT. Natomiast stanowisk, obowiązków, które należy wykonać, jest dużo więcej. Więc niezależnie od tego, czy ktoś chce być programistą i naprawdę tylko na tym mu zależy, czy ktoś po prostu chciałby gdzieś zakręcić się, może przebranżowić do IT, to jest wiele możliwości. Nie mówię tutaj tylko o analizie, ale również potrzeba grafików, specjalistów UX, testerów, DevOpsow, managerów itd. To są wszystko stanowiska, które mają swoją bardzo ważną rolę, mają swoje miejsce w procesie wytwarzania oprogramowania. Tak się składa, że analityk, jako stanowisko nie do końca określone, które ma bardzo szerokie pole obowiązków,  dotyka po trochu obowiązków różnych tych osób i do analityka lub z analityka w branży IT można się płynnie przemieścić, przebranżowić. Czasem, pracując dalej w obrębie tego samego wdrożenia, tylko dostając nieco inne obowiązki. 

Dzięki serdeczne i pozdrawiam!