Ten blog post jest o tym jak nie deprawować pracowników. Przeczytasz tutaj o pomyśle jak można wykonać pierwszy krok i zmodyfikować sposób dodatkowego wynagradzania, tak aby w efekcie końcowym pozytywnie wpłynąć na wynik finansowy firmy. Pisze o tym dlatego, ponieważ klasyczne podejście do premii jest moim zdaniem dysfunkcyjne i nie pasujące do zwinnych organizacji. Inspiracja, aby zająć się tematem premiowania i stawiania oczekiwań przyszła po wysłuchaniu pewnego zakłopotanego managera.
Nie mam nic przeciwko chodzeniu na 7 rano do pracy, ale te 8 godzin czekania na wyjście to już przesada – pewien programista
Klasycznie
Powyższy cytat jest doskonałą ilustracją środowiska jaki tworzą systemy premiowe. Jeśli pensja jest za przychodzenie do pracy to premia za co… Nie jestem zwolennikiem systemów premiowych, gdyż powodują one moim zdaniem więcej szkody niż pożytku. Do tej pory nie udało mi się zaobserwować systemu premiowego, który wnosiłby coś pozytywnego. Możliwość obdarowania pracownika „marchewką” daje przełożonemu poczucie, że „osiołek” będzie maszerował w kierunku wyznaczonego celu. W praktyce chęć otrzymania „marchewki” jest źródłem wielu nadużyć prowadzących w efekcie do kiepskiej jakości. Jak to możliwe, że stosowany od dawien dawna system kar i nagród w przypadku projektów IT szkodzi.
Powodem jest niewłaściwa i często nieadekwatna presja. W mojej pracy zdarzało mi się obserwować dyrektorów naciskających na zespół deweloperski, aby „dopchnął kolanem” release, bo od tego zależała również jego premia roczna. Oczywistym jest, że nie takiego zachowania oczekują sponsorzy. Znany mi jest również przykład organizacji w której ustanawiane były tzw. cele „stretchingowe”, czyli takie których nie dało się osiągnąć. Obiecywano pracownikom przysłowiowe gruszki na wierzbie. Oni odpłacali się tym samym i obiecywali, że zrobią wszystko by osiągnąć te cele. Z kolei inny manager dużej organizacji zadał mi kiedyś pytanie „co zrobić, aby po każdym Sprincie pracownicy nie ustawiali się po miskę ryżu?” Człowiek siedzi w tym Scrumie i zapomina, że w dalszym ciągu dalekowschodnie techniki zarządzania są na topie!
Gdy pracownikom uda się jakoś udźwignąć presję to robią to ponieważ są wielbicielami gotowanego ryżu. W momencie kiedy wypłacana jest premia nikt nie zadaje sobie pytania czy łatwo będzie utrzymywać aplikację, którą właśnie wypuściliśmy. Przynajmniej nie zadaje tego pytania nagłos. W efekcie po kilku latach diety ryżowej pracownicy dochodzą do wniosku, że ryż smakuje najlepiej na greenfieldzie i trzeba przepisać system „na nowo”. Tym razem już „na pewno” bez stosowania wzorca projektowego „murzyńska chata”.
Inaczej
Opisana powyżej sytuacja jest jedną z głównych przyczyn trudności w rozwijaniu produktów IT. Stosowanie marchwi jako motywatora jest źródłem wielu dysfunkcji. Zostało to podkreślone przez twórców Agile Manifesto w trzecim punkcie. Generalnie każdy manager dąży do sformułowania takiego systemu, który zapewni maksymalną wydajność. Pracownik z reguły chce po prostu, jak najmniejszym wysiłkiem otrzymać dodatkowe środki na utrzymanie rodziny itp. itd. Wypracowanie zasad premiowania jest poprzedzone negocjacjami w czasie których każda ze stron próbuje okopać się na jak najlepszej pozycji. Wszystko to dzieje się z reguły w atmosferze braku zaufania i podejrzliwości. Jak zatem może to wyglądać inaczej? Poniższy pomysł jest skierowany do osób będących po obu stronach barykady projektów.
Odwróć zasady
Pierwszy pomysł jest skierowany do osób zarządzających organizacją i ustalających ramy jej działania. Bezpośrednia inspiracja przyszła do mnie podczas wystąpienia pewnego managera. Opowiadał on o braku pomysłów na poradzenie sobie z problemem premii dla deweloperów. Stosowane przez jego firmę sposoby na premiowanie nie przynosiły zadowalających efektów. Z opisu sytuacji i pracowników wywnioskowałem, że są to młodzi ludzie, a kulturze tej firmy panuje przekonanie „premia musi być”. Ta postawa deweloperów skojarzyła mi się z „gangsterami” szantażującymi swoim odejściem. W tym momencie przypomniałem sobie film z lat 90 po tytułem „Młodzi gniewni”. Michelle Pfeiffer grała w nim role nowej nauczycielki w jednej z nieciekawych szkół na Bronxie. Jej sposobem na zaangażowanie uczniów w pracę nad sobą był prosty zabieg. Każdy z uczniów na początku semestru otrzymał „w ciemno” najwyższą ocenę i jedyne co musiał zrobić… to ją utrzymać do końca semestru. To nowatorskie podejście do oceniania wzbudziło w jej podopiecznych zaciekawienie i zaangażowanie. Nikt nie chciał stracić dobrej oceny.
Takie podejście jest również tym czego oczekuje najaktywniejsza obecnie grupa pracowników, czyli millenialsi. Pokolenie Y oprócz częstej informacji zwrotnej na temat swoich działań, chce szybkiego zaspokojenia swoich potrzeb. Dopiero w drugiej kolejności są gotowi podjąć wyzwanie. Wielu managerów nie potrafi skutecznie odpowiedzieć na to oczekiwanie, gdyż kiedy oni zaczynali panowały odwrotne zasady. To niedopasowanie rodzi konflikty.
Urealnienie systemu
W świecie agile często zamieniamy kolejność działań i sięgamy po automatyzację, aby skrócić pętlę informacji zwrotnej. Podobnie jest w przypadku tego pomysłu. Rozmawiając z zespołem zadeklarujmy wypłatę premii na początku okresu i umówmy się z nimi na proste reguły. Idealnie gdyby można było te reguły zautomatyzować i zwizualizować. Rozwiejemy wtedy wątpliwości co i kiedy spowoduje ewentualny zwrot/utratę premii. To stworzy ramy dla tego eksperymentu. Ta, wydawałoby się kosmetyczna zmiana, spowoduje moim zdaniem wzrost zaangażowania. Dlaczego? Ponieważ, jak wynika z badań Daniela Kahnemana, wszyscy mamy większą tendencję do unikania strat niż do zwiększania zysku. Dodatkowo to podejście zwiększy transparentność zasad. Jasne reguły znane na początku pozwolą zespołowi dowolnie często monitorować zgodność i korygować swoje działania.
Oczekiwanie jakości
Pierwszy element niewiele pomoże jeżeli jednocześnie nie zbudujemy właściwego oczekiwania dotyczącego rezultatu. Chcąc, aby nasz produkt rozwijał się długo i szczęśliwie powinniśmy oczekiwać jakości. Bez dbania o podejście inżynierskie w krótkim czasie nagromadzimy tak duży dług techniczny, że jakakolwiek zmiana będzie wymagała zwiększonego wysiłku. Na domiar złego pojawią się najpewniej awarie. Obie sytuacje mają niepożądany wymiar ekonomiczny. W dalszym ciągu są firmy w których jakość nie jest najważniejsza. Zwykle pada ona ofiarą budżetów, terminów i dodatkowych, często niepotrzebnych „ficzerów”. Szkoda, bo jakość jest właśnie tym czego tak naprawdę oczekują klienci.
My również powinniśmy tego oczekiwać, gdyż wiąże się to bezpośrednio z rentownością projektu i w dalszej perspektywie z sukcesem rynkowym naszej firmy. Raport National Institute of Standards & Technology z 2002 roku pokazuje bezsprzeczną relację jakości wytwarzanego oprogramowania oraz kosztu związanego z późniejszym utrzymaniem. Z badań tych wynika, że w skrajnym przypadku koszt naprawy błędu znalezionego w produkcyjnym systemie może być, aż 2900 razy droższy, niż korekta dokonana w początkowej fazie. Relację tą obrazowo pokazuje poniższy wykres.
Stawiając oczekiwanie wysokiej jakości na pierwszym miejscu, przed oczekiwaniem „wypalenia” całego zakresu i czasem realizacji, dajemy sobie szansę na unikniecie sporych i zbędnych kosztów związanych z utrzymaniem „naklepanego” kodu. Zwykle ten koszt jest ukryty, bo nikt go nie liczy na późniejszych etapach projektu. Dodatkowo najprawdopodobniej zmniejszy się presja na programistach. Bezcennym profitem będzie przede wszystkim zadowolony z poziomu usługi klient, który do nas wróci lub będzie w stanie nas polecić jako solidną firmę.
Under the bridge
Moim marzeniem jest, aby zespoły wypuszczając rozwiązanie na produkcję dokonywały uprzednio takiego testu jaki przeprowadza inżynier projektujący most. W czasie testów obciążeniowych wyładowane po brzegi ciężarówki wjeżdżają na most, a projektant konstrukcji ze stoickim spokojem czeka na wynik testów pod mostem. Ze spokojem ponieważ wie co zaprojektował. Ciężko o większy dowód zaufania do jakości oddawanego produktu. W przypadku katastrofy budowlanej i zawalenia się mostu użytkownicy straciliby najprawdopodobniej życie. Troszeczkę przesadzając można by powiedzieć skoro użytkownicy ryzykują życiem codziennie korzystając z jego konstrukcji to dlaczego projektant jako pierwszy nie miałby podjąć takiego ryzyka.
Z drugiej strony czy powyższe stwierdzenie to faktycznie przesada? Tego typu zachowania można napotkać w innych dziedzinach naszego życia. Na przykład wielu prezesów spółek giełdowych dobrowolnie wdraża w życie postawę pod nazwą „skin in the game”. Oznacza to, że nie tylko mówią o przyszłych wynikach finansowych zarządzanej przez nich firmy, ale również dają temu dowód nabywając pokaźny pakiet akcji. W przypadku złego zarządzania otrzymują oni natychmiastową informacje zwrotną w postaci spadającej wyceny spółki na giełdzie.
Produkcja oprogramowania jest relatywnie młodą gałęzią gospodarki. Obecnie bardzo dużo mówi się o software craftsmanshipie, słusznie przyrównując produkcję oprogramowania do rzemiosła. Mimo to branża IT dopuszcza ciągle asymetrię odpowiedzialności niespotykaną w tak starych profesjach jak np. budownictwo. Przyczyn jest tutaj pewnie kilka. Według mnie bardzo trafnie to nazywa Nassim Taleb w 3 rozdziale „Antykruchości„. Organizacje chcąc być jak najfajniejsze usunęły ze swego środowiska wszelkie stresory (ależ to słowo strasznie brzmi) zastępując je „skrobanymi marcheweczkami”. Pozbawiają się tym samym trudnych, ale wartościowych i bardzo potrzebnych informacji. Bez takiej pętli informacji zwrotnej ciężko o realny rozwój pracowników.
Mówiąc obrazowo wydaje się, że perspektywa wielu organizacji jest podobna. Albo zdecydujemy się wejść pod most, sami podejmując ryzyko i potwierdzając naszą rzetelność, albo i tak tam się znajdziemy… Za jakiś czas, bo stracimy wiarygodność i tym samym klientów.
Praktyka
Wróćmy do naszego eksperymentu. Podstawowym oczekiwaniem w kwestii jakości powinno być stosowanie podejścia Test First. Jest to praktyka znana z eXtreme Programmingu i polega na uprzednim zaprojektowaniu testów automatycznych, a następnie przejściu do implementacji rozwiązania. Praktyka ta bardzo dobrze wpływa na jakość kodu i pomaga również wyłapać potencjalne błędy w logice biznesowej funkcjonalności. Stworzone w ten sposób testy mogą być wykorzystane przez zespół do ciągłego sprawdzania warunków „kontraktu premiowego”.
W przypadku testowania możemy mówić o wielu poziomach i typach testów. Analogią przeprowadzenia testów obciążeniowych mostu jest wykonanie dla naszej aplikacji testów akceptacyjnych pokrywających obszary funkcjonalności, wydajności i bezpieczeństwa. Mam świadomość, że wiele organizacji nie korzysta z jakichkolwiek testów automatycznych. Rzadko kiedy można z dnia na dzień zacząć stosować wiarygodne testy na wszystkich poziomach. Jeżeli nie mamy nic to zacznijmy od serwera ciągłej integracji i stopniowo rozszerzajmy zasięg testów. Zacznijmy od scenariuszy dla testów manualnych, a w dalszych krokach podejmijmy wysiłek automatyzacji testów. Wyznaczy to kierunek podnoszenia jakości produktu i będzie wartością dodaną z przeprowadzenia opisywanego tu eksperymentu.
Wizualizacja
Kluczowa dla powodzenia eksperymentu jest informacja zwrotna, która powinna być łatwo dostępna dla wszystkich. Bardzo popularne są telewizory pokazujące aktualny stan środowiska na którym są wykonywane testy. Geekowska subkultura wytworzyła tak wyrafinowane gadżety jak miniaturowe wyrzutnie piankowych rakiet. Urządzenie takie połączone z naszym serwerem ciągłej integracji udziela natychmiastowego feedbacku delikwentowi, który popsuł aktualną wersje kodu! Ciekawym pomysłem o którym słyszałem jest również zainstalowanie sygnalizatora drogowego w gabinecie prezesa. W oczywisty sposób podnosi to rangę inicjatywy. Jakkolwiek te pomysły mogą się komuś wydać mocno zabawowe to są one właściwie tym samym, co branża motoryzacyjna zna pod nazwą „stop the line”.
Wartość dodana
Oprócz obsłużenia tematu premii, która „i tak musi być” mogą pojawić się dodatkowe pozytywy. Bardzo prawdopodobnym jest, że wprowadzenie wysokopoziomowego celu spowoduje wzrost współpracy pomiędzy zespołami oraz pracownikami. Wspólny, ważny i wysokopoziomowy cel stymuluje współpracę znacznie bardziej, niż indywidualne cele typu „zrób to i osiągnij tamto”. Budując cel dotyczący jakości dajemy pracownikom cel na który maja bezpośredni wpływ. Wprowadzając ten eksperyment w życie przekierujemy nacisk z czasu dostarczenia rozwiązania na sposób jego wykonania. Dzięki temu dajemy sobie szanse na budowanie naszej konkurencyjności rynkowej w oparciu o jakość, zamiast o slogan „tanio i szybko”.
Zanim zaczniesz…
Jak każdy pomysł, również ten wymaga przygotowania i sprawdzenia różnych ewentualności, które mogą wystąpić w Twojej organizacji. Możliwość jego wdrożenia mocno zależy od aktualnego kontekstu organizacji. Nie bez znaczenia jest również postawa, którą przyjmiesz. Nauczycielce ze wspomnianego wcześniej filmu naprawdę zależało na zmianie zachowania swoich uczniów. Była widocznie zaangażowana w zmianę. Opisany tutaj eksperyment jest próbą wykorzystania jakże istotnego dla każdego tematu premii do rozpoczęcia dialogu wewnątrz firmowego. Dialogu o kierunku, który wzmocni naszą organizację, a nie wręcz przeciwnie.
Eksperyment ten może być etapem przejściowym do normalizacji zasad panujących w organizacji, wzmocnienia etyki postępowania osób tam pracujących i w efekcie być może całkowitego pominięcia systemu premiowego. Gdyż jak powszechnie wiadomo, od czasu publikacji Dana Pinka „Drive” gotowany ryż, oskrobane marcheweczki oraz inne zewnętrzne motywatory nie są tym po co powinniśmy sięgać myśląc o długofalowym rozwoju i wzroście.
Postscriptum
Na koniec chciałbym wspomnieć Radka i podziękować mu za inspiracje oraz feedback.