Motto:
Mannen tittar på de smutsiga barnen och säger till sin fru: ja, ska vi tvätta dessa eller föda nya?
Nedanför snittet finns den andra delen av en artikel av vår teamledare, samt RAS produktutvecklingschef Igor Marnat, om det speciella med att motivera programmerare. Den första delen av artikeln finns här -
I den första delen av artikeln berörde jag de två lägre nivåerna av Maslows pyramid: fysiologiska behov, behov av säkerhet, komfort och beständighet och gå vidare till nästa, tredje nivå, nämligen:
III – Behov av tillhörighet och kärlek
Jag visste att den italienska maffian hette "Cosa Nostra", men jag blev väldigt imponerad när jag fick reda på hur "Cosa Nostra" översätts. "Cosa Nostra" översatt från italienska betyder "Vår verksamhet". Valet av namn är mycket framgångsrikt för motivation (låt oss lämna yrket åt sidan, i det här fallet är vi bara intresserade av motivation). En person vill vanligtvis vara en del av ett team, göra några stora, gemensamma, vår verksamhet.
Stor vikt läggs vid att tillfredsställa behovet av tillhörighet och kärlek i armén, flottan och alla stora paramilitära formationer. Och, som vi ser, i maffian. Detta är förståeligt, eftersom du måste tvinga människor som har lite gemensamt, som till en början inte bildar ett lag av likasinnade, som sammanförs genom värnplikt (inte frivilligt), som har olika utbildningsnivåer, olika personliga värderingar , att bokstavligen ägna sina liv, med dödlig risk, åt någon vanlig sak, anförtro ditt liv till en vapenkamrat.
Detta är en mycket stark motivation, för de flesta människor är det oerhört viktigt att känna att de tillhör något större, att veta att man är en del av en familj, ett land, ett team. I armén tjänar uniformer, olika ritualer, parader, marscher, banderoller och så vidare dessa syften. Ungefär samma faktorer är viktiga för alla lag. Symboler, företagets varumärke och företagsfärger, tillbehör och souvenirer är viktiga.
Det är viktigt att viktiga händelser har sin egen synliga gestaltning som de kan associeras med. Numera är det snarare normen för ett företag att ha sina egna varor, jackor, T-shirts osv. Men det är också viktigt att lyfta fram teamet inom företaget. Vi släpper ofta T-shirts baserat på resultatet av en release, som ges till alla inblandade i releasen. Vissa evenemang, gemensamma firanden eller aktiviteter med hela laget är en annan viktig motivationsfaktor.
Förutom yttre attribut påverkar flera andra faktorer känslan av att tillhöra ett team.
För det första, närvaron av ett gemensamt mål som alla förstår och delar en bedömning av dess betydelse. Programmerare vill vanligtvis förstå att de gör en häftig sak, och de gör den här häftiga saken tillsammans, som ett team.
För det andra måste teamet ha ett kommunikationsutrymme där hela teamet är närvarande och som bara tillhör det (till exempel en chatt i messengern, periodiska teamsyncaps). Förutom arbetsfrågor, informell kommunikation, ibland diskussion om externa händelser, ljus offtop – allt detta skapar en känsla av gemenskap och team.
För det tredje vill jag lyfta fram införandet av goda ingenjörspraxis inom teamet, viljan att höja standarden jämfört med de som accepteras i företaget. Genom att implementera de bästa tillvägagångssätten som accepteras i branschen, först i teamet och sedan i företaget som helhet, ger teamet möjlighet att känna att det ligger före andra på något sätt, leder vägen, detta skapar en känsla av tillhörighet till ett coolt team.
Känslan av samhörighet påverkas också av teamets deltagande i planering och ledning. När gruppmedlemmar är involverade i att diskutera projektmål, arbetsplaner, teamstandarder och ingenjörsrutiner och intervjua nya medarbetare, utvecklar de en känsla av delaktighet, delat ägande och inflytande på arbetet. Människor är mycket mer villiga att genomföra beslut som fattas och uttrycks av dem själva än de som föreslås av andra, även om de praktiskt taget är i samklang.
Födelsedagar, årsdagar, viktiga händelser i kollegornas liv - en gemensam pizza, en liten gåva från laget ger en varm känsla av engagemang och tacksamhet. I vissa företag är det brukligt att ge små minnesmärken för 5, 10, 15 års arbete i företaget. Å ena sidan tror jag inte att detta motiverar mig så mycket för nya prestationer. Men uppenbarligen kommer nästan alla att vara nöjda med att de inte har glömt honom. Detta är ett av de fall då frånvaron av ett faktum demotiverar snarare än dess närvaro motiverar. Håller med, det kan vara ganska synd om LinkedIn påminde dig på morgonen och gratulerade dig till din 10-årsjubileum på din arbetsplats, men inte en enda kollega från företaget gratulerade dig eller kom ihåg dig.
Naturligtvis är en viktig punkt förändringen i lagets sammansättning. Det är tydligt att även om ankomsten eller avgången av någon från laget meddelas i förväg (till exempel i ett företags- eller teamnyhetsbrev eller på ett teammöte), så motiverar detta inte någon särskilt till nya prestationer. Men om du en vacker dag ser en ny person bredvid dig, eller inte ser en gammal, kan det bli en överraskning, och om du går, rent ut sagt obehagligt. Människor ska inte försvinna tyst. Speciellt i ett utdelat lag. Särskilt om ditt arbete beror på en kollega från ett annat kontor som plötsligt upp och försvann. Sådana ögonblick är definitivt värda att informera laget separat i förväg.
En viktig faktor, som på engelska kallas ägande (den bokstavliga översättningen av "besittning" återspeglar inte helt dess innebörd). Detta är inte en känsla av ägarskap, utan snarare en känsla av ansvar för ditt projekt, den där känslan när du känslomässigt associerar dig med produkten och produkten med dig själv. Detta motsvarar ungefär marinens bön i filmen "Full Metal Jacket": "Det här är mitt gevär. Det finns många sådana gevär, men det här är mitt. Mitt gevär är min bästa vän. Hon är mitt liv. Jag måste lära mig att äga det på samma sätt som jag äger mitt liv. Utan mig är mitt gevär värdelöst. Jag är värdelös utan mitt gevär. Jag måste skjuta mitt gevär rakt. Jag måste skjuta mer exakt än fienden som försöker döda mig. Jag måste skjuta honom innan han skjuter mig. Låt det vara så... ”.
När en person arbetar på en produkt under lång tid, har möjligheten att ta fullt ansvar för dess skapande och utveckling, att se hur en fungerande sak uppstår ur "ingenting", hur människor använder den, uppstår denna kraftfulla känsla. Produktteam som arbetar tillsammans under lång tid i ett projekt är vanligtvis mer motiverade och sammanhållna än team som är sammansatta under en kort tidsperiod och arbetar i löpande band, växlar från ett projekt till ett annat, utan att ha fullt ansvar för hela produkt, från början till slut.
IV. Behov av erkännande
Ett vänligt ord gläder också katten. Alla motiveras av erkännande av vikten av det arbete de har utfört och dess positiva bedömning. Prata med programmerare, ge dem regelbunden feedback, fira ett väl utfört jobb. Om du har ett stort och fördelat team är periodiska möten (som kallas en till en) perfekt för detta; om teamet är mycket litet och arbetar tillsammans lokalt, ges denna möjlighet vanligtvis utan särskilda möten i kalendern (även om det är periodiskt ett). till en är allt Det behövs fortfarande, du kan bara göra det mindre ofta). Det här ämnet är väl täckt i podcaster för chefer på manager-tools.com.
Det är dock värt att hålla kulturella skillnader i åtanke. Vissa metoder som är bekanta med amerikanska kollegor kommer inte alltid att fungera med ryska. Graden av artighet som accepteras i daglig kommunikation i team i västländer verkar initialt överdriven för programmerare från Ryssland. En viss rättframhet som kännetecknar ryska kollegor kan uppfattas som elakhet av deras kollegor från andra länder. Detta är mycket viktigt i kommunikationen i ett interetniskt team, mycket har skrivits om detta ämne, chefen för ett sådant team måste komma ihåg detta.
Funktionsdemonstrationer, där programmerare visar funktioner som utvecklats under en sprint, är en bra praxis för att förverkliga detta behov. Förutom att detta är ett utmärkt tillfälle att rensa kommunikationskanaler mellan team, introducera produktchefer och testare för nya funktioner, är det också ett bra tillfälle för utvecklare att visa resultatet av sitt arbete och ange sitt författarskap. Tja, och polera dina kunskaper om att tala inför publik, naturligtvis, vilket aldrig är skadligt.
Det skulle vara en bra idé att fira särskilt framstående kollegors betydande insats med certifikat, minnesmärken (åtminstone ett vänligt ord) vid gemensamma lagträffar. Människor brukar värdera sådana certifikat och minnesmärken väldigt mycket, ta dem med sig när de flyttar och tar i allmänhet hand om dem på alla möjliga sätt.
För att markera ett mer betydande, långsiktigt bidrag till lagets arbete, ackumulerad erfarenhet och expertis, används ofta ett betygssystem (återigen kan en analogi dras med systemet med militära grader i armén, som dessutom att säkerställa underordning, tjänar också detta syfte). Ofta jobbar unga utvecklare dubbelt så hårt för att få nya stjärnor på axelremmarna (dvs. går från juniorutvecklare till heltidsutvecklare etc.).
Att känna till ditt folks förväntningar är avgörande. Vissa är mer benägna att motiveras av ett högt betyg, möjligheten att bli kallad, säg, en arkitekt, medan andra tvärtom är likgiltiga för betyg och titlar och kommer att betrakta en ökning av lönen som ett tecken på erkännande från företaget . Kommunicera med människor för att förstå vad de vill ha och vad de har för förväntningar.
En demonstration av erkännande, ett högre förtroende från teamets sida, kan ges genom att ge större handlingsfrihet eller engagemang i nya arbetsområden. Till exempel, efter att ha fått viss erfarenhet och uppnått vissa resultat, kan en programmerare, förutom att implementera sina funktioner i enlighet med specifikationen, arbeta med arkitekturen för nya saker. Eller engagera dig i nya områden som kanske inte är direkt relaterade till utveckling - testautomatisering, implementering av bästa tekniska praxis, hjälp med releasehantering, tala på konferenser, etc.
V. Behovet av kognition och självförverkligande.
Många programmerare är fokuserade på olika typer av programmeringsaktiviteter i olika skeden av livet. Vissa människor gillar att göra maskininlärning, utveckla nya datamodeller, läsa mycket vetenskaplig litteratur i arbetet och skapa något nytt från grunden. En annan är närmare att felsöka och stödja en befintlig applikation, där du behöver gräva djupt i den befintliga koden, studera loggar, stack traces och nätverkscaptchas i dagar och veckor, och nästan inte skriva någon ny kod.
Båda processerna kräver stor intellektuell ansträngning, men deras praktiska resultat är olika. Man tror att programmerare är ovilliga att stödja befintliga lösningar, de är snarare motiverade att utveckla nya. Det finns ett korn av visdom i detta. Å andra sidan var det mest motiverade och enade teamet jag någonsin har arbetat med dedikerat till att stödja en befintlig produkt, hitta och fixa buggar efter att supportteamet kontaktade dem. Killarna levde bokstavligen för detta arbete och var redo att gå ut på lördagar och söndagar. Vi tog en gång ivrigt upp ett annat akut och komplext problem, antingen på kvällen den 31 december eller på eftermiddagen den 1 januari.
Flera faktorer påverkade denna höga motivation. För det första var det ett företag med ett stort namn i branschen, teamet förknippade sig med det (se "Behovet av anslutning"). För det andra var de den sista gränsen, det fanns ingen bakom dem, det fanns inget produktteam på den tiden. Mellan dem och kunderna fanns det två nivåer av support, men om problemet nådde dem fanns det ingenstans att dra sig tillbaka, ingen stod bakom dem, hela företaget var på dem (fyra unga programmerare). För det tredje hade detta stora företag mycket stora kunder (landsmyndigheter, bil- och flygbolag, etc.) och mycket storskaliga installationer i flera länder. Som ett resultat, alltid komplexa och intressanta problem, enkla problem löstes med stöd av tidigare nivåer. För det fjärde påverkades teamets motivation i hög grad av den professionella nivån på supportteamet som de interagerade med (det fanns mycket erfarna och tekniskt kapabla ingenjörer), och vi var alltid säkra på kvaliteten på den data de förberedde, analysen de utförde , etc. För det femte, och jag tror att detta är den viktigaste punkten - laget var väldigt ungt, alla killar var i början av sina karriärer. De var intresserade av att studera en stor och komplex produkt, lösa allvarliga problem som var nya för dem i en ny miljö, de försökte professionellt matcha nivån på de omgivande teamen, problemen och kunderna. Projektet visade sig vara en utmärkt skola, alla gjorde senare en bra karriär i företaget och blev tekniska ledare och högre chefer, en av killarna är nu teknisk chef på Amazon Web Services, den andra flyttade så småningom till Google, och alla av dem minns fortfarande detta projekt med värme.
Om det här teamet bestod av programmerare med 15-20 års erfarenhet bakom sig skulle motivationen vara en annan. Ålder och erfarenhet är naturligtvis inte 100% avgörande, allt beror på motivationens struktur. I detta speciella fall gav önskan om kunskap och tillväxt hos unga programmerare utmärkta resultat.
I allmänhet, som vi redan har nämnt flera gånger, måste du känna till dina programmerares förväntningar, förstå vem av dem som vill utöka eller ändra sitt verksamhetsområde och ta hänsyn till dessa förväntningar.
Bortom Maslows pyramid: synlighet av resultat, gamification och konkurrens, inget skitsnack
Det finns ytterligare tre viktiga punkter angående programmerares motivation som definitivt måste nämnas, men att dra in dem i Maslows behovsmodell skulle vara för konstlat.
Den första är synligheten och närheten till resultatet.
Mjukvaruutveckling är vanligtvis ett maratonlopp. Resultaten av FoU-insatser blir synliga efter månader, ibland år. Det är svårt att gå till ett mål som ligger långt bortom horisonten, mängden arbete är skrämmande, målet är långt borta, oklart och inte synligt, "natten är mörk och full av fasor." Det är bättre att bryta vägen till den i delar, göra en väg till närmaste träd som är synlig, nåbar, konturerna är tydliga och det är inte långt från oss - och gå till detta nära mål. Vi vill göra en insats på flera dagar eller veckor, få och utvärdera resultatet och sedan gå vidare. Därför är det värt att dela upp arbetet i små delar (sprintar i agile tjänar detta ändamål väl). Vi har slutfört en del av arbetet - spelat in det, andats ut, diskuterat det, straffat de skyldiga, belönat de oskyldiga - vi kan börja nästa cykel.
Denna motivation liknar i viss mån vad spelare upplever när de slutför datorspel: de får regelbundet medaljer, poäng, bonusar när de slutför varje nivå; detta kan kallas "dopaminmotivation."
Samtidigt är synligheten av resultatet bokstavligen viktigt. En stängd funktion i listan ska bli grön. Om koden skrivs, testas, släpps, men det inte finns någon förändring i den visuella statusen som är synlig för programmeraren, kommer han att känna sig ofullständig, det kommer inte att finnas någon känsla av slutförande. I ett av teamen i vårt versionskontrollsystem gick varje patch igenom tre på varandra följande steg - konstruktionen monterades och testerna klarade, patchen klarade kodgranskningen, patchen slogs samman. Varje steg markerades visuellt med en grön bock eller rött kryss. När en av utvecklarna väl klagade på att kodgranskningen tog för lång tid behövde kollegorna skynda på, patchar hängde i flera dagar. Jag frågade, vad förändrar detta egentligen för honom? När allt kommer omkring, när koden skrivs, byggnaden är monterad och testerna har godkänts, behöver han inte vara uppmärksam på den skickade patchen om det inte finns några kommentarer. Kollegor själva kommer att granska och godkänna det (om det återigen inte finns några kommentarer). Han svarade, "Igor, jag vill få mina tre gröna fästingar så snart som möjligt."
Den andra punkten är gamification och konkurrens.
När vi utvecklade en av produkterna hade vårt ingenjörsteam ett mål att ta en framträdande position i gemenskapen för en av produkterna med öppen källkod, för att komma in i topp-3. På den tiden fanns det inget objektivt sätt att bedöma någons synlighet i samhället; vart och ett av de stora deltagande företagen kunde hävda (och regelbundet hävdade) att det var den största bidragsgivaren, men det fanns inget riktigt sätt att jämföra deltagarnas bidrag sinsemellan, för att utvärdera dess dynamik i tid. Följaktligen fanns det inget sätt att sätta ett mål för laget som kunde mätas i vissa papegojor, bedöma graden av dess prestation, etc. För att lösa detta problem har vårt team utvecklat ett verktyg för att mäta och visualisera bidrag från företag och enskilda bidragsgivare . Ur motiveringssynpunkt visade det sig att det bara var en bomb. Det var inte bara ingenjörer och team som ständigt övervakade deras framsteg och framstegen hos sina kollegor och konkurrenter. Vårt företags högsta ledning och alla större konkurrenter började också sin dag med stackalytics. Allt blev väldigt transparent och visuellt, alla kunde noggrant följa sina framsteg, jämföra med kollegor osv. Det har blivit bekvämt och enkelt för ingenjörer, chefer och team att sätta upp mål.
En viktig punkt som uppstår när man implementerar vilket system som helst av kvantitativa mått är att så fort man har implementerat dem strävar systemet automatiskt efter att prioritera uppnåendet av dessa kvantitativa mått, till nackdel för kvalitativa. Till exempel används antalet slutförda kodgranskningar som ett av måtten. Uppenbarligen kan kodgranskning göras på olika sätt, du kan lägga flera timmar på en grundlig granskning och kontroll av en komplex patch med kontrolltest, köra den på din bänk, kolla med dokumentation och få plus en recension i din karma, eller klicka blint på ett par dussin på ett par minuter, ge var och en +1 och få plus tjugo i karma. Det fanns komiska fall när ingenjörer klickade på patchar så snabbt att de gav +1 till automatiska patchar från CI-systemet. Som vi senare skämtade, "gå, gå, jenkins." När det gäller commits var det också många som gick igenom koden med kodformateringsverktyg, redigerade kommentarer, ändrade punkter till kommatecken och på så sätt pumpade upp sin karma. Att hantera detta är ganska enkelt: vi använder sunt förnuft och använder, förutom kvantitativa mått, även väsentliga, kvalitativa. Graden av användning av resultaten av teamets arbete, antalet externa bidragsgivare, nivån på testtäckning, stabiliteten hos moduler och hela produkten, resultaten av skala och prestandatestning, antalet ingenjörer som fått kärngranskare. remmar, det faktum att projekt accepterades i kärnprojektsgemenskapen, överensstämmelse med kriterierna för olika stadier av ingenjörsprocessen - alla dessa och många andra faktorer måste bedömas tillsammans med enkla kvantitativa mått.
Och slutligen, den tredje punkten - Inget bullshit.
Utvecklare är väldigt smarta människor och extremt logiska i sitt arbete. De lägger 8-10 timmar om dagen på att bygga långa och komplexa logiska kedjor, så de ser sårbarheter i dem i farten. När de gör något vill de, precis som alla andra, förstå varför de gör det, vad som kommer att förändras till det bättre. Det är oerhört viktigt att de mål du sätter upp för ditt team är ärliga och realistiska. Att försöka sälja en dålig idé till ett programmeringsteam är en dålig idé. En idé är dålig om du inte tror på den själv, eller, i extrema fall, du inte har det interna tillståndet att vara oense och engagera dig (jag håller inte med, men jag gör det). En gång implementerade vi ett motivationssystem i ett företag, vars ena del var ett elektroniskt system för att ge feedback. De investerade mycket pengar, tog folk till Amerika för att träna, i allmänhet investerade de fullt ut. En gång, i ett samtal efter utbildningen, sa en av cheferna till sina underordnade: ”Idén är inte dålig, det ser ut att fungera. Jag kommer inte att ge dig elektronisk feedback själv, men du ger den till ditt folk och kräver den av dem.” Det är allt, inget kunde genomföras vidare. Idén slutade förstås i ingenting.
Källa: will.com