Kiedy byłem developerem, często wyobrażałem sobie jak projektuję system od podstaw.. Zostać kiedyś Architektem, to było moje marzenie. Miałem wtedy swoje własne wyobrażenie tej funkcji.
Obecnie pełnię tę rolę już w kolejnym projekcie i współpracuję z kolejnym zespołem. Zauważam, jak rzeczywistość różni się od mojego wyobrażenia.
Chciałbym Cię na początku ostrzec, że będzie to tekst oparty o moje doświadczenia. W Twojej organizacji może to wyglądać zupełnie inaczej. Wiem jednak, że to, co opiszę, ma miejsce w wielu firmach.
Software Architekt – wyobrażenie
Wielu z developerów wyobraża sobie siebie spędzającego godziny nad głębokimi rozmyślaniami. Jaki framework wybrać lub jakie biblioteki użyć? Jaki wzorzec projektowy będzie najlepiej pasował? Czy może wdrożymy CQRS? Przecież wyglądało to tak fajnie, jak opowiadał o tym prelegent na ostatnio odwiedzonej konferencji.
Wreszcie jestem architektem. Wreszcie sam mogę o tym zdecydować.
Nie przeczę. To będzie Twoja praca. Jednak jak się okazuje, nie tylko na tym będzie ona polegać.
Czasami, poza tym, co sobie wyobrażasz, spotkasz się też z niektórymi z opisanych poniżej rzeczy.
1. Będziesz mniej kodował
Ale jak to? Zapytasz. Otóż tak to. Nie mówię, że nie będziesz pracował z kodem. Oczywiście będziesz (nawet powinieneś dążyć do tego, żeby pracy z kodem było jak najwięcej) jednak w trochę inny sposób. Bardziej będziesz patrzył na kod, niż go pisał. Bardziej będziesz projektował klasy, interfejsy niż je implementował w całości. Ponieważ w Twoim zawodowym życiu pojawią się inne obowiązki (o tym poniżej), będziesz zmuszony, czy tego chcesz, czy nie, delegować sporą część klepania kodu, którą wcześniej wykonałbyś sam. Ale kto to zrobi lepiej niż ja? Przecież oni to schrzanią. Nierzadko tak się właśnie stanie, pogódź się z tym. Jednak jedną z Twoich nowych odpowiedzialności będzie też minimalizowanie tego poziomu schrzanienia. O tym jak, przeczytasz również poniżej.
2. Staniesz się leaderem zespołu
Połączanie funkcji architekta i leadera zespołu wydaje się być oczywiste. Przecież trzeba pokierować developerami, aby implementowali według zaprojektowanej architektury. A kto zrobi to lepiej niż jej autor? Zgoda. To jest jasne. Co jednak może zaskoczyć to to, że rola leadera wymaga zupełnie innych kompetencji. Jako team leader będziesz odpowiedzialny za to, żeby członkowie Twojego zespołu mieli ciągłość pracy. Musisz przemyśleć jak rozdzielić zadania, aby nikt się nie nudził. Developerzy zasypią Cię pytaniami w najmniej oczekiwanym momencie i będziesz musiał zająć się nimi natychmiast, żeby nie blokować pracy innych. Idealnie by było, abyś jako team leader dbał o rozwój kompetencji Twojego zespołu. Twoja wiedza musi przepływać na innych mniej doświadczonych kolegów i koleżanki. Musisz dbać, aby stawali się oni coraz lepsi, bo wpłynie to na jakość kodu, za którą odpowiedzialność bierzesz Ty.
To tylko niektóre odpowiedzialności team leadera.
Szybko się zorientujesz, że to wszystko nie jest takie proste i zabiera znaczną część Twojego czasu. Dezorganizuje też tę część Twojej pracy, na której najbardziej chciałbyś się skupić.
3. Będziesz musiał wyleźć z piwnicy
Zapomnij o czasach, kiedy to przychodziłeś do pracy, otwierałeś zadanie w JIRA i kodowałeś, w ciszy i spokoju, wyskakując od czasu do czasu do kuchni po nową kawę.
Okaże się nagle, że wielu ludzi chce z Tobą rozmawiać. Biznes będzie chciał rozmawiać. PM będzie chciał rozmawiać. Koledzy z zespołu będą ciągle o coś pytać. Może nawet ktoś zechce, żebyś zrobił prezentację przed całym zespołem. W skrajnych sytuacjach Klient zaprosi Cię na spotkanie.
Może się zdarzyć, że przez cały dzień nie tyle nie napiszesz linijki kodu. Ba nawet nie otworzysz IDE
Bądź na to gotowy 🙂
4. Będziesz musiał wejść na inny poziom komunikacji
Rozmawiając z tymi wszystkimi ludźmi, szybko zorientujesz się, że część Cię po prostu nie rozumie. Nagle zauważysz, gdy opowiadasz o klasach, interfejsach, pipeline’ach i repozytoriach, że część słuchaczy dziwnie się patrzy, część ziewa, a tylko część wprost przyzna, że kompletnie nie wie, o czym mówisz i poprosi o wyjaśnienie bardziej przystępnym językiem.
Konieczne będzie, abyś dostosowywał swój język do funkcji rozmówcy. To bardzo istotne. Innego języka używaj, gdy rozmawiasz z developerami, innego z managerami, a jeszcze innego z klientem.
Uwierz mi. Dostosowanie sposobu komunikacji do rodzaju słuchaczy jest bardzo trudne. To umiejętność, o której istnieniu najprawdopodobniej wcześniej nie wiedziałeś.
5. Cząstka Ciebie będzie musiała stać się analitykiem, PM’em oraz sprzedawcą
Będziesz musiał zrozumieć biznes klienta. Koniec z czasami, kiedy to klepałeś, bez większego wnikania, formularze zapisujące dane w bazie. Niezbędne będzie, abyś zrozumiał procesy biznesowe, ich kontekst oraz ograniczenia.
Również zaczniesz dostrzegać, że terminy to nie jest zła wola PM’ów. Z reguły to wymagania klienta i to bardzo uzasadnione. Niekiedy będziesz musiał przesiedzieć godziny, aby zrobić harmonogram, a potem zadbać o to, żeby został dowieziony.
Wymagać się będzie od Ciebie, abyś umiał wytłumaczyć, dlaczego coś zajmuje (czytaj kosztuje) tyle ile zajmuje. Skąd wynika dany termin i czy to przypadkiem nie wynik błędów, a celowe i niezbędne działanie. Czasami też okażę się, że będziesz musiał sam zaproponować coś klientowi i umiejętnie przekonać go, że tego potrzebuje.
Podsumowanie
Rola architekta z dużym prawdopodobieństwem będzie wymagać od Ciebie zdobycia wielu nowych kompetencji i umiejętności. Poza skill’ami technicznymi będziesz musiał nabyć masę tak zwanych umiejętności miękkich. Wielu nie będzie dobrze się z tym czuło. Jak to powiedział Jakub Nabrdalik „nie po to zostaliśmy programistami, żeby rozmawiać z ludźmi” :). Jednak wielu się w tej roli odnajdzie i będzie czerpać z niej przyjemność.
A kto wie, może nic z tego, co napisałem nie znajdzie zastosowania w Twoim przypadku.