Kilka tygodni temu na devPytaniach pojawiło się pytanie “Jak motywować programistę?“. Wtedy się nie udzieliłem, ale właśnie naszły mnie refleksje poniekąd w tym temacie. Opiszę na swoim przykładzie.
Moja sytuacja wygląda tak:
Od ponad roku pracuję w Predice. Jak można zobaczyć na stronie: zajmujemy się głównie rozwiązaniami “klasy enterprise” (yuck!) w technologiach Microsoftu. Projekty, w których uczestniczę, to z reguły całkowite przeciwieństwo moich wcześniejszych (głównie freelancerskich) doświadczeń. SharePoint, Forefront Identity Manager i inne tego typu kobyły. Jakby mi ktoś powiedział półtora roku temu, że będę zajmował się czymś takim, do tego jeszcze z TfuFS jako narzędziem do zarządzania projektami i kontroli wersji, to by mi, że się tak swawolnie wyrażę, dupa ze śmiechu odpadła.
[/wtrącenie]
Faktem jednak jest, że z pewnością ISTNIEJĄ projekty/zlecenia/stanowiska bardziej z mojej perspektywy pociągające. A jednak jestem tu… Dlaczego?
Jednym z możliwych wytłumaczeń takiego stanu rzeczy może być, że nikt inny mnie nie chce. Chodzę po rozmowach, rozsyłam CV, błagam o szansę, ale każdy mi mówi żebym szedł za stodołę kozy paść i zapomniał o programowaniu albo siedział sobie w tej Predice skoro już tu się zaczepiłem.
Na szczęście to prawdą nie jest. Dostałem przez miniony rok kilka bardzo ciekawych propozycji pracy, co w moim przypadku (Białystok lub praca zdalna) proste nie jest. W tych alternatywnych firmach prawdopodobnie miałbym bardziej “kręcące” projekty. Z finansowego punktu widzenia każda z ofert również przebijała, nawet dość znacznie, moje aktualne zarobki.
Ale ciągle jestem tutaj i nigdzie się póki co nie wybieram. Jakie jest więc prawdziwe wytłumaczenie takiego stanu rzeczy? Posłużę się opisem kilku sytuacji z mojego rocznego pobytu w Predice, co może dać odpowiedź na pytanie z tytułu posta.
Gimmie RAMa!!
Przed samymi świętami czekałem sobie spokojnie aż TfuFS ściągnie mi źródła na nową wirtualkę i żeby kompletnie czasu nie tracić zastanowiłem się chwilę nad tym, co mi najbardziej w pracy przeszkadza. Wyszło mi, że dostaję białej gorączki, gdy siadam do projektu i widzę pasek zajętego RAMu na poziomie 98% przez co prawie nic nie działa jak powinno. RAMu mam co prawda 8GB, ale przy takich systemach to wcale nie jest dużo. Pamiętałem, że kiedyś ten temat był już w firmie poruszony, ale w specyfikacji laptopa Dell napisał że 8GB to max i więcej nie da się tu wepchnąć. Poszukałem jednak ponownie w internecie używając trochę innych haseł i znalazłem na jakimś forum wątek w którym ktoś pisze, że do tego samego modelu wsadził 16GB i mu działa.
Niewiele myśląc wystosowałem do “kierownictwa” maila z linkiem do forum, dorzucając jeszcze mimochodem że od tygodnia jadę na prywatnym SSD i różnica jest… zauważalna.
Nie spodziewałem się jakiegoś wielkiego poruszenia i wróciłem do czekania na TfuFSa.
Kwadrans po wysłaniu maila dostaję na Skype wiadomość: “jadę po RAM, dam znać czy to faktycznie działa”. Okazało się że tak. Po kolejnej godzinie powstała lista komu w firmie ile RAMu wlezie do komputera i tego samego dnia poszło zamówienie. Jako bonus – dla każdego dodatkowo SSD.
Spotkaliście się z czymś takim? Ja wiem że tak być “powinno”, bo w końcu lepszy sprzęt = mniej zmarnowanego czasu = więcej zrobione. Ale nie słyszałem jeszcze o takiej sytuacji i takim czasie reakcji na podstawie jakiegoś linka z forum.
Uśmiech nie schodził mi z ryja do końca dnia.
Do biura mi nie po drodze
Mniej więcej w połowie roku wynikła u mnie sytuacja takiej natury, że bardzo chciałem pracować zdalnie, z domu. Gdy zatrudniałem się w Predice to jasno ustaliliśmy zasady, że praca z domu wchodzi w grę, ale przeplatana regularnymi wizytami w biurze. Byłoby wtedy jednak mi bardzo na rękę, gdyby to się zmieniło.
Miałem swoje powody ale wiem, że w większości firm to by nie przeszło. Tutaj przez ostatnie pół roku pracuję z domu. Ważne jest to, że robię co trzeba, a nie gdzie znajdują się moje seksowne cztery litery. Przekonałem się na własnej skórze że “rodzina jest na pierwszym miejscu” to nie tylko hasło do wycierania korporacyjnej mordy, ale że faktycznie można postępować według tej zasady. Tusku, to dobre hasło wyborcze!:).
Chcę się rozwijać… tak jak chcę
W wielu firmach (również w tych w których wcześniej pracowałem) przez “rozwój pracowników” rozumie się wysłanie ich na obowiązkowe szkolenie do jakiegoś ośrodka po to, aby stracili 3-5 dni życia i myśleli, że firma o nich dba. Kiedyś już pisałem co o tym myślę.
Tutaj jest inaczej. Każdy ma swój roczny budżet w wysokości X tys pln który może przeznaczyć na różne cele. A to jakaś konferencja (w tym budżecie zmieści się prawie każda światowa konferencja), a to dowolne szkolenie (chociaż do kilku dni z Udim musiałbym całkiem sporo dołożyć z własnej kieszeni, no ale nie oczekujmy cudów:) ), a to książki, a to kursy… Ja kupiłem sobie za to Kindle’a, parę książek i pojechałem do Wilna na “We actually build stuff”. I jeszcze zostało, ale już nie miałem w tym roku na co wydać. Wykupiłbym sobie subskrypcję Pluralsight albo TekPub, ale te mam już z innych źródeł.
Bardzo polecam takie podejście. Naprawdę pracownik czasem wie lepiej czego mu trzeba, a nawet jeśli bezpośrednio nie przełoży się to na jego efektywność w bieżącym projekcie to z pewnością doceni taki gest.
A ja mam fajny pomysł…
Zdarza mi się czasami mieć fajny pomysł. Serio. I niesamowicie mnie irytuje jeśli ktoś go nie chce wysłuchać. Nie “wykonać”, ale nawet właśnie “wysłuchać”.
Tutaj od dawna pomysłem – nie tylko moim – było założenie firmowego bloga. Z tego co kojarzę to chyba ja dorzuciłem koncepcję, aby rozszerzyć taką działalność “community” również na open source.
Organizacja całości trochę trwała, ale blog jest: http://blog.predica.pl/. Mało tego, open source też jest: https://github.com/predica. Czy to się przełoży bezpośrednio na wzrost zysków firmy? Ciężko powiedzieć. Ale puszczanie w godzinach pracy kolejnego projektu na GitHuba albo pisanie posta w tematyce walki z FIMem daje bardzo dużo frajdy.
“Będziemy pisać testy jednostkowe”…
Taką formułkę słyszałem wielokrotnie, prawie wszędzie. Tylko zawsze niejawnie w głowach siedzi dopowiedzenie “o ile nie będzie to generowało żadnego narzutu”.
Przed dołączeniem do Prediki rozmawiałem z “osobami decyzyjnymi” i byli bardzo zadowoleni że jestem “freakiem” jeśli chodzi o testy czy czasami TDD. Oczywiście nastawienie było “super, będziemy to robić”. A u mnie od razu pojawiła się odpowiedź: “okej, zobaczymy…”.
No i zobaczyliśmy. Testy pisałem wcześniej i piszę teraz. Gdy ja byłem odpowiedzialny za projekt i nie oznaczałem ficzerów jako zakończone dopóki nie miały automatycznych testów i goniłem programistów do ich pisania – nigdy nie usłyszałem “zostaw to”.
To jest zaangażowanie w podnoszenie jakości pracy oraz rozwój pracowników pomimo inwestycji, które trzeba ponieść w trakcie tego procesu.
Podobnie było zresztą z Gitem. Moje projekty realizowaliśmy w Gicie, nawet mogłem oderwać zespół na cały dzień od prac bieżących żeby o Gicie porozmawiać. Jeszcze nie doszliśmy do momentu, w którym całkowicie i bezpardonowo TfuFSa kopiemy w krocze porzucając Git-Tfs i przechodząc na Gita w 100%, ale dzielnie walczę o to od wielu miesięcy i… kto wie:).
Pracuję od… do… i już – bo taką mamy umowę
Nie znoszę nadgodzin. Dawałem temu wyraz już niejednokrotnie na blogu, i poza nim. Zmuszanie do pracy po godzinach jest nieetyczne i nie powinno mieć miejsca. Po to podpisuje się umowę, aby określić warunki “wymiana X godzin pracy za Y kasy”. Jeśli zespół nie wyrabia się z projektami to ktoś zarządzający coś zawalił i dał im za dużo roboty. Koniec.
Nie mógłbym długo wysiedzieć w miejscu, gdzie nie respektuje się takich zasad. W Predice musiałem coś porobić po godzinach chyba dokładnie raz – prawie rok po rozpoczęciu pracy. I to dlatego, że prawdopodobnie ja zawaliłem i sam się poczułem w obowiązku zrekompensowania swojej nieuwagi dodatkowym czasem pracy. A sytuacje były różne.
Kiedyś w piątek po południu dostałem mailem TfuFSowe powiadomienie, że przypisano mi buga “critical”. Jako że jestem odpowiedzialny, fajny i w ogóle;), napisałem od razu pytanie czy jest to coś na tyle krytycznego że mam siadać i od razu poprawiać czy zrobić “do niedzieli”. Dostałem odpowiedź: “jest weekend, nawet krytyczne bugi mogą poczekać do poniedziałku”. Hel-LO!
Do tego dochodzi prawdziwie elastyczny czas pracy. Pracuję od 7 do 15 mimo tego, że większość osób pracuje inaczej – bo tak mi najwygodniej. I naprawdę od 15 do końca dnia mam wolne. Chcielibyście tak?:) Wiem co to znaczy wracać z pracy do domu o 19 bo kiedyś tak pracowałem. Nigdy więcej.
Wystarczy?
To jest tylko kilka przykładów z jednego roku pracy, które akurat przyszły mi do głowy. Było tego więcej. Ale to chyba najlepsza jaką mogę sobie wyobrazić odpowiedź na pytanie “Jak motywować programistę?”.
Przekażcie dalej.
A czy jestes Maciek w ogole dumny z tego co produkujesz? Bo odnioslem troche wrazenie po przeczytaniu tego wpisu, ze to co robisz jest “yuck”, a pracujesz tam tylko wylacznie ze wzgledu na dodatkowe benefity ;)
Podpisuje sie “recami i nogami”. Dodam jeszcze jeden aspekt motywowania programisty.
By programista byl zmotywowany to musi widziec ze kadra menadzerska dziala sprawnie, daje dobry przyklad z gory a projekt ma szanse zakonczyc sie sukcesem. Ja zawsze jestem zdemotywowany gdy widze chaos w firmie, brak pomyslu, koncepcji oraz projekt ktory jest jednym wielkim “death march”.
Tomek,
Temu napisałem na początku “wtrącenie” – żeby takiego wrażenia nie pozostawić:).
Dumny czasem jestem, czasem nie. Jak pracuję przy projekcie ciężkim, którego rozwijanie nie daje przyjemności – to nie jestem dumny i tylko czekam na koniec. Albo gdy projekt finalnie wędruje do kosza – to też nie jestem dumny.
Ale jeśli robię coś fajnego to jak najbardziej! Szczególnie jeżeli od zapytania ofertowego do wdrożenia u klienta mija na przykład miesiąc, a dotyczy to czegoś czego nikt inny na świecie nie dostarcza (bo mamy taki komponent). Generalnie częściej jestem dumny niż nie jestem. Gdyby tak nie było to żadne “dodatkowe benefity” tego nie wynagrodzą.
Ale swojej niechęci do sharepointa i TfuFSa zmienić nie potrafię. To po prostu nie są dobre narzędzia. Nauczylem się jednak jakoś z nimi żyć.
Michał,
Jak najbardziej! Mrówy mogą się naharować nie wiadomo ile, ale jak jakaś ciota na górze wszystko psuje durnymi decyzjami to trzeba szukać nowej roboty. Tu na szczęście tak nie jest:).
Świetny wpis Maćku. To co napisałeś nie odnosi się tylko do motywacji programisty ale do ogólnej motywacji pracownika. Większość opisanych przez Ciebie “motywatorów” doświadczyłem również i ja w poprzedniej firmie. Dlatego z takim utęsknieniem wspominam ją bo wiem, że było mi tam naprawdę super. A praca z domu to marzenie – jeszcze jak się ma świetnego kierownika to już w ogóle cud, miód i orzeszki.
Życzę wszystkim aby praca w korpo była tak przyjemnie motywująca.
Artykuł i komentujący przedmówcy powiedzieli już prawie wszystko, ale od “siebie” dodam tylko ciekawą (i jakże uniwersalną…) myśl Kurta Vonneguta, którą chciałabym odnieść do części dotyczącej tego, czym się na co dzień zajmujemy jako developerzy:
“Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance…”
Szczerze? Zazdraszczam Ci…przedstawiłeś model ciut-nieidealny w branży IT. Chociaż oboje wiemy, że nie jestem programistą i się w innej branży, ale jest kilka punktów styku. Racja – chaos projectowy, brak motywacji dodatkowymi bonusami, nadmiar pracy w stosunku do zasobów ludzkich, a do tego jeszcze jest ‘spychologia’…ech, takie tam, moje przemyślenia…
@osheu (…) brak motywacji dodatkowymi bonusami, (…) -Bonusy też mamy ;) … (…) do tego jeszcze jest ‘spychologia’ (…) – to też stosujemy, nie robisz swojej roboty, spychasz nieuchronnie gniew PMa na siebie ;)
To co masz w Predice jest super! ale temat motywacji dev nie jest taki prosty. tak naprawde kazdego motywuje co innego.
Jednych to ze maja flexi time, innych to ze maja super sprzet, a innych to, ze maja robote.
dla nas maniakow/geekow/nerdow to co robi Predica jest wyczes :) znam jeszcze jedna taka firme i to panstwowa, ale nie polska ;)
wiec :) zgadzam sie z Toba patrzac z mojego punktu widzenia. Ale niektorym wystarczy przynaleznosc do grupy lub nawet potrzeba bezpieczenstwa z modelu Maslowa by byc zmotywowanym. I te osoby przewaznie uwazaja to co by oczekujemy jako “arogancje” z naszej strony. Gorzej kiedy manager uwaza, ze najwazniejsze dla Ciebie to poczucie bezpieczenstwa i nic wiecej.
Hej,
Dzięki za ten wpis – uświadomiłem sobie dzięki niemu, jak sam jestem przywiązany do niektórych kwestii i jak praca w moim Zespole jest fajna ze względu na wyżej wymienione.
Gutek,
Nie wiem co model Masłowa:), ale wiem że na liście z posta każdy znajdzie coś dla siebie. A że każdego motywuje coś innego… no nie wiem czy się do końca zgodzę. Myślę że jednak większość programistów można wrzucić do jednego wspólnego wora z X motywatorami i tyle.
Jak motywować programistę? | Maciej Aniserowicz o programowaniu…
Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl…
Ostatnio w Forbes był artykuł w podobnej tonacji dość ciekawie napisany
http://www.forbes.com/sites/mikemyatt/2012/12/13/10-reasons-your-top-talent-will-leave-you
@Procent
no widzisz :) i ty i ja sie mozemy z tym nie zgodzic, tak jak i wiekszosc Twoich czytelnikow. Bo jak ktos juz czyta dev blogi to znaczy, ze zrobil krok na przod ku lepszemu.
co do jednego wora, tez tak sadzilem, do poki w kilku firmach troche nie popracowalem. Tak jak ludzi nie mozna dzielic na generacje X i Y i wszedzie znajdzie sie Z jak i nie A i B itp. itd. ;)
Przyklady sa rozne, firmie osoba ma stanowisko “Senior dev”, a na programowaniu zna sie jak kurna przedszkolaczek. Ale “odbracowal” swoje, firma uznala to za ok, i wrzucila go do wora senior. jest on szczeliwy, nie rozwija sie, nie pragnie niczego wiecej. ktos da mu lepszy komp? super, ktos nie da? tez super, wkoncu stary jest wporzadku. Chce wiecej ramu? slyszy nie: spoko, ma przeciez dobre stanowisko, komp dziala. bedzie modernizacja sprzetu za dwa lata, to wtedy dostanie. itp itd. takich przypadkow jest masa. Na 50 dev w firmie spotykalem 5-10 ktore chcialy cos zmienic, cos zrobic. reszta to szare myszki szczesliwe ze swego labiryntu. Oczekujace czasami wiecej kasy, bo w koncu maja _staz_.
Maciej, Pracuję od… do… i już – bo taką mamy umowę ten akapit najbardziej mi się podobał. Właśnie jestem na 12 godzinie pracy tego dnia, poniedziałek, i jutro pewnie podobnie i raczej to reguła. Maile w weekend, nowy rok, przed świętami nic nowego. Tak na prawdę nie ma końca pracy..
Uwierzcie, jest to bardzo trudne i męczące psychicznie, benefitów opisanych przez ciebie brak ;-)
Powiedz, jak oceniasz swoja produktywność w godzinach 7-15., co gdy masz gorszy dzień i projekt którego nie lubisz i zwyczajnie “nie idzie”? Czujesz się winny?
@Michal A zastanawiales sie moze nad zmiana pracy ?
Odgrzebalem starego linka ktory zawiery dosc osbzerna rozprawke:
http://michaelochurch.wordpress.com/2012/10/30/what-programmers-want/
Michał,
Na ten temat – pracy od-do – będzie nawet osobny za kilka tygodni:). To strasznie ważne…
Mogę jedynie zgodzić się z komentarzem: zmień pracę. Albo po prostu powiedz BASTA i zobacz co z tego wyniknie.
Co do produktywności – to zależy. Są dni kiedy spokojnie wyrabiam tygodniową normę. A są takie że nie daje się ruszyć prawie nic. Sporo zależy od projektu nad którym aktualnie pracuję. Winny się nie czuję nawet jeśli niewiele uda się zrobić, każdy w końcu może mieć “słabsze momenty”, liczy się średnia. A jeżeli pracuję nad projektem który mi nie daje satysfakcji to głośno o tym mówię;).
Dzięki chłopaki za utwierdzenie mnie w tym temacie – i tak poważnie rozważam zmianę pracy już od dłuższego okresu czasu, niestety “tylko” pół roku tak pracuję i… widzę że wiecie o co mi chodzi.
Pozdrówki!
Tak czytałem i czytałem i stwierdzałem początkowo, że to przecież norma (bo mam podobnie), ale faktycznie później jak się człowiek zastanowi i przypomni sobie co znajomi mówią o pracy czasem… To się widzi, że jednak ma się dobrze :)
Super, że tak jest też w firmie takiej jak Predica :) Mam wrażenie, że sporo daje zarówno to, że “góra” to po prostu rozsądni ludzie i miała podobne wrażenia w swoich poprzednich miejscach pracy :) Choć być może tam (a tu gdzie ja teraz jestem) trafili na kilka mniej ciekawych aspektów i sprytnie je wyplenili u siebie – czego im tylko można gratulować :)
PS. Ja o kilku podobnych aspektach pracy i motywacji i benefitów – ale w korporacji – pisałem wiele razy: http://blogs.technet.com/b/mkedziora/archive/tags/praca+microsoft/ – ale może przy okazji napiszę aktualizację i podobne zebranie tego po prawie 6 latach pracy tu w Microsoft.
Mariusz,
Tak jak piszesz, pewnie wszystko sprowadza się do tego że “góra” składa się z rozsądnych ludzi. Bardzo często to jest największy problem w firmach: albo wszystko “dont care”, albo “jestem bogiem, uswiadom to sobie i do kopalni!”.
Jest jeszcze jedna rzecz o której chyba nikt nie wspomniał a która mnie bardzo motywuje. mianowicie WOLNOŚĆ. Wolność rozumiana przez możliwość w miarę luźnego pracowania i tu zarówno chodzi o dośc elastyczny czas pracy, możliwość brania wolnego zawsze wtedy kiedy się chce i bez zbędnego problemu jak i o możliwość wyboru narzędzi/bibliotek czy sposobu pisania kodu. W pracy mamy SVN-a i nikt nie robi problemu że używam git -> svn chciałem użyć lessa – ok, ncrunch – proszę bardzo (swoją drogą teraz bez ncruncha już nie umiem :) )i tak dalej. Taka wolność w rozsądnych ramach projektu powoduje, że czasem chce się w domu nad czymś posiedzieć, żeby rozpoznać coś i wnieść to do projektu co imho jest obustronnym zyskiem Win Win
@rek,
Jak najbardziej, ten aspekt przyjmuję teraz tak naturalnie że przyszedł mi do głowy dopiero po publikacji posta:). Ma on swoje minusy z perspektywy pracodawcy i rozumiem wprowadzanie ograniczeń, szczególnie jeśli chodzi o biblioteki a nie narzędzia (ty odejdziesz a potem ktoś to musi utrzymywać), ale generalnie się zgadzam, taka swoboda daje kopa.
Dlatego napisałem w “rozsądnych ramach projektu”. Nie wszystko można użyć bo jak napisałeś, ktoś to potem musi utrzymywać.
a jeszcze uzupełniając temat myślę, że warto dodać dwa linki do bloga Alexa Barszewskiego:
http://alexba.eu/2007-12-10/rozwoj-kariera-praca/droga-zyciowa/
http://alexba.eu/2012-06-09/rozwoj-kariera-praca/szukaj-podwojnego-wynagrodzenia-za-prace/
Cześć,
też się wypowiem jako programista :) co mnie motywuje:
Ciągłość zadań – brak przestojów – wprawia mnie to w dobry rytm, tydzień pracy -release – tydzień pracy -release – tydzień pracy -release – koniec iteracji- nowa – itd itd.
Myślę, że najwięcej tutaj zależy od project managementu i devleada – wiem co będę robił, wiem co robią koledzy, wiem komu mogę pomóci kogo o pomoc poprosić
Stopień ciekawości zadań również jest dla mnie ważny. Im więcej muszę się nagłowić/poszukać – takie mikro-wyzwania motywują, nie ma się poczucia odrabiania pańszczyzny.
Sprzęt – pracujemy zdalnie dla klienta za granicą – mamy tam swoje wirtualne maszyny- generalnie chodzi to wszystko ok, ale jak czasami coś zgrzytnie potrafi rozwalić dobrze zapowiadający się dzień. Generalnie dla mnie ideałem, byłaby praca na moim własnym ultra-pc lub czymś o podobnej wydajności:D niestety takie rozwiązanie jest niedopuszczalne przez klienta – trzeba z tym żyć ,
Podsumowując uważam, że moja motywacja (w pracy) – to dobrzy ludzie, oblani sosem dobrej metodyki, jasne cele. Ze swojej strony wystarczy parcie na wiedzę i samorozwój.
Pozdr
@Maciek i @Rek – dwa slowa w kwestii wolności jeżeli tylko mogę. Ogracznienia nakładane tu i ówdzie przy wyborze bibliotek i narzędzi (narzędzi trochę mniej jednak) wynikają przeważnie (a przynajmniej u nas) nie z “nie chcemy” tylko z tego z czym pracujemy. W środowisku klientów nie jest tak łatwo wdrożyć daną bibliotekę, czasami wręcz nie można (patrz Silverlight – w niektórych sieciach jest zakazany do użycia, ze względu na konieczność isntalacji – to tylko przykład). Środowiska klientów to nie tylko latest & greatest ale często środowiska bardzo “stare” czy “legacy” jak je możemy określić.
Przykład nawet z tego tygodnia – chcieliśmy gdzieś użyć FIM Explorer (Kudos dla Maćka za kod i opublikowanie) ale nie mogliśmy tak od razu bo w środowisku klienta .NET 4.0 jest niedopuszczony. Itp it.d
W zasadzie jeszcze gorzej jest z narzędziami – ja często bym zrobił coś w kilka minut narzędziem firmy 3-ej albo z community, ale polityka klienta tego nie dopuszcza, więc zamiast tego piszemy skrypty (co de-facto kosztuje Klienta więcej ale w całości ma spójne środowisko).
O tak to sobie wygląda przeważnie … takie .02 PLN
Jako koszty klienta traktujesz tylko koszty wytworzenia, a to trochę nie tak. Dzięki spójnemu środowisku te kilka dni więcej na skrypty (z reguły) bardzo szybko się zwracają w innych miejscach.
Tomek: To co piszesz to rozumiem pod pojęciem ramy projektu. Czasem nie można czegoś użyć z tej czy innej przyczyny i to jest naturalne. Nie jest natomiast naturalne gdy nie możesz czegoś użyć bo PM/Kierownik/Leader/Przełożony/ktokolwiek mówi NIE BO “jestem bogiem, uswiadom to sobie i do kopalni!”
Wydaje mi się, że wszyscy już wiemy jak motywować programistę. Każdy średnio ogarnięty programista wie co go motywuje do pracy. Chyba każdy prawdziwy geek lubi więcej ramu, megaherców czy cali. Myślę, że największym problemem programistów jest to jak zmotywować managerów czy pracodawców, aby oni chcieli zmotywować nas. Niestety bardzo często dla nich nadal prościej jest zatrudnić X nowych pracowników, którzy jak małpki będą klepać bieda-kod, niż umożliwić tym już pracującym zrobić coś dobrze i rozwinąć swoje kompetencje. Bo w suchej kalkulacji dla nich (managerów) wychodzi taniej, bo 9 kobiet w miesiąc urodzi dziecko. Często zauważam, tak jak napisałeś, że ktoś kto dochrapał się seniora/menagera nie ma czasu/chęci/potrzeby na poszerzanie swoich kompetencji.
Teraz pojawia się pytanie, jak zachęcić szefów do tego aby stworzyli swoim pracownikom takie warunki, jakie opisałeś w swoim wpisie. Jak ich zmotywować do podjęcia/wznowienia nauki?
Gratuluję dobrego miejsca pracy. Wpis motywacyjny – bardzo dobry. Jedna tylko rzecz…
” Jeśli zespół nie wyrabia się z projektami to ktoś zarządzający coś zawalił i dał im za dużo roboty. Koniec. ”
Setki razy widziałem zespół, który nie dotrzymywał własnych terminów – bo po prostu spartolili kod, wprowadzając mnoho bugów. Za dużo, by sobie poradzić z ich usunięciem we wskazanym terminie. Koniec. Błędy są i były, nie da się ich wyeliminować do zera, jeżeli stosujesz TDD z efektem otrzymania później niewielkiej stopy błędów w testach funkcjonalnych – to chylę czoło i faktycznie masz pełne prawo do tego twierdzenia (wymiana: dajesz jakość, oczekujesz przestrzegania godzin pracy – a jest to możliwe, bo dałeś jakość…). Ale nie wszyscy tak mają :)
M,
Jeśli zespół produkuje zły kod to nie robi tego raptem w jednym sprincie/iteracji/projekcie, jakkolwiek to nazwiemy, tylko to jest po prostu kultura pracy w danej organizacji. Więc tempo poprawiania błędów jest zawsze wolne. Czyli: “management” powinien wiedzieć że ich estymacje są zaniżone i odpowiednio skorygować plan.
Zgadzam sie z procentem.
Nikt z premedytacja nie tworzy zbugowanego kodu tylko po to by nie wyrobic sie z estymacja. Pracowalem w kilku zespolach i wszedzie widzialem programistow ktorzy dawali z siebie ile tylko mogli, chcieli jak najlepiej.
To ze estymacje sie nie udaly, to po czesci wina managementu. Nawet jesli programisci zle estymuja to trzeba cos z tym zrobic. Jesli programisci nie sa zmotywowani to trzeba ich zmotywowac. A jak ktos sie nie nadaje do pracy w tym konkretnym zespole to trzeba go zwolnic. Kiedys fajny cytat podlapalem …
“Najbardziej dotkliwym anty patternem w soft devie jest brak zwolnien”
Jak dla mnie dużo racji jest w tym co napisałeś. Jednak myślę, że nic z tego nie zadziała jeśli pracownicy nie będą zadowoleni z podstawowej funkcji jaką daje im praca a więc z zarobków – gdzieś kiedyś czytałem, chyba na jakimś blogu, że pracownik jest w stanie pracować wydajnie i być odpowiednio zmotywowanym kiedy nic mu nie przeszkadza, a jeśli zarabia za mało, wtedy musi się przejmować kredytem, rachunkami itp. – a więc drodzy pracodawcy – najpierw wyeliminujcie elementy demotywujące żeby zacząć myśleć o dodatkowej motywacji ;)
@Bartek W “marszu ku klęsce” – ten czynnik był nazwany kwestią higieny :)
@Bartek – (…) Jednak myślę, że nic z tego nie zadziała jeśli pracownicy nie będą zadowoleni z podstawowej funkcji jaką daje im praca a więc z zarobków (…) – płaca to wynikowa kilku czynników:
– podaży ludzi na rynku
– popytu na ich umiejętności
– ich umiejętności bezwzględnych i względem zespołu
– Tego w jaki sposób jego praca przekłada się na przychody firmy
– itp itd.
Teraz pytanie – co to znaczy że programista za mało zarabia?? Programista zarabia tyle, na ile wycenił swoją pracę a dany pracodawca jest mu w stanie zapłacić bez podcinania sobie gałęzi na której sieci (płaca to nie jest jedyny koszt powiązany z zatrudnieniem – obciążenia te są w PL dosyć wysokie). Jeżeli uważa że to za mało bo:
a/ jego umiejętności są wyższe
b/ przykłada się w znaczacy sposób do przychodów firmy
c/ …
… to niech pogada z przełożonym otwarcie albo poszuka kogoś kto wyżej ceni jego umiejętności.
Jeżeli uważa że za mało zarabia … bo ma potrzeby większe niż to co zarabia … to nie problem pracodawcy, ale powyższe porady nadal można zastosować.
@Tomek, to co napisałeś to oczywiści prawda. Mnie bardziej chodziło o to, że jeśli pracodawca chce “dogodzić” swoim pracownikom, poprzez różnego rodzaju “benefity” opisane w poście, powinien najpierw zastanowić się czy wszyscy pracownicy (zakładam że są oni wartościowi dla pracodawcy skoro chce im “dogodzić”) są zadowoleni i nic im (m.in. za niska pensja) nie przeszkadza…
Jeśli pracownik chodzi za pracodawcą i prosi się o podwyżkę, a ten mu jej nie daje (nie ważne czy nie chce czy nie może), to myślę, że wszelkie pozapłacowe dodatki niczego tutaj w jego motywacji nie zmienią.