Blog

Na szkoleniach dotyczących Agile często pojawiają się osoby piastujące w organizacjach stanowiska kierownicze, lub przedstawiciele działów nie związanych wprost z rozwojem oprogramowania (na przykład kadr). To dobrze, bo zwinność wymaga samoorganizacji zespołów, a ta jest możliwa tylko w miejscu, gdzie taka koncepcja zarządzania jest rozumiana i choć trochę akceptowana. Zresztą, praktyki Agile mogą usprawnić nie tylko software development…

Obecność wśród uczestników managerów lub nie-developerów powoduje, że muszą nieuchronnie paść dwa pytania:

1. Jak oceniać developerów i inne osoby pracujące w metodach zwinnych?
2. Jak nagradzać i awansować takie osoby?

Gdzieś w tle pobrzmiewa obawa, że przejrzystość i samoorganizacja leżąca u podstaw empirycznej kontroli procesów nie do końca zgrywa się z „przepisami”. Bo przecież oceny pracowników i przyznawanie premii w ich opinii to procesy, w których zatrudnieni biorą udział wyłącznie indywidualnie, wszystko jest poufne. Więc gdzie tu miejsce na przejrzystość i decyzje zespołowe?

Jeszcze bardziej w tle czai się bardziej fundamentalne pytanie o to, czy aby metody zwinne nie wyrywają z rąk managerów i działów kadr władzy nad pracownikami, pozbawiając ich narzędzia do nagradzania i karania, a tym samym kształtowania postaw i moderowania nastrojów.

Po co w ogóle to robić?

Czy zastanawialiście się kiedykolwiek nad rzeczywistym celem, dla którego zatrudniająca was organizacja ocenia pracowników? Czy ten cel jest w praktyce osiągany? Kto i jak decyduje o awansach?

Zadaję te przewrotne pytania, bo w wielu firmach łatwo odnieść wrażenie, że nagrody i awanse jedynie osładzają pracownikom irytujący, często stresujący i bezduszny zbiór procedur, który służy czemuś zupełnie niezrozumiałemu. Znam firmy, które „normalizują” oceny pracowników tak, by rozłożyły się one w założony z góry schemat (co zmusza do szukania na siłę tych, których trzeba ukarać za złe efekty, nawet jak każdy dał z siebie wszystko i problemów brak). Znam też firmy, w których dzięki systemom oceny to działy kadr dyktują managerom developmentu kogo, kiedy i w jaki sposób traktować (choć pojęcia nie mają jak merytorycznie ocenić programistę czy testera).

Zadajcie sobie te pytania w kontekście miejsca, gdzie jesteście. I zastanówcie się co zamierzacie zrobić z odpowiedziami, które wam się wyłonią.

Zróbmy sobie zbiorowo krzywdę

Najczęściej podawane jest piękne uzasadnienie: trzeba motywować pracowników. Przy czym wiele procedur oceny i nagradzania jest skonstruowanych tak, że pracownicy bardziej cieszą się z braku kary niż z otrzymanej nagrody. Efektywnym ich celem jest więc takie działanie, by nie podpaść. W takim miejscu naprawdę ciężko o samoorganizację, bo ludzie zaczynają się bać odpowiedzialności za podejmowane decyzje.

Warto zadać sobie przy okazji kolejne pytanie: jeśli dajemy ludziom nagrody za to, że robią to, do czego ich zatrudniliśmy, i musimy to robić aby ich do tego zmotywować to… po co w ogóle ich zatrudniliśmy? Jeśli bez nagrody nie są zmotywowani, ani nie będą profesjonalnie wykonywać swojej pracy, może lepiej by odeszli? Pytanie, wbrew pozorom, nie jest retoryczne i warto poszukać na nie odpowiedzi. Warunki zatrudnienia (pensja i tak zwane benefity) nie powinny być podstawowym powodem, dla którego ktoś u nas się zatrudnia. Jeśli tak jest, ucieknie jak tylko ktoś da mu lub jej więcej.

Gdy pensje są godziwe, reguły awansowania jasne i przejrzyste, nagrody motywują dużo mniej niż możliwości rozwoju, poczucie wpływu na organizację i to, co ona wytwarza, relacje między ludźmi, możliwość realizowania misji społecznej, osiągania mistrzostwa i tak dalej. W tym sensie pieniądze mogą być motywatorem wyłącznie negatywnym: gdy jest ich za mało lub rozdzielane są niesprawiedliwie i w niejasny sposób, pojawiają się problemy w relacjach między ludźmi.

Czasami oceny, nagrody i awanse to narzędzie pozwalające manipulować ludźmi. Obietnice awansu, przekupstwo przy pomocy bonusów, nastawianie ludzi przeciw sobie – to rzeczywistość wielu firm. W praktyce jest to patologia, nie służąca ani pracownikom, ani pracodawcy.

