Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Pusta część pączka, czyli zadania Twojego zespołu

Dave Taubler Software Architect / Engineering Leader / Credit Karma
Sprawdź, co będzie należało do Twoich obowiązków menedżerskich, a jakie zadania będziesz zlecał swojemu zespołowi.
Pusta część pączka, czyli zadania Twojego zespołu

Częstym problemem inżynierów oprogramowania, którzy rozważają przejście na stanowisko menedżerskie, jest to, czy będzie to oznaczało koniec programowania. Tak naprawdę to typowy menedżer, a zwłaszcza ten, który jest nowy, nadal będzie wykonywać praktyczne prace techniczne. Ich charakter ulegnie jednak zmianie.

Po pierwsze, warto pamiętać, że jako tech menedżer nadal możesz wykonywać tyle prac programistycznych, ile chcesz, po godzinach. W rzeczywistości przejście do zarządzania nie zwalnia Cię nagle z potrzeby rozumienia narzędzi i technologii używanych przez zespół oraz ze śledzenia trendów w branży. 

To prowadzi nas do prac technicznych, które Ty,  jako typowy tech menedżer, będziesz nadal wykonywać na co dzień. Opisuję to jako "donut hole" (czyli pustą część w okrągłym amerykańskim pączku) prac inżynieryjnych związanych z zarządzaniem. Niektóre praktyczne zadania, które wykonasz, będą na bardzo niskim poziomie, a niektóre na znacznie wyższym. To, co znajduje się między nimi, czyli ta dziura pośrodku, będziesz zlecał swojemu zespołowi.


Pusta część pączka

Dlaczego posługujemy się metaforą pustej części w pączku? Spójrz na poniższy przekrój pączka:


Mamy więc dolną część pączka, która reprezentuje pracę niskiego poziomu, a górna część reprezentuje pracę wysokiego poziomu. Nieobecna w naszym przekroju jest środkowa część, która reprezentuje pracę, której Ty, jako menedżer, nie będziesz już wykonywać i pozostawisz ją swoim inżynierom.


Dolna część

Dolna część pączka reprezentuje niskopoziomową pracę techniczną, która wspomaga działanie zespołu i innych. W tej części zaprezentuję przykłady zadań z tym związanych, jednak w zależności od składu Twojego zespołu mogą one wyglądać nieco inaczej. Częścią Twoich obowiązków będzie ochrona inżynierów przed wszelkimi zakłóceniami, które uniemożliwiają im pracę programistyczną. Czyli — będziesz zazwyczaj wykonywał pracę, na której oni nie muszą się koncentrować.


Obejmuje to konfigurację oraz utrzymanie metryk związanych z metrykami zespołu. Dashboardy mają fundamentalne znaczenie dla możliwości Twojego teamu do obserwowania działania systemów produkcyjnych, a także w innych środowiskach przedprodukcyjnych. To samo dotyczy alertów. Musisz przejąć konfigurowanie alertów i ich utrzymanie, gdy Twój zespół więcej się dowie o oczekiwanym działaniu systemu. Będziesz również odpowiedzialny za utrzymanie harmonogramu dyżurów związanych z alertami.

Podobnie jest z zarządzaniem logami. Twój zespół będzie musiał uruchomić standardowy zestaw zapytań w swoich logach. Niezależnie od tego, czy używasz Splunk, stosu ELK, czy innego rozwiązania, powinieneś być głównym autorem i opiekunem zapytań, które są wykonywane na logach.

Może się to wydawać sprzeczne z intuicją. Zostałeś awansowany na wyższy poziom w organizacji ... dlaczego miałbyś więc odwalać czarną robotę?  Są ku temu dwa powody. Pierwsze i najważniejsze jest to, że Twoim menedżerskim zadaniem jest robienie tego, co potrzebne, aby umożliwić inżynierom wykonywanie swoich zadań. Ich zadania będą się zazwyczaj skupiać na projektowaniu i wdrażaniu funkcji produktu (oraz rozwiązywaniu problemów, które się z nimi wiążą). Wymienione tutaj zadania niskiego poziomu są niezbędne dla zespołu, ale ich wykonywanie mu przeszkadza. Po drugie, twoja praca obejmuje także utrzymywanie morale zespołu.

Równie dobrze możesz zdecydować, że za tworzenie dashboardów, dostosowywanie alertów i generowanie insightów z logów odpowiadają Twoi inżynierowie. Ale czy naprawdę chcesz, żeby Twoi programiści tak spędzali czas? Zamiast tego, samodzielne przejęcie tych obowiązków pokazuje, że jesteś prawdziwym członkiem zespołu, chętnym do zakasania rękawów i samodzielnej pracy na niskim poziomie. Utrzymasz tym samym zadowolenie w zespole, a jego członkowie będą widzieć, że umiesz grać zespołowo. 

