Blog

Jak zwiększyć motywację zespołu? Jak podkręcić „ownership” w zespole? Jak spowodować, by developerzy zaczęli wykazywać inicjatywę? Czemu zespół tak słabo utożsamia się z produktem, który wytwarza?

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 developerskich, które w efekcie tracą zdolność, a może i chęć, do szukania efektywniejszych sposobów pracy i budowania lepszych produktów. A nierzadko zamieniają się w zombie-teamy 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 meta-przyczyn:

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 i 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.

W tej krótkiej liście zupełnie celowo nie wymieniam pieniędzy, bo one nie są nigdy (albo prawie nigdy) celem same w sobie. Chęć ich posiadania jest pochodną innej potrzeby, zupełnie nie związanej z finansami. Jeśli ludzie coś robią dla pieniędzy, to dlatego, że pieniądze te coś im umożliwią lub zaspokoją jakąś potrzebę. Na przykład pozwolą wesprzeć szlachetny cel lub zrobić coś, co ma dla danej osoby duże znaczenie. Lub zapewnią pozycję, dzięki której możliwe będzie podejmowanie decyzji i wpływanie na otaczającą rzeczywistość (w tym innych ludzi). Dzięki pieniądzom można też zyskać niezależność niezbędną do robienia rzeczy, które nas rozwijają, pieniądze pozwalają poznawać świat…

A czy motywujący mnie cel może być istotny z powodów ekonomicznych (czyli jednak ze względu na pieniądze)? W pewnym sensie tak, jeśli te pieniądze służyć mają czemuś istotnemu. Natomiast nawet wtedy nie da się postawić znaku równości między pieniędzmi, które ja otrzymuję za pracę, a pieniędzmi wygenerowanymi przez efekty mojej pracy. Z tego, że dobrze mi płacą za wysiłek na rzecz niezrozumiałego celu moja motywacja do osiągania tego celu raczej nie wzrośnie. Za to jeślibym pracował na rzecz organizacji charytatywnej za małe pieniądze, budując dla niej mechanizmy, które pozwolą jej skutecznie pozyskiwać środki na prowadzenie działalności, zapewne byłbym bardzo zaangażowany w to co robię.

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

Problem 1: przede wszystkim musimy dostarczać

Bardzo trudno o zaangażowanie i motywację 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ć”, a na dyskusje o nowych pomysłach i zmianie sposobu pracy przyjdzie „kiedyś” czas.

W tym modelu miarą sukcesu staje się dotrzymanie arbitralnie ustalanych terminów albo wykazanie się produktywnością nie niższą, niż oczekiwana. Sam produkt odsuwa się gdzieś na drugi plan. Warto zdać sobie sprawę, że w organizacji funkcjonującej w oparciu o takie zasady 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 ponad to.

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 do pracy.

A jeśli pracy łatwo nie da się zmienić? Lub jeśli da się „ograć” system służący do mierzenia, czy „dowożenie” odbywa się z odpowiednią prędkością? Pojawia się wtedy zaangażowanie, ale nie przynoszące niczego pozytywnego. Celem nie jest bowiem tworzenie wartościowych rozwiązań, ale wykazanie się produktywnością i wszystkie usprawnienia temu służą.

Problem 2: marny produkt

Dużo lepiej funkcjonują zespoły, których celem działania nie jest jedynie „dowieźć 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 to coś, co jest robione niepotrzebnie, ale na razie nie ma sposobu, by zmienić kierunek działania…

Inny problem to produkt, w który nikt nie wierzy – być może poza jego pomysłodawcą. Fakt, że na genialny pomysł biznesu lub Product Ownera wzrusza ramionami zespół, który miałby go realizować, nie zawsze oznacza, że developerzy mają wszystko w głębokim poważaniu. W istocie są oni pierwszym klientem, któremu również należy „sprzedać” produkt. Jeśli go nie „kupią”, jest to silny sygnał, że reakcja rynku może być podobna. Zamiast na siłę szukać sposobu na uzyskanie zaangażowania ludzi w budowę takiego produktu, może sensowniej zbudować coś innego?

Problem 3: architekci wiedzą lepiej

Jeśli już jest atrakcyjna wizja produktu, z którą wszyscy się zgadzają, zespół wciąż może wycofać się i przejść do trybu zombie. Dzieje się tak często dlatego, że ich udział w przedsięwzięciu sprowadza się do realizacji pomysłów i koncepcji innych grup: projektantów, architektów, UX itd.

