Epigraf:
Mąż, patrząc na brudne dzieci, mówi do żony: cóż, umyjemy je, czy urodzimy nowe?
Poniżej cięcia znajduje się druga część artykułu autorstwa lidera naszego zespołu, a także Dyrektora ds. Rozwoju Produktu RAS Igora Marnata, na temat specyfiki motywowania programistów. Pierwszą część artykułu znajdziesz tutaj -
W pierwszej części artykułu poruszyłem dwa niższe poziomy piramidy Maslowa: potrzeby fizjologiczne, potrzeby bezpieczeństwa, komfortu i stałości, po czym przeszedłem na kolejny, trzeci poziom, a mianowicie:
III - Potrzeba przynależności i miłości
Wiedziałem, że włoska mafia nazywała się „Cosa Nostra”, ale byłem pod ogromnym wrażeniem, gdy dowiedziałem się, jak tłumaczone jest „Cosa Nostra”. „Cosa Nostra” w tłumaczeniu z języka włoskiego oznacza „Nasz biznes”. Wybór imienia bardzo dobrze wpływa na motywację (pomińmy zawód, w tym przypadku interesuje nas tylko motywacja). Osoba zazwyczaj chce być częścią zespołu, robić jakiś duży, wspólny biznes.
Dużą wagę przywiązuje się do zaspokojenia potrzeby przynależności i miłości w armii, marynarce wojennej i wszelkich większych formacjach paramilitarnych. I, jak widzimy, w mafii. Jest to zrozumiałe, bo trzeba zmuszać ludzi, których niewiele łączy, którzy początkowo nie tworzą zespołu podobnie myślących ludzi, których łączy pobór (nie dobrowolnie), którzy mają inny poziom wykształcenia, różne wartości osobiste dosłownie poświęcić swoje życie, narażając się na śmiertelne ryzyko, jakiejś wspólnej sprawie, powierz swoje życie towarzyszowi broni.
To bardzo silna motywacja, dla większości ludzi niezwykle ważne jest poczucie przynależności do czegoś większego, świadomość, że jest się częścią rodziny, kraju, zespołu. W wojsku mundury, różne rytuały, parady, marsze, sztandary i tak dalej służą tym celom. Mniej więcej te same czynniki są ważne dla każdego zespołu. Ważne są symbole, marka i kolory korporacyjne, akcesoria i pamiątki.
Ważne jest, aby znaczące wydarzenia miały swoje własne, widoczne ucieleśnienie, z którym można je skojarzyć. W dzisiejszych czasach raczej normą jest posiadanie własnego towaru, kurtek, T-shirtów itp. Ale ważne jest również wyróżnienie zespołu w firmie. Często wypuszczamy koszulki na podstawie wyników wydawnictwa, które rozdajemy wszystkim osobom zaangażowanym w wydanie. Kolejnym ważnym czynnikiem motywacji są niektóre wydarzenia, wspólne uroczystości czy zajęcia z całym zespołem.
Oprócz atrybutów zewnętrznych na poczucie przynależności do zespołu wpływa kilka innych czynników.
Po pierwsze, obecność wspólnego celu, który wszyscy rozumieją i podzielają ocenę jego ważności. Programiści zazwyczaj chcą zrozumieć, że robią fajną rzecz i robią to razem, jako zespół.
Po drugie, zespół musi mieć przestrzeń komunikacyjną, w której obecny jest cały zespół i która należy tylko do niego (np. czat w komunikatorze, okresowe syncapy zespołu). Oprócz spraw zawodowych, nieformalnej komunikacji, czasem dyskusji o wydarzeniach zewnętrznych, lekkiego offtopu – wszystko to tworzy poczucie wspólnoty i zespołu.
Po trzecie zwróciłbym uwagę na wprowadzenie w zespole dobrych praktyk inżynierskich, chęć podniesienia standardów w stosunku do tych przyjętych w firmie. Wdrażanie najlepszych podejść przyjętych w branży, najpierw w zespole, a potem w całej firmie, daje zespołowi możliwość poczucia, że w jakiś sposób wyprzedza innych, przodując, to buduje poczucie przynależności do fajnego zespołu.
Na poczucie przynależności wpływa także udział zespołu w planowaniu i zarządzaniu. Kiedy członkowie zespołu biorą udział w omawianiu celów projektu, planów pracy, standardów zespołowych i praktyk inżynieryjnych oraz przeprowadzaniu wywiadów z nowymi pracownikami, rozwijają poczucie uczestnictwa, współwłasności i wpływu na pracę. Ludzie znacznie chętniej realizują decyzje podjęte i głoszone przez nich samych niż te proponowane przez innych, nawet jeśli są praktycznie zharmonizowane.
Urodziny, rocznice, ważne wydarzenia w życiu współpracowników – wspólna pizza, drobny upominek od zespołu dają ciepłe poczucie zaangażowania i wdzięczności. W niektórych firmach zwyczajowo wręcza się małe tabliczki pamiątkowe za 5, 10, 15 lat pracy w firmie. Z jednej strony nie sądzę, żeby to mnie tak bardzo motywowało do nowych osiągnięć. Ale oczywiście prawie każdy będzie zadowolony, że o nim nie zapomniał. To jeden z tych przypadków, gdy brak faktu demotywuje, a nie jego obecność motywuje. Zgadzam się, może być trochę wstyd, jeśli LinkedIn przypomni Ci rano i pogratuluje 10-lecia pracy w miejscu pracy, ale żaden kolega z firmy nie pogratulował Ci ani nie pamiętał.
Oczywiście istotnym punktem jest zmiana składu zespołu. Wiadomo, że nawet jeśli przyjście lub odejście kogoś z zespołu zostanie ogłoszone z wyprzedzeniem (na przykład w firmowym biuletynie, zespołowym, na spotkaniu zespołu), nie motywuje to nikogo specjalnie do nowych osiągnięć. Ale jeśli pewnego pięknego dnia zobaczysz obok siebie nową osobę lub nie zobaczysz starej, może to być niespodzianka, a jeśli odejdziesz, wręcz nieprzyjemna. Ludzie nie powinni znikać po cichu. Zwłaszcza w rozproszonym zespole. Zwłaszcza jeśli Twoja praca zależy od kolegi z innego biura, który nagle wstał i zniknął. Zdecydowanie warto o takich momentach osobno i wcześniej informować zespół.
Ważny czynnik, który po angielsku nazywa się własność (dosłowne tłumaczenie słowa „posiadanie” nie oddaje w pełni jego znaczenia). Nie jest to poczucie własności, ale raczej poczucie odpowiedzialności za swój projekt, to uczucie, gdy emocjonalnie kojarzysz się z produktem, a produkt ze sobą. Odpowiada to mniej więcej modlitwie Marine z filmu „Full Metal Jacket”: „To jest mój karabin. Jest wiele takich karabinów, ale ten jest mój. Mój karabin jest moim najlepszym przyjacielem. Ona jest moim życiem. Muszę nauczyć się je posiadać w taki sam sposób, w jaki posiadam swoje życie. Beze mnie mój karabin jest bezużyteczny. Bez karabinu jestem bezużyteczny. Muszę strzelać prosto z karabinu. Muszę strzelać celniej niż wróg, który próbuje mnie zabić. Muszę go zastrzelić, zanim on zastrzeli mnie. Niech będzie…”.
Kiedy człowiek pracuje nad produktem przez długi czas, ma możliwość wzięcia pełnej odpowiedzialności za jego powstanie i rozwój, zobaczenia, jak z „niczego” powstaje działająca rzecz, jak ludzie z niej korzystają, pojawia się to potężne uczucie. Zespoły produktowe, które pracują wspólnie przez dłuższy czas nad jednym projektem, są zazwyczaj bardziej zmotywowane i spójne niż zespoły, które działają na krótki okres czasu i pracują w trybie linii montażowej, przechodząc z jednego projektu do drugiego, bez pełnej odpowiedzialności za cały produkt , od początku do końca.
IV. Potrzeba uznania
Dobre słowo również cieszy kota. Motywacją każdego jest uznanie wagi wykonanej pracy i jej pozytywna ocena. Rozmawiaj z programistami, przekazuj im okresowe informacje zwrotne, świętuj dobrze wykonaną pracę. Jeśli masz duży i rozproszony zespół, doskonale nadają się do tego okresowe spotkania (tzw. jeden na jeden), jeśli zespół jest bardzo mały i współpracuje lokalnie, taka możliwość zwykle jest zapewniona bez specjalnych spotkań w kalendarzu (chociaż spotkania okresowe do jednego to wszystko Nadal jest potrzebne, po prostu możesz to robić rzadziej). Temat ten jest szczegółowo omówiony w podcastach dla menedżerów na stronie manager-tools.com.
Warto jednak pamiętać o różnicach kulturowych. Niektóre podejścia znane amerykańskim kolegom nie zawsze będą działać z rosyjskimi. Poziom grzeczności akceptowany w codziennej komunikacji w zespołach w krajach zachodnich początkowo wydaje się programistom z Rosji przesadny. Pewna prostolinijność charakterystyczna dla rosyjskich kolegów może zostać odebrana przez ich kolegów z innych krajów jako nieuprzejmość. Jest to bardzo ważne w komunikacji w zespole międzyetnicznym, napisano na ten temat wiele, menadżer takiego zespołu musi o tym pamiętać.
Dobrą praktyką pozwalającą zrealizować tę potrzebę są demonstracje funkcji, podczas których programiści pokazują funkcje opracowane w trakcie sprintu. Oprócz tego, że jest to doskonała okazja do oczyszczenia kanałów komunikacji pomiędzy zespołami, wprowadzenia menadżerów produktu i testerów w nowe funkcjonalności, jest to również dobra okazja dla programistów do pokazania wyników swojej pracy i wskazania ich autorstwa. No i oczywiście szlifuj swoje umiejętności wystąpień publicznych, co nigdy nie jest szkodliwe.
Dobrym pomysłem byłoby uczczenie znaczącego wkładu szczególnie zasłużonych kolegów certyfikatami, tabliczkami pamiątkowymi (przynajmniej miłym słowem) podczas wspólnych spotkań drużynowych. Ludzie zazwyczaj bardzo cenią takie certyfikaty i tablice pamiątkowe, zabierają je ze sobą w podróż i w ogóle dbają o nie na wszelkie możliwe sposoby.
Aby zaznaczyć bardziej znaczący, wieloletni wkład w pracę zespołu, zgromadzone doświadczenie i wiedzę, często stosuje się system stopni (znowu można wyciągnąć analogię z systemem stopni wojskowych w armii, który dodatkowo do zapewnienia podporządkowania, służy również temu celowi). Często młodzi programiści pracują dwa razy ciężej, aby zdobyć nowe gwiazdki (np. przejść z młodszego programisty na pełnoetatowego programistę itp.).
Znajomość oczekiwań swoich ludzi jest kluczowa. Niektórych bardziej motywuje wysoka ocena, możliwość zdobycia tytułu, powiedzmy, architekta, inni wręcz przeciwnie, są obojętni na stopnie i tytuły i uznają podwyżkę wynagrodzenia za oznakę uznania ze strony firmy . Komunikuj się z ludźmi, aby zrozumieć, czego chcą i jakie są ich oczekiwania.
Wykazanie uznania, wyższego poziomu zaufania ze strony zespołu, można dać poprzez zapewnienie większej swobody działania lub zaangażowania w nowe obszary pracy. Przykładowo, po zdobyciu określonego doświadczenia i osiągnięciu określonych wyników, programista oprócz wdrożenia swoich funkcji zgodnie ze specyfikacją może pracować nad architekturą nowych rzeczy. Lub zaangażuj się w nowe obszary, które mogą nie być bezpośrednio związane z rozwojem - automatyzacja testów, wdrażanie najlepszych praktyk inżynierskich, pomoc w zarządzaniu wydaniami, wystąpienia na konferencjach itp.
V. Potrzeba poznania i samorealizacji.
Wielu programistów na różnych etapach swojego życia koncentruje się na różnych rodzajach działań programistycznych. Niektórzy ludzie lubią uczyć się maszynowo, opracowywać nowe modele danych, czytać dużo literatury naukowej do pracy i tworzyć coś nowego od zera. Innym jest bliższe debugowaniu i wspieraniu istniejącej aplikacji, w której trzeba zagłębiać się w istniejący kod, badać dzienniki, ślady stosów i captcha sieciowe przez wiele dni i tygodni, a prawie nie pisać nowego kodu.
Obydwa procesy wymagają dużego wysiłku intelektualnego, ale ich praktyczny efekt jest inny. Uważa się, że programiści niechętnie wspierają istniejące rozwiązania, są raczej zmotywowani do opracowywania nowych. Jest w tym ziarno mądrości. Z drugiej strony najbardziej zmotywowany i zjednoczony zespół, z jakim kiedykolwiek pracowałem, był zaangażowany we wspieranie istniejącego produktu, znajdowanie i naprawianie błędów po skontaktowaniu się z nim przez zespół wsparcia. Chłopaki dosłownie żyli tą pracą i byli gotowi wyjść w soboty i niedziele. Kiedyś z zapałem zajmowaliśmy się innym pilnym i złożonym problemem albo wieczorem 31 grudnia, albo po południu 1 stycznia.
Na tę wysoką motywację miało wpływ kilka czynników. Po pierwsze była to firma o dużej renomie w branży, zespół się z nią wiązał (patrz: „Potrzeba afiliacji”). Po drugie, byli ostatnią granicą, za nimi nie było nikogo, nie było wtedy żadnego zespołu produktowego. Pomiędzy nimi a klientami były dwa poziomy wsparcia, ale jeśli problem do nich dotarł, nie było gdzie się wycofać, nikt za nimi nie stał, cała korporacja była na nich (czterech młodych programistów). Po trzecie, ta duża firma miała bardzo dużych klientów (rządy krajowe, koncerny samochodowe i lotnicze itp.) oraz instalacje na bardzo dużą skalę w kilku krajach. W rezultacie zawsze złożone i interesujące problemy, proste problemy zostały rozwiązane poprzez wsparcie poprzednich poziomów. Po czwarte, na motywację zespołu duży wpływ miał poziom profesjonalizmu zespołu wsparcia, z którym współpracował (byli w nim inżynierowie bardzo doświadczeni i zdolni technicznie), a my zawsze byliśmy pewni jakości przygotowywanych przez nich danych i przeprowadzanych analiz itp. Po piąte i myślę, że to jest najważniejsze – zespół był bardzo młody, wszyscy chłopaki byli na początku swojej kariery. Interesowało ich studiowanie dużego i złożonego produktu, rozwiązywanie poważnych, nowych dla nich problemów w nowym środowisku, starali się profesjonalnie dopasować poziom otaczających je zespołów, problemów i klientów. Projekt okazał się świetną szkołą, wszyscy później zrobili dobrą karierę w firmie i zostali liderami technicznymi i menedżerami wyższego szczebla, jeden z chłopaków jest teraz menedżerem technicznym w Amazon Web Services, drugi ostatecznie przeniósł się do Google i wszyscy z nich do dziś ciepło wspomina ten projekt.
Gdyby ten zespół składał się z programistów z 15-20-letnim stażem, motywacja byłaby inna. Wiek i doświadczenie nie są oczywiście czynnikami determinującymi w 100%, wszystko zależy od struktury motywacji. W tym konkretnym przypadku chęć zdobywania wiedzy i rozwoju młodych programistów przyniosła doskonałe rezultaty.
Generalnie, jak już kilkukrotnie wspominaliśmy, trzeba poznać oczekiwania swoich programistów, zrozumieć, który z nich chciałby poszerzyć lub zmienić zakres swojej działalności i uwzględnić te oczekiwania.
Poza piramidą Maslowa: widoczność wyników, grywalizacja i rywalizacja, żadnych bzdur
Są jeszcze trzy ważne punkty dotyczące motywacji programistów, o których zdecydowanie należy wspomnieć, ale wciągnięcie ich do modelu potrzeb Maslowa byłoby zbyt sztuczne.
Pierwszą z nich jest widoczność i bliskość wyniku.
Tworzenie oprogramowania to zwykle maraton. Efekty prac badawczo-rozwojowych stają się widoczne po miesiącach, a czasem i latach. Trudno dojść do celu, który jest daleko za horyzontem, ilość pracy jest przerażająca, cel jest odległy, niejasny i niewidoczny, „noc jest ciemna i pełna okropności”. Lepiej podzielić drogę do niego na części, wyznaczyć ścieżkę do najbliższego drzewa, które jest widoczne, osiągalne, kontury są wyraźne i nie jest daleko od nas - i idź do tego bliskiego celu. Chcemy podjąć wysiłek przez kilka dni lub tygodni, uzyskać i ocenić wynik, a następnie przejść dalej. Dlatego warto dzielić pracę na mniejsze części (sprinty w Agile świetnie sprawdzają się w tym celu). Część pracy wykonaliśmy – nagraliśmy, wydychaliśmy, przedyskutowaliśmy, ukaraliśmy winnych, nagrodziliśmy niewinnych – możemy zaczynać kolejny cykl.
Motywacja ta jest w pewnym stopniu podobna do tej, której doświadczają gracze, przechodząc gry komputerowe: okresowo otrzymują medale, punkty, bonusy po ukończeniu każdego poziomu; można to nazwać „motywacją dopaminową”.
Jednocześnie widoczność wyniku jest dosłownie ważna. Zamknięta funkcja na liście powinna zmienić kolor na zielony. Jeśli kod zostanie napisany, przetestowany, wydany, ale programista nie będzie widział żadnych zmian w statusie wizualnym, będzie on czuł się niekompletny, nie będzie miał poczucia ukończenia. W jednym z zespołów naszego systemu kontroli wersji każda łatka przechodziła przez trzy kolejne etapy – kompilacja została zmontowana, testy zaliczone, łatka przeszła przegląd kodu, łatka została scalona. Każdy etap był wizualnie oznaczony zielonym haczykiem lub czerwonym krzyżykiem. Kiedy jeden z programistów poskarżył się, że sprawdzanie kodu trwało zbyt długo, koledzy musieli przyspieszyć, poprawki wisiały przez kilka dni. Zapytałem, co to właściwie dla niego zmienia? Przecież gdy kod jest napisany, kompilacja złożona i testy przeszły pomyślnie, nie musi zwracać uwagi na przesłaną łatkę, jeśli nie ma komentarzy. Sami koledzy to sprawdzą i zatwierdzą (jeśli znowu nie będzie komentarzy). Odpowiedział: „Igor, chcę jak najszybciej dostać swoje trzy zielone kleszcze”.
Druga kwestia to grywalizacja i rywalizacja.
Tworząc jeden z produktów, nasz zespół inżynierów postawił sobie za cel zajęcie znaczącej pozycji w społeczności jednego z produktów open source, aby znaleźć się w pierwszej trójce. W tamtym czasie nie istniał obiektywny sposób oceny czyjejś widoczności w społeczności; każda z dużych uczestniczących firm mogła twierdzić (i okresowo twierdziła), że jest ofiarodawcą numer jeden, ale nie było prawdziwego sposobu na porównanie wkładu uczestników między sobą, aby ocenić jego dynamikę w czasie. W związku z tym nie było sposobu, aby wyznaczyć zespołowi cel, który można by zmierzyć u niektórych papug, ocenić stopień jego osiągnięcia itp. Aby rozwiązać ten problem, nasz zespół opracował narzędzie do pomiaru i wizualizacji wkładu firm i indywidualnych darczyńców . Z motywacyjnego punktu widzenia okazała się to po prostu bomba. Nie tylko inżynierowie i zespoły stale monitorowali swoje postępy oraz postępy swoich kolegów i konkurentów. Najwyższe kierownictwo naszej firmy i wszyscy główni konkurenci również rozpoczęli dzień od stackalytics. Wszystko stało się bardzo przejrzyste i wizualne, każdy mógł uważnie monitorować swoje postępy, porównywać się z kolegami itp. Wyznaczanie celów stało się wygodne i łatwe dla inżynierów, menedżerów i zespołów.
Ważną kwestią, która pojawia się podczas wdrażania dowolnego systemu wskaźników ilościowych, jest to, że natychmiast po ich wdrożeniu system automatycznie stara się nadać priorytet osiągnięciu tych wskaźników ilościowych, ze szkodą dla wskaźników jakościowych. Na przykład liczba ukończonych przeglądów kodu jest używana jako jedna z metryk. Oczywiście przegląd kodu można przeprowadzić na różne sposoby, można spędzić kilka godzin na dokładnym przejrzeniu i sprawdzeniu złożonej łatki wraz z testami sprawdzającymi, uruchomieniem jej na stanowisku laboratoryjnym, sprawdzeniem dokumentacji i uzyskanie plus jednej recenzji w swojej karmie, lub kliknij na ślepo kilkadziesiąt łatek w ciągu kilku minut, daj każdemu +1 i zyskaj plus dwadzieścia karmy. Zdarzały się komiczne przypadki, gdy inżynierowie klikali łatki tak szybko, że dawali +1 automatycznym łatkom z systemu CI. Jak później żartowaliśmy: „Idź, idź, Jenkins”. W przypadku zatwierdzeń było również wiele osób, które przeglądały kod za pomocą narzędzi do formatowania kodu, edytowały komentarze, zamieniały kropki na przecinki i w ten sposób pompowały swoją karmę. Radzenie sobie z tym jest dość proste: kierujemy się zdrowym rozsądkiem i oprócz wskaźników ilościowych stosujemy także istotne, jakościowe. Stopień wykorzystania wyników pracy zespołu, liczba współpracowników zewnętrznych, poziom pokrycia testami, stabilność modułów i całego produktu, wyniki testów skali i wydajności, liczba inżynierów, którzy otrzymali rdzeń recenzenta pasy, fakt przyjęcia projektów do społeczności projektów kluczowych, zgodność z kryteriami poszczególnych etapów procesu inżynieryjnego – te i wiele innych czynników należy oceniać wraz z prostymi metrykami ilościowymi.
I na koniec trzeci punkt – Żadnych bzdur.
Programiści to bardzo mądrzy ludzie i niezwykle logiczni w swojej pracy. Spędzają 8-10 godzin dziennie na budowaniu długich i złożonych łańcuchów logicznych, dzięki czemu na bieżąco dostrzegają w nich luki. Robiąc coś, oni, jak wszyscy, chcą zrozumieć, dlaczego to robią, co zmieni się na lepsze. Niezwykle ważne jest, aby cele, jakie wyznaczasz swojemu zespołowi, były uczciwe i realistyczne. Próba sprzedania złego pomysłu zespołowi programistów jest złym pomysłem. Pomysł jest zły, jeśli sam w niego nie wierzysz lub, w skrajnych przypadkach, nie masz wewnętrznego stanu niezgody i zaangażowania (nie zgadzam się, ale to zrobię). Wdrożyliśmy kiedyś w firmie system motywacyjny, którego jednym z elementów był elektroniczny system przekazywania informacji zwrotnej. Zainwestowali dużo pieniędzy, zabierali ludzi do Ameryki na szkolenie, ogólnie rzecz biorąc, inwestowali do maksimum. Któregoś razu w rozmowie po szkoleniu jeden z menadżerów powiedział swoim podwładnym: „Pomysł nie jest zły, wygląda na to, że się sprawdzi. Sam nie będę ci przekazywać informacji zwrotnych w formie elektronicznej, ale wy dajesz je swoim ludziom i żądasz ich od nich. I tyle, nic więcej nie da się wdrożyć. Pomysł oczywiście zakończył się niczym.
Źródło: www.habr.com