Blog

Jak zwiększyć motywację Developerów? Jak podkręcić w nich poczucie własności narzędzi, procesu i samego produktu? Jak spowodować, by Developerzy zaczęli wykazywać inicjatywę? Czemu Developerzy tak słabo utożsamiają się z produktem, który wytwarzają?

To tylko kilka z pytań, jakie padają na szkoleniach dla Scrum Masterów i Product Ownerów, lub które otrzymuję mailem. Wskazują na istotny problem braku motywacji w Zespołach Scrum, a w praktyce u Developerów, którzy wydają się wyzuci z ochoty na poszukiwanie efektywniejszych sposobów pracy i budowania lepszych produktów. A nierzadko zamieniają swój Zespół w zombie, czyli grupę ludzi przychodzących do pracy tylko po to, by dostać przyzwoitą pensję i dopisać nową linijkę do CV.

Skąd bierze się motywacja?

Chęć do podejmowania wysiłków i brania na siebie odpowiedzialności za decyzje może mieć wiele źródeł, ale stosunkowo łatwo zredukować je można do trzech metaprzyczyn:

1. Zależy mi na tym, co robię, bo działam na rzecz celu, który z jakiegokolwiek powodu (społecznego, światopoglądowego etc.) ma znaczenie i jest wart osiągnięcia.
2. Jestem zaangażowany, bo mam poczucie wpływu na to, co i w jaki sposób jest robione oraz mam związane z tym przekonanie o byciu poważanym, istotnym elementem procesu (a nie jedynie trybikiem w maszynie).
3. Chcę doskonalić siebie, rozwijać własne możliwości i umiejętności (często poprzez przekraczanie zdawałoby się niemożliwych do pokonania przeszkód lub własnych ograniczeń), chcę stać się w czymś prawdziwym mistrzem.

Na tej krótkiej liście zupełnie celowo nie wymieniam pieniędzy, bo one nie są nigdy (albo prawie nigdy) celem same w sobie i nie stanowią źródła motywacji. Jeśli ludzie coś robią dla pieniędzy, to dlatego, że umożliwiają im one coś lub stanowią środek do zaspokojenia różnych potrzeb. Motywacją są więc nie same pieniądze, ale to, do czego zostaną użyte. Pozwolą sfinansować działalność organizacji pożytku publicznego, kupić materiały niezbędne do tworzenia dzieła sztuki, zatrudnić programistów do stworzenia przełomowej aplikacji itd. Dzięki pieniądzom można też zyskać niezależność niezbędną do robienia rzeczy, które nas rozwijają, a nie tego, co każą nam robić inni.

To oznacza, że jeśli dobrze nam zapłacą za wysiłek na rzecz celu, który dla nas osobiście jest bez znaczenia, to motywacja do osiągania tego celu raczej od tego nie wzrośnie. Z tego też powodu większość tzw. premii motywacyjnych w firmach ma mizerny wpływ zaangażowanie pracowników, o ile nie są skonstruowane tak, by nagradzać ciężką pracę jako taką – niezależnie od tego, czy jest ona sensowna.

Inaczej mówiąc, da się wygenerować presję, która przełoży się na wytężenie wysiłków przez pracowników, ale nie jest to nigdy motywacja pozytywna. W najlepszym razie ludzie zaczynają się starać bardziej, bo nie chcą zmarnować okazji, by zarobić więcej. Natomiast częściej po prostu boją się konsekwencji, jakie mogą ich spotkać, gdy tego nie zrobią. Wspomniane premie są wtedy w praktyce rekompensatą za funkcjonowanie w nieustannym stresie.

Bez znajomości kontekstu organizacji i Zespołu ciężko wskazać uniwersalne sposoby na podkręcenie zaangażowania. Jest za to kilka kwestii, które na pewno warto wziąć pod rozwagę, jeśli pracuje się Zespołem, w którym problem braku motywacji się pojawia.

Problem 1: przede wszystkim trzeba „dostarczać”

Bardzo trudno o zaangażowanie tam, gdzie ludzi dopada poczucie bycia ograniczanym. Co miałoby ich zmuszać do działania, jeśli nie robią nowych fajnych rzeczy, nie uczą się niczego nowego, lub gdy mają marny albo żaden wpływ na to, co i jak jest robione? Często towarzyszy temu oczekiwanie, że Zespół przede wszystkim będzie „dowozić”, czyli generować kolejne funkcjonalności produktu, a na dyskusje o nowych pomysłach i zmianie sposobu pracy przyjdzie kiedyś czas. Kiedyś, czyli nigdy.

W tym modelu miarą sukcesu staje się dotrzymanie arbitralnie ustalanych terminów albo wykazanie się produktywnością nie mniejszą niż oczekiwana. Sam produkt odsuwa się gdzieś na drugi plan. Warto zdać sobie sprawę, że w organizacji funkcjonującej wedle takich zasad motywacja, jeśli się pojawi, jest odpowiedzią na presję, swoistym dążeniem do uniknięcia porażki. To może wystarczyć do nakłonienia Zespołów do ciężkiej pracy, ale nie pozwoli uzyskać wiele więcej. A już na pewno nie uda się spowodować, by ludzie zabiegali o budowanie lepszego produktu.

Zaangażować można się jedynie w realizację celów, które są zrozumiałe i atrakcyjne dla tych, którzy podejmują wysiłek. Jeśli celem tym jest przetrwanie bez poniesienia negatywnych konsekwencji za nieosiągnięcie planu, Developerzy, zamiast angażować się w budowanie produktu, skupią się być może na poszukiwaniu lepszego miejsca pracy.

A jeśli pracy łatwo nie da się zmienić? Zapewne da się jakoś przechytrzyć system służący do mierzenia, czy „dowożenie” odbywa się z odpowiednią prędkością. Pojawia się wtedy autentyczne zaangażowanie, ale nie przynoszące niczego pozytywnego. Jest bowiem związane nie z tworzeniem wartościowych rozwiązań w produkcie, ale z wykazaniem się produktywnością.

Problem 2: marny produkt

Dużo lepiej funkcjonują Zespoły, których celem działania nie jest jedynie „dowieźć jak najwięcej na czas”, ale też osiągnięcie konkretnych celów lub rozwiązanie istotnych problemów. Im bardziej Zespół utożsamia się z produktem i wierzy w sens jego budowania, tym zaangażowanie większe.

Niestety, w wielu organizacjach budowane są rozwiązania, o których wszyscy mówią, że „zaraz zostaną zaorane” i ciężko znaleźć odpowiedź na pytanie, po co i dla kogo są wytwarzane. Ba, zarządzający produktem (na przykład Product Owner) wprost mówią, że to, co Zespół dostaje do zrobienia, jest niepotrzebnie, ale na razie nie ma sposobu, by przestać się tym zajmować…

Inny problem to produkt, w który nikt nie wierzy – być może poza jego pomysłodawcą. Fakt, że na genialny pomysł interesariuszy lub Product Ownera wzruszają ramionami Developerzy, którzy mieliby go realizować, nie zawsze oznacza, że mają oni wszystko w głębokim poważaniu i brak im motywacji do czegokolwiek. W istocie są oni pierwszym klientem, któremu również należy sprzedać produkt. Ich brak zaangażowania w opisanej sytuacji oznacza, że nie kupują tego produktu, z jakim przychodzi do nich Product Owner. A to silny sygnał, że reakcja rynku może być podobna i być może rozsądniej będzie pomyśleć o budowaniu czegoś innego.

Problem 3: architekci wiedzą lepiej

Jeśli już jest atrakcyjna wizja produktu, z którą wszyscy się zgadzają, Developerzy wciąż mogą przejść do trybu zombie. Dzieje się tak często tam, gdzie ich udział w przedsięwzięciu sprowadza się do realizacji pomysłów i koncepcji innych grup: projektantów, architektów i wszelkiej maści ekspertów, którzy – jak wiadomo – „wiedzą, co należy wytworzyć i w jaki sposób to zrobić”.

Skutkiem jest poczucie utraty poczucia własności w stosunku do rozwiązań, jakie Zespół buduje. Owszem, to wytwór pracy Developerów w tym Zespole, ale odzwierciedla decyzje kogoś, kto częścią Zespołu nie jest. Po kilku błędach „decydentów”, w wyniku których Developerzy zmuszeni są radzić sobie z nieprzewidywanymi problemami, relacje i zaufanie między Zespołem i otoczeniem są w najlepszym razie w kryzysie, a jak robi się coraz bardziej nieprzyjemnie, naturalnym odruchem jest postępujący spadek motywacji.

