Epigraf:
Manden ser på de snavsede børn og siger til sin kone: jamen, skal vi vaske disse eller føde nye?
Under snittet er anden del af en artikel af vores teamleder, samt RAS Product Development Director Igor Marnat, om det særlige ved at motivere programmører. Første del af artiklen kan findes her -
I den første del af artiklen kom jeg ind på de to lavere niveauer af Maslows pyramide: fysiologiske behov, behov for sikkerhed, komfort og stabilitet og gå videre til det næste, tredje niveau, nemlig:
III - Behov for tilhørsforhold og kærlighed
Jeg vidste, at den italienske mafia hed "Cosa Nostra", men jeg blev meget imponeret, da jeg fandt ud af, hvordan "Cosa Nostra" er oversat. "Cosa Nostra" oversat fra italiensk betyder "Vores forretning". Valget af navn er meget vellykket for motivation (lad os forlade besættelsen, i dette tilfælde er vi kun interesserede i motivation). En person ønsker normalt at være en del af et team, at gøre nogle store, fælles forretninger.
Der lægges stor vægt på at tilfredsstille behovet for tilhørsforhold og kærlighed i hæren, flåden og alle store paramilitære formationer. Og, som vi ser, i mafiaen. Det er forståeligt, for man skal tvinge folk, der har lidt til fælles, som i starten ikke udgør et hold af ligesindede, som samles af værnepligt (ikke frivilligt), som har forskellige uddannelsesniveauer, forskellige personlige værdier , bogstaveligt talt at vie deres liv, med dødelig risiko, til en fælles sag, overlade dit liv til en våbenkammerat.
Dette er en meget stærk motivation; for de fleste mennesker er det ekstremt vigtigt at føle, at de hører til noget større, at vide, at man er en del af en familie, et land, et team. I hæren tjener uniformer, forskellige ritualer, parader, marcher, bannere og så videre disse formål. Nogenlunde de samme faktorer er vigtige for ethvert hold. Symboler, firmamærke og firmafarver, tilbehør og souvenirs er vigtige.
Det er vigtigt, at væsentlige begivenheder har deres egen synlige legemliggørelse, som de kan forbindes med. I dag er det snarere normen for en virksomhed at have sine egne varer, jakker, T-shirts mv. Men det er også vigtigt at fremhæve teamet i virksomheden. Vi udgiver ofte T-shirts baseret på resultaterne af en udgivelse, som gives til alle involverede i udgivelsen. Nogle arrangementer, fælles festligheder eller aktiviteter med hele holdet er en anden vigtig motivationsfaktor.
Ud over ydre egenskaber påvirker flere andre faktorer følelsen af at høre til et team.
For det første tilstedeværelsen af et fælles mål, som alle forstår og deler en vurdering af dets betydning. Programmører ønsker normalt at forstå, at de laver en sej ting, og de gør denne fede ting sammen som et team.
For det andet skal teamet have et kommunikationsrum, hvor hele teamet er til stede, og som kun tilhører det (f.eks. en chat i messengeren, periodiske teamsyncaps). Ud over arbejdsspørgsmål, uformel kommunikation, nogle gange diskussion af eksterne begivenheder, lys offtop - alt dette skaber en følelse af fællesskab og team.
For det tredje vil jeg fremhæve indførelsen af god ingeniørpraksis i teamet, ønsket om at hæve standarderne i forhold til dem, der er accepteret i virksomheden. Implementering af de bedste tilgange, der er accepteret i branchen, først i teamet og derefter i virksomheden som helhed, giver teamet mulighed for at føle, at det er foran andre på en eller anden måde, førende, dette skaber en følelse af at høre til til et sejt hold.
Følelsen af at høre til er også påvirket af teamets deltagelse i planlægning og ledelse. Når teammedlemmer er involveret i at diskutere projektmål, arbejdsplaner, teamstandarder og ingeniørpraksis og interviewe nye medarbejdere, udvikler de en følelse af deltagelse, fælles ejerskab og indflydelse på arbejdet. Folk er meget mere villige til at udføre beslutninger truffet og givet udtryk for af dem selv end dem, der foreslås af andre, selvom de praktisk talt er i harmoni.
Fødselsdage, jubilæer, vigtige begivenheder i kollegernes liv - en fælles pizza, en lille gave fra holdet giver en varm følelse af involvering og taknemmelighed. I nogle virksomheder er det kutyme at give små mindeskilte for 5, 10, 15 års arbejde i virksomheden. På den ene side tror jeg ikke, at dette motiverer mig så meget til nye præstationer. Men selvfølgelig vil næsten enhver være glad for, at de ikke har glemt ham. Dette er et af de tilfælde, hvor fraværet af et faktum demotiverer snarere end dets tilstedeværelse motiverer. Enig, det kan være en skam, hvis LinkedIn mindede dig om morgenen og lykønskede dig med 10 års jubilæet på din arbejdsplads, men ikke en eneste kollega fra virksomheden lykønskede dig eller huskede dig.
En væsentlig pointe er naturligvis ændringen i sammensætningen af holdet. Det er klart, at selvom ankomst eller afgang af nogen fra holdet er annonceret på forhånd (f.eks. i et firma- eller teamnyhedsbrev eller på et teammøde), så motiverer dette ikke nogen særlig til nye præstationer. Men hvis du en skønne dag ser en ny person ved siden af dig, eller ikke ser en gammel, kan det være en overraskelse, og hvis du går, direkte ubehageligt. Folk skal ikke forsvinde stille og roligt. Især i et fordelt hold. Især hvis dit arbejde afhænger af en kollega fra et andet kontor, der pludselig op og forsvandt. Sådanne øjeblikke er bestemt værd at informere holdet separat på forhånd.
En vigtig faktor, som på engelsk hedder ejerskab (den bogstavelige oversættelse af "besiddelse" afspejler ikke fuldt ud dens betydning). Dette er ikke en følelse af ejerskab, men snarere en følelse af ansvar for dit projekt, den følelse, når du følelsesmæssigt forbinder dig med produktet og produktet med dig selv. Dette svarer nogenlunde til marinesoldatens bøn i filmen "Full Metal Jacket": "Dette er min riffel. Der er mange sådanne rifler, men denne er min. Min riffel er min bedste ven. Hun er mit liv. Jeg skal lære at eje det på samme måde, som jeg ejer mit liv. Uden mig er min riffel ubrugelig. Jeg er ubrugelig uden min riffel. Jeg skal skyde min riffel ligeud. Jeg er nødt til at skyde mere præcist end fjenden, der forsøger at dræbe mig. Jeg er nødt til at skyde ham, før han skyder mig. Lad det være sådan... ”.
Når en person arbejder på et produkt i lang tid, har mulighed for at bære det fulde ansvar for dets skabelse og udvikling, for at se, hvordan en fungerende ting opstår fra "intet", hvordan folk bruger det, opstår denne stærke følelse. Produktteams, der arbejder sammen i lang tid om et projekt, er normalt mere motiverede og sammenhængende end teams, der er samlet i en kort periode og arbejder i samlebåndstilstand, skiftende fra et projekt til et andet, uden fuldt ansvar for hele produktet , fra start til slut.
IV. Behov for anerkendelse
Et venligt ord glæder også katten. Alle motiveres af anerkendelse af vigtigheden af det arbejde, de har udført, og dets positive vurdering. Tal med programmører, giv dem periodisk feedback, fejr et veludført arbejde. Hvis du har et stort og fordelt team, er periodiske møder (det der kaldes én til én) perfekte til dette; hvis teamet er meget lille og arbejder sammen lokalt, tilbydes denne mulighed normalt uden særlige møder i kalenderen (dog periodiske møder til én er alt. Det er stadig nødvendigt, du kan bare gøre det sjældnere). Dette emne er godt dækket i podcasts for ledere på manager-tools.com.
Det er dog værd at huske på kulturelle forskelle. Nogle tilgange, som amerikanske kolleger kender, vil ikke altid fungere med russiske. Niveauet af høflighed, der accepteres i den daglige kommunikation i teams i vestlige lande, synes i første omgang at være overdreven for programmører fra Rusland. En vis ligefremhed, der er karakteristisk for russiske kolleger, kan blive opfattet som uhøflighed af deres kolleger fra andre lande. Dette er meget vigtigt i kommunikation i et interetnisk team; der er skrevet meget om dette emne; lederen af et sådant team skal huske dette.
Funktionsdemonstrationer, hvor programmører viser funktioner udviklet under en sprint, er en god praksis for at realisere dette behov. Ud over at dette er en glimrende mulighed for at rydde kommunikationskanaler mellem teams, introducere produktchefer og testere til nye funktioner, er det også en god mulighed for udviklere til at vise resultaterne af deres arbejde og angive deres forfatterskab. Nå, og finpuds selvfølgelig dine evner til at tale offentligt, hvilket aldrig er skadeligt.
Det vil være en god idé at fejre særligt fornemme kollegaers betydelige bidrag med certifikater, mindeskilte (i hvert fald et venligt ord) ved fælles holdtræf. Folk værdsætter normalt sådanne attester og mindeskilte meget, tager dem med, når de flytter, og tager sig generelt af dem på alle mulige måder.
For at markere et mere betydningsfuldt, langsigtet bidrag til holdets arbejde, akkumuleret erfaring og ekspertise, bruges ofte et karaktersystem (igen kan der drages en analogi med systemet med militære rækker i hæren, som desuden at sikre underordning, tjener også dette formål). Ofte arbejder unge udviklere dobbelt så hårdt på at få nye stjerner på deres skulderstropper (dvs. at gå fra juniorudvikler til fuldtidsudvikler osv.).
At kende dine folks forventninger er afgørende. Nogle er mere tilbøjelige til at blive motiveret af en høj karakter, muligheden for at blive kaldt for eksempel en arkitekt, mens andre tværtimod er ligeglade med karakterer og titler og vil betragte en stigning i løn som et tegn på anerkendelse fra virksomheden . Kommuniker med folk for at forstå, hvad de ønsker, og hvad deres forventninger er.
En demonstration af anerkendelse, et højere niveau af tillid fra teamets side, kan gives ved at give mere handlefrihed eller involvering i nye arbejdsområder. For eksempel, efter at have opnået en vis erfaring og opnået visse resultater, kan en programmør, ud over at implementere sine funktioner i overensstemmelse med specifikationen, arbejde på arkitekturen af nye ting. Eller bliv involveret i nye områder, der måske ikke er direkte relateret til udvikling - testautomatisering, implementering af bedste ingeniørpraksis, hjælp til release management, tale ved konferencer osv.
V. Behovet for erkendelse og selvaktualisering.
Mange programmører er fokuseret på forskellige typer programmeringsaktiviteter på forskellige stadier af deres liv. Nogle mennesker kan lide at lave maskinlæring, udvikle nye datamodeller, læse en masse videnskabelig litteratur til arbejdet og skabe noget nyt fra bunden. En anden er tættere på at fejlsøge og understøtte en eksisterende applikation, hvor du skal grave dybt i den eksisterende kode, studere logfiler, stack-spor og netværks-captchas i dage og uger og næsten ikke skrive nogen ny kode.
Begge processer kræver stor intellektuel indsats, men deres praktiske output er anderledes. Det menes, at programmører er tilbageholdende med at understøtte eksisterende løsninger; de er snarere motiverede til at udvikle nye. Der er et gran af visdom i dette. På den anden side var det mest motiverede og forenede team, jeg nogensinde har arbejdet med, dedikeret til at støtte et eksisterende produkt, finde og rette fejl, efter at supportteamet kontaktede dem. Fyrene levede bogstaveligt talt for dette arbejde og var klar til at gå ud på lørdage og søndage. Vi beskæftigede os engang ivrigt med et andet presserende og komplekst problem, enten om aftenen den 31. december eller om eftermiddagen den 1. januar.
Flere faktorer påvirkede denne høje motivation. For det første var det en virksomhed med et stort navn i branchen, teamet associerede sig med det (se "Behovet for tilknytning"). For det andet var de den sidste grænse, der var ingen bag dem, der var ikke noget produktteam på det tidspunkt. Mellem dem og kunderne var der to niveauer af support, men hvis problemet nåede dem, var der ingen steder at trække sig tilbage, ingen stod bag dem, hele virksomheden var på dem (fire unge programmører). For det tredje havde denne store virksomhed meget store kunder (landes regeringer, bil- og luftfartsselskaber osv.) og meget store installationer i flere lande. Som et resultat, altid komplekse og interessante problemer, blev simple problemer løst ved støtte fra tidligere niveauer. For det fjerde var teamets motivation stærkt påvirket af det professionelle niveau af supportteamet, som de interagerede med (der var meget erfarne og teknisk dygtige ingeniører), og vi var altid sikre på kvaliteten af de data, de udarbejdede, den analyse, de udførte , etc. For det femte, og jeg tror, det er det vigtigste punkt - holdet var meget ungt, alle gutterne var i begyndelsen af deres karriere. De var interesserede i at studere et stort og komplekst produkt, løse alvorlige problemer, der var nye for dem i et nyt miljø, de søgte professionelt at matche niveauet for de omkringliggende teams, problemer og kunder. Projektet viste sig at være en fremragende skole, alle gjorde senere en god karriere i virksomheden og blev tekniske ledere og seniorledere, en af fyrene er nu teknisk chef hos Amazon Web Services, den anden flyttede til sidst til Google, og alle af dem husker stadig dette projekt med varme.
Hvis dette hold bestod af programmører med 15-20 års erfaring bag sig, ville motivationen være en anden. Alder og erfaring er naturligvis ikke 100% afgørende faktorer; det hele afhænger af motivationens struktur. I dette særlige tilfælde gav ønsket om viden og vækst hos unge programmører fremragende resultater.
Generelt, som vi allerede har nævnt flere gange, skal du kende dine programmørers forventninger, forstå hvem af dem der gerne vil udvide eller ændre deres aktivitetsområde og tage højde for disse forventninger.
Ud over Maslows pyramide: synlighed af resultater, gamification og konkurrence, intet bullshit
Der er yderligere tre vigtige punkter vedrørende programmørers motivation, som absolut skal nævnes, men at trække dem ind i Maslows behovsmodel ville være for kunstigt.
Den første er synlighed og nærhed af resultatet.
Softwareudvikling er normalt et maratonløb. Resultaterne af F&U-indsatsen bliver synlige efter måneder, nogle gange år. Det er svært at gå til et mål, der er langt uden for horisonten, mængden af arbejde er skræmmende, målet er langt væk, ikke klart og ikke synligt, "natten er mørk og fuld af rædsler." Det er bedre at bryde vejen dertil i dele, lave en sti til det nærmeste træ, der er synlig, tilgængelig, konturerne er klare, og det er ikke langt fra os - og gå til dette tætte mål. Vi vil gøre en indsats på flere dage eller uger, få og evaluere resultatet, og så gå videre. Derfor er det værd at dele arbejdet op i små dele (sprints i agile tjener dette formål godt). Vi har fuldført en del af arbejdet - optaget det, udåndet, diskuteret det, straffet de skyldige, belønnet de uskyldige - vi kan begynde den næste cyklus.
Denne motivation ligner til en vis grad, hvad spillere oplever, når de fuldfører computerspil: de modtager periodisk medaljer, point, bonusser, efterhånden som de fuldfører hvert niveau; dette kan kaldes "dopaminmotivation."
Samtidig er synligheden af resultatet bogstaveligt talt vigtigt. En lukket funktion på listen bør blive grøn. Hvis koden er skrevet, testet, frigivet, men der ikke er nogen ændring i den visuelle status synlig for programmøren, vil han føle sig ufuldstændig, der vil ikke være nogen følelse af færdiggørelse. I et af holdene i vores versionskontrolsystem gennemgik hver patch tre på hinanden følgende stadier - bygningen blev samlet og testene bestået, patchen bestod kodegennemgangen, patchen blev flettet. Hver fase blev visuelt markeret med et grønt flueben eller rødt kryds. Da en af udviklerne klagede over, at kodegennemgangen tog for lang tid, var kollegerne nødt til at fremskynde, patcherne hang i flere dage. Jeg spurgte, hvad ændrer det egentlig for ham? Når alt kommer til alt, når koden er skrevet, bygningen er samlet og testene er bestået, behøver han ikke at være opmærksom på den sendte patch, hvis der ikke er kommentarer. Kolleger vil selv gennemgå og godkende det (hvis der igen ikke er nogen kommentarer). Han svarede: "Igor, jeg vil gerne have mine tre grønne flåter så hurtigt som muligt."
Det andet punkt er gamification og konkurrence.
Da vi udviklede et af produkterne, havde vores ingeniørteam et mål om at tage en fremtrædende position i fællesskabet af et af open source-produkterne for at komme ind i top-3. På det tidspunkt var der ingen objektiv måde at vurdere nogens synlighed i samfundet; hver af de store deltagende virksomheder kunne hævde (og med jævne mellemrum hævdede), at de var den største bidragyder, men der var ingen reel måde at sammenligne deltagernes bidrag på. indbyrdes for at evaluere dens dynamik i tide. Derfor var der ingen måde at sætte et mål for holdet, der kunne måles i nogle papegøjer, vurdere graden af dets præstation osv. For at løse dette problem har vores team udviklet et værktøj til at måle og visualisere bidrag fra virksomheder og individuelle bidragydere . Fra et motivationssynspunkt viste det sig kun at være en bombe. Det var ikke kun ingeniører og teams, der konstant overvågede deres fremskridt og deres kollegaers og konkurrenters fremskridt. Topledelsen i vores virksomhed og alle større konkurrenter startede også deres dag med stackalytics. Alt blev meget gennemsigtigt og visuelt, alle kunne nøje overvåge deres fremskridt, sammenligne med kolleger osv. Det er blevet bekvemt og nemt for ingeniører, ledere og teams at sætte mål.
En vigtig pointe, der opstår, når man implementerer et hvilket som helst system af kvantitative målinger, er, at så snart man har implementeret dem, stræber systemet automatisk efter at prioritere opnåelsen af disse kvantitative målinger til skade for kvalitative. For eksempel bruges antallet af gennemførte kodegennemgange som en af metrikkerne. Det er klart, at kodegennemgang kan udføres på forskellige måder, du kan bruge flere timer på en grundig gennemgang og kontrol af en kompleks patch med kontroltest, køre den på din bænk, tjekke med dokumentation og få plus én anmeldelse i din karma, eller klik blindt på et par dusin på et par minutter, giv hver en +1 og få plus tyve i karma. Der var komiske tilfælde, hvor ingeniører klikkede på patches så hurtigt, at de gav +1 til automatiske patches fra CI-systemet. Som vi senere jokede, "go, go, jenkins." I tilfælde af commits var der også mange mennesker, der gennemgik koden med kodeformateringsværktøjer, redigerede kommentarer, ændrede punktum til kommaer og dermed pumpede deres karma op. At håndtere dette er ret simpelt: Vi bruger sund fornuft og bruger udover kvantitative målinger også væsentlige, kvalitative. Graden af brug af resultaterne af teamets arbejde, antallet af eksterne bidragydere, niveauet af testdækning, stabiliteten af moduler og hele produktet, resultaterne af skala- og ydeevnetest, antallet af ingeniører, der modtog core reviewer skulder stropper, det faktum, at projekter blev accepteret i kerneprojektfællesskabet, overholdelse af kriterierne for forskellige stadier af ingeniørprocessen - alle disse og mange andre faktorer skal vurderes sammen med simple kvantitative målinger.
Og til sidst det tredje punkt - Intet bullshit.
Udviklere er meget kloge mennesker og ekstremt logiske i deres branche. De bruger 8-10 timer om dagen på at bygge lange og komplekse logiske kæder, så de ser sårbarheder i dem i farten. Når de gør noget, vil de ligesom alle andre gerne forstå, hvorfor de gør det, hvad der vil ændre sig til det bedre. Det er ekstremt vigtigt, at de mål, du sætter for dit team, er ærlige og realistiske. At forsøge at sælge en dårlig idé til et programmeringshold er en dårlig idé. En idé er dårlig, hvis du ikke selv tror på den, eller i ekstreme tilfælde ikke har den interne tilstand af uenig og forpligtende (jeg er ikke enig, men jeg gør det). Vi implementerede engang et motivationssystem i en virksomhed, hvor et af elementerne var et elektronisk system til at give feedback. De investerede mange penge, tog folk til Amerika for at træne, generelt investerede de fuldt ud. Engang i en samtale efter uddannelsen sagde en af lederne til sine underordnede: ”Ideen er ikke dårlig, den ser ud til at virke. Jeg vil ikke selv give dig elektronisk feedback, men du giver det til dine folk og kræver det af dem." Det er det, intet kunne implementeres yderligere. Idéen endte selvfølgelig i ingenting.
Kilde: www.habr.com