Sekret polega oczywiście też na tym, że przejęcie tych zadań może być osobiście satysfakcjonujące. Nauka nowych języków, takich jak influxql lub język wyszukiwania Splunk (w zależności od zestawu narzędzi) może być interesująca sama w sobie. A jeśli poświęcisz trochę czasu na ich naukę, to możesz stać się ekspertem tych technologii w Twojej organizacji, co nie umknie uwadze Twoich przełożonych. 


Górna część

Na drugim krańcu pączka znajduje się praca wysokopoziomowa. Często musisz ocenić nowe technologie, zanim przedstawisz je zespołowi: języki lub frameworki, paradygmaty (takie jak technologie serverless, przetwarzanie potokowe itp.) i inne.


Oceną technologii powinni się również zajmować Twoi czołowi inżynierowie. Ale to Ty będziesz ostatecznie odpowiedzialny za sukcesy i porażki swojego zespołu, więc musisz mieć dobre rozeznanie w technologii, którą zamierzasz wprowadzić. Warto jest dlatego przeznaczać trochę czasu na poznawanie nowych narzędzi. Twórz proof-of-concept (POC) nowych technologii, których Twój zespół mógłby użyć. Bądź na bieżąco z trendami, które cieszą się pozytywnym zainteresowaniem w kręgach technologicznych i poświęć czas na ich zrozumienie.

Powinieneś też dobrze rozumieć oraz biegle używać narzędzi, z których korzysta Twój zespół, tak, aby Twoi inżynierowie mogli się do Ciebie zwrócić z wszelkimi problemami. Chociaż nie na wszystkie pytania możesz udzielić im odpowiedzi, to musisz przynajmniej wiedzieć, o czym mowa. Oprócz nauki nowych technologii postaraj się też poświęcić czas na zrozumienie tych, których Twoja organizacja już używa. Na przykład, sklonuj jedno z repozytoriów swojego zespołu i zajrzyj w kod, aby zobaczyć, jak się sprawy mają. 

Nie bój się po drodze prosić swoich inżynierów o pomoc w zrozumieniu, jak coś działa. Oprócz otrzymania odpowiedzi pokażesz im też, że ich cenisz i chcesz posłużyć się ich wiedzą. Możesz także podjąć się prawdziwego zadania inżynierskiego, aby przyśpieszyć naukę konkretnej technologii. Bądź jednak ostrożny — jako menedżer powinieneś trzymać się z dala od udziału w programowaniu krytycznych funkcji projektu.

Tworzenie oprogramowania nie jest już Twoim głównym zadaniem, a gdy pojawią się inne priorytety, będziesz musiał się z nimi uporać w pierwszej kolejności. Nie powinieneś rywalizować o jakiekolwiek zadania techniczne z członkami swojego zespołu. Kierowałem kiedyś zespołem, który przenosił mikrousługi z centrum danych na Kubernetesa w chmurze. Stworzyłem „gildię devopsów”, złożoną z inżynierów z zespołów produktowych, którzy wykazywali duże zainteresowanie narzędziami devopsowymi.

W przenoszeniu do chmury priorytet miały mikrousługi. Czułem, że powinienem dowiedzieć się, co moi inżynierowie robią w trakcie tego procesu. Postanowiłem więc sam wybrać mikrousługę do przeniesienia. Chciałem jednak wybrać taką o najmniejszym znaczeniu, aby móc nad nią pracować, gdy tylko będę miał czas.


Środkowa część

Reszta pączka, czyli jego pusta część, reprezentuje codzienną pracę programistyczną, której już nie będziesz wykonywać. Składa się z tego to, co ogólnie uważamy za pracę związaną z inżynierią oprogramowania, czyli projektowanie i pisanie kodu, implementacja testów jednostkowych, debugowanie błędów itp.


Taka praca niekoniecznie zniknie pierwszego dnia. Zakładając, że przechodzisz z roli inżyniera oprogramowania do roli zarządzania, prawdopodobnie będzie jeszcze krótki okres, w którym nadal będziesz wykonywać niektóre z prac programistycznych. Funkcje i kod, nad którymi pracowałeś, raczej nie zniknie z dnia na dzień, dlatego będzie potrzeba tu Twojego wsparcia. W końcu nawet jeśli będziesz menedżerem, to Ty najlepiej je rozumiesz. Nie minie jednak dużo czasu, zanim nie będziesz już musiał wykonywać tej pracy. 


Podsumowanie

Nie musisz się więc martwić, że przejście na stanowisko menedżerskie będzie oznaczać, że porzucisz programowanie. Nadal w jakimś stopniu będziesz pracował z kodem.

Możesz też zawsze programować po godzinach. Większość technicznych menedżerów nadal ma własne projekty poboczne. Tylko nie siedź po nocach... przynajmniej nie wtedy, kiedy będziesz musiał przynieść rano pączki dla swojego zespołu.

Rozpocznij dyskusję

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej