POIT #176: Co oznacza bycie inżynierem w banku. Case mBanku.

Witam w sto siedemdziesiątym szóstym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest bycie inżynierem w banku na przykładzie mBanku.

Dziś moim gościem jest Leszek Włodarski – IT Deputy Director w mBank S. A. Doświadczony developer i architekt oprogramowania. Lider zespołu i menadżer w mBanku, z którym związany jest zawodowo od kilkunastu lat. Specjalista takich technologii jak .NET, C/C++ i jBASIC.

Sponsor odcinka

Sponsorem odcinka jest mBank S. A.

W tym odcinku o pracy inżyniera w banku rozmawiamy w następujących kontekstach:

  • jak wygląda praca w części korporacyjnej mBanku?
  • jakie technologie wykorzystuje się w banku?
  • jak się pracuje jako inżynier w banku?
  • czy w banku stosuje się wyspecjalizowane czy cross-funkcjonalne zespoły?
  • czy praca w banku daje możliwość tworzenia skomplikowanych rozwiązań?
  • na co ma wpływ inżynier w banku?
  • jak pracuje się na rynku regulowanym?
  • czy praca w banku oznacza mało zmieniające się otoczenie?
  • czy pandemia zmieniła coś w tym jak specjaliści IT pracują w banku?

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, które wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)

Transkrypcja podcastu

