Bazował on głównie na książce Dana Pinka "Drive: The Surprising Truth About What Motivates Us".
Tutaj filmik, który już trochę krążył po sieci ;-) Filmik jest ilustracją jednego z wystąpień Dana Pinka i pozwala się zorientować o co chodzi ;-)
Ale ja nie o tym ;-) albo nie do końca o tym ;-)
Ogólne tezy wykładu były takie, że w zawodach kreatywnych takich jak np. programista pieniądze to nie wszystko, że istotniejsza jest motywacja i chęć zrobienia czegoś nowego i fajnego. I to jest fakt.
Ale ;-) Ale istnieje ryzyko, że wiele osób, które miewają szanse na podejmowanie decyzji może to opacznie zrozumieć ;-)
To, że pieniądze nas nie motywują nie wynika z tego, że się dla nas nie liczą.... po prostu chodzi o to by pieniądze nie były problemem. Jeżeli pensja pozwala na dość wygodne życie to kolejne pieniądze w ramach premii "za wydajność" nie robią wielkiej różnicy... nie robią różnicy bo nie powodują lepszej pracy, a mogą gorszą nawet, no i nie są już taką nagrodą.
Nagrodą jest to, że robi się coś co jest wyzwaniem, coś co pozwala się wykazać, coś przy czym się czegoś trzeba nauczyć....
I tu kolejne niebezpieczeństwo ;-) Coś jest wyzwaniem nie dlatego, że tak to zostanie nazwane w momencie przekazywania developerowi. Wyzwanie to coś co zmusza do stworzenia czegoś nowego, to rozwiązanie trudnego problemu. Coś co daje satysfakcję.
Szafowanie tekstami w stylu "wielkie wyzwanie i szansa", tudzież po angielskiemu "oportunity and chalange" nic nie robi, a jedynie włącza moduł cynizmu, którego wytworem jest np. bullshit bingo.
Coś jest wyzwaniem i szansą do zabawy (tak, zabawy, bo o to chodzi) jeśli sama zainteresowana osoba tak uzna (taki hint, są ludzie których może bawić praca polegająca na zmienianiu w 100 miejscach tego samego, albo formatowanie kodu, a są ludzie, którzy przy takim zadaniu poważnie rozważają uszkodzenie kogoś w okolicy by móc tylko tego nie robić, za to będą szczęśliwi jak dzieci gdy im się da zagwozdkę, która wymaga wywrócenia mózgu na drugą stronę).
W pracy wymagającej choć krzty kreatywności nie trzeba ludźmi zarządzać, sami to zrobią o wiele lepiej, trzeba im tylko usuwać przeszkody i broń boże nie zmuszać do papierkowej roboty.... jak chcesz mieć od developerów raportowanie postępu prac to przygotuj się na wielką ściemę... (np. w jednej z poprzednich firm standardowe wypełnianie tygodniowego raportu szło wg. algorytmu:
1) we wszystkie dni wstaw 0.5 godziny na obiad
2) wstaw weekly meeting i wszystkie powtarzające się meeting'i
3) wstaw wszystkie nietypowe zdarzenia (np. awarię komputera, szkolenie)
4) jeżeli w tygodniu były inspekcje wstaw w każdym dniu z inspekcją jej czas razy dwa,
a) jeżeli czas w danym dniu przekroczył 8 godzin to przesuń czas przygotowania do inspekcji na dzień wcześniej i przeprowadź na nim jeśli konieczne podpunkt a)
5) w to co zostało wstaw losowo jakieś godziny do wiszących na tobie tasków (jak coś zostało zamknięte w poniedziałek, ale miejsce jest w piątek to wstaw w piątek i tak nikt tego nie sprawdzi).
A wszystko po to by zadowolić bożka procesu).
Btw. bożka procesu, to to złe bydle jest. Pożera dusze młodych programistek i programistów.. jeden plus, że zrywa im złudzenia wyniesione ze studiów, że np. "to wszystko powinno być podzielone na warstwy" (inaczej wyrażane lamentem "w każdej normalnej firmie to by było podzielone na warstwy"........ który jest o tyle ciekaw, że wg. niego nie ma normalnych firm ;-)).
Ogólnie fajny wykład :-) Niby już o większości gdzieś czytałem czy słyszałem, ale fajnie było to usłyszeć w jednej spójnej całości.
[od pewnego czasu mam straszny problem z tytułami wpisów i wybieram takie, który mi fajnie brzmią po prostu, ale mogą nie mieć wiele wspólnego z treścią postu]
Podobne postybeta
Prosty test obiektywności dla zwolenników PiS/PO/whatever
Dobrze, że dzięcioły nie lubią komputerów...
Dieta informacyjna przed wyborami
Knowledgeware
Lubię enumy
Brak komentarzy:
Prześlij komentarz