Jak zniechęcić do programowania?

Marek Rafałowicz · 04/04/2006 · Link

W jaki sposób można (nieświadomie) zniechęcić programistów do pracy? Jak sprawić, by praca przestała sprawiać im frajdę? Dlaczego młodzi kierownicy mają tendencję do demotywowania zespołu? Pierwsza część artykułu na temat motywowania programistów.

Mówiąc o motywacji w kontekście pracy najczęściej mamy na myśli zwiększanie zarobków, udział w zyskach firmy, służbowe telefony, laptopy i samochody. Pomijając kwestię, czy czynniki te są skuteczne, to należą one (bądź nie), do polityki danej firmy i kierownik projektu (lider zespołu programistów) nie zawsze ma możliwość sterowania nimi. Mimo to właśnie on ma kluczowy wpływ na postawę pracownika.

Rozważania o motywowaniu warto zacząć nieco przekornie od tego,

W jaki sposób zniechęcić do pracy?

Jest kilka metod, które zastosowane mniej lub bardziej świadomie mogą zniechęcić do solidnej pracy:

• Ograniczenie samodzielności
• Ignorowanie wyników
• Nieumiejętna krytyka
• Karanie za błędy
• Poczucie porażki

Przyjrzymy się w jaki sposób działają one w praktyce.

Ograniczenie samodzielności

Praca informatyka jest działalnością twórczą. To oznacza, że nie może zostać zredukowana do "zakodowania" dokładnie podanego pomysłu. Jeżeli pomiędzy programistą a kierownikiem wytwarza się układ, w którym programista nie ma żadnej swobody w kształtowaniu swojego rozwiązania, udziału w rozwiązywaniu problemów, organizacji czasu pracy, używa narzuconych narzędzi, jeśli jego potencjał jest wykorzystywany tylko w zakresie znajomości pisania w języku programowania a nie rozwiązywaniu trudnych zadań, to satysfakcja z wykonanej pracy będzie niewielka. W konsekwencji trudno będzie pracownikowi wykrzesać w sobie entuzjazm do następnych rutynowych zadań.

Samodzielność idzie w parze z odpowiedzialnością. Jeżeli pracownik dostaje ścisłą instrukcję wykonania zadania, jego zakres odpowiedzialności nie może być jest wielki. Jeżeli ma sporo swobody, realną możliwość wybrania sposobu rozwiązania oraz poczucie bezpieczeństwa na wypadek popełnienia błędów (o czym więcej napiszę innym razem), to wzrasta jego odpowiedzialność. I jest to czynnik mocno motywujący, zarówno jako forma "odwdzięczenia" się za otrzymane zaufanie, jak i ze względu na troskę o swój własny obszar działalności (produkt, projekt, zadanie).

Problem ograniczonej samodzielności związany jest często z niewłaściwym zrozumiem roli kierownika. Dotknąć to może zwłaszcza osoby, które awansowały na to stanowisko, bo były dobrymi programistami. Mimowolnie pojawia się wtedy tendencja do rozwiązywania problemów i przekazania "najlepszego" rozwiązania programiście. Rolą kierownika powinno być raczej właściwe przedstawienie problemu do rozwiązania, wymagań, kontekstu biznesowego a następnie zapewnienie odpowiedniego wsparcia pozwalającego pracownikowi na jego samodzielne rozwiązanie. Nawet, jeśli przez to rozwiązanie wykonane przez pracownika nie będzie tym najbardziej optymalnym (w ocenie kierownika).

Innym powodem ograniczania samodzielności bywa brak zaufania do osoby podwładnej. Taka sytuacja jest zasadniczo destrukcyjna dla motywowania pracownika. Jeżeli w ocenie przełożonego pracownik nie jest w stanie podołać przydzielonemu zadaniu, to zamiast ręcznego sterowania powinno się albo zmienić przydział zadań, albo zapewnić pracownikowi wsparcie (szkolenia, literatura, konsultacje), by - poświęcając więcej czasu i ryzykując gorsze rozwiązanie - umożliwić mu rozwój jego umiejętności.

Ignorowanie wyników

Jeśli wysiłek, który wkłada pracownik w solidne wykonanie zadania zostanie zignorowany i jeśli takie ignorowanie jest stałą praktyką w zespole, to za każdym następnym razem wykonawca będzie się starał trochę mniej, bo "przecież nikomu na tym zależy". Dobrze byłoby, gdyby zakończenie każdego zadania kończyło się odbiorem przez kierownika. Ważne, by przy tej okazji został włożony wysiłek w faktyczne obejrzenie rozwiązania, ocenę, przekazanie życzliwych uwag. Brak takiego podkreślenia zakończenia zadania może być odebrany jako brak szacunku do wykonawcy i jego pracy.

W ramach podsumowania można posłużyć się następującym prostym schematem:

• podkreślić, co zostało wykonane dobrze,
• wskazać, co można było zrobić lepiej,
• zasugerować, jak usprawnić to następnym razem.

Jeżeli kierownik nie ma dobrego pomysłu, w jaki sposób usprawnić działanie (punkt 3), to powinien się w ogóle wstrzymać z krytyką (punkt 2). "Brzydko programujesz" nie będzie odebrane jako mobilizujące do przyszłych działań.

Nieumiejętna krytyka