To jest 176. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o tym, co znaczy bycie inżynierem w banku. Sponsorem tego odcinka jest mBank S.A. `Przypominam, że w poprzednim odcinku rozmawiałem o chmurze jako ucieczce przed rosnącymi kosztami energii. Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresemporozmawiajmyoit.pl/176

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. Od niedawna można wystawiać oceny podcastom w Spotify. Będzie mi bardzo miło, jeśli w ten sposób odwdzięczysz się za treści, które dla Ciebie tworzę. Dziękuję.

 Ja się nazywam Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten podcast. Wspierając mnie przez Patronite, dzieląc się tym odcinkiem w swoim kręgu lub feedbackiem na jego temat ze mną, pomagasz w realizacji tej misji. Ja natomiast bardzo dziękuję moim obecnym patronom. A teraz życzę Ci już miłego słuchania!

Odpalamy!

 

Cześć! Mój dzisiejszy gość to IT Deputy Director w mBank S.A., doświadczony deweloper i architekt oprogramowania, lider zespołu i menedżer w mBanku, z którym zawodowo związany jest od kilkunastu lat. Specjalista takich technologii, jak .NET, C, C++ i jBasic. Moim i Waszym gościem jest Leszek Włodarski.

 

Leszku, bardzo mi miło gościć Cię w podcaście.

 

Cześć! Witam wszystkich.

 

Leszek z uwagi na swoje wieloletnie doświadczenie w banku z różnymi technologiami jest idealną osobą do rozmowy o tym, co to właściwie znaczy być inżynierem w banku. Każdy bank mimo pewnych podobieństw ma swoją specyfikę, więc w tej dzisiejszej rozmowie skupimy się głównie na case mBanku.

Ale zanim do tego przejdziemy, to mam w zwyczaju na początku pytać moich gości o to, czy słuchają podcastów, jeśli tak, to jakich najczęściej, więc jak to u Ciebie, Leszku, wygląda?

 

Ja tak naprawdę bardziej się koncentruję nie na IT, jeśli chodzi o podcasty. Z wielu powodów. Kiedyś próbowałem i nadal próbuję, szukam fajnego źródła. Kiedyś No kill switch Sebastiana Gębskiego, ale się skończył, jest na szczęście w formie pisanej, i to jest coś, co ratuje sytuację. Twój podcast jest fajną inspiracją do tego, gdzie zajrzeć, czego posłuchać, i to jest super. A tak, od czasów pandemii Raport o stanie świata, szczególnie, że ja cierpię na ten problem 24 godzin w trakcie doby. To ograniczenie powoduje, że mój czas na podcast jest głównie wtedy, kiedy idę pobiegać. A po jakimś czasie biegania percepcja i przyswajanie wiedzy są coraz gorsze, dlatego takie różne tematy w podcastach się pojawiają.

 

Fajnie, dzięki za te rekomendacje. Zanim przejdziemy do takiej bardziej merytorycznej rozmowy o tym, co to znaczy być inżynierem w banku, to warto, myślę, nakreślić pewien kontekst, pokazać trochę realia, w których będziemy się później poruszać, bo tak, jak już mówiłem we wstępie, każdy bank mimo podobieństw ma też swoją specyfikę. W naszej dzisiejszej rozmowie skupimy się głównie na mBanku, z którym masz wieloletnie doświadczenie. Więc prośba do Ciebie, Leszku, żebyś trochę opowiedział o mBanku i o tej części korporacyjnej, z którą jesteś związany, jak ta praca inżyniera wygląda w tej części.

 

mBank składa się z dwóch dużych części. Z części detalicznej, którą celowo ominę, i z części korporacyjnej, gdzie jest moje miejsce, czyli tej części banku, która opiekuje się dużymi firmami, małymi i tymi olbrzymimi. Jest to dosyć specyficzne miejsce, dlatego że ten profil klienta jest zupełnie inny niż w detalu. Są to aktywni użytkownicy bankowości,  liczne transakcje zawierane na duże wolumeny, specyficzne, bardzo unikalne transakcje. Niby 30 tys. klientów, ale bardzo wartościowych, bardzo dużych.

To też duża odpowiedzialność za to, co się dzieje w biznesie, bo nasi klienci w dniu wypłaty przelewają olbrzymie kwoty dla swoich pracowników. Gdyby ten jeden przelew nie wyszedł, byłby płacz i zgrzytanie zębów, do czego nie chcemy doprowadzić. Dlatego po okresie pandemii jest to obszar, który zaczyna gwałtownie reagować na nowe możliwości albo powraca do swojej dawnej aktywności.

Więc tu się dużo dzieje. I jest to też miejsce, w którym mamy dużą aktywność regulatorów ustawodawcy, więc naprawdę od wielu lat się nie nudzimy. W sumie raz chyba się tylko nudziłem w tym banku, w 2007 r. Więc tak, korpo to jest to miejsce, w którym można robić różnice, i to jest bardzo fajne.

 

Czyli duży wpływ, duża odpowiedzialność, nastawienie na niezawodność, na bezpieczeństwo. Można powiedzieć, że dla takiego rasowego inżyniera to może być faktycznie świetny obszar, świetne środowisko do rozwoju, dlatego żeby mierzyć się z ciekawymi problemami, co też, mam nadzieję, wyjdzie w naszej rozmowie.

Jak już jesteśmy przy tych technologiach, to może pociągnijmy ten wątek. Bardzo często, kiedy rozmawiam z ludźmi, którzy nigdy nie mieli do czynienia z pracą w bankach, w większych instytucjach, pojawia się taka wątpliwość, czy tam faktycznie pracuje się z technologiami sprawdzonymi w boju, nieco może nawet podstarzałymi, czy też może jest to miejsce, gdzie faktycznie możemy sobie próbować różnych rzeczy. Jednym słowem mówiąc, czy praca w banku to praca ze sprawdzonymi rozwiązaniami, które się nie zmieniają latami, czy też jest to obszar, w którym te nowsze technologie są wykorzystywane? Gdybyś mógł nam naszkicować przekrój technologii, z którymi miałeś do czynienia, myślę, że to dałoby fajny obraz sytuacji.

 

Tak, technologii w bankach jest bardzo dużo i ważne, żeby słuchacz zrozumiał, dlaczego ich jest bardzo dużo. Zacznę od takich, które są naprawdę starożytne. Mamy w banku systemy centralne, to jest serce banku, mamy dwa takie serca. W części korporacyjnej to serce się opiera o taką platformę jBase, jBasic, jest to dosyć stare rozwiązanie, mało znane, unikalne. W części detalicznej mamy COBOL-a. I to faktycznie są takie platformy, których zmienność jest bardzo mała. Ale na COBOL-a każdy reaguje dosyć nerwowo, bo przecież dinozaury go wymyśliły.

W części korporacyjnej jest jBasic, to też jest technologia, która w 2003 r., gdy wdrażany był nasz system centralny, była być może state of the art, potem już było tylko gorzej, bo wychodziły kolejne nowe wersje, ale miały breaking changes, więc dosyć ciężko było zaktualizować cały system centralny. Nadal mało znana technologia, która jest mało znana do teraz.

Natomiast to nie jest tak, że tylko takie leciwe technologie są w banku. One są głównie dlatego, ze w banku nie nastawiamy się na technologię dla technologii. Robimy technologię po to, żeby bank mógł dobrze funkcjonować. I system centralny to są 3 mln linii kodu, które są dopracowane i dostosowane do tego, żeby działać na nasze potrzeby. To jest coś, co nas wyróżnia, coś, czego nie mają inne banki. To jest przystosowane do nas, więc pielęgnujemy to. To jest potężna wartość, która jest tak ważna, że tolerujemy tak stare platformy, o jakich opowiadałem.

Tylko to nie jest tak, że my z nimi zostaniemy do końca. To nie jest tak, że mBank będzie skansenem technologicznym, bo ma system centralny. My tutaj dużo robimy, żeby się modernizować, zmieniać te technologie. I to jest cała droga, którą pamiętam od początku, odkąd tutaj pracuję, zaczęło się od takiego błyskotliwego pomysłu: to może uratujemy sobie nasz świat za pomocą C++. Wtedy C++ to był state of the art, najważniejsza, najlepsza technologia na świecie. Tyle że to była porażka, bo mało kto rozumiał ten język programowania, mało kto się nim sprawnie posługiwał, nadal tak jest, że to jest mimo wszystko takie specjalistyczne rozwiązanie, nie każdy potrafi z niego korzystać. A my tu mówimy o dużym rozwiązaniu, które powinno być skalowalne, więc to nie może być C++. Bardzo łatwo zrobić sobie nim krzywdę.

Więc dalej wybraliśmy ścieżkę .NET i pamiętam, że jest on w banku od czasu chyba wersji 2.0, może wcześniej, kiedy uznaliśmy, że jest on wystarczająco dojrzały, żeby w niego zainwestować. I nadal z nim pracujemy. Sam z siebie pokazuje on, jak bardzo gwałtownie zmieniają się technologie. Poza tym COBOL-em i jBasiciem standard C++, który też miał wcześniej taką zmienność niewielką, co 5 lat nowy standard, to teraz faktycznie co roku coś nowego się pojawia. Prawdopodobnie community C++ odżyło troszeczkę albo znalazło swoją niszę w postaci rozwiązań mobilnych, ale tu się zaczyna już dużo dziać.

.NET po tej swoje początkowej fazie, gdzie te zmiany wersji, zmiany standardu były rzadkie, teraz ma mnogość swoich wersji, które powoli tracą ważność. Co roku nowa wersja, teraz .NET Core, to wszystko powoduje, że ciężko mówić o tym, że ktoś jest specjalistą w jakiejś technologii i nim zostanie. Jakbym był specjalistą C++ do końca swojego życia, to powoli już bym tracił miejsce pracy, bo ich nie ma już dużo wbrew pozorom.

Poza tymi technologiami, .NET akurat jest naszym mainstreamem w departamencie, który zajmuje się korpo, w niego najwięcej inwestujemy, ale lubimy różnorodność i dywersyfikacje. Też taki system napisany w Javie, nasze okno na świat, i o nim dużo nie opowiem, bo się na nim nie znam. Java to miejsce, w którym długo nie zostałem, natomiast mamy genialny zespół, który w genialny sposób posługuje się językiem, technologiami związanymi z Javą do tego, żeby nasze okno na świat, frontend, utrzymywać, rozbudowywać, pielęgnować. Mam nadzieję, że oni też kiedyś będą mogli opowiedzieć o swoich podbojach i sukcesach.

To, co można zauważyć, to kiedyś usłyszałem takie celne sformułowanie, Hadi Harry w jednym ze swoich wystąpień powiedział o tym, że IT to jest self sustaining industry. I to faktycznie trochę tak wygląda. Znajdujemy problem, technologię, która rozwiązuje ten problem, dalej robimy z tego szkolenia, certyfikacje, wdrażamy, znajdujemy kolejne problemy, a na nie kolejną technologię, która to rozwiązuje.

I miałem opowiedzieć o tym, dlaczego mamy w banku tak dużo technologii. Bo tu się dużo dzieje. I wdrażamy te technologie faktycznie, mamy ich całkiem sporo, rozwiązań, które bazują na starych frameworkach i nie jesteśmy w stanie w sposób ciągły aktualizować tych rozwiązań, mimo że w banku wyrobiliśmy już sobie taką kulturę dbania o dług technologiczny i naprawiania tego długu technologicznego, to są dziesiątki lat intensywnego rozwoju zespołu, który zaczął się od mniejszego, skromnego, a potem urósł do takiego już dużego, 170-osobowego.

Ale żeby zapamiętać to, co jest najważniejsze, mainstream u nas to jest .NET, nawet z tym sercem w jBasiciu, co do którego mamy ambitne plany i toczy się taki mocno innowacyjny projekt, to jest to .NET, to jest mainstream, ale tak po inżyniersku patrzymy na ten świat i raczej staramy się używać narzędzi zgodnie z ich przeznaczeniem i nie fiksować się na jednej technologii.

 

.NET po tej swoje początkowej fazie, gdzie te zmiany wersji, zmiany standardu były rzadkie, teraz ma mnogość swoich wersji, które powoli tracą ważność. Co roku nowa wersja, teraz .NET Core, to wszystko powoduje, że ciężko mówić o tym, że ktoś jest specjalistą w jakiejś technologii i nim zostanie. Jakbym był specjalistą C++ do końca swojego życia, to powoli już bym tracił miejsce pracy, bo ich nie ma już dużo wbrew pozorom.

 

Rozumiem, czyli taka mnogość i różnorodność technologii, ale jednak z tym akcentem, że liczy się przydatność, użyteczność, utylitaryzm tych rozwiązań – na koniec dnia to muszą być sprawdzone rozwiązania.

Myślę sobie, że niezależnie od tego, jakiej technologii byśmy nie wybrali, to jednak równie ważnym elementem całego tego równania są ludzie, którzy tę technologię wykorzystają i zbudują z tego coś, co sprawdza się w prawdziwym świecie. Myślę tutaj o inżynierach, którzy na co dzień trudzą się, żeby rozwijać tego typu systemy, ale też utrzymywać je – bo myślę, że tutaj też trzeba powiedzieć, że w dużym stopniu znaczy, że te systemy muszą być utrzymywane.

Więc chciałbym Cię zapytać, jak ty widzisz i oceniasz pracę inżynierów w mBanku. Z czym ona się wiąże?

 

Celnie to nazwałeś, być inżynierem w mBanku, bo my mamy tak naprawdę inżynierów. To nie jest zespół deweloperów .NET, nie jest to zespół deweloperów Java Script. To są inżynierowie. I tak staramy się kształtować ten świat.

To jest bardzo ciekawe w ogóle, od czasu, gdy wystartowałem z mBankiem, to było takie miejsce, w którym od zawsze mieliśmy space na rozważne i innowacyjne podejście do rozwiązywania problemów. I to jest właśnie takie inżynierskie podejście, w którym lubimy zmierzyć, lubimy podjąć decyzję na bazie faktów, a nie subiektywnych przeświadczeń, chociażby o tym, że jBasic to jest technologia nikomu nieznana. No, jest znana i dobrze się sprawdza w niektórych sytuacjach. Lubimy rozumieć, w jakich sytuacjach się sprawdza, i nie boimy się zmiany. Jak opowiadałem, ta zmiana towarzyszy nam od początku, jBasic, C++, C Sharp, po drodze pojawiło się jeszcze sporo innych technologii, które nam ułatwiają życie, więc tak, my mamy inżynierów i oni są bardzo ważnym elementem tej układanki.

Tak na marginesie mówiąc, to jest w ogóle ciekawe, jak słowa klucze kreują rzeczywistość w IT. Dawno temu mój szef poprosił mnie, żebym się zdefiniował, co bym chciał robić w banku albo jak bym chciał, żeby funkcjonował mój zespół, czy ma się zajmować. I wtedy rozpoczęła się moja przygoda z zespołem architektury. Takiej architektury deweloperskiej, która zajmuje się bibliotekami wspierającymi inne zespoły, frameworkami, środowiskami testowymi, automatyzacją. To było super doświadczenie, polecam każdemu taką przygodę. Ale to był moment, w którym słowo architektura było unikalne. Ono jeszcze nie eksplodowało do tego znaczenia, które jest teraz. I z tego się cieszyłem, to było takie miejsce, że faktycznie tych architektów było mało.

I jakiś rok, dwa lata później, na jakimś spotkaniu szef przedstawia zespół, jesteśmy z dostawcą zewnętrznym, i szef mówi tak: To jest architekt systemowy, to jest architekt danych, to jest architekt procesów. Architekt architekta architektem pogania. To był ten moment, w którym słowo architekt straciło jakiekolwiek znaczenie.

Tak samo stało się teraz może trochę ze słowem inżynier. Nie mów nikomu, jakiś czas temu na LinkedInie zasubskrybowałem sobie informacje o wszystkich ofertach pracy ze słowem kluczowym inżynier. I początki były takie, że raz na pół roku coś wpadło. A teraz jest tego zalew. Wszystko dlatego, że takie duże firmy, jak Microsoft, które od zawsze mówiły o swoich inżynierach, Google, Amazon i pewnie jeszcze inne, faktycznie podbiły znaczenie tego inżynieryjskiego podejścia do rzeczywistości. Bo ciężko w tym naszym świecie być obecnie specjalistą w jednej dziedzinie.

Teraz powiem zupełnie niesprawiedliwie, dawno temu, jak ktoś został kowalem, to był kowalem do końca życia. Kowal nadal musi się szkolić i uczyć, wiem to z pierwszej ręki, natomiast nadal jest kowalem. A u nad deweloper .NET za 5 czy 10 lat już pewnie nie będzie deweloperem .NET, tylko będzie zajmował się zupełnie inną technologią, bo nie będzie miał za bardzo wyjścia.

Więc tak, lubimy mierzyć, lubimy podejmować decyzje w oparciu o fakty, ale do tego jest potrzebny też menedżer inżynier, to nie jest tak, że każdy będzie w stanie podjąć dobre decyzje, bo one muszą być projektowe, czy mówiąc o ciągłości działania w banku, tak jak powiedziałeś, wysoka dostępność, wysoka jakość, ten menedżer też musi być trochę inżynierem, musi rozumieć to, czym zarządza. I jako inspiracja z jednego z Twoich podcastów, którego wysłuchałem, z Alkiem Gawrońskim, o jednostce 8200 Israela. Tam jest bardzo ciekawy sposób opisany, jak się szkoli takich wybitnych specjalistów. I oni pracują w takich sytuacjach konieczności i braku zasobów. 

I my trochę tak pracujemy w mBanku, tzn. wiemy, co jest ważne, na kiedy, negocjujemy zakres prac i do tego też menedżer inżynier jest bardzo użyteczny, i nie ma tu tego przerostu formy nad treścią. To nie jest przeinwestowane miejsce, w którym mamy plus 20 ludzi tylko na wszelki wypadek. Tu zawsze pracy jest więcej niż ludzi, którzy mogą ją wykonać, ale to skutkuje tym, że to, co robimy, jest mocno przemyślane, jest ustrukturyzowane i buduje taką architekturę, z którą da się pracować. I to jest bardzo ważna cecha. 

Więc bycie inżynierem to nie tylko deweloper programista, ale to też te kolejne warstwy: menedżerskie, team liderskie, które powodują, że można być inżynierem w banku i z godnością pracować, proponować rozwiązania i ktoś tego wysłucha i nawet to zrozumie, i nie skasuje dobrego pomysłu tylko dlatego, że nie spina mu się w Excellu.

 

I my trochę tak pracujemy w mBanku, tzn. wiemy, co jest ważne, na kiedy, negocjujemy zakres prac i do tego też menedżer inżynier jest bardzo użyteczny, i nie ma tu tego przerostu formy nad treścią. To nie jest przeinwestowane miejsce, w którym mamy plus 20 ludzi tylko na wszelki wypadek. Tu zawsze pracy jest więcej niż ludzi, którzy mogą ją wykonać, ale to skutkuje tym, że to, co robimy, jest mocno przemyślane, jest ustrukturyzowane i buduje taką architekturę, z którą da się pracować. I to jest bardzo ważna cecha

 

 

Myślę sobie, że to podejście inżynierskie jest bardzo ważne, ale rzadko co obecnie powstaje w IT jako przebłysk geniuszu jednej osoby, to jest już bardzo rzadka sytuacja, obecnie większość rozwiązań powstaje w efekcie pracy zespołów.

Skoro jesteśmy przy zespołach, wiadomo, można mieć różne podejście do organizacji zespołów, można mieć różne metodyki pracy, możemy stosować zespoły, które są jednostkami specjalnymi, które specjalizują się w konkretnym zadaniu, albo mogą to być jednostki multidyscyplinarne, czy tak zwane cross funkcjonalne, które posiadają wszystkie kompetencje na pokładzie i dzięki temu są w stanie dosyć autonomicznie realizować określone zadania.

Jestem ciekaw, jak to wygląda w mBanku. Jakiego typu zespoły, o jakiej organizacji najczęściej są wykorzystywane, jakie wady, jakie zalety tych sposobów organizacji dostrzegasz?

 

Aktualnie stawiamy na mocno samodzielne zespoły, które w całym pay planie C i CD, SDLS, jak zwał, tak zwał, mają dużo możliwości i mogą samo stanowić się, więc samo wytworzenie oprogramowania to jest dosyć prosta rzecz, chyba najprostsza z tych wszystkich, wbrew pozorom. I zespoły poza wytworzeniem oprogramowania są odpowiedzialne za to, żeby utrzymać ich jakość, czyli za testowanie automatyczne, ale też za to, żeby to było testowalne ręcznie, za przygotowanie mechanizmów wdrożeniowych, za utrzymanie środowiska testowego, co też jest istotne i buduje dyscyplinę i często powoduje, że jesteśmy w stanie reagować na systemach produkcyjnych na błędy w takim samym trybie wiedzy–niewiedzy, bo już przećwiczyliśmy to na środowiskach testowych. 

Dalej, to co bardzo ważne, to pielęgnacja tego, co się dzieje na produkcji. To też dzieje się w tym zespole. Nie ma osobnego zespołu, który zajmuje się quality, nie ma osobnego zespołu, który to potem wdraża, albo osobnego zespołu, który zajmuje się błędami, które zrobiliśmy. Mamy taką szybką pętlę zwrotną, jak dobrze robimy oprogramowanie. Im lepiej robimy, tym mamy więcej czasu na nowe fitchery, na pielęgnację systemu, a im gorzej, tym więcej troubleshooting i naprawiania błędów. I to jest bardzo fajny mechanizm samo regulujący, który powoduje, że zespoły mają szansę się doskonalić.

Ale tak nie było zawsze. Jak przeczytałem książkę Team Topologies , to z takim bananem na twarzy ją czytałem, bo to była taka ścieżka w mBanku, bo to się będzie zmieniało, my reagujemy na to, co się dzieje na rynku pracy, reagujemy na to, co się dzieje z systemami, reagujemy na to, kto u nas pracuje i jak duzi jesteśmy. Więc bywało różnie. Mieliśmy zespoły SWAT, które zajmowały się specjalnymi rzeczami, były zespoły, które miały mało stopni swobody i mogły realizować po prostu kolejne okienka, kolejne serwisy. 

Ale aktualnie stawiamy na multidyscyplinarność. Chyba też po to, żeby podkreślić znaczenie bycia inżynierem, że to nie jest tylko jedna technologia, tylko tak naprawdę jest to dobór technologii z naszej skrzynki narzędziowej. To niestety ma swoje zalety i wady. Jak kiedyś byłem młodszy, to byłem bardziej czarno-biały, teraz już wiem, że to nie jest tak do końca. 

Zaleta oczywista jest taka, że zespół samo stanowi, sam decyduje, ma wpływ na dobór technologii, na to, jak, jakim narzędziem, nie musi się dostosowywać, naginać niektórych swoich zasad do ogólnych reguł. Natomiast ma to też swoją wadę, bo w takim multidyscyplinarnym zespole trzeba te kompetencje utrzymać. Jeśli to jest zespół do 10 osób, to tam kryje się już dosyć dużo technologii. Gdybyśmy jeszcze chcieli utrzymać work-life balance, to nie może być jedna osoba, która zajmuje się daną technologią, tylko musi mieć jakiś backup. Więc to często jest wyzwaniem, jak skonstruować taki zespół.

Inny problem jest taki, że czasami fajnie jest nie mieć wyjścia, tzn. nie musieć podejmować decyzji. To też jest coś, co zajmuje dużo energii, co kosztuje dużo siły, szczególnie gdy chce się podjąć decyzję dobrze, czyli po inżyniersku. Dobór systemu kolejkowego to jest w ogóle wyzwanie samo w sobie. Jeśli każdy zespół miałby przechodzić przez ścieżkę takiego doboru systemu kolejkowego, to wymaga to dużo siły i energii, a nie koniecznie musi się skończyć sukcesem. I to jest na pewno wada tego rozwiązania. I staramy się tutaj balansować. 

Od zawsze próbujemy balansować w mBanku z tym tematem, co centralizować, co decentralizować i kiedy. I to, czego można być pewnym, to jak się w banku ktoś pojawi, to na pewno to, że tutaj nie będzie stagnacji, tutaj na pewno będziemy się dopasowywać do istniejących sytuacji.

To, co jest ważne, to że to nie jest tylko zmiana technologiczna pod spodem bebechów, my zmieniamy też frontend dla pracownika banku, który korzysta z tego systemu. To też jest ciekawe wyzwanie, bo przestało ono być już wyzwaniem technologicznym, jest to wyzwanie czysto ludzkie. Bo trzeba ludzi przekonać do tego, żeby zaczęli korzystać z nowego rozwiązania, które wygląda trochę inaczej, zachowuje się inaczej. 

I to też jest ciekawe, jak to zrobić w organizacji, gdzie jednak są jakieś procedury pracy, przyzwyczajenia, ktoś bardzo szybko klika na klawiaturze numerycznej, a w aplikacji webowej niekoniecznie to musi tak samo dobrze działać. Ale jeszcze raz powiem, to jest naprawdę niesamowite doświadczenie, móc realizować taki projekt. Innowacje na wielką skalę. I to nie wydarzyłoby się, gdyby nie cały zespół, który włożył siłę w to, żeby urealnić taki projekt i gdyby nie inżynierskie podejście menedżerów, moich szefów, którzy rozumieją to, że warto ponieść takie wyzwanie, zupgradować swoją technologię, zostawić to, co nas wyróżnia, czyli system centralny, i warto ponieść tego koszty, konsekwencje, ale myślę, że gdyby zrobić taki rachunek sumienia po tych 6 latach, to jesteśmy do przodu, jeśli chodzi o dostarczone funkcjonalności i fitchery.

To, co jest bardzo ważne, to że początek tego projektu to był wielki nacisk na jakość, na podniesienie jakości, na utrzymanie jakości. Pierwsze pytanie, które zrodziło nam się w głowie, to jak my sprawdzimy, że ten system działa tak samo dobrze i tak samo źle, jak ten oryginalny, skoro testy są głównie ręczne. I tych testów automatycznych, które zdefiniowaliśmy, takich ciężkich, funkcjonalnych testów, które pokrywają dużą część funkcjonalności, narobiło się grube tysiące. Sam mechanizm translacji kodu to jest jakieś 40 tys. testów, które weryfikują, czy ta translacja jest dokładna, jednoznaczna. 

I bardzo ważna rzecz, która wyszła w ramach projektu, a której nie planowaliśmy, to że przez jednoznaczność translacji kodu jBasic do .NET-a byliśmy w stanie zastosować taką sztuczkę, czyli utrzymanie jakości na poziomie .NET-a implikuje nam jakość po stronie jBasica i faktycznie to jest coś, czego owoce zbieramy teraz na co dzień, mimo że projekt jeszcze się nie skończył.

Te stare technologie mają też jedną potężną wadę. Oprócz tego, że są stabilne, stateczne, jest właśnie problem z pozyskaniem ludzi, którzy będą się tej technologii uczyli, nauczą się albo ją znają. I w tej części korporacyjnej mieliśmy już taki problem braku nowego narybka, ludzi, którzy znają tę technologię, będą chcieli ją rozwijać. I z tym nowym otwarciem na .NET-a już od dwóch lat jesteśmy w stanie zrekrutować ludzi, którzy przy okazji nauczą się jBasica, ale ten .NET z tyłu jest, który ich przyciąga, który uczy, który powoduje, że będą wartościowi na rynku pracy. Więc znowu nam się otworzyła możliwość rekrutacji, co było bardzo ważne, bo chcemy zachować ciągłość działania tego systemu i ciągłość jego utrzymania.

 

To jest fascynujące wyzwanie nie tylko pod względem technologicznym, ale również pod względem ludzkim, ale też zarządczym, bo świadomość kadry kierowniczej jest istotna, żeby to w ogóle mogło się wydarzyć.

Chciałbym jeszcze na chwilę wrócić do tematu organizacji zespołów, bo wspomniałeś, że preferujecie taki sposób organizacji, który daje silną pętlę zwrotną. Ja myślę sobie, że dla nas, inżynierów, jest niezwykle istotne to, żeby widzieć efekty swojej pracy, co daje możliwość uczenia się na błędach, które popełniamy. Nawiasem mówiąc, to jest też coś, co mnie urzekło w programowaniu. To, że szybko widać efekty pracy, co poszło dobrze, co poszło źle.

Zastanawiam się, czy pracując nad takimi dużymi systemami, jak np. bankowe, widzi się wpływ swojej codziennej pracy na system, na produkt, czy ma się realny wpływ, no chociażby wybór technologii. Jak to wygląda w banku?

 

W dużych organizacjach, gdzie ten podział frontend, backend istnieje, frontend widać, backendu nie widać. Przez lata próbowałem wytłumaczyć w mojej rodzinie, czym się zajmuję, i to, co zostało, to takie uproszczenie mojego brata, który w pewnym momencie powiedział: Czyli co, Leszek, skręcasz myszki. I to trochę tak jest, że żeby zobaczyć, co my robimy, trzeba się nauczyć to pokazywać. 

I szczególnie w banku dużo rzeczy dzieje się pod spodem. To oczywiście widać, użytkownik z tego korzysta, ale w części korporacyjnej jednak jest dużo transakcji automatycznych. PSE2 otworzyło tę furtkę API, ale w mBanku korporacyjnym to API było wystawione dużo wcześniej, te transakcje działy się automatycznie, więc na to trzeba patrzeć zupełnie inaczej. 

Znowu tutaj z pomocą przychodzi inżynierskie podejście, bo my tak lubimy sobie robić taki dashbot, który pokazuje, jak dużo tych requestów wpada, z jaką prędkością, że system żyje, że pojawiły się transakcje, że faktury się spłacają, że nasi użytkownicy są aktywni. Lubimy to zobaczyć. Tak jak mechanik, który słucha silnika, czy dobrze warkocze, tak my lubimy patrzyć na takie liczby. I wtedy faktycznie widać ten efekt naszej pracy.

Ale widać go też, jak spojrzy się na LinkedIna, jak nasi prezesi chwalą się transakcjami. Widać też, że nowi klienci korzystają z naszych produktów, w sposób inżynierski jest to jeszcze bardziej widoczne, ale to, co jest ważne, to to, że w banku dokonała się już jakiś czas temu taka transformacja myślenia, że IT to nie jest tylko miejsce kosztów, które trzeba tolerować, tylko faktycznie to jest to narzędzie, które będzie powodowało różnicę. 

To jest ten sposób dotarcia do klienta, sposób, bez którego nie da się już funkcjonować i fajnie powiedział Adam Pers na jednym z naszych ostatnich spotkań: My w korpo mówimy o sobie MY, czy to jest biznes, czy IT, to mówimy MY. I faktycznie tak jest na co dzień, to my kształtujemy rozwiązania. 

Owszem, czasami trzeba zrobić kolejne okienko z kolejnym serwisem, stopni swobody i możliwości wiele tutaj nie ma i nie ma co wymyślać, ale są rozwiązania, chociażby taki projekt innowacyjny, albo inne, które związane są z naszym Oknem na świat lub z produktami, które pod spodem naprawdę są spektakularne i IT miało duży wpływ na ich kształt.

Cały czas mam w głowie ten moment, kiedy PFA wchodził i był definiowany, i jak duży wkład w jego konstrukcję, sposób działania miał mBank, i to nie tylko w części biznesowej, ale właśnie to połączenie biznes – IT.

I to jest fajne, bo tutaj faktycznie możemy kreować to, jak pracujemy. I po inżynieryjsku możemy zobaczyć, jak to tam działa pod spodem.

 

Wspomniałeś wcześniej, że uczycie się cały czas tej domeny. Uczymy się projektów w momencie, kiedy on powstaje, dlatego tak trudne jest zaplanowanie pewnych rzeczy gdzieś tam na początku. 

Zastanawiam się, jak ta domena bankowa, w której operujecie, jak fakt działania na rynku regulowanym, fakt bycia dostępnym praktycznie 24/7 i jeszcze operowania na czyichś pieniądzach wpływa na pracę inżyniera w banku na co dzień.

 

W części korporacyjnej jest trochę inaczej. To jest tak, że jakby coś poszło nie tak, to prezes jednej dużej firmy rozmawia z naszym prezesem. I jest to duża odpowiedzialność, i faktycznie, jak człowiek sobie uzmysłowi, jakimi wolumenami operujemy, jakimi kwotami, jakie to są firmy, to pojawia się lekki stresik, ale właśnie dlatego jest duży nacisk na jakość, powtarzalność, automatyzowanie i poprawianie naszego warsztatu pracy. To jest też coś, dzięki czemu IT nie jest już jednostką kosztową, tylko faktycznie wiemy, że inwestowanie w poprawę IT jest wartościowe. To ma też emanację w takim dużym strumieniu prac, który w IT jest już dostępny, gdzie możemy sami się poprawiać. 

Często na rozmowach rekrutacyjnych słyszę od kandydatów: no, nam nie kazano pisać testów. Mi nikt nie pozwolił pisać testów. Albo słyszę już w kontekście technologii: no, nikt nam nie powiedział, że trzeba zrobić upgrade, nie mieliśmy projektu na upgrade .W mBanku to się już skończyło, mamy na to miejsce, żeby się poprawiać i razem z tym stres`, obawa, ryzyko, to jest coś, co na pewno się zmniejsza. I my nie lubimy ryzykować, bo to są pieniądze naszych klientów, chodzi o ich bezpieczeństwo, więc ryzyko nie jest wpisane w nasz genotyp.

 

I jest to duża odpowiedzialność, i faktycznie, jak człowiek sobie uzmysłowi, jakimi wolumenami operujemy, jakimi kwotami, jakie to są firmy, to pojawia się lekki stresik, ale właśnie dlatego jest duży nacisk na jakość, powtarzalność, automatyzowanie i poprawianie naszego warsztatu pracy. To jest też coś, dzięki czemu IT nie jest już jednostką kosztową, tylko faktycznie wiemy, że inwestowanie w poprawę IT jest wartościowe. To ma też emanację w takim dużym strumieniu prac, który w IT jest już dostępny, gdzie możemy sami się poprawiać.

 

Kilka razy zahaczyłeś o wyzwania rekrutacyjne, które się pojawiają. I nie ma co ukrywać, że kiedyś myślano o pracy w banku (ogólnie, nie tylko w IT) jak o stabilnym miejscu pracy w środowisku, które się niezbyt często zmienia. Dla niektórych była to wartość sama w sobie, żeby taką pracę zdobyć, inni bardzo od tego stronili. Jestem ciekaw Twojej opinii na ten temat, czy tak właśnie wygląda obecnie praca inżyniera w banku?

 

To jest ten moment, w którym warto powiedzieć, jak to się stało, że pracuję 19 lat w jednym miejscu. Bo pojawiłem się w banku zaraz po studiach i na szczęście dlatego, że nie dostałem się do firmy Accenture. To było też ciekawe doświadczenie, bo studiowałem w Poznaniu, poznańska politechnika współpracuje z Poznańskim Centrum Superkomputerowo-Sieciowym i tam było takie rozwiązanie European Globus Grid. 

