Jak wygląda praca w bankowości? Devdebata

Czym projekty bankowe różnią się od innych? Kto odnajdzie się w bankowości oraz w jaki sposób w ogóle wygląda praca w tym segmencie rynku? Na te pytania wspólnie odpowiedziało pięciu doświadczonych developerów z Margo.

W devdebacie udział wzięli:

• Michał Dobrowolski. Senior IT Project Manager, Konsultant Margo, certyfikowany Project oraz Programme Manager z 14 letnim doświadczeniem w biznesie oraz IT. Realizował projekty w 3 bankach. Z wyróżnieniem ukończył niejedne studia. Był wielokrotnie nagradzany za skuteczność w zarządzanych przez siebie projektach. Lubi sport, wspinaczkę wysokogórską, podnoszenie ciężarów, triathlon.
• Łukasz Napora. .NET Fullstack Developer, Konsultant Margo. Swoje 7-letnie doświadczenie jako developer zdobywał w branżach: telekomunikacyjnej, finansowej oraz bankowej. W przyszłości chciałby rozwijać się w kierunku architekta. Lubi żeglować, a także uprawiać inne sporty takie jak: snowboard, crossfit czy bieganie.
• Marcin Szymczak. Architekt / Senior Java Developer, Konsultant Margo. Z IT związany od 10 lat. Pracował do tej pory w 5 bankach, głównie w międzynarodowych środowiskach i projektach. Jego mocną stroną są wystąpienia publiczne, miał okazję być prelegentem m.in. na Warszawskich Dniach Informatyki. Prywatnie lubi taniec i niepraktyczne samochody.
• Patryk Mundzik. Quantitative Risk (C#) Developer, Konsultant Margo. Aktywnie uczestniczy w rekrutacjach przeprowadzając weryfikacje techniczne kandydatów. Doświadczenie w IT zbierał pracując dla instytucji finansowych oraz w konsultingu zarządczym. Specjalizuje się w platformie .NET oraz wycenie instrumentów finansowych. W czasie wolnym spotkać można go w kuchni oraz w podróży (najbardziej lubi te kulinarne).
• Łukasz Pysz. Frontend Architekt / Team Leader, Konsultant Margo. Od 12 lat programuje w technologiach frontendowych (JavaScript, Angular, React, Vue) jak również w technologiach backendowych (Java, PHP, C#). Prowadzi szkolenia dla początkujących adeptów kodowania. Zawodowo programuje, szkoli, rekrutuje i audytuje – można określić, że odpowiada za pełne full circle. W wolnych chwilach kolekcjonuje okrągłe kawałki plastiku z zapisami dźwiękowymi.

Na temat branży bankowej narosło wiele mitów, spróbujmy ją zatem odczarować. Jak tu trafiliście i jakie były Wasze pierwsze wrażenia?

Michał Dobrowolski:

Mój pierwszy projekt w bankowości realizowałem dla private banku w Genewie. Pracują tam ludzie, którzy czują się wyjątkowo i mają ku temu powody, bo zarządzają ogromnymi majątkami. Dość mocno odczuwalna jest tam też obecność „polityki”. Wcześniej nie zdawałem sobie sprawy, że istnieje taki obszar bankowości. Pracując tam uczyłem się na bieżąco i było to dość mocne doświadczenie, bo tutaj jeden klient może być wart tyle co pół banku!

Bankowość inwestycyjna charakteryzuje się wielkimi kwotami i pojedynczymi klientami. Tu na błędy po prostu nie można sobie pozwolić, bo jeden błąd w implementacji systemu informatycznego może kosztować bank miliony (utratę klienta, straty finansowe). Bankowość inwestycyjna i wealth management przypominają mi produkcję szwajcarskich zegarków – ze względu na precyzję oraz tempo wypuszczania ich na rynek. Inne zegarki wychodzą na rynek często i są sprzedawane za małe pieniądze, a wyprodukowanie fantastycznych modeli Omegi czy Rolex’a to sztuka, która sporo kosztuje i jest czasochłonna.

Łukasz Napora:

Powiedziałbym, że do bankowości trafiłem raczej standardową drogą. Szukałem nowego projektu, który by mi odpowiadał pod względem technologicznym oraz obowiązków. Znalazłem kilka interesujących ofert, najciekawsza okazała się ta z sektora bankowego.

Byłem zaskoczony, jak sprawnie poszła rekrutacja oraz wdrożenie mnie do projektu, biorąc pod uwagę, że miało to miejsce podczas pandemii. Podobał mi się proces rekrutacji. Zawierał tylko niezbędne do zweryfikowania elementy, nie był sztucznie rozciągnięty, nie składał się z kilkunastu etapów. Obawiałem się, że wdrożenie zdalne w tak dużej firmie będzie trudne i będzie wymagało dużego nakładu pracy. Jednak w rzeczywistości okazało się bardziej przyjazne niż oczekiwałem. Niewątpliwie bardzo pomocna była dokumentacja systemu, która po pierwsze istniała, a po drugie była na bieżąco aktualizowana.

Marcin Szymczak:

Trafiłem tu trochę z przypadku. Kiedy planowałem swoją karierę w IT to raczej pod względem technologii, jakimi chciałbym się zajmować. Podejrzewam, że większość ludzi też tak robi – chcą programować w Java lub .Net, a branża to sprawa drugorzędna. Do bankowości przyciągnęły mnie między innymi atrakcyjne stawki, które potrafiły być wyższe niż w innych branżach.

Moje pierwsze wrażenia były takie, że jest to branża dziwna i dużo bardziej uregulowana niż to, co widziałem wcześniej. Bo jeśli trafi się do startupu czy sprzedaje dowolny produkt (szklanki czy ciężarówki), nie ma dodatkowych komplikacji. A jeśli weźmie się pod lupę produkty bankowe, to wszystko jest bardzo mocno uregulowane. Ale z perspektywy programisty praca w banku to dalej praca w dziale IT. Pracowałem w m.in. bankowości korporacyjnej oraz retailowej (skierowanej do klienta indywidualnego), ale także w firmie, która produkowała ciężarówki i różnic w tworzeniu aplikacji od strony architektury, procedur, testów itd. nie było aż tak wiele, te rzeczy są stosunkowo podobne.

Jeśli aplikacja bankowa się popsuje, będzie informował o tym cały Internet zawsze na stronach głównych i z wymienioną nazwą banku. Jakiś czas temu awarię miał YouTube i nie było o tym aż tak głośno. Aplikacje bankowe muszą być niezawodne i bezpieczne, to rodzi pewne ograniczenia. Ale jakby komuś zniknęły wszystkie pieniądze, nie byłby specjalnie zachwycony i sam bank miałby z tego powodu kłopoty.

Patryk Mundzik:

Do branży bankowej trafiłem zaraz po studiach, a studiowałem Informatykę na Politechnice Warszawskiej i Finanse w Szkole Głównej Handlowej w Warszawie. Połączenie informatyki, matematyki i finansów wydawało mi się ciekawe i jednocześnie dość naturalne jako odpowiednia dla mnie ścieżka kariery zawodowej. W trakcie studiów stwierdziłem, że samo programowanie jest dla mnie interesujące, ale jeszcze lepiej byłoby, gdybym mógł rozszerzyć to o wiedzę domenową. Finanse odpowiadały moim zainteresowaniom i oferowały szerokie pole do rozwoju. Jako programista mogłem znaleźć dla siebie ciekawe zagadnienia np. quantitative finance, wycena instrumentów finansowych, czy instrumenty pochodne, które z mojej perspektywy oferują najszersze możliwości połączenia programowania i finansów.

Moje pierwsze doświadczania zawodowe były związane z branżą finansową. Pomimo tego, zanim trafiłem do banku, bywały też takie okresy, w których zajmowałem się wyłącznie programowaniem. Pierwsze wrażenie jakie odniosłem po rozpoczęciu pracy w szwajcarskim banku inwestycyjnym było takie, że właśnie takiego rodzaju pracy szukałem – szedłem do pracy szczęśliwy, w pracy też byłem szczęśliwy i wracałem z pracy szczęśliwy. Miałem poczucie, że robię to, co chciałem i to dawało mi satysfakcję, a największa płynęła z tego, że mogę zmonetyzować wszystkie swoje zainteresowania i kompetencje.

Bardzo spodobało mi się też, że środowisko pracy nie jest ograniczone wyłącznie do programistów. W ciągu jednego dnia jestem w stanie spotkać matematyka, finansistę i senior developera i z każdym porozmawiać na inne tematy, co dawało mi duże pole do rozwoju. Mogłem także odkryć, co w pracy najbardziej mi się podoba.

Łukasz Pysz:

W moim przypadku proces „wsiąkania” w branżę bankową był stopniowy. Zaczynałem od firmy, która zewnętrznie wykonywała niewielkie zlecenia dla jednego z banków w Polsce. Później trafiłem do jednej z firm tzw. „wielkiej czwórki”, gdzie w ramach dużego projektu rozwijaliśmy powszechnie używaną przez banki na całym świecie aplikację. W międzyczasie pracowałem także w dużej, niemieckiej korporacji z branży ubezpieczeniowej. Aktualnie pracuję dla jednego z największych polskich banków. Choć taka ścieżka kariery może wydawać się celowa, nie była zaplanowana. Duży wpływ na jej przebieg miały pozytywne doświadczenia na każdym z jej etapów.

Pierwsze wrażenia po zatrudnieniu się w banku najlepiej oddają słowa: spokój, bezpieczeństwo, pewność. Trafiłem bowiem do nowo formowanego zespołu, który powstawał z myślą o rozwoju bankowości internetowej w pionie bankowości przedsiębiorstw. Od początku wiedziałem, że zespół ma mieć stosunkowo dużą niezależność oraz ma realizować długoterminowe cele kluczowe z punktu widzenia banku. Z perspektywy czasu mogę powiedzieć, że rzeczywiście tak było, choć w rezultacie pandemii pracy było znacznie więcej niż początkowo zakładano.

Początkowy okres upływał w stosunkowo spokojnej atmosferze, bez presji na szybki rezultat pracy. Gdy pojawiły się pierwsze konkretne cele, zespół był już dobrze ukonstytuowany w ramach struktury organizacyjnej banku, co przełożyło się na sprawniejsze realizowanie zadań w przy bardziej napiętym grafiku pracy (zwłaszcza w obszarach integracji z systemami zewnętrznymi).

Co może zaskoczyć osoby wchodzące do tej branży? Czym różni się od innych?

Michał Dobrowolski:

Zdecydowanie jest to osadzenie w regulacjach i konieczność bycia bardziej precyzyjnym niż w innych branżach. Zaadaptowanie się nie było trudne i było dla mnie fantastycznym doświadczeniem. Inne branże działają bardziej chaotycznie, a regulacje w bankowości nadają pracy pewne ramy. Dla osoby ultra kreatywnej, która chciałaby poza te ramy wyjść, może być to problem. Ale dla osoby z branży IT jest to efekt nawet bardzo pożądany. Uważam, że osoby techniczne czują się bezpieczniej i bardziej komfortowo w takim poukładanym środowisku, więc jest to zdecydowanie benefit.

Poza tym bankowość to też innowacyjne technologie, ale rozwiązania są tworzone i rozwijane przez wiele lat, np.: core’owe systemy bankowe takie jak Profile, Flex Cube, Isis. Bankowość może dać więc programiście poczucie stabilności i tego, że rozwiązanie, nad którym pracuje, będzie w użytku na długo.

Pracując w największym banku na świecie nauczyłem się, że kluczowe są dostępność oraz bezpieczeństwo pieniędzy i danych. W innych branżach kupujesz pewną usługę lub produkt np. grę komputerową i możesz być z niej zadowolony lub nie. W banku trzymasz pieniądze, więc kluczowe jest zaufanie. I to jest podstawowa a zarazem diametralna różnica, bo pracując w IT w banku musisz rozumieć, że do banku klient przychodzi po bezpieczeństwo dorobku swojego życia, a nie jak w telekomunikacji po zadowalający go pakiet i gratis w postaci Tidala.

Z mojego punktu widzenia, jeśli ktoś lubi duże firmy, to bankowość nie będzie się od nich dramatycznie różniła. Można tam znaleźć wyzwania i świetną zabawę. A o to właśnie chodzi, żeby rozwijać się w przyjemnej atmosferze i banki nie odbiegają w tej kwestii od innych firm. Być może jakąś skrajnością byłby Google, gdzie praca to fun i na porządku dziennym jest zjeżdżanie na stołówkę ze zjeżdżalni. Bankowość jest nieco bardziej poważna, ale to nie oznacza, że ludzie są kosmitami i się nie lubią i że brakuje tam dobrego humoru… To wszystko tam jest!

Łukasz Napora:

Dla mnie zaskakująca była dbałość o bezpieczeństwo i jakość rozwijanego oprogramowania. Departament bezpieczeństwa wyjaśnia na bieżąco każdą nieprawidłowość, która wyjdzie na jednym z wielu skanerów. Pierwsze takie wiadomości na skrzynce e-mailowej potrafiły zaskoczyć i lekko zestresować. Z czasem jednak można się do tego przyzwyczaić. Jednak nie powinno to nikogo dziwić, bo rozmawiamy o branży bankowej, która zajmuje się jedną z ważniejszych rzeczy dnia codziennego czyli pieniędzmi. Ponadto wszystkie zmiany na produkcji muszą być zaplanowane i odpowiednio potwierdzone.

Oferty pracy z

Początkujący developer może mieć wrażenie, że ma bardzo wąski zakres obowiązków i że mało rzeczy tutaj wolno. Z drugiej strony wraz z rozwojem w roli technicznej okazuje się, że ta branża oferuje bardzo ciekawe wyzwania. Aplikacja ma być nie tylko działająca, ale ma spełniać wiele dodatkowych kryteriów związanych z funkcjonalnością, bezpieczeństwem i innymi czynnikami, co jest po prostu trudniejsze. Podsumowując sobie moje podejście i odczucia, to bywałem zarówno sfrustrowany ograniczeniami, jak i podekscytowany wyzwaniami.

Na starcie zaskakujące może być też to, że w branży bankowej często poszukiwane są osoby z analogicznym doświadczeniem. Wynika to z faktu, że bardzo przydatna jest wiedza domenowa, ale także doświadczenie pracy w mocno uregulowanym oraz korporacyjnym środowisku. Osoby, które nie są przyzwyczajone do takiego środowiska mogą przeżyć szok kulturowy, być zaskoczone i zdezorientowane, a także mieć trudności w adaptacji, co skutkować może problemami z efektywnością. Nawet bardzo inteligentne i doświadczone osoby mogą zetknąć się z takimi problemami.

W korporacji trochę inaczej trzeba rozwiązywać problemy, dlatego inżynierowie, którzy słabiej radzą sobie w kontaktach społecznych (dla nich najbardziej typowe jest rozwiązywanie problemów przy pomocy ulubionego języka programowania), mogą mieć pod górkę. W dużych firmach często jest tak, że twój zespół zajmuje się jednym małym wycinkiem, a drugim zajmuje się ktoś inny (czasami znajduje się na innym piętrze, w innym mieście, kraju, a nawet na innym kontynencie). Dlatego konieczny jest networking i samodzielne zdobywanie informacji od osób, które czasami zajmują bardzo wysokie stanowiska albo pracują w zupełnie innym, nietechnicznym obszarze biznesu. Dla mnie kiedyś było to trudnością i sprawiało, że nie rozumiałem decyzji podejmowanych przez management. Wiedza o tym, jak ważna jest proaktywność i rozwijanie umiejętności społecznych była dla mnie kluczem, którego mi brakowało, a który odkryłem jakoś w połowie mojej kariery.

Zaskoczyć może także uwaga, którą poświęca się zabezpieczeniom. Pracując jako developer w bankowości trzeba wiedzieć, czym różnią się basic authentication od OAutha czy też JWT, a także czym jest mutual TLS. Ważne jest rozumienie, jak te mechanizmy działają i jak je konfigurować. Jest to także obszar, którego w bankowości można się nauczyć. Zabezpieczenia są także o tyle nietypowym zagadnieniem, że wymagają innego podejścia przy uczeniu się ich – często trudno od razu zastosować je w kodzie. Trzeba dużo nad tym myśleć i analizować, a samego tworzenia kodu jest przy tym mniej niż zazwyczaj, bo może być to na przykład jedna linijka w konfiguracji… Podsumowując, jest to trochę inny rodzaj pracy programistycznej.

Z moich doświadczeń wynika, że bankowość ma jeszcze jedną specyficzną cechę. Często bywało tak, że aplikacje rzadziej niż w innych miejscach są wdrażane na produkcję (na przykład raz na kwartał czy raz na pół roku), co może narzucać pewien specyficzny („a la sesyjny”) tryb pracy i może być pewną wadą tej pracy dla developera.

Patryk Mundzik:

Zaskoczeniem może być przede wszystkim fakt, że przydatna jest podstawowa wiedza dotycząca finansów i ekonomii. Zrozumienie nomenklatury finansowej i tego jak operują banki, może stanowić wyzwanie dla tych, którzy nie mieli wcześniejszych doświadczeń związanych z tą branżą. Jest to oczywiście wiedza, którą można zdobywać w trakcie pracy. Natomiast dla osoby, która pracuje tak jak ja w roli Quant Developera (programista, który implementuje w kodzie pewną logikę dotyczącą zagadnień finansowych), jest ona niezbędna do codziennej pracy, a dla programisty jest po prostu pomocna. Moim zdaniem dzień programisty, który pracuje w roli Quant Developera, nie różni się jednak zbytnio od dnia programisty, który pracuje w innym miejscu czy innej branży.

Najbardziej atrakcyjne w roli Quanta jest to, że nie tylko programujesz, ale musisz także bardzo dokładnie rozumieć, co programujesz i całą finansową metodologię, która za tym stoi. Dodatkowo trzeba zrobić to jak najbardziej optymalnie. Ciekawy jest także kontekst i konsekwencje, które ta implementacja niesie dla banku i jego wskaźników finansowych.

Na początku zaskoczyło mnie, że w zespołach quantowych nie czuć formalności i korporacyjności. Myślę, że wynika to z bardzo dużej różnorodności w tych zespołach i osobom w nich pracujących po prostu nie można narzucić jednego stylu pracy, wyglądu, zachowania, czy ubierania się. Więc pomimo tego, że jest to praca w korporacji, na co dzień zupełnie tego nie czułem. Nikt nie wymagał ode mnie na przykład określonego stylu ubioru.

Łukasz Pysz:

Każda branża posiada własną specyfikę i pod tym względem branża bankowa czy też szerzej – finansowa – nie różni się od pozostałych. Z mojego doświadczenia wynika, że największą różnicą jest kultura pracy. Mam na myśli odpowiednie przygotowanie merytoryczne osób zarządzających projektami i zespołami. Osobiście – pracując w branży finansowej – nie natrafiłem na osoby na stanowiskach managerskich, które wykazywałyby się niekompetencją, brakiem znajomości zagadnień biznesowych czy też technicznych. Ten aspekt mocno przekłada się na jakość wykonywanej pracy, co jak sądzę, jest oczywiste dla każdego programisty. Dawniej – pracując w innych branżach – również pracowałem z dobrymi managerami. Zdarzały się jednak przypadki skrajnie odmienne.

Druga różnica na którą warto zwrócić uwagę, to kwestie związane z bezpieczeństwem aplikacji. Warto wiedzieć, że – z oczywistych względów – aplikacje bankowe, by trafić na produkcję muszą być bardzo dobrze sprawdzone pod kątem bezpieczeństwa. Następstwem tego jest bardzo długi i często skomplikowany proces wdrożeniowy, który obejmuje wiele środowisk, procedur oraz obligatoryjne audyty zewnętrzne aplikacji. Kwestie bezpieczeństwa powinny być poważnie traktowane w każdej branży. Jednak to branża bankowa będzie zawsze tą, w której w tym aspekcie zrobi się znacznie więcej niż niezbędne minimum.

Jednym z mitów jest korporacyjność, biurokracja i obecność szeroko pojętej “polityki”. Jak wygląda to z Waszej perspektywy? Czujecie, że macie wpływ na projekty, które realizujecie? Jak wygląda podejmowanie decyzji?

Michał Dobrowolski:

Wydaje mi się, że tak duże firmy bez względu na branżę są do siebie podobne. Bankowość jest bardziej wyregulowana. Z mojej perspektywy obecność regulacji oznacza dla programisty, że w systemach informatycznych zwiększa się ilość rzeczy do implementacji, a co za tym idzie daje to więcej fun’u z pracy.

Mnie ta korporacyjność włożyła w pewne ramy i nauczyła dyscypliny. Jestem osobą kreatywną i bywam ekstrawertyczny, a to poukładało moją pracę. Ekscytuje mnie to, że jednym dealem mogę zarobić dla banku 100 milionów złotych. Praca ta bywa też pełna adrenaliny, a dają ją tempo projektów, ich wielkość i powaga sytuacji. Nie chodzi tylko o pieniądze, ale także o to, że niewprowadzenie pewnych rozwiązań informatycznych może spowodować paraliż banku, uniemożliwić raportowanie do odpowiednich instytucji, na przykład Komisji Nadzoru Finansowego, a w rezultacie być przyczyną nałożenia na bank ogromnych kar albo zamknięcia całej linii biznesowej, a to są bardzo poważne sprawy.

Aktualnie w miejscu w którym pracuję, mam bardzo dużą samodzielność w prowadzeniu projektów. Nie waham się jednak konsultować z zespołem i korzystać z kompetencji jego członków. O ile nie napotkam pola wymagającego decyzji strategicznych, które muszą być podejmowane na wyższych poziomach, to mam pełną autonomię. Jako Project Manager konsoliduję biznes z IT, a moja autonomia wynika po pierwsze z moich doświadczeń, a po drugie z zaufania, którym darzą mnie współpracownicy. Oni wiedzą, że dla mnie biznes zawsze będzie na pierwszym miejscu, a dopiero później będziemy dostosowywać się do tych pomysłów biznesowych w IT.

Łukasz Napora:

Myślę, że jest podobnie jak w każdej dużej firmie. Moja praca nie wygląda tak, że całe dnie spędzam na uzupełnieniu systemów raportujących, uzupełnianiu wniosków czy przechodzeniu wewnętrznych szkoleń. Oczywiście te elementy występują, ale nie zajmują mi więcej niż 15 min dziennie i nie wykonuję ich każdego dnia. Nie ma też dziwnych zaleceń co do rytmu pracy, nikt nie sprawdza też co do minuty, co robiłem w ciągu dnia.

Uważam, że jeśli ktoś ma chęci, to będzie miał wpływ na podejmowane w zespole decyzje, co za tym idzie na realizowane projekty. Wszystkie większe zmiany są omawiane na spotkaniach całego zespołu, gdzie rozwiązania problemów są na bieżąco wymyślane lub prezentowane. Każdy może wtedy powiedzieć, co sądzi o danym rozwiązaniu lub przedstawić swój punkt widzenia i aktywnie uczestniczyć w procesach decyzyjnych. Każda propozycja jest rozpatrywana pod kątem plusów i minusów, a na końcu zespół podejmuje ostateczną decyzję, w którą stronę chce iść. Jeśli chodzi o drobne i mniejsze zmiany, to dyskusja o nich zazwyczaj odbywa się na bieżąco.

Marcin Szymczak:

Zależy na jakim ktoś pracuje stanowisku. Jeśli ktoś pracuje jako standardowy developer, to bym powiedział, że atmosfera w zespole jest taka sama jak w każdej innej firmie. Nie ma aż takiego korporacyjnego narzutu, ale to oczywiście zależy od firmy, bo są takie dwa banki w Polsce, w których jednak trzeba na co dzień ubierać się w koszule. Generalnie na poziomie pojedynczego zespołu, to atmosfera jest taka, jaką zespół sobie stworzy. Natomiast jeśli ktoś planuje dłuższą karierę w finansach, to już od stanowiska tech leada w górę, czeka go zderzenie z tym, co określić można jako “politykę” i “korporacyjność”. O radzeniu sobie w takim środowisku i mojej “recepcie” opowiedziałem już w kontekście poprzedniego pytania.

Jeśli chodzi o podejmowanie decyzji, to z punktu widzenia developera bardzo dużo można robić na poziomie kodu, ale niewiele jest wpływu na architekturę, biznes i infrastrukturę. O ten wpływ trzeba zabiegać w kontakcie na przykład z architektem, czy też team leadem. Więc jeśli sam developer, team lead i architekt są “ogarnięci” i potrafią się dogadać, to developer może mieć tego wpływu więcej, ale musi sam o to zadbać.

Jako architekt mam ogromną decyzyjność i bardzo duży wpływ na realizowane przeze mnie projekty (nie wiem, czy kiedykolwiek w życiu miałem większy), ale mój wpływ zmniejsza decyzyjność innych osób. Jeśli ktoś pracuje w start-upie, to może mieć wpływ na wszystko, bo wystarczy, że dogada się z kolegami z zespołu, a w zespole z reguły nie ma dedykowanej roli architekta. W dużej firmie wpływ na aspekty techniczne rozkłada się pomiędzy deweloperów, tech leadów oraz architektów i rośnie w każdym z wymienionych stanowisk.

Moim zdaniem w każdej grupie ludzi, która jest dostatecznie liczna, jakaś polityka musi wystąpić niezależnie od branży.

Patryk Mundzik:

Przez odgórne regulacje, które dyktują co i jak ma być policzone (mogą dotyczyć konkretnego rejonu świata) czuć, że pracuje się w dużej korporacji o światowym zasięgu. Fakt istnienia tych odgórnych regulacji, nad którymi pracują rządowe i pozarządowe instytucje finansowe dbające o światowy ład finansowy, sprawia, że można odczuć, że jest się oczkiem globalnego łańcucha finansowego. A na co dzień to właśnie mój zespół implementuje te regulacje. Te dyktowane są wewnętrznym podejściem banku do realizacji celów biznesowych lub polityką finansową regionu, w którym bank działa.

Sposób modelowania i implementacji tych obliczeń finansowych jest w 100% zależny od mojego zespołu. Mogę powiedzieć, że mam bardzo duży wpływ na ostateczny wygląd i wynik wskaźników finansowych. Bardziej szczegółowo są to takie zagadnienia jak optymalizacja implementacji – czyli jak szybko będzie to działało, ale także konstrukcja danego modelu jest rezultatem wspólnej pracy zespołu finansistów i programistów. Na co dzień mogę zgłaszać swoje wątpliwości i pomysły w tych obszarach.

Łukasz Pysz:

Moim zdaniem tzw. „polityka” ma więcej wspólnego z wielkością (a właściwie – złożonością) korporacji niż z samą branżą. Fakt, że zwykle banki należą do dużych organizacyjnie podmiotów sprawia, że stosuje się ten kwantyfikator w odniesieniu do branży bankowej, a jednak nietrudno wyobrazić sobie wielką, międzynarodową korporację, która choć zupełnie niezwiązana z branżą bankową, tonie w biurokracji i „polityce”. Prawdę mówiąc – nawet nie trzeba jej sobie wyobrażać.

Rzeczonej „polityki” doświadczyłem w nadmiarze w poprzedniej pracy dla dużej korporacji z sektora ubezpieczeń. Miałem tam okazję pracować przy projekcie, który duża część tej korporacji bardzo chciała zrealizować, a druga – równie duża część – próbowała doprowadzić do tego, by projekt nie został zrealizowany. Każda ze stron miała swoje w pełni uzasadnione racje, a problem wynikał ze struktury organizacyjnej bardzo dużego podmiotu. Aktualnie nie doświadczam takich praktyk. Trzeba mieć na uwadze, że polskie banki, choć duże na naszym rynku, nie są tak bardzo rozbudowanymi organizacjami na tle ich zachodnich odpowiedników.

Dalsza część devdebaty dostępna jest tutaj. Dowiecie się z niej m.in. o możliwościach rozwoju w branży bankowej.

Zdjęcie główne artykułu pochodzi z unsplash.com.