Zawód-team leader. Mój najważniejszy obowiązek.

“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?” ?.