Bywa, że stosowany jest prymitywny model kija-marchewki: jak pracujesz ponad siły – dostaniesz bonus, jak coś zawalisz – karę finansową. Pracownicy „wykazują” się za wszelką cenę pracowitością, niekoniecznie są przy tym efektywni. To również patologia, nikomu nie dająca faktycznych korzyści, a często wiodąca do wypalenia zawodowego tyrających ponad siły ludzi.

Jak zrobić to lepiej?

Najpierw warto zadać sobie pytanie o cel, jaki firma chciałaby osiągnąć. Potem poszukać sposobu na osiągnięcie tego celu nie poprzez awanse i nagrody.

Oczywiście należy też dbać o wynagrodzenia, aby nie pojawiło się poczucie, że jest się niedocenionym przez firmę. Całkiem nieźle zadziała uzależnienie pensji od wykształcenia, doświadczenia zawodowego i stażu pracy w firmie – reguły te mogą być jawne i wszystkim znane. Trzeba pomyśleć o automatycznym indeksowaniu płac o wskaźnik inflacji. Jeśli wynagrodzenia mają składnik podstawowy i premię, ta ostatnia powinna zależeć po prostu od kondycji lub rentowności firmy, a niekoniecznie od wydumanej lub wyliczonej w niejasny sposób oceny pracownika.

Tu pojawi się wątpliwość: traktowanie wszystkich po równo może być demotywujące, bo przecież niektórzy się lenią, a inni wybijają ponad przeciętną. Tak, to się zdarzy, ale nagradzanie i karanie w takich przypadkach nie wymaga ciężkiej machiny procesowej z całą masą odpowiedzialnych za nią ludzi. Każdy ma jakiegoś szefa, który powinien wiedzieć, co się dzieje w podlegającym mu kawałku organizacji. Jeśli ktoś zasłuży na nagrodę, szef jawnie powinien ją przyznać. Jeśli kogoś trzeba ukarać, podstawą takiej decyzji i tak powinny być opinie lub wnioski o interwencję współpracowników tejże osoby. Nikt nie będzie zaskoczony decyzjami, jakie kierownik podejmie.

Dlaczego miałoby to być lepszym rozwiązaniem niż „end-year appraisal”, „DPM” i inne „performance review”? Cóż, większość decyzji dotyczących pracowników będzie albo obiektywnie wynikać z jasnych reguł, albo będzie wypracowana w bezpośredniej komunikacji między grupą pracowników a jej szefem. Reguły proste, możliwe do zmiany za obopólną zgodą, do tego pracownicy mają poczucie traktowania podmiotowego a nie przedmiotowego.

Agile a oceny i nagrody

Wróćmy do tego jak oceniać i nagradzać w Agile.

Podstawą większości (być może wszystkich) metod zwinnych jest zespół developerski samodzielnie zarządzający swoją pracą. To oznacza, że oceniany powinien być cały zespół, nie pojedyncze osoby. Jeśli nie dochodzi do sytuacji wyjątkowych, sprzyja to samoorganizacji. Jeśli takie wyjątkowe sytuacje się pojawią, na przykład w zespole jest krańcowo niekompetentny lub konfliktowy developer, pozostali „poradzą sobie” z tym problemem wnioskując wprost do szefa o usunięcie go z grupy.

A zatem:

1. Oceniajmy zespoły, nie jednostki – chyba że zespół sam poprosi o pochylenie się nad konkretną osobą z jego składu.
2. Nagradzajmy zespoły, a nie jednostki.

Ten model nie zamyka drogi do nagradzania i awansowania za szczególne osiągnięcia, ale wtedy odbywa się to poza standardowym procesem. Ktoś pomógł zawrzeć nowy kontrakt, choć wydawało się to niemożliwe? Stworzył nowy produkt, który przynosi firmie zysk? Opatentował nowe rozwiązanie w imieniu firmy? Przeszkolił współpracowników i pozwolił im usprawnić sposób działania? Zaproponował innowacyjne zmiany w procesie i pomógł je wdrożyć? Wtedy firma (czasem nawet osobiście sam CEO) powinna nagrodzić, a jakże!

Toż to komunizm w czystej formie…

Otóż nie. Mamy jasne reguły i ci, którym one nie odpowiadają, powinni odejść. Brzmi to brutalnie, ale dla zdrowia organizacji i zatrudnionych w niej ludzi tak jest po prostu lepiej. Nie ma nic gorszego niż niejasne zasady i jad sączący się w relacje międzyludzkie, oraz trauma po dorocznym sabacie „ocen pracowniczych”.

