“Firma” organizuje programistom warunki pracy. Środowisko. Sprzęt. Oprogramowanie. Kawkę/herbatkę/whateva. Na ten temat się jeszcze pewnie kiedyś “rozwinę”.
A co najważniejsze, ten abstrakcyjny byt – “firma” – programistom PŁACI.
A ja, jako team leader? Co ja mogę zrobić? Co POWINIENEM robić? Dumałem nad tym dość sporo i wydaje mi się, że po dobrych kilku tygodniach refleksji sformułowałem idealne podsumowanie roli team leadera. A przynajmniej takiego team leadera, do którego ja chciałem trafić, wyobrażając sobie kiedyś pracę zawodową. Team leadera, jakim ja chcę być.
Moim zdaniem, główną odpowiedzialnością team leadera jest zadbanie o to, żeby programista z jego zespołu nie przeszedł do innej firmy nawet wtedy, gdy zaoferują mu tam wyższą pensję.
Oczywiście można się nie zgodzić i twierdzić, że obowiązkiem team leadera jest dostarczenie klientowi produktu najwyżej jakości bez przekraczania terminu i budżetu. Ale z drugiej strony – to można powiedzieć o każdym członku zespołu, od programisty po PMa.
Kilkukrotnie podejmowałem pracę jako programista – i ani razu nie wybrałem firmy oferującej najwyższe zarobki. Zawsze przedkładałem “wyższe” programistyczne idee ponad kasę. Jak na tym wyszedłem? Hmm… wyszedłbym lepiej od samego początku stawiając pensję na pierwszym miejscu, ponieważ kilkukrotnie też rezygnowałem z pracy – bo te idee okazywały się nie do zrealizowania.
Na ten temat rozpisałem się już dawno temu, w poście z roku 2008: “Zawód – programista. Nadzieje.” Do lektury zapraszam (sam go właśnie teraz, po tych kilku latach, przeczytałem i… nadal podpisuję się pod nim wszystkimi kończynami).
Moja odpowiedź na pytanie “jak z tego obowiązku się wywiązać?” brzmi: walczyć z nudą i rutyną. I to mogę starać się robić.
Każdy, nawet najbardziej interesujący projekt, ma części nudniejsze. Nie ma mocnych – zawsze wpadnie się w końcu w kołowrót rutyny, gdy trzeba powtarzalnie implementować podobne kawałki funkcjonalności według ustalonych reguł, w znajomej architekturze, gdzie niewiele zostało już do wymyślenia.
Znam to bardzo dobrze. Długotrwałe wystawienie programisty na działanie tak miażdżących okoliczności potrafi zabić wszelką inicjatywę, zainteresowanie pracą i chęć rozwoju. Przychodzi do roboty, robi to samo co wczoraj, to samo co tydzień temu, to samo co miesiąc temu, a w perspektywie ma kolejne tygodnie/miesiące klepania identycznych linii kodu. I tak do wyrzygu. Moim zdaniem gdyby kogoś pociągało takie zajęcie to zamiast marnując kilka lat na studia – poszedłby na kasę w markecie od razu po podstawówce.
Zadaniem team leadera jest dbanie o to, aby w każdych okolicznościach dało się odnaleźć chociaż odrobinę świeżości. Aby choć raz na kilka tygodni programista mógł poznać coś nowego, wykazać się inicjatywą, oderwać na chwilę od codzienności. Wiem doskonale jak przeraźliwie nudna może być praca developera, choć tak naprawdę takie stwierdzenie powinno być z założenia fałszywe. Nawet jeśli tenże developer jest pełen zapału, jeśli drzemią w nim pokłady energii do poznawania czegoś nowego… to na nic się to zda, jeśli KTOŚ tego nie wykorzysta. A nie ma chyba nic gorszego niż marnowanie takiego potencjału.
Nieraz doświadczyłem osobiście sytuacji, gdzie wszystko w projekcie zostało już wymyślone i postanowione przez kogoś innego, gdzie decyzje zostały podjęte, gdzie największy “fun” się zakończył, gdzie zostało po prostu “klepanie”… i dopiero wtedy wkracza do pracy programista. Bierze w ręce kilof, zaciska zęby, nakłada na kark chomąto, pada na kolana i sunie przez to smutne życie z poczuciem że “coś jest nie tak, ale widocznie musi tak być, bo pewnie wszędzie tak jest”. Znacie to? Założę się, że większość z Was niestety tak.
Przyjmując stanowisko team leadera postanowiłem sobie, że u mnie w zespole tak nie będzie. Właśnie mija pierwszy kwartał i póki co mi się to nawet udaje (choć nie mnie to tak naprawdę oceniać).
Jak staram się to osiągać?
Co najważniejsze – traktuję programistów jak równoprawnych technicznych partnerów. Ja nie jestem “tym jedynym”, wielkim Neo, który ma zrobić wszystko co jest trudne – czyli fajne – a w zespół wrzucić jakieś ochłapy. Pracujemy wspólnie, razem. Trudna funkcjonalność (i to taka naprawdę – w skali tego konkretnego projektu – trudna, gdzie np. jeden niewielki ekran zajmuje 2 tygodnie roboty, podczas gdy w trakcie jednego dnia pracy można spokojnie zamknąć 10 innych ekranów) jest dzielona w miarę równo. Każdy dostaje kawałek, z którego realizacji może być dumny. Siadając z rana do komputera MUSI wytężyć mózgownicę, pokombinować, poeksperymentować. Może zdarzyć się tak, że po całym dniu nie ma ani jednej linii kodu lądującej w repozytorium. I to jest całkowicie OK – nie liniami kodu mierzy się przecież wydajność pracy programisty.
Ważna jest świadomość odpowiedzialności. “To właśnie JA mam zrobić coś całkiem skomplikowanego i bardzo ważnego, mam to zrobić po swojemu najlepiej jak potrafię, i nikt mi się nie wcina; zaufanie zespołu spoczywa we mnie; tak samo jak moje zaufanie spoczywa w tym ziomku z biurka obok”.
Jako team leader, czyli proxy między programistami a PMem/klientem, dbam też o to, aby w świadomości wszystkich zainteresowanych istniał cały mój zespół, a nie tylko ja. Gdy ktoś mówi “dobra robota z funkcjonalnością X” to podkreślam “wiem, ale to nie ja; zrobił ją ten i ten, włożył w to masę pracy i było warto”. A pozytywny feedback zawsze trafia za moim pośrednictwem do autora. Bo – znowu – sam wiem, jak ważne jest usłyszenie czasem kilku słów pochwały za dobrze kawał odwalonej roboty.
Oczywiście każdy dostaje też swoją działkę tępych banałów do naklepania, ale i one muszą być zrobione.
Staram się też zaszczepić bądź rozwijać ciekawość nowych rozwiązań. I dawać możliwość zaspokajania tej ciekawości. Mnie to bardzo motywuje i zakładam, że motywuje każdego innego programistę. Terminy terminami, ale nie można żyć ciągłym “chętnie poznalibyśmy coś nowego, ale terminy, terminy, terminy!”. Z takim myśleniem nigdy nie wyściubi się nosa ze swojej ciepłej, nieustannie goniącej terminy, zatęchłej dziupli.
Z góry odpowiem na pytania: “ale co jeśli naprawdę terminy gonią?”. I to odpowiem bardzo prosto: nic. Terminy zawsze gonią. Wymagania zawsze się zmieniają. Klient zawsze się do czegoś przyczepi. Nigdy nie będzie idealnie, bez względu na to, czy zespół poświęci kilka chwil na prawdziwą programistyczną frajdę czy też nie. Tym bardziej, że nie chodzi przecież o wzięcie wolnego od pracy w każdy ostatni piątek miesiąca, a o ROZWÓJ.
W wielu firmach jest tak: “bardzo chcielibyśmy zmienić u siebie X, nauczyć się Y, wprowadzić Z; wiemy że w dalszej perspektywie byśmy na tym skorzystali; ale nie mamy na to czasu bo musimy przecież programować!”. I taki okres nieustannego kodowania nie trwa tydzień czy miesiąc, ale trwa latami. Im więcej razy to słyszę, tym mniej jestem zaskoczony… i tym bardziej mi ręce opadają. Dlatego też podczas rozmów o swoim aktualnym stanowisku już na pierwszej rozmowie zapytałem o podejście do takich kwestii. Trochę ku swojemu zdziwieniu, a jednocześnie ku wielkiemu zadowoleniu, usłyszałem: “zdajemy sobie sprawę z tego, że na rozwój/naukę potrzeba czasu i jesteśmy w stanie ten czas poświęcić”.
Bottom line: mam wolną rękę.
Nie czekałem długo z powiedzeniem “sprawdzam”. A co z tego wynikło – napiszę następnym razem. Przykłady, z życia wzięte, z prawdziwego projektu wyskrobane, nie wymyślone na potrzeby bloga – już wkrótce.
A tymczasem… zapraszam do dyskusji. Zgadzacie się z moim postrzeganiem tego stanowiska? Czy może inaczej odpowiedzielibyście na pytanie “jaki jest najważniejszy obowiązek team leadera?” ?.
Niestety, całkowicie się z tym zgadzam. W mojej aktualnej pracy ciągle mówi się o innowacji, jednak gdy chce wprowadzić jakieś nowe rozwiązanie okazuje się, że nie ma aktualnie czasu na zmiany. Mimo przeszło 7 letniego stażu pracy i zżycia się z wszystkimi członkami firmy zastanawiam się nad zmiana miejsca pracy.
Twoi podwładni mają to szczęście że umiesz postawić się w ich sytuacji i dobrze wywiązać się ze swoich obowiązków
Ja czekam na te przykłady z życia wzięte :).
w skrocie o Tobie : pracujesz jako team leader w zespole 4 osobowym WG CIEBIE NAJWAZNIEJSZY OBOWIAZEK TO : "zadbanie o to, żeby programista z jego zespołu nie przeszedł do innej firmy nawet wtedy, gdy zaoferują mu tam wyższą pensję" JAK ROZWIAZUJESZ TEN PROBLEM ? "walczyć z nudą i rutyną" i tu nastepuja pare zdan opisu … 1) "Każdy, nawet najbardziej interesujący projekt, ma części nudniejsze. Nie ma mocnych – zawsze wpadnie się w końcu w kołowrót rutyny, gdy trzeba powtarzalnie implementować podobne kawałki funkcjonalności według ustalonych reguł, w znajomej architekturze, gdzie niewiele zostało już do wymyślenia" – JAK WSZYSTKO… Read more »
Picasso,
Moje wizje to jedno, a możliwość ich realizacji to drugie. Na szczęście aktualnie póki co jedno jest z drugim kompatybilne.
tomaszon,
Będą we wtorek po świętach:)
ante, Dzięki za komentarz. Poniżej się trochę rozpisałem w odpowiedzi: Na początek dodam do "kilku słów o mnie" tyle, że w tej roli jestem od stycznia, więc wszystko jest dla mnie nowe. Tu wrzucam swoje spostrzeżenia aby wymienić się doświadczeniami z innymi osobami w mojej sytuacji, dostać feedback od bardziej doświadczonych, zostawić ślad "na przyszłość" aby za jakiś czas móc tu wrócić i przypomnieć sobie "jak to było"… Jest chyba oczywiste, że na wszystko co piszę mają wpływ moje codzienne zajęcia, warunki i obowiązki. Ad 1) z tym co złe nie trzeba się godzić, tylko trzeba szukać sposobów na poprawę… Read more »
1) Oczywiscie nie trzeba sie godzic, ale chcac czy nie, niektorych rzeczy nie przeskoczysz i musisz je robic. W koncu do tego przywykniesz. Trywialny przyklad rutyny i przesadnego standardu to np ze musisz codziennie wstac, to ze musisz np w piatek odkurzyc dom i umyc kabine do prysznica, ze trzeba zlosliwa tesciowa odwiedzic bo cale osiedle bedzie wiedziec jaki to cham jestes itd. Jak to sie ma do projektu ? Ano tak ze jesli kazdy by chcial robic tylko super-hiper-fajne rzeczy to zaden projekt by sie nie zakonczyl sukcesem. Ja rozumiem ze wiele osob nie chce robic nudnych rzeczy bo… Read more »
ante, Ad 1) tu wchodzimy już chyba w jakieś głębsze filozofie odnośnie podejścia do całego życia; oczywiście że dużo rzeczy nieprzyjemnych zrobić TRZEBA i z tym przecież nie polemizuję, napisałem w poście "Oczywiście każdy dostaje też swoją działkę tępych banałów do naklepania, ale i one muszą być zrobione." Ad 2) Z jednej strony: to jest właśnie dylemat który poruszam, czyli kasa vs satysfakcja z pracy. Żeby nie było: nie piszę, że moja firma płaci słabo i dlatego muszę takie myślenie stosować:). Nie mam pojęcia ile kto tutaj zarabia i jak to wypada na tle innych firm w regionie. Nie chodzi… Read more »
@Procent "odpowiedzialnością team leadera jest zadbanie o to, żeby programista z jego zespołu nie przeszedł do innej firmy nawet wtedy, gdy zaoferują mu tam wyższą pensję." W jaki sposób chcesz go jako team leader zatrzymać? Jakie masz pole manewru? Dawno zostało udowodnione, że na motywację pracowników twórczych pensja i nagrody nie działa. Działają za to nowe wyzwania i problemy do rozwiązania. Niestety jak sam stwierdziłeś ilość takie pracy w projekcie to niestety nie jest 100% czasu. Co może zrobić TL, PM czy nawet szef firmy, gdy pracownik dostaje kod, który ma 20 lat, zespół który go tworzył znudził się poprawkami… Read more »
Tutaj się trochę wtrącę: (…) Co może zrobić TL, PM czy nawet szef firmy, gdy pracownik dostaje kod, który ma 20 lat, zespół który go tworzył znudził się poprawkami i grzebaniem się w archeologi technologicznej i oddał go do niskopłatnego centrum w Polsce. (…) Szef firmy może zrobić tyle, że może się postarać żeby nie było sytuacji, w której jego zespół zajmuje się tego typu rzeczami i generować im ciekawe zajęcie. To kwesti strategii firmy :). Oczywiście łatwiej w małej firmie o to niż w dużej korporacji, która siłą rzeczy ma swój ogon zależności i zaszłości. Podsumowując, każdy ma udział… Read more »
Widzę że często panuje przeświadczenie, że sam kod jest JEDYNYM czynnikiem wpływającym na satysfakcję z pracy i że TYLKO kodowanie można usprawnić w celu zwiększenia frajdy. A to przecież nieprawda. Jeśli bym miał opowiedzieć o moim aktualnym projekcie to wątpię czy udałoby mi się przedstawić go w sposób interesujący dla programisty. A mimo to udało mi się z niego wycisnąć parę bardzo ciekawych miesięcy, i dla siebie i dla zespołu. Oczywiście sporo jest rzeczy nudnych, ale tak jak wiemy – od tego się nie ucieknie. Pracowałem nad różnymi projektami i ZAWSZE jest możliwość znalezienia obszaru, z którego można autentycznie czerpać… Read more »
W całości wpisu brakuje jednej istotnej rzeczy: podanie całości zakresu obowiązków. Wtedy można by do nich odnieść to co uważasz za główną odpowiedzialność. Bo jak widać z wypowiedzi dotyczących "zawód team-leader", każdy ma o tym inne wyobrażenie, więc dobrze gdyby istniał konkret (był uwagi, że to powinien robić PM).
PaSkol,
Po 1) to uważam za główną odpowiedzialność team leadera niezależnie od całości jego obowiązków
Po 2) o swoich obowiązkach pisałem w poprzednim wpisie, który zresztą komentowałeś :) http://www.maciejaniserowicz.com/post/2012/03/26/Zawod-team-leader-Plan-tygodnia.aspx
Po 3) każdy ma inne wyobrażenie, i ja piszę o swoim wyobrażeniu; nie jestem w stanie wypunktować wszystkiego co robię (w sposób inny niż w podlinkowanym poście), a mimo różnych obowiązków TL w każdej firmie kryje się jednak pod tym coś wspólnego: prowadzenie zespołu programistów, co wynika z dosłownego przecież tłumaczenia nazwy stanowiska
W takim razie na chwilę wracam do poprzedniego wpisu, tam Cię pomęczę i być może wrócimy tutaj ;)