Gdy spotkałem się z będącym już na emeryturze dyrektorem, który mi powiedział: Panie Włodarski, będzie pan pracował, jeśli się dogadamy z systemem Globus. Pomyślałem sobie: o kurcze, Globus, przetwarzanie gridowe, bank, ja cię kręcę, to będzie się działo. Potem powiedział coś dziwnego, bo technologia J Base, to sobie pomyślałem: Java, no dobra, będę tolerował, trudno się mówi. Okazało się, że to jest coś zupełnie innego, ale faktycznie rozwój był gwarantowany. 

I tak jak mówię, mBank jest zupełnie innym bankiem. Miałem to szczęście trafić na fantastycznych ludzi, z którymi pracowałem i pracuję, część z nich jest na emeryturze, część z nich już nie pracuje w mBanku, a część nadal pracuje, sporo jest moich rówieśników, którzy zaczęli w 2003 r., ale dzięki temu mixowi, który często definiował to, co w IT się działo albo będzie działo, albo przynosił to, co rozpoczynało się na świecie, było naprawdę dużo i ten rozwój był w zasadzie wpisany w codzienność. I to dlatego ja w mBanku nadal pracuję. Bo się nie nudzę, bo się rozwijam. I coś, co było dla mnie ważne na początku kariery i jest ważne nadal, jest tutaj gwarantowane.

