Co robi architekt w branży IT – wywiad z Krystianem Jarzenko

Na architektach w branży IT spoczywa duża odpowiedzialność – nie tylko pod kątem stanu projektu, lecz również w kwestii dobra całego realizującego go zespołu. O kulisach pracy na tym stanowisku opowiada Krystian Jarzenko – Lead Architect oraz Co-head w Hued.me.

Jak rozpoczęła się Twoja historia w Hued.me?

Jeszcze przed pandemią, pod koniec 2019 roku. Właśnie wtedy wraz z Szymonem rozmawialiśmy na temat rozpoczęcia działalności dotyczącej szkoleń w branży IT, pomagających w zarządzaniu zespołem. Czyli: definiujemy problem i proponujemy rozwiązania, które ułatwią pracę i komunikację. W ten sposób projekt funkcjonuje płynnie i spełnia oczekiwania klienta.

Ta początkowa idea szybko ewoluowała – zmieniliśmy perspektywę i skupiliśmy się na outsourcingu, którego zostałem menadżerem. Ponadto, jako Lead Architect jestem odpowiedzialny za część techniczną naszych projektów

Czym dokładnie zajmuje się architekt w branży IT?

Pomagam zrozumieć skalę projektu – zarówno w kontekście potrzeb biznesowych klienta jako menadżer, jak i w kwestii wymagań technologicznych, jakie musimy spełnić jako zespół odpowiedzialny za warstwę IT. Działam więc na dwóch płaszczyznach, w których rola architekta sprowadza się do zagwarantowania, że dostarczane przez nas rozwiązania będą uszyte na miarę potrzeb naszego klienta. 

Na podstawie doświadczenia zdobytego w realizowanych przeze mnie projektach wspieram zespół w doborze technologii wykorzystywanej w realizacji danego projektu. Pomaga to w zmniejszeniu kosztów lub w wytłumaczeniu klientowi, jakie rezultaty przyniesie zastosowanie większych nakładów pracy. Przykładowo, wyjaśniam, jak użycie chmury Azure umożliwi łatwiejszy dostęp do aplikacji bez względu na region świata – dzięki niej możemy dużo łatwiej i prościej skalować nasze rozwiązania, co w efekcie usprawnia proces prezentowania i przetwarzania danych w wielu lokalizacjach jednocześnie.

A jaka jest Twoja odpowiedzialność jako Co-heada firmy?

Moja praca to przede wszystkim podejmowanie decyzji w kontekście samego funkcjonowania firmy, ukierunkowania jej, wskazania, co robimy dalej i dlaczego, we współpracy z resztą zarządu.

Tu również pojawiają się właśnie kwestie menadżerskie: rozmowa i utrzymanie kontaktu z klientem oraz prowadzenie zespołu wykonującego dla niego zadania. W dużej mierze opieram się więc na metodyce Scrum: ustalam kolejne kroki w ramach realizacji projektu i nadzoruję team w estymowaniu pracy, pilnując, aby planowane funkcjonalności zostały dostarczone na czas. Nie jestem w tych zadaniach sam – przykładowo, często wymieniamy się tymi obowiązkami razem z Adamem, jednym z Co-headów Hued.me. 

Zarządzanie zespołem, w tym dobór pracowników do danego projektu, to duża odpowiedzialność. Na jakiej podstawie jesteś w stanie określać doświadczenie ludzi, z którymi współpracujesz – lub których rekrutujesz?

Dobre pytanie! Odpowiedź na nie brzmi: to zależy.

Zacznijmy od osób, które znam i z którymi pracuję na co dzień. Spędzony z nimi czas pozwala na obserwację: widzę, co poszczególni członkowie zespołu robią, jakie postępy czynią w swojej pracy. Określenie ich poziomu odbywa się w kilku czynnikach. Sprawdzam, czy rozumieją technologię, czy potrafią ją stosować – a jeśli tak, to czy robią to w sposób innowacyjny, czy może przepisują rzeczy, które już powstały i nie dostrzegają możliwości kreatywnego budowania czegoś nowego.

Taka obserwacja pozwala mi określić poziom zaawansowania takiej osoby – natomiast nie jest to jednoznaczne. Istnieje jeszcze wiele innych czynników, np. zrozumienie i analiza kwestii biznesowych projektu. Jeżeli ma on wymagania „XY”, a dostarczone funkcjonalności będą bliższe „Z” i nie pokrywają się w 100% z założeniami projektu, to wpływa to na ocenę danego człowieka. Choć potrafi on działać samodzielnie i napisać naprawdę złożony kod, to klient nie będzie zadowolony z efektu pracy. Taka osoba nie rozumie oczekiwań biznesowych i jest to pole wymagające dalszego rozwoju – ale wiemy już, że mówimy w tym przypadku o mid developerze, nie juniorze.

A kiedy możemy mówić o seniorze?

To lider zespołu, lub kluczowy dla projektu specjalista. Osoba, która ma kompleksową wiedzę i potrafi ją wykorzystać, tworząc nowe rozwiązania, ale nie boi się jednocześnie utrzymywać tych, które sprawdziły się i działają. Często „początkujący” senior chce jedynie tworzyć nowe, zaawansowane funkcjonalności – podobnie z resztą jak mid developer. Nie chcą 10 razy wracać do tego samego, poprawiać coś lub trzymać się jakiegoś kodu. To im nie przystoi – muszą się rozwijać, chłonąć wiedzę i biec do przodu!

