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 diskussionen af vores teamleder, samt RAS produktudviklingsdirektør, Igor Marnat, om det særlige ved at motivere programmører.
Hemmeligheden bag succes med at skabe fede softwareprodukter er velkendt - tag et hold af seje programmører, giv holdet en fed idé og bland dig ikke i holdets arbejde. Seje udviklere er sjældne og efterspurgte. Nogle rekrutterere siger endda, at de har indtryk af, at det er nemmere at producere en sej programmør end at hyre en fra markedet. Ud over vanskelighederne med at ansætte som sådan, er hver enkelt udviklers erfaring, hans viden om det eksisterende produkt og historien om dets udvikling, ofte uerstattelig eller svær og tidskrævende at genopbygge. Hvis du er heldig og allerede har et sejt team af programmører, er det derfor vigtigt at arbejde med deres motivation. Det er næsten lige så svært og tidskrævende at ansætte og træne nye udviklere, at lave et hold ud af dem som at føde og opdrage børn.
Lad os overveje de vigtigste motivationsfaktorer for programmører (teams af programmører), ved at bruge Maslows pyramide til klarhed og strukturering af præsentationen. Hvis du ikke har hørt om Maslows pyramide, er det ikke en ubestridt, men meget populær og illustrativ teori fra den amerikanske psykolog Abraham Harold Maslow, som foreslog en teori om personlig motivation baseret på hierarkiet af menneskelige behov (se billedet nedenfor).
Maslow arrangerede individets behov i en hierarkisk rækkefølge, fra fysiologiske behov til behovet for potentiel udvikling og selvaktualisering. En central antagelse i Maslows teori er, at "en person ikke kan opleve behov på højere niveau, før hans behov på lavere niveau er opfyldt." For eksempel kan en person ikke være drevet af behov for viden eller æstetiske behov, hvis denne person samtidig ikke har sovet eller spist i tre dage.
Inden vi går i detaljer, lad os fokusere på et indlysende faktum – et team består af mennesker, alle mennesker er forskellige, hver har deres egen motivationsstruktur. Udover at hver person er drevet af forskellige interesser, er hver person også i forskellige livsbetingelser. Nogen er i begyndelsen af en karriere og tænker på, hvordan man bygger den op, nogen skal giftes, og nogen vil mestre et nyt fagområde. Hvad der er vigtigt for en er fuldstændig ligegyldigt for en anden, og i morgen vil alt ændre sig igen. For at forstå denne sammenhæng korrekt, er der et simpelt middel - du skal tænke over det og arbejde med det. Det vigtigste er kommunikation.
Sørg for at tale med dit team om noget andet end arbejde, opbyg uformelle relationer.
Så lad os nu gå igennem Maslows pyramide og betragte dens niveauer som anvendt til at styre et team af programmører.
I: Fysiologiske, biologiske behov:
Når man taler om motivation, tænker mange ofte først og fremmest på løn. I dette tilfælde mener jeg med løn en permanent del af kompensationspakken, som ikke på nogen måde afhænger af resultaterne. Dette gælder ikke for bonusser, bonusser og virksomhedskampagner. Det er lønnen, som jeg vil tilskrive niveauet af "fysiologiske behov" i vores tilfælde. Bonusser, bonusser baseret på præstationer, optioner og selskabsaktier – jeg vil klassificere alt dette på andre niveauer.
Efter min mening, hvor mærkeligt det end lyder, kunne lønnen hellere være demotiverende faktor frem for en motiverende faktor. Det særlige ved at arbejde med programmører er, at de alle er mennesker, for det første meget smarte (et kendetegn ved professionen), og for det andet dybt og/eller bredt uddannede. Typisk har programmører, udover deres fag, en dyb forståelse for et eller flere fagområder, som de skaber produkter til. Derudover er gode programmører interesserede i og kender godt historien om programmeringsudvikling, algoritmer, standarder mv. Det samme gælder deres fagområde. For personer på dette niveau er løn normalt ikke den primære motivationsfaktor.
Samtidig demotiverer og demotiverer manglen på en rimelig løn for programmører i deres forståelse i høj grad. At have en rimelig løn er normen. Lønnen er meget højere end normen (markedet) - også mærkeligt nok en ret demotiverende faktor. En kollega fortalte mig engang om et team af programmører i et af de store amerikanske animationsfirmaer, som på grund af en række omstændigheder fik løn på et niveau, der var to til tre gange højere end markedet. Som han sagde, havde han aldrig set flere kedelige, dovne og demotiverede programmører i sit liv. Det faktum, at en lønstigning kan motivere på kort sigt, men efter nogle måneder bliver den nye løn normen og holder op med at motivere. Generelt vil jeg sige, at for programmører i begyndelsen af deres karriere er lønfaktoren vigtigere, da de vokser professionelt og udvikler sig, dens betydning falder, og andre faktorer begynder at sejre.
Det andet vigtige punkt er tilstedeværelsen af en rimelig balance i lønniveauet i teamet. Hvis et team føler, at et medlems bidrag er mærkbart lavere, men kompensationsniveauet er det samme, vil det demotivere hele teamet. Nogle gange bliver ledere fristet til at fyre op med penge – for at fastholde en udbrændt eller demotiveret person ved at hæve hans løn over det normale. Dette skaber normalt kun problemer i det lange løb – motivationen hos personen selv vil ikke stige meget, eller den vil stige i et par måneder, men motivationen hos resten af teamet vil falde. I sådanne situationer er det værd at lede efter andre tilgange, medmindre dette selvfølgelig er en unik specialist, der skal bibeholdes for enhver pris, selv i kort tid.
II. Behov for sikkerhed, komfort, sammenhæng i levevilkårene:
For 70 år siden kunne tilstedeværelsen af en brændeovn i en bil være en motivationsfaktor, når man skulle vælge bil; dengang var det over normen og var et tegn på luksus. Nu er selv fraværet af aircondition noget vrøvl, og dets tilstedeværelse vil selvfølgelig ikke være en motiverende faktor, når du skal vælge bil. Så for 10-15 år siden, et bekvemt kontor, godt isenkram, lækker kaffe, fitness, fleksible timer mv. kunne være gode motiverende faktorer, men nu er dette snarere normen for en god programmørs arbejde. Samtidig vil deres fravær igen være demotiverende.
En vigtig demotiverende faktor er manglende koncentrationsevne og et støjende arbejdsmiljø. En programmørs arbejde kræver stilhed og koncentration. Hvis kontorlokalet ikke giver mulighed for at give udviklere et afsondret arbejdsområde, er det nødvendigt i det mindste at sikre et behageligt samarbejde mellem kolleger, der ikke forstyrrer hinanden. Det er bedre at forene energiske og højlydte kammerater med hinanden, hvilket giver mulighed for at koncentrere sig til dem, der har brug for det.
Udgifterne til en programmørs tid er nu væsentligt højere end prisen på den hardware, han arbejder på. To eller tre skærme, kraftfulde computere, en behagelig arbejdsplads for enhver udvikler - burde være normen i enhver virksomhed. Dette emne er godt dækket i en af Joel Spolskys artikler "Joel-testen: 12 trin til bedre kode."
Den fysiske komponent af komfort er den mest basale og enkle; lad os nu tale om resten.
I mange virksomheder er normen for programmører en fleksibel arbejdsplan og ingen dresscode. Dette er godt og korrekt, hvis de særlige forhold i teamets arbejde tillader det (der er f.eks. ingen møder med kunder, politikere eller bankfolk).
Det vigtige er at have et bestemt tidsvindue, hvor hele teamet arbejder sammen lokalt, så folk kan kommunikere og løse problemer ansigt til ansigt. En programmør forlader i bund og grund ikke arbejdet selv efter arbejde. Typisk gentager arbejdsspørgsmål i hans sind uanset hans tilstedeværelse på kontoret, og gode beslutninger kommer ofte uden for kontoret. I betragtning af behovet for at være god (som vi vil diskutere nedenfor), er smålig kontrol skadelig. Det er ikke kun demotiverende, det reducerer også produktiviteten. Som praksis viser, i mangel af kontrol, er det mere sandsynligt, at et motiveret team arbejder længere end nødvendigt. Hvis der er kontrol, kan udviklere sidde ved tastaturet fra ni til seks, men resultatet, tror jeg, bliver værre. Som de siger, kan en person føre en hest til vandet, men selv hundrede vil ikke tvinge ham til at drikke, hvis han ikke vil.
Beskrivelsen af dette behovsniveau nævner også frihed fra angst og frygt, fravær af kaos og behovet for struktur og orden. Det er også ekstremt vigtige punkter, som i høj grad påvirker stemningen i holdet.
For det første fraværet af kaos, struktur og orden - teamet skal forstå, hvem der har ansvaret for hvad, hvordan roller fordeles, hvad der skal gøres, til hvem, hvornår, hvilke krav ligger til grund for produktet, hvad er ledelsens forventninger og kunden... Det meste af dette skal være formelt beskrevet, alt bør diskuteres med jævne mellemrum. Uden diskussion og periodisk brug fungerer beskrivelser ikke. Det er god praksis at diskutere dem med jævne mellemrum og opdatere dem baseret på resultaterne af postmortem-analyse efter udgivelsen.
For det andet en rolig og venlig atmosfære. Vi bruger alle det meste af vores tid på arbejdet, og vi vil gerne gøre det uden stress, konflikter eller frygt. Udviklingsteamet arbejder normalt under pres fra tidsplaner og kunder. Ingen har brug for yderligere stress fra kolleger og overordnede. Atmosfæren i teamet, generelt selve det faktum, at en gruppe udviklere kan kaldes og være et "team", er lederens direkte og vigtige ansvar, en af de vigtigste mellem- og langsigtede opgaver. Derfor er det vigtigt for en leder at arbejde især med konflikter i teamet og ikke lade deres udvikling gå sin gang. Konflikthåndtering er et særskilt emne, som fortjener særskilt undersøgelse.
Der er to hovedmåder til at påvirke teamets følelsesmæssige tilstand og kollegaernes adfærd (hvis nogen tilføjer i kommentarerne, ville det være fantastisk). Den første er din egen adfærd. Personligt eksempel er super vigtigt for en leder og team. Som man siger, ligesom præsten, så er ankomsten. Opfør dig, som du forventer, at dine kollegaer opfører sig. Den anden er at tilskynde til korrekt adfærd og så at sige de-opmuntre forkert adfærd. Kommuniker med folk, giv dem feedback, der er mange måder at gøre dette på. Generelt er feedback et emne for en separat diskussion, det er en stor og vigtig del af arbejdet med motivation.
Endnu en bemærkning om atmosfæren, som kan virke usædvanlig, men i praksis er den vigtig. Som oftest er der færre piger på udviklingsholdet end mænd. Ofte er grupperne udelukkende mænd. Under sådanne forhold, også under belastning, begynder nogle gange uanstændigt sprog at blive brugt i teamet. Praksis viser, at dette har en negativ indvirkning på atmosfæren; kommunikation bliver gradvist uhøflig. Du bør undgå at bruge det selv og fraråde brugen af det i dit team.
Udviklingsteams kaldes ofte R&D (forskning og udvikling), hvor forskning udgør en væsentlig del af arbejdet. Det er den del, der normalt er svær at programmere og planlægge efter, ellers ville det ikke være forskning. Det er vigtigt, at teamet har ret til at begå fejl, til at tage initiativ, til at prøve forskellige muligheder, der måske eller måske ikke ender med succes. Fejl er en normal del af arbejdet, de kan ikke undgås, men du kan studere, analysere, lære af dem for fremtiden og komme videre. 5 Why's-princippet, som stammer fra Toyota, er en god måde at finde frem til årsagen til et problem. At straffe fejl er en fantastisk måde at skabe en atmosfære af frygt og usikkerhed på. Den eneste undtagelse er, når det på baggrund af analysens resultater viser sig, at fejlen skyldes en uprofessionel holdning til arbejdet, i dette tilfælde kan det være nødvendigt at træffe personalebeslutninger.
Stemningen i teamet er i høj grad påvirket af dine forventninger og følelsesmæssige tilstand, før samtalen begynder. Inden du starter en svær diskussion, en form for debriefing eller blot en følelsesladet samtale, er dit humør og din holdning til den person, du skal tale med, vigtig. Jeg tror og handler altid som standard ud fra, hvad personen oprigtigt forsøgte at gøre bedst. Hvis det fra din holdning ser ud til, at det ikke er tilfældet, skal du roligt og detaljeret finde ud af sammenhængen og forstå, hvad han gjorde rigtigt, hvorfor han mente, det var rigtigt, og hvor vores forventninger divergerer. Det viser sig normalt, at de ikke rigtig adskiller sig, det er bare, at hans vision af konteksten er mere komplet eller frisk, og der er noget, du ikke vidste. Eller omvendt, han vidste ikke noget. Dette er især vigtigt i et distribueret team, når folk kommunikerer sjældnere personligt og bruger e-mail og instant messengers. Dette er endnu mere kritisk i et team bestående af programmører fra forskellige lande og fordelt på tværs af forskellige tidszoner. Det er her, kulturelle forskelle begynder at spille en stor rolle.
I en vanskelig situation er det let, meget nemt at køre over på farten, men så er det svært at køre tilbage, og bundfaldet bliver liggende i lang tid. Lad mig give dig et simpelt eksempel fra nyere erfaringer. En af teamlederne havde akut brug for kommentarer om et eller andet problem med en kunde fra en leder fra et relateret team i et andet land. Han pingede en kollega i messengeren, ventede 15 minutter, pingede igen, så 15 minutter senere gik han til en stor chat, hvor de andre ledere også var, og angreb kollegaen let med en formulering som: ”da du ikke gør det. værdig til at svare mig, måske, og spørgsmålet er ikke så presserende?" Til sidst viste det sig, at vores corporate messenger var lidt sløv, og kollegaen så slet ikke spørgsmålet. Jeg var nødt til at undskylde. Generelt er det bedre at starte med det gode. Det er altid muligt at lave en slem fejl og løbe ind i problemer senere; det er der ikke noget problem med (selvom du ikke bør gøre det). Generelt har jeg i mere end 20 års arbejde i vores branche kun mødt en virkelig ondsindet kollega én gang (!). Heldigvis gik vi ret hurtigt fra hinanden. Det viser sig i langt de fleste tilfælde at være korrekt at antage, at kolleger vil det bedste, efter deres bedste forståelse af sammenhængen.
Din opgave som leder er at sikre synkronisering af sammenhænge, en fælles forståelse af forventninger, krav, deadlines og standarder accepteret i teamet. Det kan virke som små ting, men stemningen i teamet er netop bygget op af sådanne småting. Fra et distribueret teamperspektiv er en af de vigtige opgaver at sikre, at teammedlemmerne har periodisk ansigt-til-ansigt kommunikation. Jeg har hørt mere end én gang fra programmører, at efter for eksempel ingeniører fra supportteamet kom til dem og arbejdede sammen personligt, blev de gladeligt på arbejde for at hjælpe i en vanskelig sag personligt til Pasha, som for nylig var kommet til dem, selvom Pasha tidligere bare var et ikon i messengeren, og ingen ville have stoppet for ikonets skyld.
Forresten begyndte jeg at tale om supportteamet og huskede et kanonisk eksempel for mig. Engang havde en af kunderne i Amerika et problem med produktet, en af ingeniørerne fra supportteamet, der arbejdede på hans implementering (udsendt fra Rusland), blev efter arbejde for at hjælpe, men problemet blev ikke løst og blev ikke løst. Generelt dvælede han og sad der næsten til morgenen. På dette tidspunkt eskalerede kundens ledere problemet, identificerede dets kritiske betydning for dem og forlod arbejdet om aftenen. Eskaleringsprocessen tog allerede fart i en anden tidszone, supportchefer i Rusland begyndte at forsøge at hjælpe på grund af visse vanskeligheder med kommunikationen med kundens kontor (VPN, forbindelsesproblemer, problemer med opkald mellem lande, ...) vidste ikke, at fyren allerede sad i fængsel på kontoret og løser problemet, og forsøgte at finde ham. De fandt det først om morgenen (amerikansk), da problemet allerede var praktisk talt løst, og produktet virkede. Lige fra starten begyndte de at sige, at hvad fanden, kunden har sådan en eskalering, intet virker, hvor er du, vi kan ikke finde dig osv. Det er overflødigt at sige, at fyren som et resultat af en sådan adfærd var meget demotiveret. Organisering af arbejdet i et distribueret team er et separat stort emne, men det er vigtigt at huske to ting. For det første er kommunikation og atmosfære meget vigtigt, arbejdets succes afhænger af det. For det andet fungerer dette ikke af sig selv, det skal behandles særskilt og i dybden.
Et andet vigtigt punkt relateret til dette behovsniveau er igen løn. Ikke størrelsen af lønnen som sådan, men tilstedeværelsen af en bestemt procedure for at ændre den. Virksomheden skal have en tilgang til at fastlægge kravene til stillinger på forskellige niveauer. Hver udvikler bør være i stand til at diskutere forventninger til deres arbejde med virksomheden, forstå hvordan og hvornår deres indsats kan påvirke deres løn. Periodiske møder med lederen, halvårlige eller årlige resultatgennemgange tjener dette formål. Dette er igen et af de øjeblikke, hvis tilstedeværelse ikke udtrykkeligt motiverer, men deres fravær er meget demotiverende.
Fra behovet for orden og tilstedeværelsen af regler følger behovet for at overholde disse regler, for at følge de normer, der accepteres i teamet, både formelle og uformelle. Generelt vil jeg kalde det behovet for at "være god." Tilstedeværelsen af dette behov bekræfter, at mikrostyring ikke er nødvendig, men snarere skadelig. Det er nok at give en person alt det nødvendige til arbejdet, give ham viden om konteksten, prioriteringer og give handlefrihed og beslutningstagning på hans niveau. Under sådanne forhold vil han føle tillid, mulighed for at træffe sine egne beslutninger, tage ansvar for dem og vil være i stand til at afsløre sit potentiale.
Et andet vigtigt punkt, der bør tilskrives behovet for orden og fraværet af kaos, er evnen til at koncentrere sig om en opgave, fraværet af hyppige kontekstskift. At være programmør kræver tid og fokus. Programmører kan virkelig ikke lide akut at opgive én opgave og skifte til en anden. En nødvendig del af en programmørs arbejde er normalt ikke kun selve udviklingen af koden, men også fejlretning og hjælp til behandling af anmodninger fra kunder. Det er værd at planlægge sådanne ting på forhånd, på en sådan måde at give programmøren mulighed for roligt og fuldstændigt at fuldføre arbejdet med en opgave, før han skifter til en anden. Den bedste mulighed er at give dig selv mulighed for selv at planlægge dit arbejde, identificere prioriteter og kommende opgaver på forhånd, afsætte lange, længere perioder til at arbejde med én type opgave. Dette emne er godt beskrevet i bogen "Google - Site Reliability Engineering”, som godt beskriver tilgange til planlægning af arbejdet i teams, der sikrer drift og udvikling af store, højt belastede, fejltolerante systemer, samt ingeniører, hvis erhverv kombinerer softwareudvikling og dens support.
Fortsættes ...
Kilde: www.habr.com