Nie wiem, czy tak mają wszystkie duże organizacje, ale na pewno jak zaczynałem pracę w banku, to nie było dlatego, że bank, że stabilność, stateczność i że będę mógł z nogami na biurku czekać na zadanie i będę się nudził. Nie postrzegałem tego też na zasadzie gwarancji zatrudnienia. To był wtedy rynek pracodawcy, więc było troszeczkę inaczej. Natomiast od momentu, jak zacząłem tu pracować, to faktycznie to jest ciągła zmiana. Ja powiedziałem na początku, że raz, w 2007 r. się nudziłem, poszedłem do mojego przełożonego, powiedziałem, że się nudzę, i to był ostatni raz, kiedy się nudziłem. Bo tu jest przestrzeń na to, żeby zaproponować coś, zrobić coś innowacyjnie, lepiej, szybciej, zaaplikować nową technologię w dobrym celu. 

Więc polecam to miejsce pracy do rozwoju, do zbierania doświadczenia, bo tu jest od kogo się uczyć. Ja miałem takie szczęście w życiu, że akurat nie udało mi się dostać do jednej z firm, o której już powiedziałem, i że ten Globus to nie było gridowe przetwarzanie, tylko to faktycznie jest system centralny, a cała reszta to na pewno ludzie, którzy od góry do dołu pozwalają na to, żeby być inżynierem. Wpierają to, cenią to. Wielu ludzi, z którymi zacząłem pracę w 2003 r., to już jest taka relacja weteranów, którzy przeżyli pewne trudne momenty i wiedzą, że mogą na sobie polegać, wiedzą, że dane słowo będzie dotrzymane i to często jest potrzebne szczególnie w tych momentach innowacyjnych uniesień i rozwiązań, które nie do końca jeszcze każdy rozumie, czuje, ale wie, że może zaufać tej drugiej stronie.

 