W efekcie w dłuższej perspektywie ciężko nakłonić kogokolwiek w Zespole do proponowania własnych rozwiązań lub choćby wypróbowania jakiejś nowej praktyki albo narzędzia. Dochodzi często do absurdalnej sytuacji, w której ci, co pozbawili Developerów wpływu na produkt i sposób jego budowania, narzekają na nadmiar roboty i irytują się, że „leniwi Developerzy” za nic nie chcą wziąć odpowiedzialności ani nawet nie raczą w czymkolwiek pomóc, tylko domagają się „precyzyjnych wymagań”. Najczęściej wtedy prosi się Scrum Mastera, by coś z tym zrobił, a on poszukuje (np. na szkoleniach) magicznego zaklęcia, które dokona cudu.

Problem 4: „failure is not an option”

Przyjmijmy, że Zespołom pozwala się decydować o wielu rzeczach i wręcz zachęca się je do tego, by proponowały rozwiązania. Jesteśmy na prostej drodze do sukcesu, o ile ludzie nie są karani za niepowodzenia, wynikające z dążenia do nauczenia się czegokolwiek nowego lub odkrycia nowych możliwości.

Niestety często jest wręcz na odwrót: zachęca się Zespoły do bycia innowacyjnym, ale surowo rozlicza z każdej porażki. A przecież bycie innowacyjnym oznacza podejmowanie działań o nikłym prawdopodobieństwie powodzenia w nadziei, że jednak się uda i pozwoli to pójść drogą, która dziś jest zablokowana.

Kultura organizacji musi być otwarta na eksperymenty, w tym i te, które kończą się niepowodzeniem. Tylko to pozwala się uczyć, a w miejscach, gdzie na serio traktuje się Agile i empiryzm, jest to niezbędne.

Problem 5: kotwica długu technicznego

A jeśli wizja produktu i sposób zarządzania organizacją nie stanowi przeszkody? Rujnujący dla zaangażowania może być stan produktu, z jakim pracować muszą Developerzy – często nie ze swojej winy. Jeśli rozwiązania obarczone są ogromnym długiem technicznym, a jednocześnie ważne staje się szybkie osiągnięcie nowych celów, pojawia się frustracja. Bo fizycznie nie da się tego zrobić.

Wspominany wcześniej imperatyw „dowożenia” za wszelką cenę może również spowodować, że w zupełnie nowym produkcie od samego początku zaczyna się kumulować dług techniczny. Dość szybko można dojść do podobnego stanu: choćbyśmy chcieli, nie da się dalej rozwijać produktu w tempie, jakie jest oczekiwane. Winni stanu spraw? Developerzy, któż inny! A tak naprawdę winę ponosi cała organizacja, natomiast winy Developerów jest w tym tyle, że nie okazali się wystarczająco asertywni i zgodzili się na obniżenie jakości, byleby tylko uzyskać oczekiwaną produktywność.

Konieczne jest poszukanie balansu między czasem wkładanym w sprzątanie kuwety a czasem poświęconym na robienie nowych rzeczy. Frustracja wynikająca z ignorowania oczywistego problemu i odkładania go na później spowoduje erozję poziomu zaangażowania, który będzie spadał wraz z poziomem jakości produktu. Co więcej, ochota na traktowanie technologicznego bubla jako coś swojego, również zniknie. Bo kto chciałby chwalić się, że spłodził potworka powiązanego sznurkami, który w każdej chwili może się rozlecieć? A jeśli nie możemy się czymś chwalić i nie jesteśmy z efektów własnej pracy dumni, to skąd miałaby się pojawić motywacja do zajmowania się tym?

Problem 6: najważniejsze są procesy

Widywałem Zespoły, które budują fajne produkty, na których im zależy, ale borykające się z rozmaitymi ograniczeniami i idiotyzmami (tak, użyję tego słowa zupełnie świadomie) funkcjonującymi w organizacji. Idiotyzmami takimi są wszystkie rzeczy, które empirycznie zidentyfikowano jako szkodliwe, ale których „nie da się zmienić w tej firmie i już”.