Niektóre zwinne organizacje zamiast systemu ocen stosują systemy punktów, które pracownicy przyznają sobie wzajemnie: za pomoc, zrobienie czegoś lepiej niż inni, innowację, cokolwiek co wyda się pozytywne. Punkty mogą dawać wszyscy, nie tylko managerowie – więc nie jest to system ocen jako takich. Bonusy przyznane są na zespoły, a korzystając z punktów można je łatwo podzielić proporcjonalnie między developerów. Brak zaskoczonych, zawiedzionych lub pokrzywdzonych, czyż nie?

Bardziej odważni managerowie po prostu przyznają bonusy zespołom prosząc je, by samodzielnie rozdysponowały kwotę między siebie. To niekoniecznie zadziała w dużych firmach i w przypadku każdego zespołu, ale jest niewątpliwie interesującym i sprawiedliwym rozwiązaniem. Dlaczego? Ci, którzy potrafią ze sobą skutecznie współpracować, potrafią dokonać podziału nagrody tak, by odzwierciedlała ona rzeczywisty wkład poszczególnych osób. A jak nie potrafią, cóż… może lepiej, by rozeszli się w różne strony.

Perspektywa jest ważna

Dokonując oceny zawsze warto popatrzeć „poziom wyżej”. Chcemy ocenić wartość indywidualnych developerów – oceniajmy zespoły, których są częścią. Jeśli będą słabym ogniwem, zespół świadom takiego modelu oceny dość szybko pozbędzie się osoby, która go nieracjonalnie spowalnia i się nie rozwija. Chcemy ocenić zespoły – popatrzmy na efekty działu, w którym pracują i wartość produktu, jaki wytworzyli. Chcemy ocenić produkt i dział, który go rozwija – popatrzmy na całą organizację.

O czym warto pamiętać

Nagrody nie mogą być przesadnie przewidywalne, bo wtedy staja się czymś normalnym. Tak dzieje się, gdy nagradza się nie za szczególne osiągnięcia, ale dlatego, że „pracownikom się należy”. Za co? Tego często nikt nie potrafi powiedzieć.

Co więcej, jeśli ktoś spodziewa się bonusu wypłacanego z rozdzielnika w ustandaryzowanym procesie, „przyzwyczai” się do niego zanim zostanie wypłacony. Gdy już to się stanie, efektu „wow” najczęściej brak, a nagroda mniejsza niż spodziewana może być katastrofalna dla morale.

Dlatego tak ważne jest by nagrody nie były jeszcze jednym składnikiem pensji (uznaniowym), ale czymś wypłacanym w sytuacji, gdy zespół, firma albo nawet jedna osoba osiągnie coś więcej, niż się spodziewano.

Kto za to odpowiada?

Na koniec narażę się pewnie wielu osobom, ale i tak to napiszę: warto zastanowić się nad tym, kto w organizacji definiuje zasady, wedle których awanse i nagrody są przyznawane. Często bardzo mocno zaangażowane są w to działy kadr, nierzadko narzucając swoje reguły wszystkim managerom, zmuszając do niesprawiedliwych porównań zupełnie niepodobnych do siebie działów, arbitralnie rozdzielając wypracowane zyski między managerów…

Tymczasem pracownicy kadr nie mają żadnych szans na realną ocenę tego, co dzieje się w zespołach developerskich. Żaden feedback 360 stopni, systemy ocen, szczegółowe plany rozwoju i rozliczanie z nich nie da tej wiedzy. Brak wiedzy prowadzi do wypaczeń w procesie decyzyjnym.

Szczególna rola pracowników działu kadr w tym procesie powinna redukować się zatem do dbania o poziom kadry zarządzającej poprzez doradztwo i dbanie o przestrzeganie prawa i kodeksów etyki firmy, jeśli takowe istnieją. Ale to managerowie powinni podejmować decyzje, będąc blisko zespołów, z którymi pracują.

Zarządzanie w Agile

Code Sprinters posiada w ofercie szkolenia dla osób pracujących na stanowiskach kierowniczych. Na przykład szkolenie Management 3.0 może być źródłem inspiracji, dać nową perspektywę i dostarczyć narzędzi.

W Agile ważna jest odpowiednia postawa leaderów, którzy powinni rozumieć czym jest służebne przywództwo, z czym wiąże się samoorganizacja zespołów i jak nie zdusić jej w zarodku. Kursy Professional Scrum Master oraz Agile Coaching Academy są podstawą dla Scrum Masterów (co oczywiste), ale pomogą także innym managerom, włączając w to właścicieli firm pracujących zwinnie.

Code Sprinters prowadzi też dedykowane warsztaty dla managerów zainteresowanych metodami pracy zwinnej – prosimy o kontakt z nami.