Właśnie to jest bardzo ważne, żeby znaleźć taki balans pomiędzy tą świeżością technologiczną, a odpowiednio długim stażem pracy, bo dopiero wtedy widzi się efekty tych decyzji, tych kroków podejmowanych wcześniej. I tak, jak powiedziałeś, te relacje, to zżycie w boju, ono nie ma szansy wystąpić, kiedy jesteśmy kilka miesięcy, wskakujemy do projektu i od razu z niego wyskakujemy, to się gdzieś tam latami buduje.

Powiedziałeś, że mBank dla Ciebie to ciągła zmiana. To jeśli jesteśmy przy zmianach, to jak oceniasz, czy pandemia coś zmieniła w sposobie pracy specjalistów IT dla banku, czy coś tutaj w tym temacie się zmieniło?

 

Jest taki dowcip w naszej branży. CIO wdrożył platformę, CEO wdrożył jakąś technologię, a covid wdrożył pracę zdalną. Faktycznie to był moment, w którym zespół Alka mocno się sprężył i dostosował bank do pełnej pracy zdalnej w bezpieczny sposób na taką skalę. Więc to na pewno się wydarzyło i zmusiło nas, menedżerów, żeby wyjść ze swojej strefy komfortu, bo nie było wyjścia. Natomiast trochę się z tego podnosimy już, tzn. to jest na pewno fajne, modne, ale ja jestem jednak przyzwyczajony do tego, żeby mieć kontakt z człowiekiem. 

