Epigraf:
Mannen, som ser på de skitne barna, sier til sin kone: ja, skal vi vaske disse eller føde nye?
Under kuttet er den andre delen av en artikkel av teamlederen vår, samt RAS produktutviklingsdirektør Igor Marnat, om særegenhetene ved å motivere programmerere. Første del av artikkelen finner du her -
I den første delen av artikkelen berørte jeg de to lavere nivåene i Maslows pyramide: fysiologiske behov, behov for sikkerhet, komfort og stabilitet og gå videre til neste, tredje nivå, nemlig:
III – Behov for tilhørighet og kjærlighet
Jeg visste at den italienske mafiaen ble kalt "Cosa Nostra", men jeg ble veldig imponert da jeg fant ut hvordan "Cosa Nostra" er oversatt. "Cosa Nostra" oversatt fra italiensk betyr "Vår virksomhet". Valget av navn er veldig vellykket for motivasjon (la oss legge bort yrket, i dette tilfellet er vi bare interessert i motivasjon). En person ønsker vanligvis å være en del av et team, å gjøre noen store, felles virksomheter.
Det legges stor vekt på å tilfredsstille behovet for tilhørighet og kjærlighet i hæren, marinen og alle store paramilitære formasjoner. Og, som vi ser, i mafiaen. Dette er forståelig, fordi du må tvinge folk som har lite til felles, som i utgangspunktet ikke danner et team av likesinnede, som samles ved verneplikt (ikke frivillig), som har ulike utdanningsnivåer, ulike personlige verdier. , for å bokstavelig talt vie livet deres, med dødelig risiko, til en vanlig sak, overlate livet ditt til en våpenkamerat.
Dette er en veldig sterk motivasjon; for de fleste er det ekstremt viktig å føle at de tilhører noe større, å vite at du er en del av en familie, et land, et lag. I hæren tjener uniformer, ulike ritualer, parader, marsjer, bannere og så videre disse formålene. Omtrent de samme faktorene er viktige for ethvert lag. Symboler, bedriftens merkevare og bedriftsfarger, utstyr og suvenirer er viktige.
Det er viktig at vesentlige hendelser har sin egen synlige legemliggjøring som de kan assosieres med. I dag er det snarere normen for en bedrift å ha egne varer, jakker, t-skjorter osv. Men det er også viktig å fremheve teamet i bedriften. Vi gir ofte ut T-skjorter basert på resultatene av en utgivelse, som gis til alle som er involvert i utgivelsen. Noen arrangementer, felles feiringer eller aktiviteter med hele laget er en annen viktig motivasjonsfaktor.
I tillegg til ytre egenskaper er det flere andre faktorer som påvirker følelsen av å tilhøre et team.
For det første tilstedeværelsen av et felles mål som alle forstår og deler en vurdering av viktigheten. Programmerere ønsker vanligvis å forstå at de gjør en kul ting, og de gjør denne kule tingen sammen, som et team.
For det andre må teamet ha et kommunikasjonsrom der hele teamet er til stede og som bare tilhører det (for eksempel en chat i messenger, periodiske teamsyncaps). I tillegg til arbeidsspørsmål, uformell kommunikasjon, noen ganger diskusjon om eksterne hendelser, lys utenfor - alt dette skaper en følelse av fellesskap og team.
For det tredje vil jeg fremheve innføringen av god ingeniørpraksis i teamet, ønsket om å heve standarder sammenlignet med de som er akseptert i selskapet. Implementering av de beste tilnærmingene som er akseptert i bransjen, først i teamet, og deretter i selskapet som helhet, gir teamet muligheten til å føle at det er foran andre på en eller annen måte, leder vei, dette skaper en følelse av tilhørighet til et kult lag.
Følelsen av tilhørighet påvirkes også av teamets deltakelse i planlegging og ledelse. Når teammedlemmer er involvert i å diskutere prosjektmål, arbeidsplaner, teamstandarder og ingeniørpraksis, og intervjue nye ansatte, utvikler de en følelse av deltakelse, delt eierskap og innflytelse på arbeidet. Folk er mye mer villige til å gjennomføre beslutninger tatt og uttalt av seg selv enn de som foreslås av andre, selv om de praktisk talt er i harmoni.
Bursdager, jubileer, viktige hendelser i kollegenes liv - en felles pizza, en liten gave fra teamet gir en varm følelse av engasjement og takknemlighet. I noen bedrifter er det vanlig å gi små minneskilt for 5, 10, 15 års arbeid i bedriften. På den ene siden tror jeg ikke at dette motiverer meg så mye for nye prestasjoner. Men åpenbart vil nesten alle være fornøyd med at de ikke har glemt ham. Dette er et av de tilfellene når fraværet av et faktum demotiverer snarere enn dets tilstedeværelse motiverer. Enig, det kan være ganske synd om LinkedIn minnet deg om morgenen og gratulerte deg med 10-årsdagen på arbeidsplassen, men ikke en eneste kollega fra selskapet gratulerte deg eller husket deg.
Et viktig poeng er selvfølgelig endringen i sammensetningen av laget. Det er klart at selv om ankomst eller avgang av noen fra laget varsles på forhånd (for eksempel i et bedrifts- eller teamnyhetsbrev, eller på et teammøte), motiverer ikke dette noen særlig til nye prestasjoner. Men hvis du en vakker dag ser en ny person ved siden av deg, eller ikke ser en gammel, kan det være en overraskelse, og hvis du drar, rett og slett ubehagelig. Folk bør ikke forsvinne stille. Spesielt i et distribuert lag. Spesielt hvis arbeidet ditt er avhengig av en kollega fra et annet kontor som plutselig opp og forsvant. Slike øyeblikk er definitivt verdt å informere laget separat på forhånd.
En viktig faktor, som på engelsk kalles eierskap (den bokstavelige oversettelsen av "besittelse" gjenspeiler ikke helt dens betydning). Dette er ikke en følelse av eierskap, men snarere en følelse av ansvar for prosjektet ditt, den følelsen når du følelsesmessig assosierer deg med produktet og produktet med deg selv. Dette tilsvarer omtrent bønnen til marinesoldaten i filmen "Full Metal Jacket": "Dette er riflen min. Det finnes mange slike rifler, men denne er min. Geværet mitt er min beste venn. Hun er livet mitt. Jeg må lære å eie det på samme måte som jeg eier livet mitt. Uten meg er riflen min ubrukelig. Jeg er ubrukelig uten riflen min. Jeg må skyte geværet mitt rett. Jeg må skyte mer nøyaktig enn fienden som prøver å drepe meg. Jeg må skyte ham før han skyter meg. La det bli slik… ".
Når en person jobber på et produkt i lang tid, har muligheten til å bære det fulle ansvar for dets skapelse og utvikling, for å se hvordan en fungerende ting oppstår fra "ingenting", hvordan folk bruker det, oppstår denne kraftige følelsen. Produktteam som jobber lenge sammen om ett prosjekt er vanligvis mer motiverte og samstemte enn team som er satt sammen for en kort periode og jobber i samlebåndsmodus, bytter fra ett prosjekt til et annet, uten fullt ansvar for hele produktet , fra begynnelse til slutt.
IV. Behov for anerkjennelse
Et vennlig ord gleder også katten. Alle motiveres av erkjennelse av viktigheten av arbeidet de har gjort og dens positive vurdering. Snakk med programmerere, gi dem periodiske tilbakemeldinger, feir en godt utført jobb. Hvis du har et stort og distribuert team, er periodiske møter (det som kalles en-til-en) perfekt for dette; hvis teamet er veldig lite og jobber sammen lokalt, tilbys denne muligheten vanligvis uten spesielle møter på kalenderen (selv om det er periodiske møter). til en er alt Det er fortsatt nødvendig, du kan bare gjøre det sjeldnere). Dette emnet er godt dekket i podcaster for ledere på manager-tools.com.
Det er imidlertid verdt å ha kulturelle forskjeller i bakhodet. Noen tilnærminger kjent for amerikanske kolleger vil ikke alltid fungere med russiske. Nivået på høflighet som aksepteres i daglig kommunikasjon i team i vestlige land virker i utgangspunktet overdreven for programmerere fra Russland. En viss rettlinjethet som kjennetegner russiske kolleger, kan oppfattes som frekkhet av deres kolleger fra andre land. Dette er veldig viktig i kommunikasjon i et interetnisk team; det er skrevet mye om dette emnet; lederen av et slikt team må huske dette.
Funksjonsdemonstrasjoner, der programmerere viser funksjoner utviklet under en sprint, er en god praksis for å realisere dette behovet. I tillegg til at dette er en utmerket mulighet til å rydde kommunikasjonskanaler mellom team, introdusere produktsjefer og testere for nye funksjoner, er det også en god mulighet for utviklere til å vise resultatene av arbeidet sitt og indikere forfatterskapet sitt. Vel, og finpusse dine offentlige talerferdigheter, selvfølgelig, noe som aldri er skadelig.
Det vil være en god idé å feire det betydelige bidraget fra spesielt fornemme kolleger med attester, minneskilt (minst et vennlig ord) ved felles lagtreff. Folk setter vanligvis slike sertifikater og minneskilt svært høyt, tar dem med seg når de flytter, og tar generelt vare på dem på alle mulige måter.
For å markere et mer betydelig, langsiktig bidrag til lagets arbeid, akkumulert erfaring og ekspertise, brukes ofte et karaktersystem (igjen kan det trekkes en analogi med systemet med militære rangeringer i hæren, som i tillegg å sikre underordning, tjener også dette formålet). Ofte jobber unge utviklere dobbelt så hardt for å få nye stjerner på skulderstroppene (dvs. flytter fra juniorutvikler til fulltidsutvikler osv.).
Å kjenne til folks forventninger er avgjørende. Noen er mer sannsynlig å bli motivert av en høy karakter, muligheten til å bli kalt for eksempel en arkitekt, mens andre tvert imot er likegyldige til karakterer og titler og vil vurdere en økning i lønn som et tegn på anerkjennelse fra selskapet . Kommuniser med folk for å forstå hva de ønsker og hvilke forventninger de har.
En demonstrasjon av anerkjennelse, et høyere nivå av tillit fra teamets side, kan gis ved å gi større handlefrihet eller involvering i nye arbeidsområder. For eksempel, etter å ha oppnådd viss erfaring og oppnådd visse resultater, kan en programmerer, i tillegg til å implementere funksjonene sine i samsvar med spesifikasjonen, jobbe med arkitekturen til nye ting. Eller bli involvert i nye områder som kanskje ikke er direkte relatert til utvikling - testautomatisering, implementering av beste ingeniørpraksis, hjelp med utgivelseshåndtering, foredrag på konferanser, etc.
V. Behovet for erkjennelse og selvaktualisering.
Mange programmerere er fokusert på forskjellige typer programmeringsaktiviteter på forskjellige stadier av livet. Noen mennesker liker å gjøre maskinlæring, utvikle nye datamodeller, lese mye vitenskapelig litteratur for arbeid og skape noe nytt fra bunnen av. En annen er nærmere feilsøking og støtte for en eksisterende applikasjon, der du trenger å grave dypt inn i den eksisterende koden, studere logger, stackspor og nettverkscaptchaer i dager og uker, og nesten ikke skrive ny kode.
Begge prosessene krever stor intellektuell innsats, men deres praktiske resultater er forskjellige. Det antas at programmerere er motvillige til å støtte eksisterende løsninger; de er heller motiverte for å utvikle nye. Det er et korn av visdom i dette. På den annen side var det mest motiverte og forente teamet jeg noen gang har jobbet med dedikert til å støtte et eksisterende produkt, finne og fikse feil etter at supportteamet kontaktet dem. Gutta levde bokstavelig talt for dette arbeidet og var klare til å gå ut på lørdager og søndager. Vi tok en gang ivrig tak i et annet presserende og komplekst problem, enten om kvelden 31. desember eller om ettermiddagen 1. januar.
Flere faktorer påvirket denne høye motivasjonen. For det første var det et selskap med et stort navn i bransjen, teamet assosierte seg med det (se "Behovet for tilknytning"). For det andre var de den siste grensen, det var ingen bak dem, det var ikke noe produktteam på den tiden. Mellom dem og kundene var det to nivåer av støtte, men hvis problemet nådde dem, var det ingen steder å trekke seg tilbake, ingen var bak dem, hele selskapet var på dem (fire unge programmerere). For det tredje hadde dette store selskapet svært store kunder (landsmyndigheter, bil- og luftfartsselskaper, etc.) og svært store installasjoner i flere land. Som et resultat, alltid komplekse og interessante problemer, ble enkle problemer løst ved støtte fra tidligere nivåer. For det fjerde ble teamets motivasjon sterkt påvirket av det profesjonelle nivået til støtteteamet som de samhandlet med (det var svært erfarne og teknisk dyktige ingeniører), og vi var alltid trygge på kvaliteten på dataene de utarbeidet, analysen de utførte , etc. For det femte, og jeg tror dette er det viktigste poenget - laget var veldig ungt, alle gutta var i begynnelsen av karrieren. De var interessert i å studere et stort og komplekst produkt, løse alvorlige problemer som var nye for dem i et nytt miljø, de forsøkte å profesjonelt matche nivået til de omkringliggende teamene, problemene og kundene. Prosjektet viste seg å være en utmerket skole, alle gjorde senere en god karriere i selskapet og ble tekniske ledere og seniorledere, en av gutta er nå teknisk sjef hos Amazon Web Services, den andre flyttet etter hvert til Google, og alle av dem husker fortsatt dette prosjektet med varme.
Hvis dette teamet bestod av programmerere med 15-20 års erfaring bak seg, ville motivasjonen vært en annen. Alder og erfaring er selvfølgelig ikke 100 % avgjørende faktorer, alt avhenger av motivasjonsstrukturen. I dette spesielle tilfellet ga ønsket om kunnskap og vekst hos unge programmerere utmerkede resultater.
Generelt, som vi allerede har nevnt flere ganger, må du kjenne til forventningene til programmererne dine, forstå hvem av dem som ønsker å utvide eller endre aktivitetsfeltet, og ta hensyn til disse forventningene.
Utover Maslows pyramide: synlighet av resultater, gamification og konkurranse, ingen tull
Det er ytterligere tre viktige punkter angående motivasjonen til programmerere som definitivt må nevnes, men å trekke dem inn i Maslows behovsmodell ville være for kunstig.
Den første er synlighet og nærhet til resultatet.
Programvareutvikling er vanligvis et maraton. Resultatene av FoU-innsatsen blir synlige etter måneder, noen ganger år. Det er vanskelig å gå til et mål som er langt utenfor horisonten, mengden arbeid er skremmende, målet er langt unna, ikke klart og ikke synlig, "natten er mørk og full av grusomheter." Det er bedre å bryte veien til den i deler, lage en sti til det nærmeste treet som er synlig, tilgjengelig, konturene er klare, og det er ikke langt fra oss - og gå til dette nære målet. Vi ønsker å gjøre en innsats på flere dager eller uker, få og evaluere resultatet, for så å gå videre. Derfor er det verdt å dele opp arbeidet i små deler (sprinter i smidig tjener dette formålet godt). Vi har fullført en del av arbeidet - spilt inn det, pustet ut, diskutert det, straffet de skyldige, belønnet de uskyldige - vi kan begynne neste syklus.
Denne motivasjonen er til en viss grad lik det spillere opplever når de fullfører dataspill: de mottar med jevne mellomrom medaljer, poeng, bonuser etter hvert som de fullfører hvert nivå; dette kan kalles "dopaminmotivasjon."
Samtidig er synligheten av resultatet bokstavelig talt viktig. En lukket funksjon i listen skal bli grønn. Hvis koden er skrevet, testet, utgitt, men det er ingen endring i den visuelle statusen synlig for programmereren, vil han føle seg ufullstendig, det vil ikke være noen følelse av fullføring. I et av teamene i vårt versjonskontrollsystem gikk hver oppdatering gjennom tre påfølgende stadier - konstruksjonen ble satt sammen og testene bestått, oppdateringen bestod kodegjennomgangen, oppdateringen ble slått sammen. Hvert stadium ble visuelt merket med en grønn hake eller rødt kryss. Når en av utviklerne klaget over at kodegjennomgangen tok for lang tid, måtte kollegene øke hastigheten, patchene hang i flere dager. Jeg spurte, hva endrer dette egentlig for ham? Når alt kommer til alt, når koden er skrevet, bygget er satt sammen og testene har bestått, trenger han ikke å ta hensyn til den sendte oppdateringen hvis det ikke er kommentarer. Kolleger vil selv vurdere og godkjenne det (hvis det igjen ikke er noen kommentarer). Han svarte: "Igor, jeg vil ha de tre grønne flåttene mine så snart som mulig."
Det andre punktet er gamification og konkurranse.
Da vi utviklet et av produktene, hadde ingeniørteamet vårt et mål om å ta en fremtredende posisjon i fellesskapet til et av produktene med åpen kildekode, for å komme inn på topp-3. På den tiden var det ingen objektiv måte å vurdere noens synlighet i samfunnet på; hver av de store deltakende selskapene kunne hevde (og hevdet med jevne mellomrom) at de var nummer én bidragsyter, men det var ingen reell måte å sammenligne bidragene til deltakerne på. seg imellom, for å evaluere dens dynamikk i tid. Følgelig var det ingen måte å sette et mål for laget som kunne måles i noen papegøyer, vurdere graden av oppnåelse osv. For å løse dette problemet har teamet vårt utviklet et verktøy for å måle og visualisere bidraget fra bedrifter og individuelle bidragsytere . Fra et motivasjonssynspunkt viste det seg bare å være en bombe. Det var ikke bare ingeniører og team som hele tiden overvåket fremgangen deres og fremgangen til sine kolleger og konkurrenter. Toppledelsen i selskapet vårt og alle større konkurrenter startet også dagen med stackalytics. Alt ble veldig gjennomsiktig og visuelt, alle kunne nøye overvåke fremgangen deres, sammenligne med kolleger osv. Det har blitt praktisk og enkelt for ingeniører, ledere og team å sette mål.
Et viktig poeng som dukker opp når man implementerer et hvilket som helst system med kvantitative beregninger, er at så snart man har implementert dem, streber systemet automatisk etter å prioritere oppnåelsen av disse kvantitative metrikkene, til skade for kvalitative. For eksempel brukes antall fullførte kodegjennomganger som en av beregningene. Åpenbart kan kodegjennomgang gjøres på forskjellige måter, du kan bruke flere timer på en grundig gjennomgang og sjekk av en kompleks oppdatering med sjekketester, kjøre den på benken din, sjekke med dokumentasjon, og få pluss én anmeldelse i karmaen din, eller klikk blindt på et par dusin i løpet av et par minutter, gi hver enkelt +1 og få pluss tjue i karma. Det var komiske tilfeller da ingeniører klikket på patcher så raskt at de ga +1 til automatiske patcher fra CI-systemet. Som vi senere spøkte, "gå, gå, jenkins." Når det gjelder commits, var det også mange som gikk gjennom koden med kodeformateringsverktøy, redigerte kommentarer, endret punktum til komma, og dermed pumpet opp karmaen sin. Å håndtere dette er ganske enkelt: vi bruker sunn fornuft og bruker, i tillegg til kvantitative beregninger, også essensielle, kvalitative. Graden av bruk av resultatene av teamets arbeid, antall eksterne bidragsytere, nivået på testdekning, stabiliteten til moduler og hele produktet, resultatene av skala og ytelsestesting, antall ingeniører som mottok kjerneanmelder skulder stropper, det faktum at prosjekter ble akseptert i kjerneprosjektfellesskapet, samsvar med kriteriene for ulike stadier av ingeniørprosessen - alle disse og mange andre faktorer må vurderes sammen med enkle kvantitative beregninger.
Og til slutt, det tredje punktet - No bullshit.
Utviklere er veldig smarte mennesker og ekstremt logiske i jobben sin. De bruker 8-10 timer om dagen på å bygge lange og komplekse logiske kjeder, så de ser sårbarheter i dem i farten. Når de gjør noe, ønsker de, som alle andre, å forstå hvorfor de gjør det, hva som vil endre seg til det bedre. Det er ekstremt viktig at målene du setter for teamet ditt er ærlige og realistiske. Å prøve å selge en dårlig idé til et programmeringsteam er en dårlig idé. En idé er dårlig hvis du ikke tror på den selv, eller, i ekstreme tilfeller, du ikke har den interne tilstanden til å være uenig og forplikte (jeg er ikke enig, men jeg skal gjøre det). Vi implementerte en gang et motivasjonssystem i en bedrift, hvor ett av elementene var et elektronisk system for å gi tilbakemelding. De investerte mye penger, tok folk til Amerika for å trene, generelt investerte de til det fulle. En gang, i en samtale etter opplæringen, sa en av lederne til sine underordnede: «Ideen er ikke dårlig, det ser ut til at den vil fungere. Jeg vil ikke gi deg elektronisk tilbakemelding selv, men du gir det til folket ditt og krever det fra dem.» Det er det, ingenting kunne implementeres videre. Ideen endte selvfølgelig i ingenting.
Kilde: www.habr.com