Porozmawiajmy o IT
Porozmawiajmy o IT
Jak bank wdraża nową platformę i adaptuje nowoczesne technologie. Gość: Leszek Włodarski - POIT 304
Witam w trzysta czwartym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest to jak bank wdraża nową platformę i adaptuje nowoczesne technologie.
Dziś moimi 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 ponad 20 lat. Specjalista takich technologii jak .NET, C/C++ i jBASIC.
Sponsor odcinka
Sponsorem odcinka jest mBank S. A.
W tym odcinku o zmianach technologicznych w banku rozmawiamy w następujących kontekstach:
- duża zmiana technologiczna w bankowości korporacyjnej – kulisy projektu Houston
- specyfika IT w bankowości korporacyjnej vs. detalicznej
- replatforming systemu core’owego „na otwartym sercu”
- migracja danych, infrastruktury i testów – etapowanie vs. big bang
- nowa architektura i jej realne możliwości biznesowe
- ewolucja zespołu i kompetencji w trakcie wieloletniego projektu
- współpraca wewnętrznych zespołów i partnerów zewnętrznych
- metodyka, organizacja pracy i praktyki inżynierskie w skali enterprise
- wpływ transformacji technologicznej na kulturę zespołu i codzienną pracę
- lekcje z replatformingu i fundament pod przyszłe zmiany technologiczne
Subskrypcja podcastu:
- zasubskrybuj w Apple Podcasts, Spreaker, Sticher, Spotify, przez RSS, lub Twoją ulubioną aplikację do podcastów na smartphonie (wyszukaj frazę „Porozmawiajmy o IT”)
- poproszę Cię też o polubienie fanpage na Facebooku
Linki:
- Profil Leszka na LinkedIn – https://www.linkedin.com/in/leszekwlodarski/
Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.pl
https://porozmawiajmyoit.pl/304
To jest 304 odcinek porozmawiajm IT. Dziś rozmawiamy o tym, jak bank wdraża nową platformę i adaptuje nowoczesne technologie. Sponsorem odcinka jest MBank SA. Dodatkiem linki i transkrypcję, czyli wszystko to, co porządny słuchacz powinien mieć pod ręką, znajdziesz na porozmawiajmyite.pl łamane na 304. Nazywam się Krzysztof Kępiński, tworzę ten podcast, napisałem też książkę Marka osobista branży IT i lubią, jak ludzie z naszej branży rozwijają się z głową a nie na oczkiem. Bardzo mi pomożesz, jeśli ocenisz podcast w swojej aplikacji albo puścisz ten odcinek dalej. Tylko tyle, bo mówią, że karma wraca. No dobra, odpalamy. Moim waszym gościem jest IT Deputy Director w Mbanke SA, doświadczony deweloper i architekt oprogramowania, lider zespołu i menadżer w MBanku, z którym związany jest zawodowo od kilkunast lat. Specjalista takich technologii jak dotnet, CC i Joy Basic. Moim waszym gościem jest leczek łodacki. Do śdzeczku, i witaj ponownie w moim podcastu.
SPEAKER_01:Miło mnie, że ponownie możemy rozmawiać.
SPEAKER_00:Właśnie ostatnio rozmawialiśmy co temu, jak się okazuje ten czas bardzo szybko leci, i wówczas tematem naszej rozmowy było to, jak to jest być inżynierem w banku i kolejnie jako będziemy kontynuować ten temat, ponieważ na kanwie dużej zmiany technologicznej w części korporacyjnej banku będziemy rozmawiać o tym, jak to jest, gdy bank wdraża nową platformę, adaptuje nowoczesne technologie, więc oczywiście jest to kontynuacja rozmowy o różnych praktykach inżynierskich. Myślę, że to nam się tutaj dobrze jedno z drugim będzie łączyło. Zanim do tego przejdziemy, to chciałem troszeczkę zapytać, czy coś się zmieniło na twojej liście podcastowej od naszej ostatniej rozmowy?
SPEAKER_01:Tak, jest jedna duża zmiana. By mówiłeś, spotkaliśmy się trzy lata temu i ja wtedy bardzo uważałem, żeby nie mówić o tym projekcie, o którym dzisiaj będziemy mówić. I trzy lata temu trochę się zamknąłem w sobie. Więcej pracowałem mniej słuchałem, więc lista nie wzbogaciła się, nie zmieniła, raczej kontynuowałam ten trend, który wtedy, o którym wtedy rozmawialiśmy.
SPEAKER_00:Jasne. Dobrze, to chciałbym cię właśnie poprosić na wstępie, żebyś powiedział o tym dużym wówczas tajemniczym projekcie, który zająłeś podczas naszej ostatniej rozmowy. Projekcie Houston, czyli dużej zmiany technologicznej w części korporacyjnej MBanku. Na czym ten projekt polegał, z jakich etapów się składał?
SPEAKER_01:No dobrze, to tak, projekt Houston to taki projekt transformacja. Kiedyś mówiliśmy na to bioplatforming, bo mówił tylko o technologii, ale na końcu okazało się, że to jest taka pełna transformacja w obszarze core banking w części korporacyjnej, bo to jest migracja całego kodu źródłowego systemu ze starych technologii, mieliśmy taką technologię JBASISI do.NET, bazy danych ze starej technologii JBASE do Postgresa, to też migracja User Interface, User Experience, jakby zupełna poprawa, zmiana ze starego Visual Basic, którego na szczęście nawet nie mieliśmy kodów, do nowoczesnej aplikacji webowej, ankularowej, gdzie nasz pracownik banku, bo to jest aplikacja używana przez pracownika banku, tak jak każdy cywilizowany człowiek jest w stanie wysłać sobie link do danej transakcji, do danego obiektu, w starym systemie to było niemożliwe. To też jest zmiana API, aż strach powiedzieć, ten stary system opierał się na Telnecie, to było ten główne medium komunikacyjne i olbrzymia zmiana, transformacja w obszarze Developer Experience. To, jak pracują deweloperzy, to co robią, w jaki sposób, to była też duża zmiana i z tej perspektywy dobrze, że to zajęło 9 lat, bo mieli czas na to, żeby się zaadaptować. To też nowe podejście do jakości. Gdy zaczynali projekt, testów automatycznych, które weryfikowały działanie systemu, mieliśmy mniej więcej zera. Teraz te liczby są, wchodzą w tysiące, to o tym też będę mówił, więc w zasadzie zmieniło się wszystko w obszarze core banking. Od technologii pod zespoły, jak ludzie pracują, w czym pracują, te techniki inżynierijskie, to też jest coś, co się zmieniło. A to wszystko robiliśmy i to było bardzo ważne założenie tego projektu, bez zatrzymania rozwoju biznesu. Nie wyobrażam sobie, żebyśmy 9 lat temu zatrzymali biznes, powiedzieli, no sorry, teraz już nic nie robimy, migrujemy system. I teraz jakby pytałeś o etapy projektu, z perspektywy czasu mogę je nazwać. Wtedy, gdy to robiliśmy, to etap był zawsze taki, za rok kończymy. My co roku kończyliśmy projekt, tak planowaliśmy pracę, no bo okazywało się, że to jest w ogóle bardzo skomplikowane, to co jest przed nami. Ale jakby tak się teraz zmusić nazwać te etapy, no to definicja problemu to była bardzo ważna rzecz, bo w ogóle zaczęło się od czegoś błahego. Szef powiedział, leczek, no musimy bazę wymienić. Ta stara zupełnie nie funkcjonuje, nie sprawdza, nie wyliwkuje danych i w ogóle ten disaster recovery to jest w ogóle dramat. Więc wymieńmy bazę. Szybko się okazało, że to jest cała platforma, to jest język czwartej generacji, to tak brzmi dumnie, więc to jest i język programowania, i baza danych, i cały runtime, który jest pod spodem, który w zasadzie musimy wymienić, no ale ważne było dojść do tego, że to nie jest tylko baza danych. Więc jakby sama definicja problemu. Potem była coś, to była jedna z piękniejszych przygód, którą tutaj przeżyłem, to jest translacja kodu. Wybraliśmy ścieżkę translacji kodu automatycznej, nie przypisywania ręcznego, tylko automatycznej translacji z jednego języka w drugi. I to była naprawdę czysta frajda, taka czysta inżynierska praca, AST, abstract syntax tree, analiza kodu, budowanie z tego dotneta, naprawdę super sprawa. To o tym też potem jeszcze mam nadzieję, że będę mógł powiedzieć. Potem szybko się zorientowaliśmy, że tego systemu code banking, serce banku, nikt nie przetestuje ręcznie. Przez lata, wtedy 13 lat dewelopmentu, 15 lat dewelopmentu, przez lata on powstawał, był budowany, były dokładane kolejne funkcjonalności, ale na końcu nikt nie wie, jak on powinien działać, więc założyliśmy, że bez testów automatycznych, bez podejścia do tego, jak zweryfikować, że ten system tak samo dobrze i tak samo źle działa, no bez tego nie mamy szans się wdrożyć. No i też smażyło nam się, żeby to robić w sposób pływający, zresztą migrację wykonać pływająco, więc bezpiecznie, w jakiś sposób krokowo, nie robić big bang, bo ponoć statystyki mówią, że nie dojesz, że projekt, który trwa dłużej niż 3 lata, ma 30% mniej szans na sukces. To jeszcze takie transformacyjne projekty 3 na 10 kończą się sukcesem, to jeszcze Big Bang powoduje, że 50% jest szans na to, żeby się projekt udał, więc bardzo marzyło nam się, żeby tego nie robić w ten sposób na Big Bang. Więc cały duży wysiłek był taki etap, którym pamiętam, gdzie właśnie jakość, testy, jakość, weryfikacja, to były te rzeczy, których były istotne. Po drodze staraliśmy się wyłączać te tematy, które były, te elementy systemu, które nie rokowały w nowym świecie, chociażby klient obalczył teleta. Tego nie chcieliśmy zostawić. Więc to, co mogliśmy, wyłączaliśmy, to też jest coś, co jakby z ważną cechą inżyniera umieć zrezygnować z czegoś i coś zamknąć w końcu. I tu też mieliśmy całkiem niezłe sukcesy. Ostatnia prosta to była walka o wydajność. To były te ostatnie testy z biznesem już wtedy na pokładzie. No i big bang. Ostatni etap największy. Jednak mimo wszystko nie było wyjścia. Tak, ale o tym też jeszcze powiem. Ale tak jak mówię, z roku na rok zawsze myśleliśmy, że skończymy w tym kolejnym roku. Więc to planowanie nam nie wyszło, ale to też jest właśnie specyfika tego systemu, albo core bankingu w ogóle, to jest bardzo wrażliwe miejsce na błędy i bardzo musieliśmy być ostrożni.
SPEAKER_00:Tak czy dużo rzeczy, znacznie szersza niż tylko zmiany technologiczne. Jestem przekonany, że wiele lessons learned, które będę dzisiaj chciał też tutaj od Ciebie wyciągnąć, ale właśnie powiedziałem, że to jest takie miękkie podbrusze, prawda, że to jest bardzo wrażliwa część całego banku. Jakiś czas temiałem z Michałem Nziewieckim właśnie o takiej zmianie w tej części detalicznej. Tutaj dzisiaj poruszamy temat związany z częścią korporacyjną, więc w sumie powinienem zacząć od zapytania ciebie, czym właściwie jest ta część korporacyjna banku i czy jest jakaś specyfika tej części, która wpływa na to, że zmiana technologiczna, o której rozmawiamy, no właśnie czymś się charakteryzuje jest jakaś inna specyficzna.
SPEAKER_01:Już ostatnio o tym trochę rozmawialiśmy, czym jest część korporacyjna, to na pewno mniejsza liczba transakcji niż w części detalicznej. Natomiast mają one swój ciężar. Poza taką naturalną konsekwencją obsługi dużych firm, czyli czasami kilkadziesiąt tysięcy przelewów od jednego klienta naraz, mamy na przykład między bank, czyli obsługa rachunków banków zagranicznych, banków polskich, i to jest czasami kilka tysięcy przelewów dziennie, ale na kwota około 150 miliardów polskich złote. A gdy to wszystko dzieje się około godziny 16, łatwo sobie wyobrazić, że błąd w tym momencie, w tym miejscu może być bardzo, bardzo bolesny, nawet proste odsetki od takich kwot są olbrzymie. I to są te zasady, które rządzą korporacją. Tutaj mamy dużych klientów, mamy duże transakcje i do tego duży wpływ na rynek bankowy w Polsce.
SPEAKER_00:Czy ta część korporacyjna, no właśnie w kontekście LEP-formingu jakoś wpływała, ta specyfika tej części korporacyjnej wpływała na to, że musieliście inaczej podejść do zmiany platformy, czy też ta operacja na otwartym sercu właśnie w jakiś specyficzny sposób przez to musiała przebiegać?
SPEAKER_01:Na pewno ważne było to, że to było kilkanaście lat dewelopmentu, który wprowadził bardzo dużo produktów wszytych na miarę. I to też jest powód, dla którego my z tym systemem, który mamy, mieliśmy zostaliśmy, bo jest uszyty na miarę. Bardzo specyficzne, bardzo dedykowane. Często ważne było, żeby raz dziennie dany proces uruchomił się, przytworzył dwie transakcje, to było na ścieżkę krytycznej. My wyizolowaliśmy około 600 procesów, takich, które działają w tym naszym systemie. Mniej więcej też podobną liczbę funkcji API, które są wykorzystywane codziennie z perspektywy zewnętrznych systemów, zewnętrznych do core bankingu. No i część z nich była rozwijana kilkanaście lat temu i ludzie, którzy to definiowali wymagania do tych funkcjonalności, którzy to dewelopowali, już dawno z niem nie pracują. I to było duże wyzwanie, tak naprawdę to było to największe wyzwanie. No bo w tych wszystkich obszarach, których pracujemy na co dzień, bo tam toczą się projekty, życie regulacyjne, mamy tam doświadczenie, mamy już teraz dużo testów automatycznych, to wszystko jest coś, czego byliśmy pewni. Najgorsze były te obszary, które faktycznie przez od dawna nie były dotykane i modyfikowane i w zasadzie wykraczaliśmy tam znowu po raz pierwszy.
SPEAKER_00:Z tego, co rozumiem, projekt Houston jest swego rodzaju parasolem takim, czymś, co łączy wiele różnych działań. Jego elementem jest projekt Globusnet. Prosiłbym, żebyś może właśnie chwilkę o tym opowiedział, skąd wynikała potrzeba replatformingu właśnie w postaci projektu Globusnet i w jakich obszarach IT był realizowany?
SPEAKER_01:Tak, masz rację. W zasadzie można byłoby powiedzieć, że Houston był programem, który zaczął się 9 lat temu. Składał się z wielu ścieżek. Ta na której się koncentruje, to jest Globusnet i migracja systemu, transformacja systemu centralnego crowdbanking. I wszystko zaczęło się od takich wstrząsów przypowiadających, że za chwilę będzie problem. Zrobiliśmy coś zupełnie prostego 9 lat temu, może 10 lat temu, czyli zaktualizowaliśmy system operacyjny, na którym działał nasz system bankowy i całość nam się zatrzymała. Szybko to odkręciliśmy, wycofaliśmy te zmiany, które były wgrywane na poziomie systemu operacyjnego. To jest coś, co większość deweloperów w ogóle nie zdaje sobie sprawy, że my też patrzyjemy systemy operacyjne. I już 6 miesięcy później mieliśmy diagnozę, że to było jedno takie pokrętło, które się zmieniło, które się okazuje, że ona już nie pasuje do naszej starej bazy danych, bo ona już wtedy była stara. Rok później wydarzyło się kolejna sytuacja trudna, to znaczy błąd w kodzie, ale takim starym kodzie, który był niedotykany przez pewnie 20 lat, jeszcze nawet nienapisany w Polsce, spowodował, że w wyniku innych naszych rozwiązań, które się toczyły i zaczęły działać w systemie produkcyjnym, mieliśmy duży problem, duży błąd w systemie, który potem sprzątaliśmy. No i te dwa wstrząsy, to było enough, żeby stwierdzić, że stoimy nad krewędzią, coś trzeba zrobić, bo te dwa razy sobie poradziliśmy, ale to dalej będzie. Technologia, którą mamy, jest długiem technologicznym, jest nierozwijana, niewspierana, nie jest nowoczesna. Mamy monolit, który jest osadzony na jednej maszynie i mamy jakiś dezaster cover, które na szczęście nie musimy z niego korzystać. Do tego wszystkiego nasze wszystkie próby unowocześniania tego systemu stosu technologicznego kończyło się na tym, że w tym systemie operacyjnym, w którym pracowaliśmy, nie było open source, nie było nowych płatnych bibliotek. Ciężko było cokolwiek zrobić, co miało znajomione od nowoczesnego dewelopmentu. Użycie web serwisów prawie niemożliwe. Zrobiliśmy to tak naokoło. Resty, konsumpcja restów prawie niemożliwa. Wszystko było trudne, wszystko było bardzo trudne. Na szczęście wtedy jeszcze development, skala dewelopmentu w systemie centralnym nie była duża, no bo wszyscy czuli, że tam się ciężko coś czkolwiek robi, więc budowaliśmy na zewnątrz naokoło. Ale w 2017 roku, to ja pamiętam, to było już po roku trwania naszego projektu, rozpoczęła się taka i nie skończyła ścieżka projektów regulacyjnych. Po drodze był Sprit Payment, jakiś MIFIT, teraz mamy ISO, projektów regulacyjnych, które już nie da się zrobić nigdzie indziej, one muszą być zrobione w systemie centralnym. No i całe szczęście, że my zaczęliśmy to 9 lat temu, bo teraz mamy takie możliwość realizowania tych projektów w sposób wydajny. Jeśli chodzi o obszary, w których my pracowaliśmy, to dotknęło na końcu całego IT, który pracuje z częścią kooperacyjną, no bo dotknęło samego systemu centralnego zespołów dewelopejskich, nasi administratorzy bardzo dzielnie pracowali nad tym, żeby zaupgradować, przygotować nowe środowiska, żeby je testować, weryfikować. W ogóle przez te 9 lat wydarzyło się bardzo dużo w świecie bankowym, w IT bankowym, dostosowanie do regulacji, które powodowało, że my zawsze mieliśmy ruch. Zawsze coś się musiało dziać, nie mówiąc o pandemii, która w ogóle zrobiła swoje.
SPEAKER_00:Czyli mamy tutaj dane z powiązaną bazą danych, mamy infrastrukturę, mamy testy, no oczywiście kod aplikacji. Czy te wszystkie obszary były można powiedzieć migrowane, ulepszane równocześnie, czy też może było to jakoś podzielone na etapy najpierw infrastruktura później kod takiem tradycyjnym pojęciu, właśnie jak totaj do tej migracji tych poszczególnych obszarów podeszliście?
SPEAKER_01:Znaczy tak, my zaczęliśmy oczywiście od kodu, pracujemy w Software House, ale to też dlatego, że zrobiliśmy duży ruch w tym okresie, duży ruch shift-left. Czyli tak naprawdę ta infrastruktura ostateczna powstała na końcu, to nie jest do końca prawdą, to też o tym za chwilę powiem. Wszystkie elementy się przenikały, no bo sukces w migracji danych spowodował, że mogliśmy zacząć myśleć o testach automatycznych. Jak myśleliśmy o testach automatycznych, które nam się udały, mogliśmy myśleć spokojnie o dużym rozwoju runtime'u i platformy. Duży rozwój runtime spowodował, że mogliśmy myślić znowu o testach automatycznych i tak każdy mały sukces w tym obszarze powodował, że powstawały nam nowe możliwości, otwierały nam się nowe drzwi do tego, żeby ten projekt z sukcesem i wbrew wszystkiemu, co można byłoby myśleć 9 lat projekt, wbrew wszystkiemu w sposób optymalny doprowadzić do końca. Więc każdy z etapów, każdy ze stłumieni, które staraliśmy się izolować, żeby nie miały na siebie wpływu, każdy dawał coś od siebie i to powodowało, że byliśmy w stanie zrobić duży zazwyczaj krok w pozostałych obszarach.
SPEAKER_00:Wspomniałeś tutaj o Monolicie w tym pierwotnym wydaniu systemu. Jak teraz wygląda architektura całego rozwiązania, jakie takie główne możliwości daje teraz ta architektura w stosunku do tego, co było wcześniej?
SPEAKER_01:Więc tak, przede wszystkim, my jesteśmy na nowoczesnym stopie technologicznym. Większość systemu mamy na klasrze kubernetesowym, więc mamy skalowanie wbudowane w rozwiązanie. Nie dlatego, że Kubernetes, ale dlatego, że tak to zaplanowaliśmy i faktycznie z tego skalowania już skorzystaliśmy, żeby zwiększyć wydajność systemu. Pod spodem mamy nowoczesną bazę danych, która działa w trybie Master Slave, Active Passive. To jest też coś, co spowodowało, że zarówno z Kubernetesem, jak i z nowoczesną bazą danych, nasze disaster recovery jest. Liczy się w minutach, ale możemy spać spokojnie. Wiemy, że ten element infrastruktury działa poprawnie. Na DSE, bo to jest na DSE, w takim dużym systemie UI jest troszeczkę na DESY, aplikacja webowa oparta na angularze, cały kod systemu w dotnecie. Chciałem powiedzieć w najnowszym dotnecie, ale niestety trzy tygodnie temu pojawił się dotnet 10, więc tego ruchu jeszcze nie zrobiliśmy, ale tak, dotnet Core 8 to jest to, nad czym pracujemy. I to, co najważniejsze, my przez te 9 lat stopniowo, krok po kroku, robiliśmy upgrade w platformie dotneta do coraz to nowszych wersji. I to jest ważne, my jesteśmy gotowi na kolejny upgrade w związku z tym. Mając tam 1040 tysięcy testów automatycznych, które weryfikują jakość działania platformy, jesteśmy gotowi na dziesiątkę i na to, co przyniesie dalej świat. Co wpływ pozorom jest bardzo ważne, no bo w tym starym systemie monolitycznym w tym obszarze nie było zawirowań, bo my od 2004 roku nie zrobiliśmy upgradu technologii. No i nikt nie zauważył tego braku. Tak, o Disaster Recovery mówiłem, to jest bardzo ważny element, coraz bardziej ważny element, szczególnie gdy zaczynamy się rozpraszać. I bardzo ważne to, co z nami zostało i jest, i to ja przycę w architekturę rozwiązania, to są testy automatyczne. Mamy takie narzędzie, które zbudowaliśmy zaraz na samym początku Houstona, które miało za zadanie wycisnąć z organizacji testy automatyczne. Chodziło o to, żeby je dobrze zdefiniować i móc automatycznie wykonać. Nazwaliśmy je Squeezer. No i zaczęło się oczywiście od zera testów, potem stu testów. Teraz mamy około 5000. testów, które są wykonywane codziennie na trzech środowiskach. Każde środowisko, każde te pięć tysięcy testów to jest 40 tysięcy, 50 tysięcy kroków testowych, które kiedyś zażertuję, robił biznes ręcznie, oczywiście, że nie robił. A teraz mamy je w cyku dziennym uruchamiane i to ten nasz shift left jest naprawdę super. I pamiętam ten taki dzień, kiedy, no właśnie, jeden z etapów rozwoju tego narzędzia, to nie było to, żeby mieć jak najwięcej testów automatycznych, tylko żeby móc diagnozować błędy, które mamy na produkcji, w starym środowisku, które, uwaga, to narzędzie nie było dla deweloperów, tylko było dla analityków, dla użytkowników biznesowych, tak żeby oni byli w stanie bardzo łatwo wprowadzić przypadek testowy i pokazać deweloperowi, że jest błąd. I pamiętam taki wieczór, godzina osiemnasta, taka z analityczek najlepsza, którą mieliśmy w zespole, Superbata, wstaje w pewnym momencie od komputera i mówi mam to. Powtórzyłam błąd produkcyjny. I zrobiła to w narzędziu, zrobiła to ustawiając odpowiednie parametry transakcji w ciągu godziny, weryfikując różne możliwości, bo miała możliwość eksperymentowania, bez tego, co do tego momentu były takim naszym developer experience, czyli pełen restaur środowiska, próba uruchomienia tego jeszcze raz, no nie udało się, więc jeszcze raz robimy restaur środowiska. To był game changer. I to jest ważny element teraz architektury. Nadal to inwestujemy. Przez te grube lata my te tysiące testów utrzymywaliśmy, to też jest mega ważne. To znaczy kultura w zespołach zmieniła się właśnie w tą stronę, że my to utrzymujemy, badamy, jeśli coś jest czerwone, to patrzymy dlaczego. Bo to też słyszałam o takich eksperymentach, które skończyły się dużą liczbą testów, ale wszystkimi błędnymi. Tak i teraz to, co jest jeszcze ważne, bo to architektura nie jest dla samej siebie, ona jest po coś. I teraz my to zrobiliśmy wszystko po to, żeby nam było łatwiej. No i to, co jest przed nami, to jest wszystko. To tam sky is the limit. Możemy użyć każdej nowoczesnej technologii, która jest na rynku. Teraz rozmawialiśmy z innym zespołem o projekcie, no i nas pytają, czy możemy użyć stumieniowania? Nie ma problemu. Możecie użyć restać, to nie ma problemu. Może mamy kolejki jakiej, tak, nie ma problemu. Drzwi stoją otwoją, bo mamy ten nowoczesny stos technologiczny, który ma wsparcie narzędziowe, ludzie wiedzą, jak z tym pracować, na rybku są firmy, które wiedzą, co z tym robić. Wróciliśmy do żywych.
SPEAKER_00:Powiedziałeś tutaj o wielu takich pozytywach dla deweloperów, tak, coś, co powoduje, że programiści i deweloperzy są bardziej szczęśliwi, jeśli mają za zadanie coś właśnie dołożyć, coś modyfikować. Czy ta nowa architektura, nowy stos technologiczny to również lepszy performance, łatwiejsze operation, zrozumiane właśnie jako administrowanie tym systemem obserwability, i wszystko to, co w tym dzisiejszym świecie jest niezbędne, aby monitorować, nadzorować aplikację działającą właśnie produkcyjnie?
SPEAKER_01:To był jeden z elementów projektu tak naprawdę. Musieliśmy wiedzieć, co musimy zmigrować, co musimy zransformować. I monitoring obserwability to były jakby te podstawowe klocki, które zbudowaliśmy w pierwszych miesiącach projektu, bo to też jest. Pewnie ktoś, kto ma jakieś wykształcenie związane z prowadzeniem projektu, zastanawia się, jak to jest możliwe, gdzie w dużej instytucji finansowej, w której jest cykl czteroletni, gdzie się zmienia zarząd albo się nie zmienia, mamy dziewięcioletni projekt. On powinien być zatrzymany po pierwszych dwóch latach i potem po pokolejnych dwóch latach. To wszystko dlatego, że my co roku dostarczaliśmy, co roku, co kwartał, co miesiąc dostarczaliśmy wartość organizacji i monitoring obserwability to był jeden z tych elementów, który mieliśmy zupełnie na początku. Nasze podejście do analizy tego, co się dzieje w systemie. Widoczność, wykrywanie błędów, problemów, to jest niebozięne między tym, co było kiedyś, a co mamy teraz. Trzeba wziąć pod uwagę, że przez te 9 lat ten ruch transakcyjny w banku urózł znacząco. Trzeba wziąć pod uwagę to, że gdy zaczynaliśmy projekt, to zespół, który zajmował się systemem centralnym, to było około 20 deweloperów. Teraz jesteśmy na poziomie 80 stu i rośniemy. I to nie dlatego, że potrzebujemy więcej ludzi, bo oni wolno robią, no tylko mamy takie jakby tyle rzeczy do zrobienia, bo regulacje, bo zmiany biznesowe, bo kolejne pomysły. I jak widać jest, jak to robić. Bank widzi to, że może to inwestować i będzie to dobrze wydany pieniądze?
SPEAKER_00:Wspomniałeś tutaj o zespole. No i właśnie, o ile nowe klocki, nowe narzędzia, nowy stack technologiczny zróży, oczywiście bardzo ważny, żeby realizować te kolejne pomysły biznesowe, o tyle odpowiedni zespół jest tutaj niezbędny, dlatego, żeby cokolwiek mogło się wydarzyć. Jak ten zespół tego wewnętrznego software house, o którym mówiłeście, zmieniał? Jakie kompetencje musiał nabywać w trakcie, aby ten dziewięcioletni projekt dowieść?
SPEAKER_01:To jest w ogóle piękna historia, bo to zaczęło się 9 lat temu. Zespół, w którym zacząłem wtedy pracować, miał swój obszar biznesowy, no i było to wyzwanie, zmigrujcie bazy danych, była ta stara, nie ten teraz. Więc zaczęliśmy małym teamem, czteroasobowym, który zajmował się tylko i wyłącznie tą migracją, badaliśmy, co można zrobić, jak można zrobić, a obok mieliśmy zespół biznesowy, który jakby żył z tym systemem. No i to było bardzo ważne, bardzo ważny układ. No bo z zaczynając od czterech my tak troszeczkę rośliśmy. Co pół roku planning zasobów, coraz więcej ludzi, coraz więcej ludzi. Ten zespół też był bardzo ważny w tych początkowym okresie, bo on był blisko mnie, więc było łatwo, on pokazywał, że da się. Nie musiałem nikogo specjalnie przekonywać. Po prostu przyjeździony zespół wykonywał testy automatyczne, wykonywał analizy. Było widać, że to wszystko zaczyna działać. To jest ważne, żeby pokazać innym zespołom, które może trochę nie wierzą, trochę się boją zmiany, może trochę czekają, aż to ktoś pokaże, że to da się zrobić. No my te drzwi otworzyliśmy. Na końcu pracowaliśmy w 4-5 w sumie intensywnych strumieniach prac, około dwudziestu kilku osób, które bezpośrednio pracowały w tym ostatnim etapie nad transformacją, ale to wszystko była kropla w morzu, no bo to miało wpływ na 80-osobowy zespół, który pracował w ogóle nad systemem centralnym, rozwijając go dzień w dzień. W ostatniej fazie to były setki ludzi z biznesu, którzy razem z nami to weryfikowali zachowanie systemu, testowali, pomogli nam zrobić big bang i wdrożenie, więc na samym końcu to był olbrzymi zespół, jak dołożył kropeczkę na D, także całe te 9 lat wysiłku mogło się udać. Pytały się kompetencje, które były ważne. Jako, że wcześniej mówiłem o tym byciu inżynierem, który używa odpowiednich narzędzi, do odpowiednich wyzwań, ja myślę, że to najważniejsza by ta odwaga. Bo to jest odwaga przed zmianą, odwaga przed wyjściem ze strefy komfortu, bo zaczynamy robić inaczej, to zawsze wiąże się z pewnymi potencjalnymi problemami, bo ktoś bierze na siebie ryzyko, że pomoże zająć na początku dłużej, więcej czasu. I to też odwaga, no bo przez lata wspierając ten system, zajmując się nim tak dzień w dzień, wiemy, co to znaczy błąd w tym systemie. Wiemy, ile ono kosztuje, ile on waży. Wiemy, jak to jest ciężkie później postfaktu, po sprzątanie tego wszystkiego. No i utrzymanie relacji z biznesem czy z klientem. Więc widziałem wiele razy, jak zespół się wahał, żeby ten N-tek wcisnąć na końcu, żeby na końcu postawić kropkę zdania. I ta odwaga była bardzo ważną kompetencją, żeby w ogóle dalej sobie z tym poradzić. I to też pewna odwaga, no bo pracowaliśmy w dużej niepewności. Tak jak mówiłem, 20 lat dewelopmentu systemu i nie zawsze było tak, jak jest teraz, że piszemy testy automatyczne, że mamy ich coraz więcej, umiemy pisać dokumentację. I jeśli piszemy, to jeszcze w nowożytnym języku, który daje się jakoś ustrukturyzować, więc duża praca w niepewności, czy to zachowanie, które obserwujemy, to była intencja dewelopora 10 lat temu, czy może to jest bug, który stał się featureem, czy może to jest coś, co nas może uderzyć w przyszłości, bo do tej pory nie było takiej transakcji. No i mieliśmy taki super team. Mamy wszyscy na tym pracujemy, który miał tą odwagę i tą czelność dokonania takiej zmiany odważnej.
SPEAKER_00:To jest bardzo budujące, że wspominasz tutaj głównie o tych kompetencjach właśnie takich związanych z postawą, z wewnętrznymi wartościami, a nie ze znajomością kolejnego języka programowania? Myślę, że z perspektywy czasu to właśnie te kompetencje są kluczowe, dużo ważniejsze niż ekspertyza z jakiejkolwiek gałęzi technologicznej. Czy te wewnętrzne zasoby, że tak to nieładnie nazwę, były wystarczające, żeby tą migrację, tą transformację dokonać, czy też posiłkowaliście się pomocą z zewnątrz?
SPEAKER_01:Wiesz co tak, w początkowej fazie bardzo pomogła nam belgijska firma, która to są specjaliści, eksperci od kompilatorów i translatorów. I oni pozwoli, ja myślę, że zupełnie subiektywnie umując, przyspieszyli ten projekt o kilkadziesięć lat. Pamiętam jak dzisiaj oni po dwóch miesiącach pracy nad dokumentacją, która była mało pełna, to znaczy były takie głosy, że język programowania JBASIC formalnie nie jest językiem. To mówi dużo za siebie, jeśli ktoś zajmował się kompilatorami, a chłopaki w ciągu dwóch miesięcy z tej firmy zrobili analizator kodu, dali narzędzie, które też u nich się sprawdzało, na bazie którego zrobiliśmy translację. I bez nich zrobienie tego to byłoby naprawdę niezłe wyzwanie. Pewnie jeszcze byśmy... Bylibyśmy 2, 3, 5 lat wcześniej tak naprawdę i chyba tego byśmy nie uzasadnili, dlaczego tak długo nad tym pracuje. Tak, ta firma to było super wsparcie. W ogóle tak, translacja, to jest niesamowita rzecz, która się wydarzyła. Trzystopniowa translacja, najpierw tak pierwszy etap, który pomaga wyczyścić JBasic w J-Basiku, żeby był trochę bardziej czytelny, koszerny. W ogóle magia, którą zrobił zespół z Belgii, czyli pozbycie się takich konstrukcji, które wszyscy wiemy, że w nowożytnych językach się tego nie robi, takiego jak go'tu, no ale w tamtym języku to był jakby chleb powszedni, co łamało strukturę i w ogóle nasz pomysł na translację, dzięki nim dało się tego pozbyć. Drugi etap translacji to zbudowanie dotneta, takiego dotneta, na który żaden dotnet dewelopery by nie spojrzał, nie zmuszony. Więc trzeci etap to było zrobienie tak, żeby w tym dotnecie było jeszcze więcej dotneta, żeby on był czytelny i był widoczny. No i na końcu efekt mamy taki, że jeśli kod był napisany przez normalnego dewelopera, który troszeczkę wie o kodowaniu, to ładny kod w JBasiku był ładny w dotnecie, a ten brzydki nadal jest brzydki, ale w dotnecie. I to, co jest istotne, bo zastanawiałem się nad tym punktem, teraz nam się dopiero otworzyły drzwi w współpracy z firmami zewnętrznymi, no bo Postgresa zna kilka firm na rynku. Wie, co z tym robić. Dotneta zna kilka firm na rynku. Kubernetes tak samo, no oprócz tego, że mamy świetnych ludzi w banku, którzy się tym zajmują, to tak, teraz mamy możliwość korzystania z ludzi z umiejętności, które są na rynku. No bo w tym starym świecie nie byłoby to możliwe już od kilku lat. Próbowaliśmy, ale nie było już specjalistów.
SPEAKER_00:Z tego co mówił wynika, że właściwie byliście poniekąd skazani na ten ruch, ponieważ pozostawanie w tym wcześniejszym staku technologicznym groziło po prostu stagnacją, brakiem możliwości rozwoju.
SPEAKER_01:To jest to jest ciekawe to, co mówisz, no ale nadal cobol jest i funkcjonuje na świecie. Sam JBasic, tylko że w nowszej formie w Stanach Zjednoczonych jest językiem, który jest rozpoznawany, ale w zupełnie nowszej wersji nie to, co u nas funkcjonuje od 2004 roku. Więc trochę tak, ale jak widać, trochę nie. Moglibyśmy zostać tam, gdzie byliśmy. Ale wtedy pewnie byśmy pracowali w zupełnie innym składzie już.
SPEAKER_00:No tak, to jest też ważna rzecz, prawda, że to deweloperzy tutaj, którzy zazwyczaj są zainteresowani raczej bawieniem się nowymi klockami niż chodzeniem starszy są niezbędni do tego, żeby system mógł iść do przodu. No i też taki szeroko rozumiany deweloper experience mógłby ucierpieć, jeśli faktycznie żadnych nowych technologii do waszego Staku by nie było dodawane. Chciałbym Ci zapytać o metodologie, o takie podejście związane właśnie z praktykami inżynierskimi, z jakimiś podziemne zespoły w tych kolejnych etapach, jakie tutaj podejście zastosowaliście.
SPEAKER_01:Pamiętam, kiedyś w na uczelni byłem na politechnica poznańska, jak jeszcze studiowałem więc dawno temu wpływ pozorom, i było spotkanie ze znamitą firmą, jedną z top firm konsultanckich na A, no i mój profesor, który zajmował się inżynierą oprogramowania, zapytał, to w jakiej metodologii robicie projekty? I tutaj się zupełnie nie dogadali, więc cieszę się, że pytasz o praktyki inżynierskie, które używaliśmy. No bo jak widać metodologia prowadzenia projektu przez 9 lat jest zupełnie nietrafiona, bo try roku myśleliśmy, że skończymy. Tak, jeśli chodzi o praktyki inżynierskie, to były praktyki inżynierskie, my lubiliśmy zmierzyć. Lubiliśmy wiedzieć tak naprawdę, z czym się mierzymy, łącznie z tym, że to mocno wpłynąło na nasze obserwability i opomiarowanie tego, co realnie dzieje się w środowisku produkcyjnym, żebyśmy nie migiełali tych obumarłych tkanek, które trochę troszeczkę bez sensu przenosić. W ogóle walka o jakość, testy automatyczne, automatyzacja, to mówiłem trochę poprzednio przy podkaście, ale to jest niby taka oczywista rzecz, a cały czas trzeba powtarzać, że to jest ważne. Testy, automatyzacja testów, jakość. Zadawać takie trudne pytanie, jak za pięć lat sprawdzić ten moduł, który właśnie napisałeś? Będziesz pamiętał, co tam jest? Niektórzy młodzi mówią, że będą pamiętać, ale oni są młodzi. Ważnym elementem tych 9 lat było to, że my faktycznie co kwartał, co miesiąc, co pół roku wdrażaliśmy na produkcję coś, co już się wygrzewało. Nasz serwer aplikacyjny, który teraz jest podstawą całego całej komunikacji globusneta ze światem zewnętrznym, był wdrożony 7 lat temu. User interface nowy, aplikacja webowa, wdrożona 7 lat temu. Przez te 7 lat było używane oczywiście z różną intensywnością, na początku mniejszą, potem większą, no ale dzięki temu nie było zawału w organizacji, kontrolowaliśmy tą przestrzeń. I to wydaje mi się, że też bardzo ważny element, że planowaliśmy to krokowo. Dzielenie się wiedzą to jest temat, który jest trudny i złożony, ale staraliśmy się to robić, praktykować. Bez tego byłoby ciężko zrobić to, co się udało zrobić, czyli mieć zespół, który po transformacji pracuje w dotnecie i nawet nie zauważył, że mu się coś zmieniło. Są pojedyncze osoby, które tak długo pracowały w tym starym świecie, czują się tak mocno ekspertami, że dla nich to przejście było trudne, ale większość zespołu, która pracowała, po prostu przeszła na nowe technologie, chociażby pod pretekstem pisania testów automatycznych już dawno, dawno temu i dla nich to nie był problem. Na samym końcu taka rzecz, która nas spowodowała w ogóle, że to się wszystko udało, to są testy porównawcze. My to nazywaliśmy tak brzydko po polsku testy komparacyjne, takie blackboxowe testy i rozwiązanie problemu, jak przetestować jakość w systemie, który jest tak mocno współbieżny, jakim jest system bankowy, jak to zrobić na danych produkcyjnych. Nam się udało, udało się rozwiązać tak naprawdę te zależności i zrobić to w ten sposób, żeby te testy porównawszy tych 600 procesów, które działają w trakcie dnia w systemie, żeby były miarodajne i żeby pokazać, że faktycznie to zachowuje się bit do bita tak samo jak w starej technologii. I to jest chyba w ogóle podstawa tego projektu. W ostatniej fazie oczywiście mieliśmy super project management, który pociągnął temat, bo to już nie była tylko i wyłącznie synchronizacja pracy na poziomie 20 osób, tylko tak jak mówiłem, ten zespół ludzki, który zajmował się tym wszystkim, był dużo, dużo szerszy. Ale tak, to są te podstawowe zasady, mierzenie. Staraliśmy się też, to jest istotne, budować te strumienie prac, które toczyły się równolegle w taki sposób, żeby one od siebie mocno nie zależały, żeby one były w stanie pracować w sposób ciągły, bez czekania na innych w dłuższej perspektywie czasu i to jest coś, co faktycznie spowodowało, że nie musieliśmy rozwiązywać zależności między tematami i zadaniami, no i na końcu się udało. Mamy nowy system w dotnecie o nowej platformie.
SPEAKER_00:Ta współpraca człowieka z technologiem zespołu deweloperskiego z technologią zazwyczaj działa w dwie strony. Deweloperzy dokonują wyboru technologii tam, gdzie oczywiście mogą, stosują te praktyki, które technologia nie daje, ale zazwyczaj ta pętla feedbacku działa też w drugą stronę, czyli ten dobór narzędzi inżynierskich wpływa na zespół, na jego kulturę pracy, na takie codzienne praktyki. Czy zaużyliście coś podobnego na przestrzeni tych lat?
SPEAKER_01:Razem z nowymi ludźmi, razem z nowymi możliwościami, razem z pojawieniem wśród metach faktycznie ta asymilacja nowoczesnych metod, narzędzi znacząco się zwiększyła, bo ona w ogóle się wydarzyła, bo w starym świecie to był taki dylemat, czy używać Notwat, czy jakiegoś innego edytora tekstu, nic więcej tam się nie działo. Ewentualnie czy używać takiego klienta telnet albo innego. W nowym świecie faktycznie dużo więcej możliwości. Nie mówię już o tym, co się jest w dotnecie typu dotrace i pokrycie kodu testami. To są w ogóle magia, która teraz mamy po prostu pod ręką i możemy z niej korzystać. Ale nawet takie najprostsze rzeczy, to jest istotne, jak debagowanie. To jest coś, co zatrybiło w ludziach, którzy do tej pory działali w tylu Chaanalisa. Czyli patrzyli na kod tak długo, aż kod się poddał i powiedział, gdzie ma błędy. No teraz można to zrobić zupełnie inaczej. Może to jest trochę mniej cierpliwe, może to jest mniej profesjonalne zdebowanie tego 50 razy, aż w końcu się znajdzie błąd, ale za to bardziej efektywne. I jakby to jest ważne, to my trochę się do tego szykowaliśmy jeszcze przed projektem, no bo nasze zespoły były tak skonstruowane, że to nie był zespół, który zajmował się tylko i wyłącznie starą technologią i tylko tam był ekspertem. Mieliśmy zespoło, które zajmowało się i systemem centralnym, i systemami naukami. który były pisany w Dotnetzie lub w Ceplusie, więc już był ten miks z kili umiejętności, który spowodował, że to nie było taka totalna manipulacja duszami ludzkimi, że teraz Dotnet i teraz wpatrujcie się w obrazek. Nie to było przygotowane. Większość wskoczyła na tego nowego konia bardzo szybko, bo wiedzieli, z czym to się jest, z czym to się wiąże, nie bali się. I potem już ta transformacja w zespołach poszła płynnie.
SPEAKER_00:Bank to oczywiście część IT, ale również część biznesowa, no i musi dochodzić do takiej codziennej współpracy tych dwóch części. Jak ten biznes tak w cudzysłowie postrzega, postrzegał projekty Houston, co dzięki niemu zzyskał?
SPEAKER_01:No to jest dobre pytanie. W sumie to najpierw byłoby zadać je biznesowi. Ale moja perspektywa tego jest taka uproszczona, bo przez wiele lat biznes nie czuł ciężaru tego projektu. No bo my wzbogacaliśmy Developer experience, poprawiliśmy swoje rejestwo, budowaliśmy wiedzę o systemach, robiliśmy testy automatyczne, to tak bezpośrednio tego biznes nie odczuwał. No może jakość się podnosiła tego wszystkiego. Potem był ten etap, kiedy wyminaliśmy UI-a i wtedy był opór przed zmianą. Klasyczny opór przed zmianą jest nowy. Wygląda tak samo, a jest nowe, więc może trochę bez sensu z tego korzystać. Ale jako, że to zaczęło się wcześnie, więc przeszliśmy przez ten opór i mieliśmy wszystkich na pokładzie. W momencie, gdy robiliśmy Big Bang, ta współpraca z biznesem, którą mieliśmy na piętrze, ten dzień zero, który obserwowaliśmy, to była piękna synergia pracy ludzkiej. Biznes IT, jakby te granice się zacierały, to tak głupio brzmi teraz biznes IT. Wszyscy trzymali za nas kciuki, wszyscy wiedzieli, że to jest potrzebne, że to jest ważne. Może dlatego, że były te wstrząsy przypowiadające, może dlatego, że to, co jest przed nami, to jest olbrzymie wyzwanie, które bez nowej platformy stare to nie dałoby się zrobić. Więc myślę, że i tak słyszałem zaprzyjaźnionych kolegów z biznesu, że bardzo dobrze zrobiliśmy to, porę skończyliśmy, bo teraz możemy z przytupem ruszyć dalej.
SPEAKER_00:Cieszę się bardzo, że takie też jest odbiór, bo to jakby nie było pokazuje, że był sens, ale też dowiezienie się liczy i to, co na końcu zrealizowaliście, jest wartościowe. Pora chyba zapytać o lekcje wyniesione z tego wielkiego projektu platformingowego dla Was jako inżynierów, też dla osób zarządzających teamami inżynierskimi, co byś mógł tutaj wymienić?
SPEAKER_01:To jest dużo elementów, które są oczywiste dla inżyniera. Trochę tak jak, warto robić testy automatyczne. Niby wszyscy wiedzą, ale tak różnie to wychodzi. Ale po co ty robimy testy automatyczne? Ja już kilka razy to mówiłem u nas w zespole, jakże nasze życie byłoby prostsze, gdyby wszystko, co robiliśmy przez ostatnie 20 lat, miało swoje testy automatyczne. To nie byłby replatforming, tylko zrobilibyśmy kolejny refactoring systemu. Nie, tutaj trzeba było zrobić bardzo dużo, bardzo wiele. No i niby taki lesson learned, ale o którym trzeba cały czas mówić, że tak właśnie mniej więcej, między innymi z tego powodu warto mieć te testy. To mierzenie, inżynierskie mierzenie, postawa inżynierska to jest coś, co jest bardzo ważne i chyba to, że przez 9 lat przesuwaliśmy projekt i koniec, nauczyło takiej cierpliwości i to jest coś, co jest chyba ważne na każdym poziomie cierpliwości, no bo to nie jest aplikacja do urlopów. No jak nie będzie działać, to nie będzie działać, no nikt nie weźmie Europą. Dużo bardziej poważne aspekty wchodzą w grę. I tak samo chyba ważny to jest z perspektywy zarządzających, że to był projekt, który wyrwał się wszelkim ramom, bo my nie dość, że trwaliśmy 9 lat, to jeszcze 9 lat bez zmiany nazwy, bo to jest taka sztuczka, czasami zmienić nazwę projektu i wtedy będzie wiadomo, że nowy projekt, dwa lata trwa. I utrzymać ten kierunek, wizję i kurs przez całe te 9 lat, mimo różnych zmian okoliczności przyrody, a więc znowu, niby taka rzecz oczywista. Ta wizja, mega ważna, dobrze ją narysować, nazwać, tak żeby wszyscy z tym koralowali. No i iść w tą stronę. Z rozwagą i rozsądkiem, nie zawsze po trupach był moment deadline, bo się kończy rok i kończy się finansowanie. Ja tu bardzo szanuję moich szefów, którzy mieli tą otwartą głowę i widzieli sens prowadzenia tego projektu dalej, dalej. No i to też dzięki temu udało się to wszystko domknąć, mimo tego przeciągnięcia w czasie. I to są chyba te najważniejsze rzeczy, bo tych technologicznych lekcji, które wyciągnaliśmy, jak robić software, jak go komponować, jak budować repozytoria, że automatyzacja, to jest bardzo dużo rzeczy, o których już nie myślimy, bo to jest trochę tlen, to jest na co dzień. Ale jeśli chodzi o duży projekt, duży projekt transformacyjny, to jest chyba najważniejsze.
SPEAKER_00:Czy ten projekt jest oficjalnie uznany jako zakończony, czy też może w jakiejś formie będzie jeszcze kontynuowany?
SPEAKER_01:Oficjalnie projekt zakończył się, budżet został zamknięty, jeszcze rok budżetowy się kończy, więc ale generalnie projekt zakończyliśmy. W zasadzie tak można sobie pomyśleć, że to nie był projekt, no bo projekt to znaczy jakąś różmapę, jakiś Majestone, to był trochę rozwój produktu, i teraz tak do tego podchodzimy, że teraz będziemy ten produkt, jakim jest nowa platforma, utrzymywać, będziemy go rozwijać, tak, żeby zespoły, które na tym produkcie budują rozwiązania już biznesowe, żeby mogły działać efektywnie i mogły działać sprawczo.
SPEAKER_00:Zostaje mi chyba tylko pogratulować tak dużego sukcesu. Z tego co mówiłeś, naprawdę dużo energii widać, że ten twój zespół, oczywiście przy współdziale całej firmy, zostało tutaj włożone. Z pewnością wiele cennych lekcji wyciągniętych, no i dobrze jest myślę o tego typu dużej zmianie technologicznej mówić, bo to też jest inspiracja pewnie dla innych, więc cieszę się bardzo, że mieliśmy po raz kolejne okazję tutaj porozmawiać. No i bardzo Ci dziękuję za to spotkanie.
SPEAKER_01:Dzięki.
SPEAKER_00:Powiedz jeszcze, proszę, na koniec, gdzie się możemy znaleźć w internecie.
SPEAKER_01:Pewnie się nie zmieni względem poprzedniego nagrania na Linkedinie i chyba głównie tam. Wszystkie inne miejsca są prywatne, więc prywatnie możecie mnie znaleźć w jeziorze, bo lubię pływać i to jest coś, co się zmieniło w ostatnim czasie. Nawet jak jest zimno, więc prywatnie szukajcie mnie w jeziorach.
SPEAKER_00:Super, to tam oczywiście zapraszamy. Link do Linkedina i do naszej wcześniejszej rozmowy również znajdziecie w opisie do tego odcinka. Jeszcze raz bardzo dziękuję, do usłyszenia. Cześć. Cześć, dzięki. To już wszystko na dzisiaj. Jeśli chcesz więcej takich rozmów, archiwum czeka. Tam też dzieją się ciekawe rzeczy. Masz pytania, przemyślenia? Możecie ze mną skontaktować na social mediach albo mailowo na Krzysztof Małpa.porozmawiajmyit.pl. Nazywam się Krzysztof Kiempiński, a to był odcinek podcastu porozmawiajmy IT o tym, jak bank wdraża nową platformę i adaptuje nowe technologie. Dzięki za wspólnie spędzony czas. Do usłyszenia w kolejnym odcinku. Cześć!