To jest dla mnie bardzo ważne. Ten cały okres pandemii, pracy zdalnej, to było trochę tak, jakbym pracował bez jednej ręki. Nie było pełnych relacji, nowych przyjaźni, co jest bardzo ważne, szczególnie gdy pracuje się tak długo w jednej organizacji. Ciężko pracować w ten sposób z nowymi ludźmi. I z tego się podnosimy trochę. 

Teraz pracujemy w trybie hybrydowym, możemy być w biurze częściej, na pewno raz na dwa tygodnie się spotykamy, żeby odbudować te relacje, nawiązać znajomości, żeby sobie móc zaufać. To jest bardzo ciekawe, żeby poznać siebie, czy jest się wysokim, czy niskim, grubym, czy chudym. Pierwszy mój dzień w biurze, gdy przyjechał cały zespół, który zajmuje się tym platformingiem, był takim dniem zaskoczeń, bo jednak się okazało, że kamera trochę zmienia rzeczywistość. 

Ale to jest bardzo ważne, trochę się zastanawiam też jako ojciec dzieci, które w tym okresie chodziły do szkoły, jaki to będzie miało wpływ na młodych ludzi, jak ten wymuszony brak kontaktu wpłynie na ich relacje między sobą, bo ja wiem, że mi tego brakowało oraz że młodzieży, nowym pracownikom zupełnie tego nie brakuje. Trochę już było mówione o tym, chociażby w Twoim poprzednim odcinku o tym zżyciu się z firmą. Ciężko się zżyć z firmą, jeśli to jest tylko skrzynka i słuchawki, a to też jest bardzo ważne. Bo to też jest coś, co widzimy jako efekt swojej pracy, więc czekam na podsumowanie jakieś, badawcze prace, które będą mówiły o tym, jaki to miało wpływ na ludzi, na ich relacje i możliwość pracy wspólnej. Mnie na pewno tego brakowało.

 

