Poza schematem Jiry. Jak wygląda rola Technical Team Leadera w nowoczesnych projektach ubezpieczeniowych?

Masz dość ślepego „domykania ticketów” w Jirze i sztywnego realizowania z góry narzuconych user stories? Comarch Digital Insurance wychodzi poza utarte schematy. To nowoczesny, globalny produkt tworzony w duecie Java + Angular, gdzie prawdziwa inżynieria zaczyna się tam, gdzie kończą się tabelki w Excelu. Przeczytaj wywiad z Robertem Błaszyńskim – starszym programistą w Comarch – i zobacz, jak firma buduje unikalną kulturę techniczną. To środowisko, w którym każdy programista zyskuje realną przestrzeń na myślenie architektoniczne, spłacanie długu technologicznego i konstruktywne kwestionowanie status quo. Sprawdź, jak wyglądają kulisy pracy w zespole stawiającym na inżynierski pragmatyzm i przekonaj się, dlaczego warto dołączyć do Comarch.

Tytuł wywiadu sugeruje, że rola Tech Leadera w Comarch wykracza daleko poza standardowe zarządzanie taskami. Jak ta wolność od „schematu Jiry” przekłada się na Twoją codzienną pracę z Javą i Angularem w sektorze ubezpieczeń? Gdzie kończy się tabelka w Excelu, a zaczyna prawdziwa inżynieria? 

W pełni zgadzam się z tym stwierdzeniem. Tech Leader w naszym zespole to ktoś znacznie więcej niż menedżer zarządzający zadaniami. Wolność od „schematu Jiry” oznacza dla mnie elastyczność i realną przestrzeń na myślenie architektoniczne, a nie tylko bezrefleksyjne egzekwowanie z góry narzuconego planu. Projekty, które realizujemy, to duże wyzwania inżynieryjne. Rozwijamy wspólny produkt, który później wdrażamy u różnych klientów – to wymusza tworzenie kodu niezwykle elastycznego i modularnego.

Prawdziwa inżynieria zaczyna się wtedy, gdy zamiast ślepo realizować kolejne user stories, siadamy i analizujemy, jak dana zmiana wpłynie na system w szerszej perspektywie – nie tylko w kontekście konkretnego wdrożenia, ale całego produktu. Oczywiście zdarzają się momenty, gdy gonią nas terminy i musimy pójść na kompromis. Na szczęście pracujemy w Scrumie, co pozwala nam budować system inkrementalnie i świadomie zarządzać długiem technologicznym. Dzięki temu, nawet jeśli dziś musimy dostarczyć coś szybciej, w kolejnych sprintach znajdujemy przestrzeń, by ten dług spłacić i dopracować architekturę. I to jest właśnie ten moment, w którym tabelka w Excelu musi ustąpić miejsca inżynierskiemu pragmatyzmowi.

Kiedy Team Leader przestaje programować, często traci autorytet techniczny w zespole. Jak bycie blisko kodu pomaga Ci podejmować kluczowe decyzje architektoniczne?

W branży IT często spotyka się pojęcie Ivory Tower Architect – architekta z wieży z kości słoniowej, który projektuje systemy w całkowitym oderwaniu od rzeczywistości. Tworzenie architektury wyłącznie w oparciu o suchą teorię czy aktualnie modne trendy – czyli tzw. hype-driven development – prowadzi donikąd. W idyllicznym świecie, z nieograniczonym budżetem i czasem, taka czysta teoria być może by się obroniła, ale realia rynkowe są zgoła inne.

Bycie blisko kodu i samego procesu tworzenia oprogramowania pozwala mi natychmiast weryfikować wszelkie pomysły. Pracując na żywym organizmie, od razu widzę, jak decyzje architektoniczne wpływają na aplikację, którą sukcesywnie dostarczamy klientom. Rozwijamy wspólny produkt, więc każdy błąd projektowy uderza w nas rykoszetem przy kolejnych wdrożeniach. Utrata kontaktu z kodem oznacza dla Tech Leada utratę intuicji technicznej oraz wyczucia tego, co jest realne do wykonania w założonym czasie, a co pozostaje jedynie pobożnym życzeniem.

Comarchowy zespół Financial Services/Insurance czasem kojarzy się z systemami legacy. Jak jako Tech Lead dbasz o to, aby Wasz stack technologiczny nadążał za nowoczesnymi standardami, a praca nie polegała tylko na „utrzymywaniu staroci”?