Skutkiem jest poczucie utraty „właścicielstwa” w stosunku do rozwiązań, jakie zespół buduje. Owszem, to wytwór ich pracy, ale odzwierciedla decyzje kogo innego. Poczucie wpływu na to, co i jak jest robione, jest często mierne, albo w ogóle go brak. Po kilku błędach „decydentów”, w wyniku których developerzy musieli radzić sobie z nieprzewidywanymi problemami, relacje i zaufanie między zespołem i otoczeniem są w najlepszym razie w kryzysie, a jak robi się nieprzyjemnie, naturalnym odruchem jest wycofanie.

W efekcie w dłuższej perspektywie ciężko nakłonić taki team do zaproponowania własnych rozwiązań lub choćby spróbowania jakiejś nowej praktyki albo narzędzia, bo odruchowo odsyłają dręczącego ich osobnika a to do Product Ownera, a to do architektów, a to do managementu.

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ę 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 poszerzyć dostępne dziś spektrum możliwości.

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 sztandarach niesione są hasła takie jak „Agile” czy „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ę osiągnięcie nowych celów – i zespół to rozumie – 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.

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 „kiedyś” rzutować będzie na poziom zaangażowania. 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ę tam pojawić motywacja i zaangażowanie?

Problem 6: najważniejsze są procesy

Widywałem zespoły, które robią 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 są generalnie 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 jasnym stanie się, że mniej ważne od tego, co robimy, jest to, jak opisujemy to w dokumentach i raportach, w końcu machniemy ręką na produkt i wszystko co w 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 procesowymi. Niewykluczone, że mimo zmiany pracy podejrzewają nowe otoczenie i obecnego pracodawcę o wszystko, co najgorsze. Tu przydaje się dobry management (albo dobry Scrum Master, jeśli mamy taką rolę), który zauważy problem i pomoże wyjść ludziom ze skorupek, w które się pochowali.

Problem 8: opresyjny management

A skoro już o wsparciu ze strony managementu wspominam – może być niestety tak, że postawa zarządzających nie wspiera, tylko zabija zaangażowanie.

Nierzadko intencja firmy co do pracy zespołowej jest torpedowana przez sposób zarządzania ludźmi, w którym każdy dostaje indywidualne cele i jest z nich rozliczany. W tym modelu fokus będzie zawsze na „mój plan” a nie jakiś tam mniej lub bardziej abstrakcyjny produkt. Ciężko przecież od ludzi wymagać przedkładania dobra 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 mówić o zaangażowaniu zespołu, bo w istocie mamy do czynienia nie z zespołem, ale zaledwie grupą ludzi pracujących wspólnie.

Podejście managementu może nakładać się z jednoczesnym karaniem za wszelkie niepowodzenia i próbą kontrolowania, 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 przyjęcie postawy gotowości do pójścia gdzie indziej. 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

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 testerowi itd., to zamiera umiejętność pracy zespołowej. Powoli rozmywa się odpowiedzialność (zamiast „ja swoje zrobiłem” pojawia się „myśmy swoje zrobili”), a gdy zaczyna się wszystko sypać odbywa się klasyczna gra w co-złego-to-nie-my.

W takim środowisku zaangażowanie i poczucie właścicielstwa produktu byłoby ryzykowne, bo oznaczałby chęć do wzięcia na siebie odpowiedzialności za skutki pracy innych grup niż moja własna.

Problem 10: zaangażowanie traktowane jako wymaganie

Jednym z nieoczywistych, ale skutecznych sposobów na zamordowanie w zespole chęci do angażowania się w cokolwiek jest wytykanie ludziom paluchem przez management, 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 to wiele czynników, z których tylko niektóre są pod kontrolą zespołu.

Dlatego jeśli wydaje się komuś, że zespół ma 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. Niewykluczone bowiem, że okaże się, że poziom motywacji jest naprawdę wysoki, jeśli popatrzymy na niego w odpowiednim kontekście. Wtedy jedynym sposobem, by go podnieść, 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 zombie-developera 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 developerzy są współtwórcami produktu a nie jedynie wykonawcami poleceń, tym większe zaangażowanie i silniejsze poczucie „ownershipu” się pojawi.

Oczywiście o ile w tle nie będzie kontr-produktywnych działań managementu, 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ć… Plus ważne, 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 na początku walczą z osunięciem się w marazm. 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, bo przecież „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, bo 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ć, raczej nie warto zwlekać tylko trzeba dążyć do wyeliminowania przyczyn, dla których zaangażowanie zaczyna zanikać.