“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 INNE W ZYCIU, NIE MA TU NIC NOWEGO I Z ZYCIEM TRZEBA SIE POGODZIC, TAK JEST WSZEDZIE …
2) "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"
– MOMENTALNIE SIE ZWALNIAM JESLI TAKA SYTUACJA FAKTYCZNIE MA MIEJSCE … ALE JESLI DOBRZE MI PLACA TO MOGE TO ROBIC BO INTERESUJACE RZECZY ROBIE NA BOKU… WOGOLE PACHNIE TO GIGANTYCZNA KORPORACJA WIEC W PRZYPADKU TWOJEGO MALEGO ZESPOLU TAKA SYTUACJA NIE MA MIEJSCA
3) "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.
– RAZ JESZCZE POWTORZE – 4 OSOBOWY ZESPOL MA INNY CHARAKTER PRACY NIZ KAZDA INNA WIELKA KORPORACJA. JESLI PRACOWNIK STOI W MIEJSCU, NUDZI SIE, NIE ROZWIJA SIE, WYPALA SIE TO PREDZEJ CZY POZNIEJ ZNIKNIE …
4) 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.
– Oh w8 … pracujesz w 4 osobowym zespole i tak powinno byc bo inaczej by Cie zwolnili ??? …
Reszta tez standard :)
Osobiscie uwazam ze na wstepie zadales sobie zle pytanie. Ogarniety programista wie ze pieniadze nie sa glownym wyznacznikiem tego czy opuszci swoje aktualne miejsce pracy. Jest duzo innych czynnikow ktore decyduja o takich zmianach ale to material na ksiazke … Bo kazdy jest inny, ma swoje poglady, priorytety,plany a Ty opisales to tylko z wlasnej perspektywy.
Ja sie zapytam co robi u was PM ? Bo jak tak czytam to czesciowo wykonujesz jego obowiazki i wczuwasz sie w jego role :)
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ę sytuacji
Ad 2) jesteś niekonsekwentny: najpierw piszesz że w takiej sytuacji od razu się zwalniasz, a w następnym zdaniu że możesz to robić jeśli dobrze płacą; mój pogląd to: programista powinien mieć okazję czerpać przyjemność z programowania NIE TYLKO w domu i chodzić do pracy NIE TYLKO dla kasy; a opisywana przeze mnie sytuacja może mieć miejsce zarówno w 2-osobowym jak i 30-osobowym projekcie
Ad 3) Im więcej czytam tym mniej rozumiem co chcesz przekazać. I w małym i w dużym zespole może być nudno. Identycznie, i w małym i w dużym zespole może być ciekawie. Korporacja czy nie – co za różnica?
Ad 4) Po raz kolejny piszesz o 4-osobowym zespole, i cały czas nie wiem co to ma do rzeczy. Czyżbym prawo do dzielenia się swoimi refleksjami zdobywał dopiero prowadząc ekipę piszącą Windowsa?
Zgadzam się z Tobą co do jednego: "tak powinno być" (tzn. tak jak ja to próbuję robić). Jednak chyba rozmijamy się w postrzeganiu rzeczywitości, jeśli twierdzisz, że tak jest wszędzie lub że każda firma wymaga tego od team leadera. Jeśli wyłącznie z takimi firmami/leaderami miałeś do czynienia to zazdroszczę farta w życiu.
Co do reszty wypowiedzi: nie twierdzę, że to co piszę nie jest "standardowe". Wiem, że dla mnie jest nowe. Mogę też mniemać na podstawie komentarzy do poprzedniego posta, że wiele osób przeczyta to z zainteresowaniem.
Uwaga o tym, że to temat na całą książkę, jest jak najbardziej prawdziwa. Jednak zamiast pisać książki, wolę pisać posty.
Z kolei fakt, że "kazdy jest inny, ma swoje poglady, priorytety, plany a ja opisalem to tylko z wlasnej perspektywy", jest chyba oczywistą oczywistością, czyż nie? Z czyjej perspektywy mam pisać na własnym blogu, jak nie ze swojej?:) A pytanie postawiłem sobie właśnie takie a nie inne, bo to dokładnie ono wydało mi się najważniejsze przed rozpoczęciem nowej pracy. Chyba dobrze jest odpowiedzieć sobie na pytanie "co mam osiągnąć/robić" zanim zacznie się to robić?
I jeszcze odpowiedź na pytanie o PMa i o to czym się u nas zajmuje… PM zajmuje się "zarządzaniem projektem", cokolwiek przez to można rozumieć. Na pewno nie można przez to rozumieć tego co opisałem w niniejszym poście, bo właśnie to jest MOJĄ rolą.
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 im sie po prostu juz nie chce i zygaja tym. Ale zycie bywa przewrotne i czasem na niektore rzeczy w zyciu trzeba spojrzec z pozycji obowiazkow. Sam kiedys mialem podobnie bo nie moglem wytrzymac w obecnej pracy, tak wialo nuda ze juz nawet wstawac z rana mi sie nie chcialo. Zmienilem prace na inna i przekonalem sie moglem to inaczej rozegrac bo wcale nie bylo zle w poprzedniej pracy. Pewne zdarzenia w zyciu osobistym, nie zwiazane z wykonywana praca, wplywaja na postrzeganie swojej pracy i rosnie tolerancja do tego co sie robi wraz z uplywem lat. Nawet w branzy IT wiekszosc musi popasc w rutyne i nude zeby reszta miala fajniej. Mozesz sie nie zgodzic ale pewna krzywa statystyczna doskonale to obrazuje.
2) Jak to wiadomo powszechnie, nie wszystkie firmy dobrze placa. Wiekszosc placi bardzo srednio. W takim przypadku zwolnienie sie nie wplywa negatywnie na moj stan psychiczny, ba nawet czuje ogromna ulge. Ale mozna trafic do firmy w ktorej placa bardzo dobrze i nie ma mozliwosci poprawy zadowolenia ze swojej pracy poprzez rozmowe z przelozonymi. Moze byc i tak ze jest to firma ktora przykladowo tworzy tylko jeden rodzaj produktu "X" i sprzedaje go za kolosalna kase. Pomysl ze Ty do niej trafiles i musisz wybrac: "Zostaje, nie wysilam sie. W koncu placa zajebiscie,a po pracy robie to co lubie i jestem happy" albo " Tak nie moze byc, co mi po pieniadzach jak wieje nuda". Co bys nie wybral to wybor moze byc sluszny. "Programista powinien mieć okazję czerpać przyjemność z programowania NIE TYLKO w domu i chodzić do pracy NIE TYLKO dla kasy" – idealna sytuacja, ktora dotyczy niewielu osob.Z czasem spada wartosc pierwszego, rosnie drugiego.
3) "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.
W skrocie mozna napisac ze jednym z Twoich obowiazkow jest organizowanie pracy zespolu. Mam racje ? Od Ciebie moze faktycznie zalezec ze kolega X zajmie sie tym,a kolega Y pozna cos nowego i wdrozy to w projekt. Za miesiac jakas zmiana i to teraz Y zajmie sie czyms mniej ciekawym a X niech pomysli nad innym sposobem rozwiazania jakiegos zadania niz dotychczas przyjety sposob. Cacy, tak powinno byc wszedzie. Ale odnies to do 2 punktu gdzie jest sobie zespol w jakiejs firmie, gdzie kazdy umie cos innego i to oni tworza calosc, nie majac czasu na nauke czegos nowego. Jesli "jeszcze wyzej" przelozeni nie zgodza sie na jakies uroizmacenia, to co Ci po checi wprowadzenia zmian ? Czasami niektorzy sie tam trzymaja standardow i wyzej dupy nie podskoczysz. Wtedy praca developera jest jak praca kasjerki w Realu. Nawet jesli programista zna sto innych zagadnien, a nie moze tego wdrozyc w projekt, to czy TL jest w stanie go zatrzymac w obecnej pracy jesli nawet sam podziela opinie pracownika bedac rowniez udupionym we wprowadzaniu "swiezosci" w pracy ??
4) Wyobrazasz sobie developing w 4 osobowym zespole bez takiego podejscia jak opisales ? No sytuacja w ktorej jestes panem, a Twoi developerzy to maszynki do kasy, to dlugo bys sie nie utrzymal na stanowiski :)) Pytasz czemu uczepilem sie wielkosci zespolu ? Mniej osob = pojedynczy pracownik powinien miec wieksze kompetencje. Wiekszy zespol = inny styl kierowania zespolem i praca takiego zespolu. Relacje miedzy pracownikami inaczej ksztaltuja sie w malej firmie, a inaczej w wiekszej. Ty masz fajnie bo mozesz bardzo dobrze poznac swoich pracownikow, ich oczekiwania, problemy, plany. Masz wieksza swobode w dzialaniu i mozesz sie bardziej do zespolu.
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 mi też o to, że programista powinien harować za grosze i zadowolić się tym że ktoś mu rzuci nową bibliotekę do rozpoznania. To jest głębsza kwestia i w kilkulinijkowych komentarzach tego nie rozwiążemy. Mi się nadal wydaje, że odpowiedzialność skonstruowana tak jak ja to zrobiłem w niniejszym poście bardzo dobrze podsumowuje moje przemyślenia dotykając więcej niż jednego tematu naraz.
Ad 3) Jeśli przełożeni "jeszcze wyżej" się na coś nie zgadzają to właśnie rolą team leadera jest moim zdaniem próbowanie poradzenia sobie z tym. Może ci przełożeni "jeszcze wyżej" wchodzą w jego kompetencje?
Ad 4) Tak, wyobrażam sobie opisaną przez Ciebie sytuację, czyli brak jakichkolwiek innowacji/rozwoju/nowości w 4osobowym zespole. Właściwie to nawet nie muszę zbytnio wyobraźni wysilać.
A że mam fajnie – to wiem, w końcu do tego chyba każdy dąży… żeby "mieć fajnie"?:)
@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 i grzebaniem się w archeologi technologicznej i oddał go do niskopłatnego centrum w Polsce.
Może tylko dać wysoką pensje, jak nie to po roku z tego zespołu zostaną tylko ludzie, z których i tak nie będzie pożytku.
Co z tego, że pracujesz w fajnej firmie, jak po dwóch latach pracy, pytasz się szefa o podwyżkę a w odpowiedzi dostajesz, że na prąd i wodę nie ma.
A za 3 tygodnie przychodzi mail z centrali gdzie chwalą się rekordowymi zyskami.
Niestety, zadowolenie z pracy jest ważne, ale pod koniec miesiąca przychodzi czas płacenia rachunków i całe zadowolenie z pracy zamieniasz na frustrację.
Dlatego proszę cię teksty typu, pensja nie jest najważniejsza tylko zadowolenie z pracy, to można sprzedawać na spotkaniach firmowych.
Większość ludzi mając do wyboru zadowolenie z pracy i niską pensje a podwyżkę, pójdzie tam gdzie mu więcej dadzą.
Piszę to z własnego doświadczenia, teraz mam nudną pracę ale na przejście do nowej firmy dostałem około 80% podwyżki.
Pewnie, że bym chciał robić coś ciekawego, ale rachunki się same nie zapłacą.
Pozdrawiam
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ł w firmie w tak skonstruowanej roli jak opisał to % tylko w swoim obszarze. Pracownik też ma w tym udział – jeżeli nie ma innych przeciwności (nie podoba mu się w firmie itp) to powinien umieć jasno sformułować swoją wizję rozwoju i tego co go "kręci" do TL i przełożonych, żeby można było dostarczać mu odpowiedniej pożywki umysłowej nawet w obrębie codziennych obowiązków.
Moje .02PLN
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ć przyjemność. Ale trzeba sobie zdawać sprawę, że do tego nie wystarczy jeden wizjoner wśród betonu. Tutaj musi panować zgodność w skali całej firmy – że to co robimy przede wszystkim NIE MA BYĆ męczarnią. Takie podejście naprawdę bardzo wiele zmienia i otwiera sporo nowych możliwości.
Dodatkowo podkreślę jeszcze raz: nigdzie nie napisałem, że moim celem jest zatrzymywnie programistów robiących za pół-darmo. Zdecydowanie uważam, że dobry programista powinien dużo zarabiać, niezależnie od tego czy ma z pracy przyjemność czy nie. Ja nie wiem ile zarabiają osoby u mnie w zespole, nie mam na to wpływu i mnie to nie interesuje – to zupełnie nie moja brocha.
Robot napisał, że "rachunki się same nie zapłacą". No to chyba jest jasne, prawda? Podobnie jak to, że raczej naturalnym krokiem jest skorzystanie z opcji 80% podwyżki związanej z przejściem do innej firmy. Nie czarujmy się, przecież nie twierdzę że pieniądze nie są ważne – bo są BARDZO ważne. Tylko moim zdaniem, przy odpowiedniej kwocie wystarczacjącej na [tutaj każdy może sobie wpisać co chce], coraz bardziej ważny staje się czynnik satysfakcji z wykonywanej pracy.
A co do stwierdzenia, że "pieniądze i nagrody nie motywują twórczych pracowników" to się nie zgodzę. Wiem że mogą być takie badania, że tak może wychodzić z jakichś sond, ale sam uważam siebie za twórczego pracownika i znam wielu twórczych ludzi, ale nie znam nikogo kto by powiedział że pieniądze nie są motywujące. Moim zdaniem – bzdura.
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 ;)