13 godzin temu
Był sobie zespół programistyczny złożony z paru osób. Wszyscy z żyłką pasji zabrali się do projektu. Ponieważ wychodzili założenia, iż dobrze się uczyć na własnych błędach, przeprowadzali regularne retrospekcje. W trakcie retrospekcji analizowali sprawy takie jak:
- zgodność szacowania z oczekiwaniami
- pokrycie testami i ich skuteczność
- ilość błędów znalezionych w fazie testów
- czytelność kodu
Ponieważ praca szła wyjątkowo sprawnie, sponsor zespołu począł rekrutować kolejnych programistów i kolejnych i kolejnych. Pierwsi członkowie zespołu zostali liderami, potem kierownikami. Wszystko szło sprawnie. Naturalnie nowe osoby w dziale (tak, tak zespół stał się Działem, a jakże!) były zapoznawane z obowiązującymi i sprawdzonymi standardami i zobligowane do ich przestrzegania.
Po jakimś czasie nasi kierownicy zauważyli, iż standardy są kiepsko przestrzegane. Trudno im było zmobilizować programistów do ich stosowania. Długo zastanawiali się jak zaradzić tej sytuacji. Ponieważ byli wytrawnymi inżynierami, podeszli do sprawy stricte analitycznie. Wykombinowali wcale skomplikowany wzór, który uzależniał dodatek premiowy od stopnia przestrzegania standardów. Na przykład: za 80% pokrycia testami +2%premii, za każde 50 błędów zgłoszonych przez testerów + 1,3%premii, za utrzymanie szacowania +3,2% premii....pomysł genialny...
i wtedy zaczęła się GRA.
Zasady gryIntencją kierowników było nagradzanie osób z zespołu za przestrzeganie standardów i zachęcanie do ich stosowania. Jednak zupełnie nieświadomie stworzyli GRĘ, o następujących zasadach:
- uczestnikami gry są członkowie zespołu projektowego
- wygrywasz wtedy, gdy zdobywasz jak największą ilość pieniędzy
- reguły zdobywania pieniędzy określone są poprzez standardy obowiązujące w zespole
Szybko okazało się, iż programiści i testerzy są bardzo wytrawnymi graczami. Często wygrywali...,ale:- pokrycie testami było idealne, lecz: testowane były gettery, settery, testy bardziej przeszkadzały niż pomagały
- programiści szacowali idealnie co do dnia, ale bardzo, ale to bardzo pesymistycznie
- testerzy znajdowali tysiące błędów, ale większość z nich dotyczyła nadmiarowych spacji w labelkach, braku kropek itp
- standard kodowania był przestrzegany, ale tam gdzie było można programiści i tak pisali po swojemu
- retrospekcje upadły; standardy przestały się rozwijać, w końcu stały się nieadekwatne do obecnej sytuacji i przeszkadzały w pisaniu
Konflikt wartościZnajomy metodolog zajmujący się badaniem hierarchii wartości u pracowników (bywa, iż firmy chcą wiedzieć co jest dla Ciebie ważne: rozwój, profesjonalizm, bezpieczeństwo, kariera i w jakiej kolejności) wyłożył mi cierpliwie, iż w żadnym poważnym teście nie zestawia się wartości istotnych w miejscu pracy z wartościami typu: rodzina, zdrowie, gdyż te pierwsze zawsze muszą przegrać. Gdy test nie szanuje tej zasady, to otrzymujemy zafałszowane dane, gdyż wyniki testu będą "skrzywione" w kierunku właśnie rodziny, zdrowia itp. W sumie logiczne, iż gdy mam do wyboru karierą versus trwały uszczerbek na zdrowiu, to motywowany samozachowawczym instynktem, będę chronił swoje zdrowie, choćby kosztem kariery.
W omawianym wyżej zespole, kierownicy popełnili właśnie ten metodologiczny błąd No, bo jeżeli wybieram między zmieszczeniem się w szacowaniach (nawet jeżeli trzeba by ociupinkę je zawyżyć), a gwiazdkowymi prezentami dla rodziny, to szacowanie będzie idealne - choćby nie wiem co! I wcale nie w tym rzecz, iż jesteśmy źli, upadli, oszuści. Nic z tych rzeczy. Tak jesteśmy skonstruowani, a granica między rzetelnym oszacowaniem a nieco zawyżonym jest tak płynna, tak rozmyta, iż bardzo łatwo i bardzo gwałtownie racjonalizujemy sobie drobne jej przekroczenia. Myślę, iż większą winę ponosi ten, kto doprowadził do sytuacji sprzyjającej takiemu postępowaniu, niż ten kto rzeczywiście tak postępuje.
Opłakane skutkiPonieważ przestrzeganie standardów było tylko środkiem do celu, standardy przestały się rozwijać, przestały żyć. W niczyim interesie nie było modyfikowanie standardów i ulepszanie ich. Po zmieniać i komplikować sposób na zarabianie, skoro już mam opracowane sposoby wygrywania?
Motywowanie pieniędzmi jest w porządku, gdy w działaniu ludzi o pieniądze przede wszystkim chodzi. Weźmy takich na przykład sprzedawców. W uproszczeniu: sprzedawca sprzedaje produkt/usługę i przynosi pracodawcy fakturę, od której otrzymuje procent. To będzie działać. Ale jeżeli sprzedawca będzie dostawał premię za ilość spotkań, to znów zaczyna się GRA. Bo oto może się okazać, iż spotkania są i owszem, ale z firmami, które prawdopodobnie nigdy nie zostaną naszymi klientami. Kto za to ponosi odpowiedzialność? Przede wszystkim ten, kto stworzył GRĘ.
Gdy Twoi pracownicy pracują kreatywnie (tu programiści) i zasady pracy muszą dojrzewać i ulepszać się wraz z nimi, to nigdy przenigdy nie wolno uzależniać wynagrodzenia od ich przestrzegania. Takie działanie zabije kreatywność i zasady pracy gwałtownie się usztywnią.
Przestrzegaj standardów "bo warto"By standardy w zespole działały i ewoluowały muszą być ważne tak po prostu. Ludzie muszą widzieć w nich wartość, muszą chcieć ich przestrzegać, muszą dostrzegać, iż dzięki nim stają się lepsi. Tak właśnie działali pierwsi członkowie zespołu z naszego obrazka. Wtedy standardy będą ewoluowały, a ludzie będą chętnie je rozwijać. W przeciwnym razie ryzykujesz, iż standardy będziesz wprowadzał sam, siłowo, albo dzięki nowo zatrudnionych członków Komitetów Standaryzacyjnych i tak skomplikujesz zasady GRY, iż już nikt nie połapie się o co w ogóle na samym początku chodziło.
A co z pieniędzmi?Opisaną scenę można by streścić następująco: Motywuj ludzi pozafinansowo, ale płać im dobrze...:) W sumie nic dziwnego - jeżeli podstawowe potrzeby nie są zaspokojone, to nie ma co myśleć o tych wyższych. Oczywiście, iż potrzeba tu wyważenia, złotego środka, w końcu każdy budżet jest ograniczony. "Płacić dobrze" zwykle nie oznacza "więcej niż konkurencja". Może być choćby mniej w zamian za inne pozafinansowe dobra. To jest sprawa bardzo indywidualna i chcę robić nieuprawnionych uogólnień.