To chyba największy i najbardziej krzywdzący mit na temat naszej branży. Owszem, wchodząc do dużych organizacji, zderzamy się z ich zastaną rzeczywistością i napotykamy systemy działające od wielu lat. Warto jednak doprecyzować, że jest to dług technologiczny klienta, a nie nasz. Nasz codebase pozostaje czysty, a ze starym światem łączą nas wyłącznie protokoły wymiany danych, przez co archaiczne rozwiązania pojawiają się u nas wyłącznie jako specyficzne punkty integracyjne. Naszym głównym zadaniem jest przeprowadzanie kompleksowych transformacji cyfrowych oraz wymiana przestarzałych narzędzi na nowoczesne systemy z przyjaznym interfejsem użytkownika, których zakres bywa bardzo szeroki – od wsparcia sprzedaży, przez obsługę posprzedażową, aż po zarządzanie szkodami.

Utrzymanie świeżości tak dużego ekosystemu wymaga ogromnej systematyczności, o którą dbamy na dwa sposoby. Z jednej strony inwestujemy w inżynierski „czas dla siebie” – w każdym sprincie staramy się wygospodarować przestrzeń na zadania czysto techniczne, kiedy odcinamy się od presji biznesu i skupiamy się na samym rzemiośle, dając programistom realny komfort poprawiania tego, co ich na co dzień irytuje w kodzie. Z drugiej strony kierujemy się zasadą wspólnego produktu i wspólnego zysku. Nasz produkt to żywy organizm i suma doświadczeń wielu zespołów. Pracując dla różnych klientów w sektorze ubezpieczeń, na co dzień zderzamy się z najróżniejszymi wyzwaniami biznesowymi i integracyjnymi. Zamiast jednak wymyślać koło na nowo i zamykać się w silosach, stale dzielimy się tymi lekcjami i równie świadomie zarządzamy samą technologią. Podbijanie wersji frameworków nie dzieje się u nas z doskoku, ponieważ prowadzimy osobną roadmapę techniczną, planowaną z dużym wyprzedzeniem. Wszystkie usprawnienia wdrażamy ewolucyjnie, małymi krokami, dzięki czemu produkt rośnie stabilnie, a technologia stale nadąża za bieżącym stanem rynku.

W systemach finansowych frontend to już dawno nie jest tylko „ładna nakładka” – to potężne aplikacje procesowe, które muszą przetwarzać skomplikowane formularze, walidacje i ścieżki użytkownika w czasie rzeczywistym. Jakie są największe wyzwania przy budowaniu tak złożonego frontendu w Waszych projektach i jak dbacie o to, by kod Angulara pozostawał czysty, modułowy i łatwy w utrzymaniu? 

Masz absolutną rację – formularze w aplikacjach ubezpieczeniowych bywają gigantyczne, a liczba zależności i walidacji potrafi przytłoczyć. Gdybyśmy pisali ten kod bez jasnej strategii, szybko utonęlibyśmy w długu technicznym. Naszym sposobem na to jest rozbijanie struktury frontendu na niezależne pluginy domenowe. Taka izolacja sprawia, że poszczególne moduły stają się klockami, którymi możemy swobodnie żonglować – podmieniać je, dokładać nowe funkcjonalności lub po prostu wyłączać te, które dla danego klienta są niepotrzebne. Staramy się również, aby każdy widok i formularz powstawał jako maksymalnie generyczny element produktu, gotowy do reużycia w kolejnych wdrożeniach. Porządek w architekturze utrzymujemy dzięki rozbudowanej bibliotece mniejszych i większych komponentów logicznych. Co kluczowe, ten ekosystem żyje nie tylko w samym repozytorium, ale również w procesie analitycznym. Analitycy oraz zespół UX/UI doskonale go znają, dzięki czemu późniejszy proces wytwarzania oprogramowania staje się o wiele prostszy, a końcowy rezultat jest w pełni spójny. 

Zespół Insurance to specyficzne środowisko – z jednej strony mamy zaawansowaną logikę taryfikacji, systemy polisowe i masę integracji (często z systemami legacy), a z drugiej strony potrzebę błyskawicznego działania. Jak od strony backendowej (Java) i architektonicznej projektujecie system, by zachować elastyczność biznesową, nie generując przy tym długu technicznego, który utopiłby zespół za pół roku? 