Przykładem może być przesadna „raportoza” wymagająca od pracowników rozliczenia się z każdego kwadransa i udowodnienia, że zasługują na pieniądze, które im się płaci. Na dłuższą metę jest ona zabójcza dla zaangażowania, podobnie jak wymóg kreowania zbędnych dokumentów tylko dlatego, że jakiś proces tego wymaga. Pomijając już oczywisty fakt oparcia takiego mechanizmu na braku zaufania i potrzebie kontroli, na pierwszy plan wysuwać się zaczyna zapewnienie, że ludzie są zajęci i ciężko pracują, a nie że pojawiają się sensowne efekty ich pracy.

Zaangażowane Zespoły próbują z tym walczyć, nierzadko stawiając na szali swoją pozycję w organizacji. I to odpowiedź (reakcja) tej ostatniej determinuje, w którą stronę pójdzie Zespół. Jeśli opór zostanie zduszony i organizacja postawi na swoim, nie kłopocząc się przesadnie wyjaśnieniem, dlaczego tak postępuje (witamy w typowej korporacji), Zespoły machną ręką na produkt i wszystko, co z nim związane…

Problem 7: blizny Developerów

Cyniczna postawa „ja tu jestem tylko dla kasy” u paru osób w Zespole może spowodować, że pozostałe też zamkną się w skorupę. Konflikty (niekoniecznie widoczne) spowodują, że każdy zajmie się swoją robotą, we mgle rozpłynie się myślenie o wspólnym celu, wizji produktu i wszystkim, co mogłoby kontrybuować do zaangażowania Zespołu jako całości.

Mniejszy, ale wciąż negatywny skutek może mieć złe doświadczenie ludzi, którzy w innych firmach (u wcześniejszych pracodawców) zetknęli się z patologiami i złym traktowaniem. Niewykluczone, że mimo zmiany pracy, podejrzewają nowe otoczenie i obecnego pracodawcę o wszystko, co najgorsze. Tu kluczowa staje się kultura kadry zarządzającej oraz dobry Scrum Master, jeśli Zespół pracuje w Scrumie. Rośnie wtedy szansa na podjęcie takich działań, które pomogą ludziom wyjść z ochronnych skorup, w które się pochowali.

Problem 8: opresyjne kierownictwo

A skoro już o wsparciu ze strony przełożonych wspominam – może być niestety tak, że postawa kierowników nie wspiera, tylko zabija zaangażowanie.

Nierzadko tak zaangażowanie, jak i chęć do pracy zespołowej są torpedowane przez sposób zarządzania ludźmi, w którym każdy dostaje indywidualne cele i jest z nich rozliczany. W tym modelu każdy będzie zawsze miał swój plan działania, na którym się skupi. Ludzi zupełnie przestanie obchodzić jakiś tam mniej lub bardziej abstrakcyjny produkt. Ciężko przecież od nich wymagać przedkładania dobra tego produktu nad zadbanie o swoją pozycję w firmie, a jeszcze trudniej oczekiwać, że swoim kosztem będą pomagać innym w kryzysowej sytuacji. Bardziej oczywiste jest, że każdy zajmie się udowadnianiem, że „ja swoje zrobiłem”… W tym przypadku ciężko nawet mówić o zaangażowaniu Zespołu, bo w istocie mamy do czynienia nie z zespołem, ale Zaledwie grupą ludzi pracujących nad jednym produktem.

Takie postępowanie kierownictwa może łączyć się z jednoczesnym karaniem za wszelkie niepowodzenia oraz nieustannym kontrolowaniem, czy ludzie na pewno ciężko pracują i nie marnują cennego czasu, za który im płaci firma. W branżach, gdzie o zmianę pracodawcy łatwo, powoduje to machnięcie ręką i złożenie wypowiedzenia najszybciej, jak to możliwe. Developerzy zaczynają bardziej przejmować się tym, co mogą dodać do swego CV niż produktem, jaki budują, czy relacjami z innymi osobami w Zespole. W branżach, gdzie o pracę nie jest łatwo, skutkiem może być unikanie podejmowania decyzji, z którymi mogą wiązać się konsekwencje (kary) i powolne wycofywanie do bezpiecznego kąta.

Problem 9: silosy kompetencyjne

Erozja zaangażowania zajdzie również wtedy, gdy w Zespole następuje podział na grupki, za którym często podąża ukaskadowienie procesu. Jeśli analityk daje wymagania programiście, ten daje kod do sprawdzenia testerowi itd., to zamiera umiejętność pracy zespołowej i dążenia do wspólnego celu. Powoli rozmywa się odpowiedzialność, bo nikt nie chce być odpowiedzialny za ewentualną klęskę. Można często usłyszeć: „ja swoje zrobiłem”, „myśmy swoje zrobili” itd., co stanowi jasny sygnał, że w razie czego winnych należy szukać gdzie indziej.

