Epigraaf:
De man sjocht nei de grimmitige bern en seit tsjin syn frou: no, sille wy dizze waskje of nije bern jaan?
Under de besuniging is it twadde diel fan in artikel troch ús teamlieder, lykas RAS Product Development Director Igor Marnat, oer de eigenaardichheden fan motivearjende programmeurs. It earste diel fan it artikel is hjir te finen -
Yn it earste diel fan it artikel rekke ik op 'e twa legere nivo's fan Maslow's piramide: fysiologyske behoeften, needsaak foar feiligens, komfort en konstantens en gean troch nei it folgjende, tredde nivo, nammentlik:
III - Ferlet fan hearren en leafde
Ik wist dat de Italjaanske mafia waard neamd "Cosa Nostra", mar ik wie tige ûnder de yndruk doe't ik fûn út hoe't "Cosa Nostra" wurdt oerset. "Cosa Nostra" oerset út it Italjaansk betsjut "Us bedriuw". De kar fan namme is tige suksesfol foar motivaasje (litte wy de besetting oan 'e kant litte, yn dit gefal binne wy allinich ynteressearre yn motivaasje). In persoan wol gewoanlik diel útmeitsje fan in team, wat grutte, mienskiplike, ús bedriuw dwaan.
Grut belang wurdt pleatst op it befredigjen fan de needsaak foar hearren en leafde yn it leger, marine, en alle grutte paramilitêre formaasjes. En, lykas wy sjogge, yn 'e mafia. Dat is begryplik, om't jo minsken twinge moatte dy't net folle mienskiplik hawwe, dy't yn earste ynstânsje gjin team foarmje fan likesinnige minsken, dy't troch de tsjinstplicht byinoar brocht wurde (net frijwillich), dy't ferskate opliedingsnivo's hawwe, ferskillende persoanlike wearden , om har libben letterlik te wijen, op stjerlik risiko, oan ien of oare mienskiplike oarsaak , fertrouwe jo libben oan in kameraad yn wapens.
Dit is in heul sterke motivaasje; foar de measte minsken is it ekstreem wichtich om te fielen dat se by iets grutters hearre, om te witten dat jo diel binne fan in famylje, in lân, in team. Yn it leger tsjinje unifoarmen, ferskate rituelen, parades, marsen, spandoeken, ensfh. Rûchwei deselde faktoaren binne wichtich foar elk team. Symboalen, bedriuwsmerk en bedriuwskleuren, parafernalia en souvenirs binne wichtich.
It is wichtich dat wichtige eveneminten har eigen sichtbere belichaming hawwe wêrmei't se kinne wurde assosjearre. Tsjintwurdich is it earder de noarm foar in bedriuw om eigen merchandise, jassen, T-shirts, ensfh. Mar it is ek wichtich om it team binnen it bedriuw te markearjen. Wy faak frij T-shirts basearre op de resultaten fan in release, dy't wurde jûn oan allegearre belutsen by de release. Guon eveneminten, mienskiplike feesten of aktiviteiten mei it hiele team binne in oare wichtige faktor fan motivaasje.
Neist eksterne attributen beynfloedzje ferskate oare faktoaren it gefoel fan in team te hearren.
As earste, de oanwêzigens fan in mienskiplik doel dat elkenien begrypt en dielt in beoardieling fan har belang. Programmeurs wolle gewoanlik begripe dat se in cool ding dogge, en se dogge dit coole ding tegearre, as in team.
As twadde moat it team in kommunikaasjeromte hawwe dêr't it hiele team yn oanwêzich is en dy't der allinnich by heart (bygelyks in petear yn 'e boadskipper, periodike teamsyncaps). Neist wurkproblemen, ynformele kommunikaasje, soms diskusje oer eksterne eveneminten, ljocht offtop - dit alles soarget foar in gefoel fan mienskip en team.
Tredde, ik soe de ynfiering fan goede yngenieurpraktiken binnen it team markearje, de winsk om noarmen te ferheegjen yn ferliking mei dy akseptearre yn it bedriuw. It ymplementearjen fan de bêste oanpak akseptearre yn 'e yndustry, earst yn it team, en dan yn it bedriuw as gehiel, jout it team de kâns om te fielen dat it op ien of oare manier foar oaren is, it paad liedt, dit skept in gefoel fan hearren nei in koel team.
It gefoel fan hearren wurdt ek beynfloede troch de dielname fan it team oan planning en behear. As teamleden belutsen binne by it besprekken fan projektdoelen, wurkplannen, teamnoarmen en yngenieurspraktiken, en ynterviewe mei nije meiwurkers, ûntwikkelje se in gefoel fan partisipaasje, dield eigendom en ynfloed op it wurk. Minsken binne folle reewilliger om besluten út te fieren dy't troch harsels nommen en útsprutsen binne as dy foarsteld troch oaren, sels as se praktysk yn tune binne.
Jierdagen, jubilea, wichtige barrens yn it libben fan kollega's - in mienskiplike pizza, in lyts kado fan it team jouwe in waarm gefoel fan belutsenens en tankberens. Yn guon bedriuwen is it wenst om lytse tinktekens te jaan foar 5, 10, 15 jier wurk yn it bedriuw. Oan de iene kant tink ik net dat dit my sa motivearret foar nije prestaasjes. Mar, fansels, hast elkenien sil bliid wêze dat se him net fergetten binne. Dit is ien fan dy gefallen dêr't it ûntbrekken fan in feit demotivearret ynstee fan syn oanwêzigens motivearret. It iens, it kin in skande wêze as LinkedIn jo moarns herinnere en jo lokwinske mei jo 10e jubileum op jo wurkplak, mar gjin inkelde kollega fan it bedriuw lokwinsket jo of ûnthâlde jo.
Fansels is in wichtich punt de feroaring yn 'e gearstalling fan it team. Dúdlik is dat ek as de komst of it fuortgean fan ien út it team fan tefoaren bekend makke wurdt (bygelyks yn in bedriuw- of teamnijsbrief, of op in teamgearkomste), dit net bysûnder motivearret immen ta nije prestaasjes. Mar as jo op in moaie dei in nije persoan neist jo sjogge, of gjin âlde sjogge, kin it in ferrassing wêze, en as jo fuortgean, gewoan ûnnoflik. Minsken moatte net rêstich ferdwine. Benammen yn in ferdield team. Benammen as jo wurk hinget ôf fan in kollega fan in oar kantoar dy't ynienen op en ferdwûn. Sokke mominten binne perfoarst de muoite wurdich om it team foarôf apart te ynformearjen.
In wichtige faktor, dy't yn it Ingelsk hjit eigendom (de letterlike oersetting fan "besit" wjerspegelet de betsjutting net folslein). Dit is gjin gefoel fan eigendom, mar earder in gefoel fan ferantwurdlikens foar jo projekt, dat gefoel as jo josels emosjoneel assosjearje mei it produkt en it produkt mei josels. Dit komt rûchwei oerien mei it gebed fan 'e Marine yn' e film "Full Metal Jacket": "Dit is myn gewear. Der binne in protte sokke gewearen, mar dizze is fan my. Myn gewear is myn bêste freon. Sy is myn libben. Ik moat leare om it te besit op deselde manier as ik myn libben besit. Sûnder my is myn gewear nutteloos. Ik bin nutteloos sûnder myn gewear. Ik moat myn gewear rjochtút sjitte. Ik moat krekter sjitte as de fijân dy't my besiket te deadzjen. Ik moat him sjitte foardat er my sjit. Lit it sa wêze..."
As in persoan foar in lange tiid wurket oan in produkt, hat de kâns om folsleine ferantwurdlikens te dragen foar syn skepping en ûntwikkeling, om te sjen hoe't in wurkjend ding ûntstiet út "neat", hoe't minsken it brûke, ûntstiet dit krêftige gefoel. Produktteams dy't lange tiid gearwurkje oan ien projekt binne meastentiids mear motivearre en gearhingjende as teams dy't foar in koarte perioade gearstald binne en wurkje yn assemblagelinemodus, wikselje fan it iene projekt nei it oare, sûnder folsleine ferantwurdlikens foar it heule produkt , fan begjin oant ein.
IV. Need foar erkenning
In aardich wurd fynt de kat ek wol. Elkenien wurdt motivearre troch erkenning fan it belang fan it wurk dat se dien hawwe en de positive beoardieling dêrfan. Praat mei programmeurs, jou har periodike feedback, fiere in goed dien wurk. As jo in grut en ferspraat team hawwe, binne periodike gearkomsten (wat ien op ien neamd wurde) perfekt foar dit; as it team heul lyts is en lokaal gearwurket, wurdt dizze kâns meastentiids foarsjoen sûnder spesjale gearkomsten op 'e kalinder (hoewol periodyk ien oan ien is alles It is noch nedich, jo kinne it gewoan minder faak dwaan). Dit ûnderwerp wurdt goed behannele yn podcasts foar managers op manager-tools.com.
It is lykwols de muoite wurdich om kulturele ferskillen yn gedachten te hâlden. Guon oanpak dy't bekend binne foar Amerikaanske kollega's sille net altyd wurkje mei Russyske. It nivo fan beleefdheid akseptearre yn deistige kommunikaasje yn teams yn westerske lannen liket ynearsten te heech foar programmeurs út Ruslân. Guon rjochtlinen karakteristyk foar Russyske kollega's kinne wurde waarnommen as grofheid troch har kollega's út oare lannen. Dit is heul wichtich yn kommunikaasje yn in ynteretnysk team; der is in protte oer dit ûnderwerp skreaun; de manager fan sa'n team moat dit ûnthâlde.
Funksjesdemonstraasjes, wêrby't programmeurs funksjes sjen litte ûntwikkele tidens in sprint, binne in goede praktyk foar it realisearjen fan dizze need. Neist it feit dat dit in poerbêste kâns is om kommunikaasjekanalen tusken teams te wiskjen, produktbehearders en testers yn te fieren oan nije funksjes, is it ek in goede kâns foar ûntwikkelders om de resultaten fan har wurk te sjen en har auteurskip oan te jaan. No, en poets jo feardigens yn it iepenbier, fansels, wat noait skealik is.
It soe in goed idee wêze om de wichtige bydrage fan benammen foarname kollega's te fieren mei sertifikaten, tinktekens (op syn minst in freonlik wurd) by mienskiplike teambyienkomsten. Minsken wurdearje sokke sertifikaten en betinkingsbuorden meastentiids tige, nimme se mei by it ferpleatsen en soargje der oer it algemien op alle mooglike manieren foar.
Om in wichtiger, lange termyn bydrage oan it wurk fan it team te markearjen, opboude ûnderfining en saakkundigens, wurdt faak in gradesysteem brûkt (wer kin in analogy lutsen wurde mei it systeem fan militêre rangen yn it leger, dy't boppedat om ûndergeskiktheid te garandearjen, tsjinnet ek dit doel). Faak wurkje jonge ûntwikkelders twa kear sa hurd om nije stjerren op har skouderriemen te krijen (dus ferhúzje fan junior ûntwikkelder nei folsleine ûntwikkelder, ensfh.).
It kennen fan de ferwachtings fan jo minsken is kritysk. Guon wurde earder motivearre troch in hege graad, de kâns om bygelyks in arsjitekt neamd te wurden, wylst oaren, krekt oarsom, ûnferskillich binne foar rangen en titels en sille in ferheging fan salaris beskôgje as in teken fan erkenning fan it bedriuw . Kommunisearje mei minsken om te begripen wat se wolle en wat har ferwachtingen binne.
In demonstraasje fan erkenning, in heger nivo fan fertrouwen fan 'e kant fan it team, kin jûn wurde troch mear frijheid fan hanneljen of belutsenens by nije wurkgebieten te jaan. Bygelyks, nei it opheljen fan bepaalde ûnderfining en it berikken fan bepaalde resultaten, in programmeur, neist it útfieren fan syn funksjes yn oerienstimming mei de spesifikaasje, kin wurkje oan 'e arsjitektuer fan nije dingen. Of wurde belutsen by nije gebieten dy't miskien net direkt relatearre binne oan ûntwikkeling - testautomatisearring, ymplemintearjen fan bêste yngenieurpraktiken, helpe mei releasebehear, sprekken op konferinsjes, ensfh.
V. De needsaak foar kennis en selsaktualisaasje.
In protte programmeurs binne rjochte op ferskate soarten programmearringaktiviteiten yn ferskate stadia fan har libben. Guon minsken wolle masine learen dwaan, nije gegevensmodellen ûntwikkelje, in protte wittenskiplike literatuer lêze foar wurk, en wat nij meitsje fanôf it begjin. In oar is tichter by it debuggen en stypjen fan in besteande applikaasje, wêryn jo moatte grave djip yn 'e besteande koade, studearje logs, stack spoaren en netwurk captchas foar dagen en wiken, en skriuwe hast gjin nije koade.
Beide prosessen fereaskje grutte yntellektuele ynspanning, mar harren praktyske útfier is oars. It wurdt leaud dat programmeurs weromhâldend binne om besteande oplossingen te stypjen; se binne earder motivearre om nije te ûntwikkeljen. Der sit in kerltsje wiisheid yn. Oan 'e oare kant wie it meast motivearre en ferienige team wêrmei't ik ea wurke haw wijd oan it stypjen fan in besteand produkt, it finen en reparearjen fan bugs nei't it stipeteam kontakt mei har hie. De jonges libbe letterlik foar dit wurk en wiene ree om op sneon en snein út te gean. Wy hawwe ienris grif mei in oar driuwend en kompleks probleem te krijen, itsij op 'e jûn fan 31 desimber of op' e middei fan 1 jannewaris.
Ferskate faktoaren beynfloede dizze hege motivaasje. As earste wie it in bedriuw mei in grutte namme yn 'e yndustry, it team assosjearre har dêrmei (sjoch "De needsaak foar oansluting"). Twad wiene se de lêste frontier, der wie gjinien efter harren, der wie gjin produkt team op dat stuit. Tusken harren en de klanten wiene d'r twa nivo's fan stipe, mar as it probleem har berikte, wie d'r nergens om werom te lûken, gjinien wie efter har, de heule korporaasje wie op har (fjouwer jonge programmeurs). Tredde, hie dit grutte bedriuw tige grutte klanten (lannen oerheden, auto- en loftfeartbedriuwen, ensfh.) En tige grutskalige ynstallaasjes yn ferskate lannen. As gefolch, altyd komplekse en nijsgjirrige problemen, ienfâldige problemen waarden oplost troch de stipe fan eardere nivo's. Fjirde waard de motivaasje fan it team sterk beynfloede troch it profesjonele nivo fan it stipeteam mei wa't se omgeane (d'r wiene heul betûfte en technysk bekwame yngenieurs), en wy wiene altyd betrouwen yn 'e kwaliteit fan' e gegevens dy't se tariede, de analyse dy't se útfierden. , ensfh. Fyfde, en ik tink dat dit it wichtichste punt is - it team wie heul jong, alle jonges wiene oan it begjin fan har karriêre. Se wiene ynteressearre yn it studearjen fan in grut en kompleks produkt, it oplossen fan serieuze problemen dy't har nij wiene yn in nije omjouwing, se sochten profesjoneel oerien te kommen mei it nivo fan 'e omlizzende teams, problemen en klanten. It projekt waard in poerbêste skoalle, elkenien makke letter in goede karriêre yn it bedriuw en waard technyske lieders en senior managers, ien fan 'e jonges is no technysk manager by Amazon Web Services, de oare ferhuze úteinlik nei Google, en alles fan harren ûnthâlde dit projekt noch mei waarmte.
As dit team bestie út programmeurs mei 15-20 jier ûnderfining efter har, soe de motivaasje oars wêze. Leeftyd en ûnderfining binne fansels net 100% bepalende faktoaren; it hinget allegear ôf fan 'e struktuer fan motivaasje. Yn dit bysûndere gefal, de winsk foar kennis en groei fan jonge programmeurs levere treflike resultaten.
Yn 't algemien, lykas wy al ferskate kearen hawwe neamd, moatte jo de ferwachtings fan jo programmeurs kennen, begripe wa fan har har aktiviteitsfjild útwreidzje of feroarje wolle, en dizze ferwachtingen rekkenje.
Beyond Maslow's piramide: sichtberens fan resultaten, gamification en konkurrinsje, gjin bullshit
D'r binne noch trije wichtige punten oangeande de motivaasje fan programmeurs dy't perfoarst neamd wurde moatte, mar se tekenje yn it behoeftenmodel fan Maslow soe te keunstmjittich wêze.
De earste is de sichtberens en de tichtby fan it resultaat.
Softwareûntwikkeling is normaal in maraton. De resultaten fan R&D-ynspanningen wurde nei moannen, soms jierren, sichtber. It is lestich om nei in doel te gean dat fier bûten de hoarizon is, de hoemannichte wurk is skriklik, it doel is fier fuort, net dúdlik en net sichtber, "de nacht is tsjuster en fol mei horrors." It is better om de wei nei it yn dielen te brekken, in paad te meitsjen nei de tichtstbye beam dy't sichtber, berikber is, de konturen binne dúdlik, en it is net fier fan ús - en gean nei dit tichtby doel. Wy wolle in ynspanning fan ferskate dagen of wiken dwaan, it resultaat krije en evaluearje, en gean dan troch. Dêrom is it wurdich it wurk yn lytse dielen te brekken (sprints yn agile tsjinje dit doel goed). Wy hawwe in diel fan it wurk foltôge - opnommen, útademen, besprutsen, de skuldige bestraft, de ûnskuldigen beleanne - wy kinne de folgjende syklus begjinne.
Dizze motivaasje is foar in part gelyk oan wat spilers ûnderfine by it foltôgjen fan kompjûterspultsjes: se krije periodyk medaljes, punten, bonussen as se elk nivo foltôgje; dit kin "dopamine-motivaasje" wurde neamd.
Tagelyk is de sichtberens fan it resultaat letterlik wichtich. In sletten funksje yn 'e list moat grien wurde. As de koade wurdt skreaun, hifke, frijlitten, mar der is gjin feroaring yn 'e fisuele status sichtber foar de programmeur, hy sil fiele ûnfolslein, der sil gjin gefoel fan foltôging. Yn ien fan 'e teams yn ús ferzjekontrôlesysteem gie elke patch troch trije opienfolgjende stadia - de bou waard gearstald en de tests trochjûn, de patch trochjûn de koadebeoardieling, de patch waard gearfoege. Elke poadium waard visueel markearre mei in griene tik of read krús. Ienris ien fan 'e ûntwikkelders klage dat de koadebeoardieling te lang duorre, kollega's moasten rapper meitsje, patches hingje ferskate dagen. Ik frege, wat feroaret dit eins foar him? Ommers, as de koade is skreaun, de bou is gearstald en de tests binne trochjûn, hy hoecht net omtinken te jaan oan 'e ferstjoerde patch as der gjin opmerkingen binne. Kollega's sels sille it besjen en goedkarre (as d'r wer gjin opmerkings binne). Hy antwurde: "Igor, ik wol sa gau mooglik myn trije griene teken krije."
It twadde punt is gamification en kompetysje.
By it ûntwikkeljen fan ien fan 'e produkten, hie ús yngenieurteam in doel om in promininte posysje yn te nimmen yn' e mienskip fan ien fan 'e iepen boarne produkten, om de top-3 yn te gean. Op dat stuit wie d'r gjin objektive manier om de sichtberens fan ien yn 'e mienskip te beoardieljen; elk fan 'e grutte dielnimmende bedriuwen koe beweare (en periodyk bewearden) dat it de nûmer ien wie, mar d'r wie gjin echte manier om de bydragen fan dielnimmers te fergelykjen ûnderinoar, om syn dynamyk yn 'e tiid te evaluearjen. Dêrtroch wie d'r gjin manier om in doel foar it team te setten dat koe wurde mjitten yn guon papegaaien, beoardielje de mjitte fan har prestaasjes, ensfh. Om dit probleem op te lossen, hat ús team in ark ûntwikkele om de bydrage fan bedriuwen en yndividuele bydragen te mjitten en te visualisearjen . Ut motivearjend eachpunt die bliken dat it mar in bom wie. It wiene net allinich yngenieurs en teams dy't har foarútgong en de foarútgong fan har kollega's en konkurrinten konstant kontroleare. It topmanagement fan ús bedriuw en alle grutte konkurrinten begon ek har dei mei stackalytics. Alles waard heul transparant en fisueel, elkenien koe har foarútgong soarchfâldich folgje, fergelykje mei kollega's, ensfh. It is handich en maklik wurden foar yngenieurs, managers en teams om doelen te setten.
In wichtich punt dat ûntstiet by it ymplementearjen fan elk systeem fan kwantitative metriken is dat sa gau as jo se hawwe ymplementearre, it systeem automatysk stribbet om it berikken fan dizze kwantitative metriken te prioritearjen, yn it neidiel fan kwalitative. Bygelyks, it oantal foltôge koadebeoardielingen wurdt brûkt as ien fan 'e metriken. Fansels kin koadebeoardieling op ferskate manieren dien wurde, jo kinne ferskate oeren besteegje oan in yngeande resinsje en kontrôle fan in komplekse patch mei kontrolearjen fan tests, it útfiere op jo bankje, kontrolearje mei dokumintaasje, en plus ien resinsje krije yn jo karma, of klik blyn op in pear dozen yn in pear minuten patches, jou elk +1 en krije plus tweintich yn karma. D'r wiene komyske gefallen doe't yngenieurs sa fluch op patches klikten dat se +1 joegen oan automatyske patches fan it CI-systeem. As wy letter grapke, "go, go, jenkins." Yn it gefal fan commits wiene d'r ek in protte minsken dy't troch de koade gongen mei ark foar opmaak fan koade, opmerkings bewurke, perioaden feroare yn komma's, en sa har karma oppompten. It omgean mei dit is frij ienfâldich: wy brûke sûn ferstân en, neist kwantitative metriken, ek essensjele, kwalitative. De mjitte fan gebrûk fan 'e resultaten fan it wurk fan it team, it oantal eksterne bydragen, it nivo fan testdekking, de stabiliteit fan modules en it heule produkt, de resultaten fan skaal- en prestaasjestesten, it oantal yngenieurs dy't kearnbeoordelaarskouder krigen riemen, it feit dat projekten waarden akseptearre yn 'e kearnprojektenmienskip, neilibjen fan' e kritearia fan ferskate stadia fan it yngenieursproses - al dizze en in protte oare faktoaren moatte wurde beoardiele tegearre mei ienfâldige kwantitative metriken.
En as lêste, it tredde punt - Gjin bullshit.
Untwikkelders binne heul tûke minsken en ekstreem logysk yn har line fan wurk. Se besteegje 8-10 oeren deis oan it bouwen fan lange en komplekse logyske keatlingen, sadat se kwetsberens yn har sjogge. As se wat dogge, wolle se, lykas elkenien, begripe wêrom't se it dogge, wat sil feroarje foar it better. It is ekstreem wichtich dat de doelen dy't jo foar jo team ynstelle earlik en realistysk binne. Besykje in min idee te ferkeapjen oan in programmearteam is in min idee. In idee is min as jo net leauwe yn it sels, of, yn ekstreme gefallen, jo hawwe net de ynterne steat fan it net iens en commit (ik net iens, mar ik sil it dwaan). Wy hawwe ienris in motivaasjesysteem ymplementearre yn in bedriuw, ien fan 'e eleminten wêrfan in elektroanysk systeem wie foar it jaan fan feedback. Se ynvestearre in protte jild, namen minsken nei Amearika foar training, yn 't algemien ynvestearren se folslein. Op in kear, yn in petear nei de training, sei ien fan de managers tsjin syn ûndergeskikten: “It idee is net min, it liket derop dat it sil wurkje. Ik sil jo sels gjin elektroanyske feedback jaan, mar jo jouwe it oan jo minsken en freegje it fan har." Dat is it, neat koe fierder útfierd wurde. It idee einige fansels op neat.
Boarne: www.habr.com