Projekty dla klientów z Islandii, Holandii czy Nowej Zelandii to obecnie standard, a praca w branży telekomunikacyjnej daje spore możliwości rozwoju i nauki. Pracy jest sporo, ale jak zaznacza nasz rozmówca - „Nie ma czasu na nudę”. Dzięki międzynarodowym projektom możemy tworzyć globalne rozwiązania i dostosowywać ścieżkę kariery do własnych oczekiwań.
Efekt końcowy i świadomość, że wdrażało się rozwiązania dla światowych sieci telekomunikacyjnych, daje ogromną satysfakcję. Choć od początków mojej zawodowej kariery sporo się zmieniło, a sama branża przeszła niejedną transformację to projekty dla telecomów dalej pozostają jednymi z najatrakcyjniejszych w branży. Wyjazdy do klienta niesamowicie otwierają oczy. Dzięki nim zrozumiałem, po co robimy funkcjonalność X w module Y, gadającą z Z – komentuje nasz dzisiejszy rozmówca, Wojciech Wiśniowski, dyrektor działu BSS R&D w Comarch, który swoją przygodę z Comarch rozpoczął od stażu.
Swoją przygodę z Comarch rozpocząłeś w 2004 roku od programu stażowego. Czy pamiętasz swoje początki?
Tak, rzeczywiście. Pracę w Comarch zacząłem od wakacyjnego stażu w 2004 roku. Studiowałem wówczas na AGH i chciałem zdobyć pierwsze doświadczenie w zawodzie. Dostałem się na staż o profilu telekomunikacyjnym, a zadanie, które otrzymał mój zespół, było bardzo ambitne. Musieliśmy napisać automat do instalacji patchy i upgradów dla nowej wersji Tytana (Comarch Billing System).
Oczywiście udało nam się zrealizować zadanie i w ten sposób powstał Tytan Patch Installer, który jest używany do dziś. Po stażu otrzymałem propozycję dalszej współpracy i tak oto rozpoczęła się moja przygoda z Comarch.
Szybko okazało się, że jesteś pełnokrwistym programistą. Jak wyglądała praca w branży telekomunikacyjnej nad wspominanym modułem, który musieliście pisać od zera
Ze stażysty wskoczyłem od razu w rolę programisty. Moja praca nie polegała wówczas tylko na kodowaniu. Razem z moim kolegą z zespołu, który później został szefem tego działu, musieliśmy zrobić research dostępnych narzędzi. Następnie wybrać te najlepsze, zaimplementować je, dodatkowo przeprowadzić testy i tuning wydajności. Końcowym etapem było napisanie w tym narzędziu kilku przykładowych raportów. Mimo presji czasu udało nam się zrealizować cel. Ten moduł jest wciąż dostępny i co najważniejsze używany przez klientów. Warto dodać, że skorzystano z niego już w ok. 30 różnych wdrożeniach.
To był Twój pierwszy duży projekt i od razu udało się zakończyć go z ogromnym sukcesem. Czy możesz zdradzić coś więcej na temat tego modułu? Czego dotyczył?
Moduł Raportów w Billing System (BS) składał się z kilku części. Pierwsza część - data source - pozwalała na przygotowanie zapytań do bazy, które agregowały dane na potrzeby późniejszej prezentacji. Drugą częścią był moduł do definicji layaoutów raportu. Ciekawym rozwiązaniem była możliwość wpinania pluginów na potrzeby różnych formatów, takich jak: RTF, CSV, XLS, PDF. Oczywiście można było dla danego data source podpiąć kilka layoutów i generować w różnych formatach. Ostatnia część to moduł podglądu i generacji gotowych raportów.
Niektóre raporty w Billing Systemie są duże, np. szczegóły połączeń telefonicznych dużej firmy, więc pluginy musiały mieć bardzo dużą wydajność. Moduł był dostępny zarówno w aplikacji dla administratorów billingu (Delphi) jak również dla operatorów z biur obsługi klienta (Java). W związku z tym musiał powstać moduł, który działa zarówno z Delphi, jak i Java.
Jako ostatnią ciekawostkę dodam, że później rozszerzyliśmy te mechanizmy do użycia również w C++ na potrzeby masowej generacji wydruków faktur z systemu bilingowego.
Hofdorp – koło Amsterdamu – projekt marzenie od analizy przez implementacje po uruchomienie, fot. W. Wiśniowski
Jak wspomniałeś, w tamtym czasie Twoja praca nie polegała tylko na kodowaniu. Będąc programistą stały przed Tobą inne zawodowe wyzwania.
Po tym, jak zakończyliśmy prace nad wspominanym modułem, przyszło kolejne ciekawe wyzwanie. Tym razem miałem zmienić technologię i zająć się podnoszeniem systemu obsługi klientów w biurach obsługi klienta (BOK) do Java 5. W trakcie realizacji tego zadania, biznes klienta się rozwijał i rosła ilość użytkowników - niestety pojawiły się problemy wydajnościowe. Jednak dzięki temu, mogłem zająć się stres testami, wtedy JMeter, oraz optymalizacją pamięciową i wydajnościową dużej aplikacji w Java. Dla mnie jako pracownika był to kolejny etap ścieżki rozwoju i doskonała szansa na zdobycie dodatkowych umiejętności.
Czy mógłbyś wyjaśnić, na czym dokładnie polegało przygotowanie takich testów?
To było bardzo ciekawe zadanie. Operowałem na systemie produkcyjnym dużego operatora telekomunikacyjnego. Musiałem przygotować środowisko atakujące, składające się z kilku maszyn. Następnie nagrać testy generujące obciążenie typu zbliżonego do tego, które generują użytkownicy systemu. Pod koniec dnia musieliśmy uruchamiać testy i analizować zachowanie systemu. Dowiedziałem się wtedy dużo o działaniu maszyny wirtualnej Java, o wewnętrznej implementacji wielu klas z java.util oraz o tym, jak zachowują się aplikacje w systemach Linux.
W tym momencie nastąpiła u Ciebie niewielka przerwa zawodowa. Wyjechałeś na studia za granicę i poświęciłeś czas nauce. Czy nie było problemów, abyś po tym czasie, wrócił do firmy?
Nie, w momencie podjęcia decyzji o przerwie i wyjechaniu na studia do Grenoble wiedziałem, że będę mógł wrócić do Comarch. Firma umożliwiła mi tę przerwę. Natomiast, gdy już wróciłem, to okazało się, że nastała nieco inna rzeczywistości. Projekty i praca w branży telekomunikacyjnej, jak i w całym IT są dosyć dynamiczne. Mieliśmy kilku nowych klientów i spory projekt na horyzoncie. Jeden z tych, które są marzeniem każdego programisty. Mój szef przyszedł do mnie i powiedział: „Trzeba jechać do Holandii zrobić analizę nowego systemu, potem musimy go napisać i uruchomić u klienta – pojedziesz?”.
Zakładam, że długo się nie zastanawiałeś i pojechałeś?
Oczywiście. Choć zwykle zespół R&D nie jeździ do klientów, ponieważ w większości przypadków pracuje już na opracowanych wymaganiach.
W tym przypadku potrzebna była zarówno analiza biznesowa, jak i techniczna. To był innowacyjny projekt i wiele od niego zależało, więc pojawił się stres. Oczywiście udało nam się zrobić tę analizę. Dzięki temu dostałem zespół doświadczonych programistów i mogliśmy rozpocząć pisanie tego systemu. Testy u klienta przeszły pomyślnie, a ja, zupełnie tego nie planując, zostałem na chwilę analitykiem, a następnie projektantem.
Zespół R&D + Wdrożenia na oficjalnym kickoff na wyspie Reunion
Muszę przyznać, że to dość imponująca ścieżka kariery i wygląda na to, że nie mogłeś się nudzić.
Zdecydowanie nie, choć można odnieść wrażenie, że nie mogłem znaleźć swojego miejsca. Tak jednak nie było. Wszystkie te stanowiska były ciekawe i pozwalały mi patrzeć na proces produkcji oprogramowania z różnej strony. Takie wyjazdy do klienta niesamowicie otwierają oczy. Wtedy zrozumiałem, po co my robimy „funkcjonalność X w module Y, gadającą z Z”. Dopiero widząc, jak klient używa obecnego systemu i jak wyobraża sobie użycie naszego systemu, można zrozumieć, na co zwracać uwagę przy produkcji oprogramowania.
Patrząc na tempo twojego rozwoju, to chyba nie koniec?
Siłą rozpędu w 2009 roku jako ex-programista, ex-analityk, a ówczesny projektant, trafiłem znowu do Holandii, tym razem jako techniczne wsparcie dla dużego operatora KPN. To była końcowa faza długiej i żmudnej analizy. Krótko mówiąc - była to jazda bez trzymanki. Przed nami było kilka bardzo intensywnych wyjazdów z kolegami z działów wdrożeniowych, a następnie trzeba było wszystko zaimplementować w obrębie mojego zespołu.
Ten projekt był kluczowy z punktu widzenia firmy. Wtedy o tym nie wiedzieliśmy, ale stopniowo rosła rola naszego software’u i przez kolejne lata KPN migrował kolejne systemy do naszego rozwiązania. Do dziś go rozwijamy i obecnie w modelu Scrum prowadzimy sprinty z klientem. Dla mnie była to dalsza możliwość rozwoju oraz poznania nowych modeli biznesowych dla telecomów. Finalnie mój zespół się rozrósł i z Team Leadera zostałem kierownikiem działu.
KPN, Holandia- Haga. Ze średniego projektu ewoluował i dziś stanowi znaczące źródło przychodów dla Telco, fot. W. Wiśniowski
Twoja praca często wiąże się z wyjazdami zagranicznymi. Wspomniałeś, że pracowałeś w Holandii, ale to chyba niejedyny kraj, który udało Ci się odwiedzić w celach zawodowych?
W roku 2013 trafiła się okazja, żeby dodatkowo wziąć udział w projekcie na Islandii. Zespół działał praktycznie samodzielnie, ale potrzebne były kompetencje, które miałem, więc zgłosiłem się do pomocy przy analizie.
Jako ciekawostkę dodam, że na Islandii wymienialiśmy system, który działał tam od lat. Wiedza na temat systemu w firmie klienta była mocno rozproszona. Niesamowitą przygodą było dla mnie odkrywanie systemu i rysowanie architektury u klienta. Finalnie po pierwszym wyjeździe, mieliśmy na tablicy wielki diagram z systemem corowym w środku i ogromną ilością innych systemów o islandzkich nazwach. Finał na szczęście, był taki, że nasz system udało się uruchomić, dane zostały przeniesione i wszystko działa do dziś.
Islandia – wymiana systemu, który był wdrożony 30 lat temu…. Ciekawe wyzwanie, fot. W. Wiśniowski
Na koniec warto przypomnieć, że zaczynałeś jako stażysta, a dziś jesteś managerem, który zarządza trzema różnymi działami. Na Twoim przykładzie widać, że programista wcale nie musi tylko kodować, a ścieżki rozwoju to tak naprawdę dość indywidualna kwestia.
Zarządzam trzema działami: dwoma produkcyjnymi, i jednym DevOps. A to na pewno nie koniec. Obecnie prowadzę bardzo intensywną rekrutację pod dalszy rozwój BSS Suite. Przed nami wyzwania stawiane przez Cloud – micro service – deployment w publicznych chmurach, automatyczne skalowanie itd. Ciągła pogoń za nowymi technologiami powoduje, że cały czas dużo się dzieje. Tak więc pracy w branży telekomunikacyjnej jest sporo i bez wątpienia nie można się nudzić.
W Comarch naprawdę można robić „to, o czym się marzyło”. Jeżeli ktoś jest zmotywowany, chce się rozwijać, nie boi się wyzwań, albo boi się, ale jednak je podejmuje, to można bardzo wiele. To jest ogromna przewaga w stosunku do innych firm.