Kim jest IT Architect? Wywiad z Pawłem Pietrzakiem
Możliwość wyboru własnej ścieżki kariery, która jest dopasowana do konkretnego pracownika jest niezwykle istotna dla jego rozwoju. Duża zmiana w życiu zawodowym często może wiązać się ze sporym stresem i obawami przed dorównaniu oczekiwaniom. O swojej drodze i własnych doświadczeniach ze zmianami w ścieżkach kariery odpowiedział nam Paweł Pietrzak, IT Architect w Sollers Consulting.
Spis treści
Czym zajmuje się IT Architect? Jakie istnieją możliwości rozwoju na tym stanowisku?
IT Architect powinien umieć drążyć tematy i zadawać trudne pytania – zarówno osobom technicznym jak i biznesowym. Musi zrozumieć potrzeby biznesowe, możliwości techniczne, poznać ograniczenia w obu tych obszarach. Na podstawie tych informacji powinien zaproponować możliwe rozwiązania z argumentami za i przeciw oraz dając swoją rekomendację. Dzięki temu osoby decyzyjne mogą ocenić ryzyko i wybrać najlepsze rozwiązanie. Musi czasami studzić marzenia i oczekiwania Project Managerów. No i rzecz najważniejsza – potrafić zaprojektować optymalne rozwiązanie, a później pilnować realizacji tego planu – współpracując z zespołami projektowymi przy realizacji.
Jeśli chodzi o możliwości rozwoju – to IT Architect musi być na czasie z nowinkami technicznymi i trendami w IT. Rozwój może oznaczać nie tylko nowe technologie (np. Cloud), ale również nowe systemy, rynki. To poszerza horyzonty i pozwala na przenoszenie najlepszych praktyk rynkowych. Przygotowywanie ofert dla potencjalnych klientów pozwala mocno się rozwijać – trzeba poznać specyfikę klienta – jego systemy, procesy, ograniczenia – i dostosować ofertę operując założeniami. I to wszystko w bardzo krótkim czasie.
Czym są te najlepsze praktyki? Co ostatnio wzbudziło Twoje zainteresowanie?
Przykładem najlepszych praktyk jest np. nieużywanie systemów ubezpieczeniowych do raportowania. Brzmi banalnie, ale u wielu klientów problemy z wydajnością wynikają z tego, że potrzeby biznesowe są realizowane w niewłaściwym systemie. U jednego z klientów spotkaliśmy się z problemem długiego logowania do systemu. Problem leżał w tym, że na pierwszym ekranie po zalogowaniu użytkownika zbierane i wyświetlane było wiele informacji. Po przedyskutowaniu doszliśmy do wniosku, że można te dane dostarczyć w raporcie generowanym raz dziennie poza systemem.
Kolejny przykład to upraszczanie procesów. Niektórzy klienci działają w oparciu o praktyki, które stosują od lat – bo tak zawsze było. Można wtedy pokazać, że ustawiając odpowiednie walidacje w systemie możemy przerzucić część obowiązków z użytkowników na system.
W jaki sposób zostałeś IT Architectem?
W Sollers w 2017 roku mieliśmy zmiany w ścieżkach kariery. Wtedy był czas na przemyślenia co dalej. Wykorzystałem ten moment, żeby zastanowić się co sprawia mi największą przyjemność w pracy i w czym chce się rozwijać.
Pomogły też rozmowy z Bartkiem – współautorem zmian w ścieżkach, oraz z Krzyśkiem – moim ówczesnym “Kołczem” (obu serdecznie pozdrawiam!). Pomogli mi podjąć decyzję, która po czasie okazała się tą właściwą. Blisko technologii, kodu, poznawanie regionalnych ograniczeń, rozwiązywanie problemów na projekcie – to jest to, co w pracy IT Architekta lubię najbardziej.
Jakie miałeś wówczas wyobrażenie o pracy Architekta? Kiedy zweryfikowałeś te wyobrażenia?
Dla mnie wówczas Architekt to był ktoś kto wszystko wie. Porównywałem się z kolegami z Sollers na tym stanowisku. Wydawało mi się, że w wielu obszarach mam braki. Zweryfikowałem to wyobrażenie na podczas rozmów z osobami, które uważałem za guru oraz podczas kolejnych projektów.
Nie trzeba wszystkiego wiedzieć, tylko szybko się uczyć, pytać i szukać – tak też działają osoby, które ja pytałem o poradę. Wiedza przychodzi z czasem a doświadczenia z poprzednich projektów bardzo pomagają znaleźć się w nowych realiach. Nie ma osób, które wiedzą wszystko – są za to takie, które mają duże doświadczenie i potrafią docierać do wiedzy na kilka sposobów.
Jakie cechy lub umiejętności powinien mieć aspirujący IT Architect? Co jest ważne i co może się przydać w jego codziennej pracy?
Aspirujący IT Architect, powinien przede wszystkim cechować się doświadczeniem we wdrażaniu systemów IT oraz świetną komunikacją – zarówno z biznesem jak i z ludźmi technicznymi. Powinien być kreatywny, dociekliwy oraz umieć szybko się uczyć.
Pamiętam gdy dostałem się na projekt w Japonii, żeby zbadać wydajność systemu przed wdrożeniem produkcyjnym. Zapoznałem się z błędami zgłoszonymi do systemu. Było ich całkiem sporo i – żeby ułatwić sobie pracę – zacząłem zamykać te już nieaktualne. Niektóre z nich były zgłoszone 8 miesięcy wcześniej. Jak inni członkowie Zespołu zobaczyli, że jestem “odważny” i zamykam błędy – sami mi podesłali listę kilku kolejnych, które były do zamknięcia. Wiedzieli o tym, że te błędy zaśmiecają JIRA – tylko bali się odpowiedzialności!
IT Architect musi być biegły w przeszukiwaniu wszelkich dokumentacji, robieniu – samodzielnie lub w grupie – lokalnych PoC’y, czyli mini projektów udowadniających lub obalających hipotezy.
Jakie wyzwania stanęły przed Tobą podczas zmiany ścieżki kariery?
Po pierwsze podjęcie decyzji “co chcesz dalej robić”. Po drugie musiałem udowodnić, że spełniam wymagania dotyczące roli IT Architect. Zmiana na początku była symboliczna – zmiana nazwy stanowiska w systemie HR oraz w stopce.
Zakres obowiązków na początku nie uległ zmianie, bo zmiana ścieżki odbyła się w trakcie projektu, na którym byłem. A pierwszymi nowymi zadaniami były oferta dla Klienta oraz uczestnictwo w incepcji projektu. W Sollers zawsze można znaleźć kogoś, kto już tam był i podpowie co i jak – to bardzo pomaga.
W jaki sposób trafiłeś do Sollers Consulting?
Postanowiłem zmienić pracę. Był to czas, kiedy myślałem “nigdy nie pójdę pracować jako konsultant”. Otworzyłem się na oferty pracy i postanowiłem sprawdzić jak teraz wygląda rekrutacja. Dostałem telefon od head hunter’a z zaproszeniem na spotkanie rekrutacyjne dla Sollers. Zgodziłem się, bo chciałem zacząć poszukiwania.
Po wszystkich etapach rekrutacji uznałem, że tu są ludzie, od których się wiele nauczę i to jest to miejsce, gdzie chcę pracować. W poprzedniej pracy nabrałem takiej niezdrowej pewności siebie. Na rozmowie rekrutacyjnej w Sollers zrozumiałem, że są tu osoby z ogromną wiedzą, od których mogę się wiele nauczyć. Po niemal 10 latach wciąż uważam, że to była bardzo dobra decyzja.
10 lat w jednej firmie IT to niespotykanie długo. Rozwiń proszę, co dla Ciebie jest najbardziej wiążące, co utrzymuje Ciebie w jednej firmie?
Nie zapominajmy, że to consulting. Każdy kolejny projekt to nowe otoczenie, zespół, wymagania, priorytety i problemy. Czyli zupełnie jak nowa firma, z tym, że te same – znane – benefity, zalety oraz… wady. To co mnie trzyma w Sollers to zespół, praca w projektach, w których sukces sami wierzymy oraz to, że zdanie pracowników naprawdę ma znaczenie.
Nie masz wrażenie, że tak długa praca w jednej firmie nie pozwala Ci odkryć innych branż, zdobyć innych doświadczeń? Wiele osób właśnie tym argumentuje częstą zmianę pracy
Co do innych branż to po części prawda. Zasiedziałem się w “tych ubezpieczeniach”. Zanim przyszedłem do Sollers zastanawiałem się nad zmianą branży. Jednak oferty z “ubezpieczeń” same spływały, a inne – nie. Po pewnym czasie doszedłem do wniosku, że nie przeszkadza mi pozostawanie w jednej tematyce. Wykorzystuję swoje doświadczenie zdobywane latami, nie muszę się uczyć branży, a jedynie specyfiki danego kraju. I wcale nie czuję, żebym się nie rozwijał.
Pracuję na projektach dla klientów z wielu krajów: Polska, Dania, Wielka Brytania, Francja, Austria, a nawet Japonia. Do tego na wielu projektach uczę się nowych obszarów – czasami pracuję w systemach do obsługi polis, innym razem w systemach do likwidacji szkód, a gdzie indziej tworzę podejście do testowania wydajności. Brałem udział w projektach małych – na kilka osób oraz takich, gdzie zespół projektowy miał 450 osób a użytkowników końcowych było 12 tysięcy. Tu naprawdę można znaleźć ciekawe wyzwania.
Jakich osób poszukujecie do waszego zespołu? Czym powinni charakteryzować się potencjalni kandydaci, aby dobrze wpasować się w kulturę Waszej firmy?
Przede wszystkim szukamy osób komunikatywnych i lubiących pracę w zespole. W consultingu to podstawa. Trzeba drążyć tematy, łączyć fakty i … nie zawsze zgadzać się z wymaganiami. Każdy kandydat musi znać język angielski – bo to jest nasz wewnętrzny język komunikacji – jedyny, który łączy wszystkich pracowników. Ważne jest, żeby osoby dołączające do zespołu szybko wchodziły w tematy – w tym również zmiany technologii czy języka programowania.
Firmy konsultingowe muszą się dostosować do tego co oferuje rynek i czego potrzebują klienci. W moim przypadku też tak się stało – byłem zatrudniony jako projektant-programista PL/SQL i plan był trafić na taki projekt. Na onboardingu okazało się, że planowany projekt upadł i jest potrzeba żebym zmienił technologię i zaczął szkolenie z nowego systemu i języka programowania obiektowego.
Paweł Pietrzak. Absolwent WEEIA Politechniki Łódzkiej. Obecnie pracuje jako Senior IT Architect w Sollers Consulting. W branży ubezpieczeniowego IT pracuje od 15 lat. W Sollers od 10 lat. Wdraża systemy ubezpieczeniowe oraz doradza ubezpieczycielom w Polsce, Francji, Wielkiej Brytanii, Danii, Japonii.