Zacznijmy od przykładu. Poniższe scenki opisują różne stany motywacyjne u pięciu deweloperów.
Dawid
Dawid spogląda na zegarek. 17:58. Ma dość tego kodu, który właśnie skończył. Uruchamia go raz lokalnie. Działa? Działa. Zamyka konsolę i widzi plik module_x_test.ts w bocznym pasku. Wzdycha. Testy? Po co marnować czas? „Przecież nikt nie dotknie tego kodu przez kolejne pół roku, a nawet jeśli, to na etapie integracji wyjdzie”. Jego palce wystukują git push --no-verify. Dźwięk zamkniętego ticketa jest jak wybawienie. Ma kolejne zadanie z głowy i może iść na siłownię. Dawid wierzy w szybkie zwycięstwa, nawet jeśli są to zwycięstwa z krótkim terminem ważności.
Ania
Ania kończy pracę nad nową funkcjonalnością. Jest zmęczona. Wie, że jeśli nie napisze testów, jej PR zostanie zablokowany przez automatyczny gatekeeper. W zespole nazywają to „Podatkiem od Wprowadzenia Kodu”. Otwiera plik testowy i pisze minimalną liczbę asercji, które tylko dotykają nowej logiki. Nie testuje przypadków brzegowych, błędów, ani stanów wyjątkowych. Testy przechodzą. Przekracza próg 50% pokrycia. W komentarzu PR wpisuje: „Dodano testy jednostkowe”. Cel osiągnięty. Nie ma znaczenia, czy testy faktycznie chronią moduł, byleby maszyna przepuściła.
Przemek
Przemek wie, że jest oceniany. Menadżer ogłosił ostatnio program premiowy dla zespołów z 70% pokrycia. W ich firmie panuje zasada, która uniemożliwia proste pisanie pustych testów, ale nikt nie sprawdza jakości asercji. Przemek odnajduje stary, gigantyczny test integracyjny z innego modułu. Kopiuje go niemal w całości, zmieniając tylko import i nazwę klasy. Ma teraz 82% pokrycia. Fakt, że 90% z tych testów testuje funkcje getter i setter w encjach, jest nieistotny. Na dashboardzie widnieje piękna, zielona cyfra. A premia przyda się na urlop.
Paula
Paula patrzy na wskaźnik pokrycia swojego kodu. W głębi duszy uważa, że tutejsze wymagania są przesadzone, ale wizja, że ktoś z zespołu uzna ją za słabą programistkę, jest zbyt nieprzyjemna, żeby go ignorować. Dwa miesiące temu udało się jej przenieść do tego zespołu i bardzo zależy jej, żeby dobrze wypaść i się tu zadomowić. Dlatego siada i tworzy testy, które wyglądają „jak trzeba”. Pisze je nie dlatego, że ma to dla niej sens — lecz dlatego, że chronią ją przed wstydem i poczuciem winy, jeśli coś się później wysypie. Testy są dla niej przede wszystkim normą społeczną, nie narzędziem inżynierskim.
Michał
Michał uważał testy za nudne, dopóki nie zobaczył, jak Paweł wprowadza drobną zmianę w jego kodzie. I to na jego prośbę, bo trzeba to było skończyć, a on musiał pojechać z dzieckiem do lekarza. Zobaczył, ile czasu zajęło Pawłowi zrozumienie, jakie były jego intencje w tak zrobionej implementacji. Od tamtej pory podejście Michała się zmieniło. Dostrzega, o ile łatwiej pracuje się na czyimś kodzie, jeśli jest uzupełniony dobrymi testami. Pisze testy, które służą jako dokumentacja i siatka bezpieczeństwa dla zespołu. Michał lubi swój zespół i pisze testy z poczucia koleżeńskiej odpowiedzialności. Wie, że są innym potrzebne. Jak czasami robi fuchy na boku, to nie chce mu się w to bawić. Swój kod przecież ogarnia.
Tomek
Dla Tomka pisanie testów nie jest dodatkowym zadaniem — jest samym aktem inżynierii. Pisze je często równolegle z logiką, bo pomagają mu myśleć i wykrywać niespójności. Uważa, że rezygnacja z testowania jest jak rezygnacja ze sprawdzenia silnika, który się właśnie złożyło. Przecież wiadomo, że trzeba zobaczyć jak pracuje, a potem coś poprawić i jeszcze raz sprawdzić. Inaczej to nie ma sensu. Dla Tomka nie ma znaczenia, czy ktoś od niego tego wymaga. Dla niego to kwestia tożsamości profesjonalisty.
Paweł
Moduł płatności od roku generował sporadyczne, trudne do powtórzenia błędy. Paweł podszedł do tego jak do wielkiej, programistycznej zagadki kryminalnej. Spędził sporo czasu, analizując awarie i projektując sieć testów, która miała wytropić wystąpienie błędu. Gdy ostatni test, symulujący niefortunny zbieg okoliczności w asynchronicznych operacjach, zaświecił się na czerwono, poczuł podekscytowanie. To było jak escape room, zabawa w zagadki. Teraz, mając pełne pokrycie przypadków brzegowych, z radością zabiera się za docelowy refaktoring. Czuje, że jego praca nie polega na pisaniu kodu, ale na rozwiązywaniu problemów, które mają realny wpływ na firmę. I ma z tego niesamowitą frajdę.
Motywacja to zagadkowa rzecz. Ten ją ma, tamten nie ma, ta ją straciła, a tamta odzyskała. Zupełnie jakby motywacja była przedmiotem, a nie stanem wewnętrznym. Za tym idzie marzenie, żeby machnąć różdżką i spowodować jej pojawienie się. Kto nie chciałby mieć zespołu, który jest proaktywny, odpowiedzialny, nastawiony na rozwój i zaangażowany? Smutna wiadomość jest taka, że nie istnieje taka różdżka. Dobra jest natomiast taka, że można osiągnąć znacznie więcej, niż większość osób się spodziewa.
Zanim wyjaśnię, jak można pracować nad motywacją, uporządkujmy to, co o niej wiemy. Teoria autodeterminacji stworzona przez Ryana i Deciego (Self-Determination Theory) opisuje motywację oraz czynniki wpływające na powstawanie różnych jej rodzajów. Badania prowadzone na całym świecie pokazują jej wpływ na wydajność, satysfakcję, czy rozwiązywanie złożonych problemów. Motywacja jest przez autorów przedstawiona jako continuum: od tej kontrolowanej wyłącznie przez czynniki zewnętrzne do takiej, która jest całkowicie autonomiczna. Wyróżnione są kolejno następujące rodzaje motywacji:
Motywacja zewnętrzna — działanie w celu uzyskania nagrody (może nią być też pochwała) lub uniknięcia kary (dezaprobaty, krytyki). Aby taki rodzaj motywacji działał, konieczna jest ciągła obecność motywatora. Przykładowo: uczniowie rozwiązują zadania tylko wtedy, gdy nauczyciel patrzy, a pracownicy pracują głównie dlatego, że im za to płacą. (Ania, Przemek)
Wewnętrzna kontrola (uwewnętrzniona motywacja zewnętrzna) — działanie podejmowane po to, by uniknąć poczucia winy lub wstydu. Choć te uczucia są wewnętrzne, powstają w wyniku uczenia się i dostosowywania do zewnętrznych oczekiwań. Badacze ten i poprzedni rodzaj motywacji uznają za motywację kontrolowaną (przez czynniki zewnętrzne). (Paula)
Motywacja wynikająca ze zrozumienia ważności — osoba podejmuje działanie, ponieważ rozumie, że jest ono ważne lub że dana czynność jest komuś potrzebna. Sama czynność może nie być dla niej istotna, ale akceptuje powody, dla których trzeba ją wykonać. (Michał)
Motywacja oparta na zgodności z własnymi wartościami i postawami — dane działanie jest dla osoby ważne, utożsamia się z nim i chce tak postępować. Jest ono spójne z jej celami. Ten i poprzedni rodzaj to motywacje autonomiczne. (Tomek)
Wszystkie cztery wymienione do tej pory rodzaje motywacji pochodzą pierwotnie z zewnątrz — różni je jedynie stopień, w jakim zostają przyjęte za własne. Istnieje także motywacja wewnętrzna, czyli taka, gdy osoba robi coś dla przyjemności, jaką jej to sprawia (Paweł), oraz amotywacja, czyli brak motywacji (Dawid). Zobacz, jak to wygląda na schemacie. Podano na nim również psychologiczne nazwy poszczególnych rodzajów motywacji, żeby umożliwić samodzielne poszukanie informacji.
Skoro już rozumiemy, na czym polegają poszczególne rodzaje motywacji, przyjrzyjmy się ich dynamice — temu, jak się zmieniają w czasie. Pozostaniemy przy przykładzie testów.
Do firmy przychodzi nowy pracownik. Podczas rekrutacji dowiedział się, że będzie musiał pisać jakieś specyficzne testy. Chcąc uniknąć dezaprobaty (lub zyskać akceptację), zacznie je pisać (pierwszy rodzaj motywacji – zewnętrzna). Jeśli będzie pracował w zespole, w którym wszyscy piszą te testy, po pewnym czasie zacznie to robić, bo czułby się nieswojo, gdyby ich nie napisał (drugi rodzaj – unikanie poczucia winy lub wstydu).
Jeżeli jednak zostaną zaspokojone potrzeby określone w teorii autodeterminacji, po pewnym czasie będzie rozumiał, dlaczego te testy są istotne, i będzie przekonany do ich pisania (trzeci rodzaj – zrozumienie ważności). Gdy te potrzeby będą zaspokojone w odpowiednim stopniu, pracownik sam stanie się orędownikiem ich pisania, traktując je jako coś zgodnego z jego wartościami i sposobem, w jaki chce tworzyć oprogramowanie (czwarty rodzaj – zgodność z własnymi celami i postawami).
Opisany proces to transformowanie wymagań, które na początku pochodziły z zewnątrz na standard, którego sami chcemy przestrzegać, bo jest częścią naszej tożsamości.
Najczęściej praca złożona, wymagająca intelektualnie i koncepcyjnie — a taka jest praca osób tworzących oprogramowanie — składa się zarówno z czynności przyjemnych, jak i nużących, trudnych lub po prostu nieciekawych. Dlatego ważne jest posiadanie motywacji wewnętrznej, która pozwala czerpać przyjemność z wykonywanej pracy, oraz motywacji autonomicznej, która umożliwia odczuwanie satysfakcji i wspiera wytrwałość. Połączenie tych dwóch rodzajów motywacji pozwala wykonywać zarówno czynności, które nas ekscytują, jak i te mniej atrakcyjne, lecz potrzebne.
Możesz się zastanawiać, czy procent pracy, który sprawia przyjemność, nie powinien być większy. Niekoniecznie. Przyjemność to uczucie ulotne, podczas gdy satysfakcja, poczucie własnej skuteczności i zadowolenie z siebie są długofalowe. Dlatego, choć warto dbać o pojawianie się przyjemnych momentów, nie należy ich przeceniać.
Dodaj komentarz