Tam, gdzie ludzie zaczynają odpychać odpowiedzialność od siebie, nie ma miejsca na zaangażowanie w rozwój produktu. Nie da się przecież jednocześnie dążyć do tego, by produkt był jak najlepszy i starannie unikać podejmowania jakichkolwiek decyzji, z których być może trzeba będzie się potem wytłumaczyć. Inaczej mówiąc, silosy kompetencyjne są szkodliwe nie tylko dla poczucia odpowiedzialności i wynikającej z niego efektywności procesów decyzyjnych, ale też dla zaangażowania.

Problem 10: obowiązek bycia zaangażowanym

Jednym z nieoczywistych, ale nad wyraz skutecznych sposobów na zamordowanie w Zespole chęci do angażowania się w cokolwiek, jest wytykanie Developerom przez kierowników, Scrum Mastera, Product Ownera i każdego, kto czuje się do tego upoważniony, że „wy nie jesteście wystarczająco zaangażowani”. Już sam fakt takiej oceny sugeruje, że jest jakiś oczekiwany poziom motywacji, który należy osiągnąć. A przecież, co starałem się wykazać w tym artykule, wpływa na nią wiele czynników, z których tylko niektóre są pod kontrolą Zespołu.

Jeśli wydaje się komuś, że Developerzy mają problem z niską motywacją, pierwszym krokiem powinno być zrozumienie, jakie są możliwe źródła zaangażowania dla tych konkretnych ludzi, pracujących z tym konkretnym produktem. A także poszukanie czynników, które mogą skutkować spadkiem motywacji. Niewykluczone, że Developerzy mają wewnętrzną motywację, która w jakiś sposób zostaje w nich stłamszona. Wtedy jedynym sposobem, by ją uwolnić, jest usunąć czynniki wpływające na Zespół negatywnie, a nie napieranie na Developerów, by się bardziej zaangażowali w to, co robią.

Czy każdego Developera-zombie można wybudzić…?

Warto pamiętać, że niczego nie uda się zrobić szybko. To raczej mozolne działania, które powoli zmienią status quo. Im lepiej ludzie rozumieć będą produkt i im bardziej wyda im się on sensowny, im większy wpływ na jego budowanie będą mieli i im większe będzie poczucie, że są współtwórcami produktu, a nie jedynie wykonawcami poleceń, tym większe zaangażowanie i silniejsze poczucie własności się pojawi.

Oczywiście o ile w tle nie będzie kontrproduktywnych działań kierownictwa, generowania wyścigu szczurów, rozliczania ludzi za każdy błąd, dzielenia ich na tych, co mają prawo decydować i tych, co mają słuchać… Ważne też, by realne utrudnienia (narzucone kiepskie narzędzia, których nie wolno zmienić na inne, sprzęt nieadekwatny do potrzeb itd.), o ile się ujawnią, zostały szybko usunięte.

Wybudzenie zdemotywowanych Developerów z letargu może okazać się niemożliwe, jeśli pogrążeni w nim byli długo. Wielu Developerów to profesjonaliści, którzy naprawdę długo walczą z osunięciem się w marazm, zanim się poddadzą. Nie czują się komfortowo z refleksją, że to, co robią na co dzień, jest im obojętne (a bywa, że wstrętne). Póki mogą, szukają źródeł motywacji, ale potem, by zredukować poziom frustracji, następuje ucieczka w racjonalizowanie braku zaangażowania. W ten sposób Developer może znów poczuć się lepiej, mówiąc sobie „jestem profesjonalistą, ale w tym miejscu, z takim produktem, z takimi ludźmi, z takim procesem, nie da się pracować”.

Po przekroczeniu pewnej bariery – zapewne różnej dla różnych osób i mocno zależnej od osobistych doświadczeń każdego Developera – jedynie zmiana pracy może wykrzesać na nowo iskrę zaangażowania. Stąd dobra rada: jeśli motywacja w Zespole zaczyna spadać, nie warto zwlekać, tylko trzeba dążyć do wyeliminowania przyczyn, dla których zaangażowanie zaczyna zanikać.