Wbrew przyjętemu powszechnie przekonaniu, że aby pomóc innej osobie się usprawnić, należy jak najszybciej wytknąć jej błędy i niedociągnięcia, nie jest to wcale dobra metoda. Takie działanie może prędko doprowadzić do zniechęcenia. Ciągłe krytykowanie pracownika doprowadzi go w końcu do przekonania, że to co robi nie jest fajne i nic nie będzie w stanie go skłonić do rzetelnego zaangażowania się w pracę.

Bardziej skutecznym sposobem jest pozytywne motywowanie. Pochwalenie, docenienie, zauważenie pozytywnych rezultatów działań. To oczywiście nie powinno oznaczać ciągłego chwalenia niezależnie od rezultatów, bo to doprowadzi do deprecjacji ocen kierownika, ale nie powinny być pomijane okazje do uczciwego pochwalenia solidnie wykonanego zadania. Wbrew powszechnej opinii, chwalenie nie doprowadzi do rozpuszczenia pracownika a raczej może powodować, że będziej bardziej lubił swoją pracę.

Rola pochwały jest jeszcze większa, gdy zostanie wygłoszona publicznie. Jest wtedy bardziej wartościowa dla osoby, która została doceniona, a ponadto może oddziaływać motywująco na pozostałych członków zespołu, bo zwykle reakcją na usłyszenie takiej pochwały, jest chęć dorównania i powtórzenia sukcesu kolegi/koleżanki. Należy tu jednak zastrzec - nie zawsze musi tak być. Jeżeli menadżer nie jest szanowany z zespole, to jego pochwała wcale nie musi być odebrana pozytywnie ani przez chwalonego, ani przez jego kolegów. Co więcej wyróżnianie niektórych osób w zespole może stanowić przeszkodę w jego integracji. Tak więc chwalenie jest silnym narzędziem, ale powinno być stosowane z dużym wyczuciem.

W pewnych sytuacjach trzeba jednak przekazać pracownikowi sygnał krytyczny. Często w takich sytuacjach panuje nerwowa atmosfera i dlatego warto sobie przypomnieć, czemu ma służyć krytyka. Nie uprawia się jej w celu wyładowania negatywnych emocji, wytknięcia winy, pokazania swojej wyższości, tylko w celu pomocy pracownikowi w uniknięciu podobnych sytuacji w przyszłości. Mając to na względzie dbajmy, by krytyka była konkretna, uzasadniona, dotyczyła sytuacji, zachowań, rozwiązań, pomysłów a nie samej krytykowanej osoby i jej cech. Z oczywistych względów taką rozmowę lepiej odbyć na osobności.

Karanie za błędy

Sprawny przebieg projektu wymaga odwagi w podejmowaniu decyzji na różnych szczeblach: od elementarnych na poziomie programistów, aż po kluczowe podejmowane przez kierownictwo. Zwykle nawet podjęcie nieoptymalnej decyzji jest lepsze niż zwlekanie z jej podjęciem. Ale odwaga w podejmowaniu decyzji w projekcie wymaga zapewnienia uczestnikom poczucia bezpieczeństwa.

Jak wobec tego zniechęcić ludzi do działania? Zabrać im poczucie bezpieczeństwa. Odpowiednio zareagować na błędy - rozliczać za ich konsekwencje. Typowe pytania zadawane po wykryciu problemu: "kto to zrobił? kto jest za to odpowiedzialny? jak można było do tego dopuścić?" skutecznie zniechęcają uczestników do podejmowania ryzyka.

Jeżeli zespół ma działać sprawnie, to na popełnianie błędów musi być wyraźna zgoda, bo są one nieodłączną częścią niebanalnej pracy, jaką jest tworzenie oprogramowania. Reakcją na błąd powinno być szukanie wyjścia z sytuacji i wsparcie osoby, która je popełniła (jeżeli jest zaangażowana, to już sama dostatecznie się napiętnuje). Takie podejście powinno być stosowane bardzo konsekwentnie - kapitał zaufania gromadzi się powoli a stracić można po jednej publicznej egzekucji.

Poczucie porażki

Jeżeli zadanie przydzielone danej osobie jest źle dobrane do jej umiejętności, zdolności i zainteresowań, to szanse zakończenia go sukcesem są niewielkie. A nikt nie lubi smaku porażki. Jest jeszcze gorzej, gdy takie zadanie jest na ścieżce krytycznej i gdy w konsekwencji sukces całego przedsięwzięcia jest zagrożony. Wtedy w nieunikniony sposób problem zostanie wyeksponowany na forum zespołu lub firmy.

Idealnie zadania powinny być dobrane tak, by stanowiły dobre wyzwanie dla wykonujących je osób. By rozwiązanie związanych z nimi problemów było w zasięgu ręki, ale było na tyle niebanalne, by przyniosło wykonawcy sporą satysfakcję. Dobrze gdy zadanie jest postrzegane przez wykonawcę jako część większej całości (etapu projektu lub wytwarzanego produktu). Wtedy jego realizacja przynosi nie tylko indywidualną satysfakcję, ale również wzmacnia poczucie wspólnoty z całym zespołem.

Zadania ewidentnie nudne, nierozwojowe czy schematyczne są niestety nie do uniknięcia; dobrze by były sprawiedliwie dzielone pomiędzy członków zespołu.

W następnej części przedstawione zostanie wprost dlaczego programiści lubią swoją pracę i jakie to ma znaczenie dla ich motywowania.

Więcej na temat motywowania

The Human Factor - Gerard M Blair - zarządzanie zespołem dla inżynierów

---