Praca w IT

Jaki powinien być Team Leader/Architekt?

team leader opowiada o projekcie

Pracowałem z wieloma architektami i na podstawie tych doświadczeń przygotowałem pięć typów typy osobowościowych. Postanowiłem je opisać i podsumować, który według mnie jest najlepszy. Nałożyłem sobie filtr, by opisać tylko te typy, które koniec końców dowiozły projekt na produkcję. 

Pierwszym architektem będzie 45-letni deweloper, który przez pracę od 20 lat w jednej firmie awansował na stanowisko managera zespołu i architekta systemowego. Kiedyś stworzył aplikację, która działa do dziś, firma dała mu pieniądze na powiększenie zespołu i jej przepisanie. Tego architekta cechuje słomiany zapał, słabe rozumienie wzorców projektowych i uwielbia komplikować aplikacje. Nie słucha swojego zespołu, bo z reguły wie najlepiej. 

Tworząc architekturę wysoce złożoną i podważa istnienie rozwiązań rynkowych. Woli tworzyć własne narzędzia zamiast używać gotowych np. do migracji danych. Prawda jednak jest taka, że jego aplikacja posiada w 90% zbędny kod, który najlepiej byłoby wywalić, ale z różnych względów nie można tego zrobić (zakłada takiego vendor locka). Tego architekta cechuje także bardzo dobra pamięć, umysł analityczny i umiejętność przekonywania osób, które finansują projekt, że to właśnie jego pomysły mają sens. Dzięki jego działaniu i podejściu architektonicznego potrzeba zespołu siedmiu senior developerów, aby ogarnąć proponowaną aplikacje. 

Uwielbia Enterprise Architect rysując klocki swojej aplikacji. “Zaletą” – choć to zdecydowanie nie zaleta – pracy w jego zespole jest to, że nie trzeba myśleć nad rozwiązaniami. W końcu zdaniem tego team leadera właściwa droga jest tylko jedna.W jego zespole nie trzeba myśleć zawsze jest jedna droga zrobienia.

Drugim architektem będzie 35-letni manager, który stworzył ciekawy produkt. Uwielbia Steve’a Jobsa i jest osobą, która lubi czytać o nowościach. Decyzje w jego zespole zawsze podejmuje po konsultacji z trzema senior developerami. Nigdy sam nie podejmował decyzji przed upewnieniem się, że wybrane rozwiązanie jest aktualnie najlepsze. Pedant, jeśli cokolwiek wyświetlało się o milimetr inaczej niż planował, powodowało to jego zdenerwowanie. Zawsze schludnie ubrany, włosy idealnie przystrzyżone (żona chyba nawet fryzjerką była), bywał czasem chamski (miał nerwicę i przez nią problemy sercowe), ale jak kolega miał operację na kolano, to za czasów gdy nie było pracy zdalnej, załatwił mu pracę zdalną, aby tylko miał pieniądze. Dla swojego zespołu był w stanie poruszyć niebo i ziemię.

Trzeci typ architekta będzie w wieku 33 lat. Osoba genialna, introwertyczna. Nie dba o architekturę aplikacji, bo według niego powinna tylko działać. Stworzony projekt miał mieszaną architekturę, co nie wszystkim się podobało. Bywał nawet publicznie za to krytykowany. Pomimo tego, kiedy pojawiały się jakieś problemy można było na nim polegać. Jak czasem poruszaliśmy tematy łamigłówek on znał odpowiedź. Miał problem z radzeniem sobie z krytyką, wtedy po prostu się nie odzywał. Następnie przeczekał i dalej wracał do zarządzania i rozdzielania zadań. Człowiek bardzo sympatyczny, serdeczny i widać było od razu, że jego mózg działa na zupełnie innym poziomie niż reszty zespołu. Mimo że technologicznie nie był najmocniejszy w zespole to potrafił również dogadać się z managerem, choć był to najgorszy menager jakiego można sobie wyobrazić.   

Czwartym architektem będzie 30-letni mężczyzna, który uwielbiał SharePointa i jedną z tworzonych nakładek do niego. W tym projekcie zajmowałem się tworzeniem migracji danych pomiędzy systemami i raportami SSRS. Pan X nie był osobą wymagającą, co czasem przysparzało mu sporo problemów. Jeden z analityków to wykorzystywał i zawsze coś za późno wziął od klienta albo nie przetestował aplikacji, czy działa i szedł do klienta potem musiał czarować. 

Przez te opóźnienia zdarzała się praca na nocce, ponieważ analityk zawalił i trzeba było wracać do tematu w nocy, aby klient miał działającą aplikację. Jednak Pan X był osobą miłą, koleżeńską i dbającą o swój zespół.

Piątym architektem jest Pan S, czyli osoba dbającą o aktualną wiedzę. Zawsze otwarty na dyskusję odnośnie rozwoju aplikacji. Dodatkowo wiedząc, że pracuję z Seniorami pozwala podejmować seniorom decyzje odnośnie architektury, ale jak coś mu się nie podoba, od razu o tym powie. Pan S nigdy mnie nie zdenerwował, myślę, że to dlatego, że ma miękkie umiejętności na najwyższym poziomie.

Podsumowując, oprócz pierwszego architekta, który potrzebował kodera a nie programisty, ale nawet on zadowolił managera wdrażając aplikacje, to wszystkie powyższy typy moim zdaniem są wspaniałe. Nie miałbym problemu, gdybym dalej z nimi współpracował. Gdybym miał wyróżnić najważniejszą cechą architekta systemowego to byłaby to skuteczność. Architekt powinien dbać o to, by ci, którzy płacą za projekt, byli z niego zadowoleni. Zdecydowanie drugą cechą powinna być otwartość na współpracę. W końcu i z architektami, i innymi członkami zespołu spędzamy ogrom naszego życia.

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

Senior Full Stack Developer w Remobi

 

Autor książek fantasy oraz obyczajowych. Zdobywca nagrody Transformers Innovation Awards 2022 w Hitachi Energy. Pracował w największych międzynarodowych firmach (Hitachi, ABB, Societe Generale, Bata Poland, AON). Lubi słuchać innych i dzielić się wiedzą ze społecznością IT.

Podobne artykuły

[wpdevart_facebook_comment curent_url="https://geek.justjoin.it/jaki-powinien-byc-team-leader-architekt/" order_type="social" width="100%" count_of_comments="8" ]