Cieszę się, Leszku, że w naszej dzisiejszej rozmowie oprócz technologii bardzo często nawiązujemy do znaczenia tych relacji międzyludzkich i w ogóle, człowieka, jako takiego w organizacji. 

Myślę, że bardzo przekrojowo pokazaliśmy, na czym polega praca inżyniera w banku w tej naszej dzisiejszej rozmowie. 

Dzisiaj moim gościem był Leszek Włodarski z mBank S.A.

Leszku, bardzo Ci dziękuję za poświęcony czas i za podzielenie się swoimi doświadczeniami.

 

Dziękuję bardzo za możliwość porozmawiania.

 

Zanim się rozłączymy, powiedz, gdzie Cię można znaleźć w internecie, albo gdzie możemy odesłać słuchaczy.

 

Ja nie jestem zbyt mocno obecny w internecie. Można mnie znaleźć na LinedInie. Wszystkie inne miejsca są prywatne. Można mnie znaleźć w mBanku przy ul. Prostej 18, polecam. I to tyle.

 

Świetnie, oczywiście link do Twojego profilu podepnę do notatek do odcinka. Jeszcze raz Ci bardzo dziękuję. 

Do usłyszenia!

 

Cześć! Dzięki.

 

I to było na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Po więcej wartościowych treści zapraszam Cię do wcześniejszych odcinków. A już teraz, zgodnie z tym, co czujesz, wystaw ocenę, recenzję lub komentarz w aplikacji, której słuchasz lub w social mediach. 

Zawsze możesz się ze mną skontaktować pod adresem krzysztof@porozmawiajmyoit.pl lub przez media społecznościowe.  

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o tym, co znaczy bycie inżynierem w banku. Zapraszam do kolejnego odcinka już wkrótce.

Cześć!

 

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.