Zapominają jednak o tym, że po drodze trzeba zadbać, aby wszystko działało, jak należy. Jeśli gdzieś wkradnie się błąd, to najlepszą osobą do jego naprawienia jest senior musi. Kiedy ktoś spędził już trochę czasu z kodem i pracował nie w jednym lub dwóch projektach, lecz w kilkunastu, to zyskuje tę świadomość. I dalej potrafi się rozwijać – zawsze znajdzie zadania, które będą dla niej wyzwaniem, ale nie boi się, że będzie musiała przez jakiś czas poprawiać to, co istnieje i dbać o zachowanie/przywrócenie porządku.

Należy przy tym pamiętać, że programiści to ludzie o różnych osobowościach – co wyraźnie widać na płaszczyźnie komunikacji. Są developerzy, którym rozmowa przychodzi łatwo, oraz tacy, którzy wolą jej unikać. 

Czym różnią się jedni od drugich w kwestii pracy w zespole projektowym?

Specjalista „niekomunikatywny” jest bardzo dużym plusem dla projektu. Są to ludzie nad wyraz inteligentni, mający zupełnie inny sposób abstrakcyjnego myślenia. Z tego powodu to, co tworzą tacy programiści, choć nie jest łatwo zrozumiałe przez innych, to znacznie przyspiesza proces produkcji oprogramowania – czasem nawet o miesiące. 

Natomiast komunikatywny developer – w szczególności senior – to osoba, która prowadzi zespół. Wciąż jest to specjalista o bardzo dobrych kompetencjach technicznych, jednak jego uwaga skupia się na zarządzaniu. Potrafi wpływać na panujący w zespole nastrój, na charakter współpracy i sposób komunikacji. Rozumie potrzeby zarówno ze strony technologicznej osób, z którymi współpracuje, jak i ze strony biznesowej (managera/klienta).

A Ty? Jako doświadczony developer, z którym z tych 2 typów bardziej się utożsamiasz?

Z drugim, komunikatywnym – choć nie ukrywam, że kod najlepiej pisze mi się w pojedynkę. Jeśli mam stanowisko, na którym siadam i robię swoje, to jestem dużo bardziej produktywny i efektywny w realizacji zadań. Natomiast zazwyczaj wolę samemu nie tworzyć kodu, tylko skupić się właśnie na zarządzaniu pracą zespołu. Ciężko jest łączyć programowanie z byciem menadżerem – te dwie rzeczy są dla mnie mocno rozdzielne.

Z Twojego opisu rodzi się wizja seniora jako programisty-menadżera, który wykorzystuje swoją wiedzę jako mentor.

Tak – i myślę, że właśnie ich brakuje obecnie na rynku. Problemem jest sposób, w jaki wiedza jest teraz przekazywana w projektach. Dzisiaj nikt z nie usiądzie z Tobą na dzień lub dwa, aby wszystko wytłumaczyć. Dzisiaj usłyszysz „Tu masz dokumentację (o ile w ogóle istnieje), a tam masz kod. Przeczytaj, musisz zrozumieć”. Niestety, jest to często sposób, w jaki nowi developerzy uczą się złych praktyk. Nie mają mentora, który wytłumaczy im, dlaczego w danym miejscu coś zostało zrobione w określony sposób. 

A jeśli programista nie ma możliwości pozyskać wiedzy w ten sposób, od doświadczonego developera? Czy w takiej sytuacji istnieją dla niego substytuty?

Są różne metody. Istnieją community, w których możemy zapytać o radę innych programistów. Mamy również projekty takie jak forum Microsoft czy Stack Overflow, na którym znajdziemy odpowiedzi na pytania, jeśli czegoś nie rozumiemy. W końcu, istnieje wiele lokalnych inicjatyw – na przykład koła .NETowe w miastach takich jak Wrocław czy Poznań. Takich społeczności jest cała masa i są one szansą na poznanie bardzo ciekawych ludzi, z którymi można porozmawiać i wymienić doświadczenia – wystarczy tylko poszukać.

Natomiast jeżeli to nie pomaga, jeżeli projekt nie pozwala się rozwijać, to niestety powiem to twardo: jest to moment, w którym czas zmienić projekt. Nie oszukujmy się – specjalista IT w dzisiejszych czasach w ramach pracy w jednej firmie przepracowuje maksymalnie 3-4 lata. Przyczyny odejścia mogą być różne, a jedną z nich może być to, że czuje się on już „zasiedziały”. Projekty realizowane w ramach danej organizacji są często podobne. Technologicznie opieramy się więc cały czas o to samo, korzystamy z tego, co wcześniej zbudowaliśmy.

Jeśli więc czujemy się znużeni taką sytuacją, musimy zapytać samych siebie „co dalej?”. I jeżeli już czujemy, że stoimy w miejscu, a chcemy się rozwijać, to należy podjąć odpowiednie kroki w tym celu. Rozwój w branży IT sprowadza się do tego, że im więcej projektów przepracujemy w swoim życiu, tym więcej doświadczenia złapiemy, pracując w różnych środowiskach, z ludźmi o odmiennym podejściu. To dywersyfikuje nasze portfolio i pozwala dużo lepiej zrozumieć jakiś kod czy potrzeby biznesowe różnych sektorów, z którymi wcześniej miało się do czynienia.

Stagnację w naszej branży można porównać do tańca z tym samym tancerzem przez całe życie. Można mieć jednego partnera lub partnerkę do tańca. Kiedy jednak będziemy chcieli zatańczyć z drugą osobą, to okazuje się, że nie umiemy – bo dotychczas byliśmy nauczeni tylko jednego schematu, bez którego się gubimy. I z programowaniem często bywa bardzo podobnie.