Na backendzie stosujemy dokładnie tę samą filozofię co na frontendzie – dzielimy odpowiedzialność w ramach odrębnych, niezależnych modułów. Świadomie postawiliśmy tutaj na modularny monolit, a ta decyzja wynika z czystego pragmatyzmu. Rozwijamy wspólny produkt, który później instalujemy u różnych klientów – w takim modelu monolit gwarantuje nam o wiele prostsze, szybsze i bardziej przewidywalne wdrożenia. Z drugiej strony, dzięki silnej modularyzacji kodu, nie tracimy zalet związanych z podziałem pracy. Nasz system składa się z wielu autonomicznych komponentów, co pozwala nam oddać pełną odpowiedzialność za poszczególne elementy biznesowe dedykowanym, wyspecjalizowanym zespołom. W efekcie zyskujemy to, co najlepsze z obu światów: prosty deployment, a jednocześnie porządek w kodzie i pełną niezależność deweloperów.

Projekty ubezpieczeniowe i finansowe bywają niezwykle skomplikowane pod kątem logiki biznesowej. Jak na co dzień wygląda Twoja współpraca z analitykiem biznesowo-systemowym (BSA)? Dlaczego silny analityk to „być albo nie być” dla Fullstack Developera w takim projekcie?

Współpraca z analitykami to dla nas chleb powszedni, a nie kwestia okazjonalnych spotkań. Silny BSA to dla dewelopera absolutny fundament. Pracujemy w większości dla klientów zagranicznych, co oznacza, że zderzamy się z inną kulturą biznesową oraz specyficznymi uwarunkowaniami prawnymi i rynkowymi, których jako programiści nie musimy – a często wręcz nie mamy szans – znać od podszewki. Analityk jest dla nas łącznikiem z tamtym światem, który precyzyjnie mapuje problemy klienta na konkretne wymagania systemowe.

Praca w sprincie opiera się u nas na ciągłej, dwukierunkowej wymianie myśli. Na refinementach wspólnie analizujemy zakres zadań i przygotowujemy wyceny. Bierzemy aktywny udział w tworzeniu dokumentacji i mamy realny wpływ na ostateczny kształt wdrażanych rozwiązań. Jeśli dostrzegamy, że z inżynierskiego punktu widzenia coś da się uprościć, przyspieszyć lub po prostu zrobić lepiej – otwarcie się tym dzielimy. Reagujemy tak samo, gdy widzimy ograniczenia technologiczne – zamiast rzucać suchym „nie da się”, wspólnie z BSA szukamy alternatywnego rozwiązania, które w pełni zadowoli klienta.

Czy możesz opowiedzieć o jakimś ciekawym wyzwaniu technologicznym lub architektonicznym, z którym Twój zespół mierzył się ostatnio? Co tam „pod maską” najciekawiej zagrało w duecie Java + Angular?

Jednym z większych i bez wątpienia najciekawszych wyzwań była migracja technologiczna z AngularJS na Angulara. Początki naszego produktu sięgają czasów, gdy Angular 2+ jeszcze w ogóle nie istniał na rynku. Przez długi czas warstwa wizualna naszej aplikacji opierała się na starym AngularJS, co z czasem zaczęło nas blokować zarówno pod względem wydajności, jak i deweloperskiego komfortu. Kto choć trochę orientuje się w ekosystemie frontendu, ten wie, że między tymi frameworkami jest na tyle fundamentalna różnica, że nie da się tego procesu przeprowadzić prostym sposobem ani automatycznym skryptem – szczególnie w aplikacji o tak ogromnej skali jak nasza.

Rozwiązaniem okazało się stworzenie aplikacji hybrydowej. Przez pewien czas pod maską współistniały i komunikowały się ze sobą komponenty z obu tych światów. W tym wymagającym środowisku sukcesywnie przepisywaliśmy kolejne widoki i całe ścieżki procesowe. Ostatnim, najbardziej ekscytującym etapem było przepisanie core’owego silnika aplikacji. Dopiero po zamknięciu tego kroku mogliśmy uruchomić system oparty w stu procentach na nowym Angularze. To ostatecznie odblokowało pełen potencjał technologiczny frontendu i otworzyło nam drzwi do wykorzystania wszelkich nowoczesnych rozwiązań dostępnych na rynku.

W finansach kluczowe są wydajność, bezpieczeństwo i skalowalność. Jak jako „grający kapitan” pilnujesz jakości kodu (code review, dobre praktyki), żeby system wytrzymał próbę produkcji, a zespół nie frustrował się długiem technicznym?

W sektorze finansowym jakość kodu to fundament bezpieczeństwa i stabilności na produkcji. Jako grający kapitan dbam o to, by code review każdego merge requesta był u nas normą. Traktujemy je jednak jako punkt wyjścia – to świetne narzędzie do dzielenia się wiedzą i propagowania dobrych praktyk, a nie tylko do czepiania się formatowania.

Mocno wspiera nas technologia. Powtarzalne czynności automatyzujemy za pomocą statycznej analizy kodu w Sonarze i linterów frontendowych. Idziemy z duchem czasu – wdrożyliśmy agenta AI, który robi wstępny przegląd merge requestów i wyłapuje błędy, zanim sami do nich usiądziemy.

Praktykujemy również „deweloperski refinement” – spotkanie w gronie programistów, podczas którego rozwiązujemy techniczne przeszkody, zanim ruszą prace. Poza tym uruchomiliśmy program wymiany wiedzy dla każdego, kto tworzy Comarch Digital Insurance. To przestrzeń do otwartego dialogu, dyskusji o nowinkach i nauki od siebie nawzajem.

Mówi się, że słaby manager rządzi Jirą, a dobry – wspiera ludzi. Jak odczarowujesz te nieszczęsne „taski w Jirze”, żeby zespół czuł, że buduje realny produkt, a nie tylko domyka tickety na daily?

Na daily nie odhaczamy bezmyślnie listy obecności i nie traktujemy tego spotkania jako „spowiedzi” z postępów w pracy. Od sprawdzania statusów mamy tablicę w Jirze – wystarczy na nią spojrzeć, żeby wiedzieć, kto czym się zajmuje. W trakcie daily skupiamy się na czymś zupełnie innym: weryfikujemy, w którym miejscu jesteśmy, sprawdzamy, czy ktoś nie utknął przy trudniejszym wyzwaniu i zastanawiamy się, jak jako zespół możemy dowieźć cel sprintu.

Prawdziwe poczucie budowania realnego produktu przychodzi jednak dopiero z momentem wdrożenia. Kiedy widzisz satysfakcję klienta, który zaczyna korzystać z systemu i dostrzega, jak nasza praca ułatwia mu codzienne operacje, pojawia się ogromna duma. To właśnie sukcesy na produkcji i zadowolenie użytkowników końcowych udowadniają nam, że tworzymy coś naprawdę wartościowego, a Jira to tylko cyfrowy pomocnik, a nie cel sam w sobie.

Jakie cechy – poza świetnym skillem w Javie czy Angularze – sprawiają, że programista idealnie odnajduje się w Twoim zespole? Na co zwracasz uwagę, gdy do Was dołącza ktoś nowy? 

Świetnego programowania w Javie czy Angularze można się po prostu nauczyć, ale cechy charakteru to zupełnie inna bajka. Poza umiejętnościami technicznymi kluczowe są dla nas wartości takie jak proaktywność, kreatywność, a przede wszystkim – krytyczne myślenie.

Kiedy dołącza do nas ktoś nowy, nie oczekuję, że po prostu usiądzie przed monitorem i zacznie bezrefleksyjnie zamykać zadania według utartych schematów. Nowy członek zespołu to dla nas ogromny kapitał w postaci świeżego spojrzenia. Niezwykle cenna jest sytuacja, w której osoba z czystą głową wchodzi do projektu i zaczyna podważać rzeczy, które od lat funkcjonują u nas w określony sposób. Zdrowe zakwestionowanie statusu quo nierzadko staje się impulsem do świetnych zmian. Szukamy ludzi, którzy chcą mieć realny wpływ na swoje środowisko pracy, a nie tylko bezkonfliktowo dopasowywać się do otoczenia.

Gdybyś miał zachęcić ambitnego Fullstacka lub Analityka, który waha się, czy aplikować do zespołu Insurance – co powiedziałbyś mu prosto z mostu jako praktyk i programista?

Prosto z mostu? Zapraszamy, przyjdź i przekonaj się sam, jak to u nas wygląda! Tworzymy bardzo ciekawe projekty dla międzynarodowych klientów i dajemy realną przestrzeń do rozwoju w otoczeniu nowoczesnych technologii. Jeśli szukasz zespołu ze świetną kulturą techniczną, to lepiej trafić nie mogłeś.