Epigraaf:
Die man, wat na die vuil kinders kyk, sê vir sy vrou: Wel, sal ons hierdie was of nuwes geboorte gee?
Onder die snit is die tweede deel van 'n artikel deur ons spanleier, sowel as RAS-produkontwikkelingsdirekteur Igor Marnat, oor die eienaardighede van motivering van programmeerders. Die eerste deel van die artikel kan hier gevind word -
In die eerste deel van die artikel het ek die twee onderste vlakke van Maslow se piramide aangeraak: fisiologiese behoeftes, behoeftes aan veiligheid, gemak en bestendigheid en beweeg aan na die volgende, derde vlak, naamlik:
III - Behoefte aan behoort en liefde
Ek het geweet dat die Italiaanse mafia “Cosa Nostra” genoem word, maar ek was baie beïndruk toe ek uitvind hoe “Cosa Nostra” vertaal word. “Cosa Nostra” wat uit Italiaans vertaal word, beteken “Ons Besigheid”. Die keuse van naam is baie suksesvol vir motivering (kom ons los die beroep, in hierdie geval stel ons net in motivering belang). 'n Persoon wil gewoonlik deel wees van 'n span, om 'n groot, algemene, ons besigheid te doen.
Groot belang word geplaas op die bevrediging van die behoefte aan behoort en liefde in die weermag, vloot en enige groot paramilitêre formasies. En, soos ons sien, in die mafia. Dit is verstaanbaar, want jy moet mense dwing wat min in gemeen het, wat aanvanklik nie 'n span eendersdenkende mense vorm nie, wat deur diensplig (nie vrywillig nie), wat verskillende vlakke van opvoeding, verskillende persoonlike waardes het, saamgebring word. , om hul lewens letterlik te wy, met lewensgevaar, aan een of ander algemene saak, vertrou jou lewe aan 'n wapenkameraad toe.
Dit is 'n baie sterk motivering; vir die meeste mense is dit uiters belangrik om te voel dat hulle aan iets groter behoort, om te weet dat jy deel is van 'n familie, 'n land, 'n span. In die weermag dien uniforms, verskeie rituele, parades, optogte, baniere, ensovoorts hierdie doeleindes. Ongeveer dieselfde faktore is belangrik vir enige span. Simbole, korporatiewe handelsmerk en korporatiewe kleure, toebehore en aandenkings is belangrik.
Dit is belangrik dat betekenisvolle gebeurtenisse hul eie sigbare beliggaming het waarmee dit geassosieer kan word. Deesdae is dit eerder die norm vir 'n maatskappy om sy eie handelsware, baadjies, T-hemde, ens. Maar dit is ook belangrik om die span binne die maatskappy uit te lig. Ons stel dikwels T-hemde vry op grond van die resultate van 'n vrystelling, wat aan almal wat by die vrystelling betrokke is, gegee word. Sommige geleenthede, gesamentlike vieringe of aktiwiteite met die hele span is nog 'n belangrike faktor van motivering.
Benewens eksterne eienskappe, beïnvloed verskeie ander faktore die gevoel om aan 'n span te behoort.
Eerstens, die teenwoordigheid van 'n gemeenskaplike doelwit wat almal verstaan en deel 'n beoordeling van die belangrikheid daarvan. Programmeerders wil gewoonlik verstaan dat hulle 'n cool ding doen, en hulle doen hierdie cool ding saam, as 'n span.
Tweedens moet die span 'n kommunikasieruimte hê waarin die hele span teenwoordig is en wat slegs daaraan behoort (byvoorbeeld 'n geselsie in die boodskapper, periodieke span-sincaps). Benewens werkkwessies, informele kommunikasie, soms bespreking van eksterne gebeure, ligte buitekant - dit alles skep 'n gevoel van gemeenskap en span.
Derdens beklemtoon ek die bekendstelling van goeie ingenieurspraktyke binne die span, die begeerte om standaarde te verhoog in vergelyking met dié wat in die maatskappy aanvaar word. Die implementering van die beste benaderings wat in die bedryf aanvaar word, eers in die span, en dan in die maatskappy as geheel, gee die span die geleentheid om te voel dat dit op een of ander manier voor ander is, die pad lei, dit skep 'n gevoel van behoort aan 'n cool span.
Die gevoel van behoort word ook beïnvloed deur die span se deelname aan beplanning en bestuur. Wanneer spanlede betrokke is by die bespreking van projekdoelwitte, werkplanne, spanstandaarde en ingenieurspraktyke, en onderhoudvoering met nuwe werknemers, ontwikkel hulle 'n gevoel van deelname, gedeelde eienaarskap en invloed op die werk. Mense is baie meer gewillig om besluite uit te voer wat deur hulleself geneem en uitgespreek word as dié wat deur ander voorgestel word, selfs al is hulle feitlik in pas.
Verjaarsdae, herdenkings, belangrike gebeurtenisse in die lewens van kollegas - 'n gesamentlike pizza, 'n klein geskenkie van die span gee 'n warm gevoel van betrokkenheid en dankbaarheid. In sommige maatskappye is dit gebruiklik om klein gedenktekens te gee vir 5, 10, 15 jaar se werk in die maatskappy. Aan die een kant dink ek nie dat dit my so motiveer vir nuwe prestasies nie. Maar natuurlik sal byna almal bly wees dat hulle nie van hom vergeet het nie. Dit is een van daardie gevalle waar die afwesigheid van 'n feit demotiveer eerder as die teenwoordigheid daarvan. Stem saam, dit kan nogal jammer wees as LinkedIn jou soggens herinner en gelukwens met jou 10de bestaansjaar by jou werkplek, maar nie 'n enkele kollega van die maatskappy het jou gelukgewens of onthou nie.
Natuurlik is 'n belangrike punt die verandering in die samestelling van die span. Dit is duidelik dat selfs al word die aankoms of vertrek van iemand uit die span vooraf aangekondig (byvoorbeeld in 'n maatskappy- of spannuusbrief, of by 'n spanvergadering), motiveer dit niemand besonders tot nuwe prestasies nie. Maar as jy een mooi dag 'n nuwe persoon langs jou sien, of nie 'n ou een sien nie, kan dit 'n verrassing wees, en as jy weggaan, ronduit onaangenaam. Mense moenie stilweg verdwyn nie. Veral in 'n verspreide span. Veral as jou werk afhang van 'n kollega van 'n ander kantoor wat skielik opstaan en verdwyn. Sulke oomblikke is beslis die moeite werd om die span vooraf afsonderlik in te lig.
'n Belangrike faktor, wat in Engels genoem word eienaarskap (die letterlike vertaling van “besit” weerspieël nie die betekenis daarvan volledig nie). Dit is nie 'n gevoel van eienaarskap nie, maar eerder 'n gevoel van verantwoordelikheid vir jou projek, daardie gevoel wanneer jy jouself emosioneel assosieer met die produk en die produk met jouself. Dit stem min of meer ooreen met die gebed van die Marine in die film "Full Metal Jacket": "Dit is my geweer. Daar is baie sulke gewere, maar hierdie een is myne. My geweer is my beste vriend. Sy is my lewe. Ek moet leer om dit te besit op dieselfde manier as wat ek my lewe besit. Sonder my is my geweer nutteloos. Ek is nutteloos sonder my geweer. Ek moet my geweer reguit skiet. Ek moet meer akkuraat skiet as die vyand wat my probeer doodmaak. Ek moet hom skiet voor hy my skiet. Laat dit so wees..."
Wanneer 'n persoon vir 'n lang tyd aan 'n produk werk, die geleentheid het om volle verantwoordelikheid te dra vir die skepping en ontwikkeling daarvan, om te sien hoe 'n werkende ding uit "niks" ontstaan nie, hoe mense dit gebruik, ontstaan hierdie kragtige gevoel. Produkspanne wat lank saamwerk aan een projek is gewoonlik meer gemotiveerd en samehangend as spanne wat vir 'n kort tydperk saamgestel is en in monteerlynmodus werk, wat van een projek na 'n ander oorskakel, sonder volle verantwoordelikheid vir die hele produk , van begin tot einde.
IV. Behoefte aan erkenning
’n Vriendelike woord behaag ook die kat. Almal word gemotiveer deur erkenning van die belangrikheid van die werk wat hulle gedoen het en die positiewe beoordeling daarvan. Praat met programmeerders, gee hulle periodieke terugvoer, vier 'n werk wat goed gedoen is. As jy 'n groot en verspreide span het, is periodieke vergaderings (wat een-tot-een genoem word) perfek hiervoor; as die span baie klein is en plaaslik saamwerk, word hierdie geleentheid gewoonlik verskaf sonder spesiale vergaderings op die kalender (hoewel periodieke een vir een is al Dit is nog nodig, jy kan dit net minder gereeld doen). Hierdie onderwerp word goed gedek in poduitsendings vir bestuurders op manager-tools.com.
Dit is egter die moeite werd om kulturele verskille in gedagte te hou. Sommige benaderings wat aan Amerikaanse kollegas bekend is, sal nie altyd met Russiese benaderings werk nie. Die vlak van beleefdheid wat in daaglikse kommunikasie in spanne in Westerse lande aanvaar word, lyk aanvanklik vir programmeerders van Rusland buitensporig. Sommige reguitheid wat kenmerkend is van Russiese kollegas, kan deur hul kollegas van ander lande as onbeskof beskou word. Dit is baie belangrik in kommunikasie in 'n interetniese span; daar is al baie oor hierdie onderwerp geskryf; die bestuurder van so 'n span moet dit onthou.
Kenmerkdemonstrasies, waar programmeerders kenmerke wys wat tydens 'n naelloop ontwikkel is, is 'n goeie praktyk om hierdie behoefte te verwesenlik. Benewens die feit dat dit 'n uitstekende geleentheid is om kommunikasiekanale tussen spanne skoon te maak, produkbestuurders en toetsers aan nuwe kenmerke bekend te stel, is dit ook 'n goeie geleentheid vir ontwikkelaars om die resultate van hul werk te wys en hul outeurskap aan te dui. Wel, en poets natuurlik jou vaardighede in die openbaar, wat nooit skadelik is nie.
Dit sal 'n goeie idee wees om die beduidende bydrae van besonder vooraanstaande kollegas met sertifikate, gedenktekens (ten minste 'n vriendelike woord) by gesamentlike spanbyeenkomste te vier. Mense waardeer sulke sertifikate en gedenktekens gewoonlik baie, neem dit saam wanneer hulle verhuis, en sorg oor die algemeen op elke moontlike manier na hulle.
Om 'n meer betekenisvolle, langtermynbydrae tot die werk van die span, opgehoopte ervaring en kundigheid te merk, word 'n graadstelsel dikwels gebruik (weereens kan 'n analogie getrek word met die stelsel van militêre range in die weermag, wat boonop om ondergeskiktheid te verseker, dien ook hierdie doel). Dikwels werk jong ontwikkelaars twee keer so hard om nuwe sterre op hul skouerbande te kry (dws beweeg van junior ontwikkelaar na voltydse ontwikkelaar, ens.).
Om jou mense se verwagtinge te ken, is van kritieke belang. Sommige is meer geneig om gemotiveer te word deur 'n hoë graad, die geleentheid om byvoorbeeld 'n argitek genoem te word, terwyl ander, inteendeel, onverskillig is teenoor grade en titels en 'n verhoging in salaris sal beskou as 'n teken van erkenning deur die maatskappy . Kommunikeer met mense om te verstaan wat hulle wil hê en wat hul verwagtinge is.
'n Demonstrasie van erkenning, 'n hoër vlak van vertroue aan die kant van die span, kan gegee word deur meer vryheid van aksie of betrokkenheid by nuwe werksareas te gee. Byvoorbeeld, nadat hy sekere ervaring opgedoen het en sekere resultate behaal het, kan 'n programmeerder, benewens die implementering van sy kenmerke in ooreenstemming met die spesifikasie, aan die argitektuur van nuwe dinge werk. Of raak betrokke by nuwe areas wat dalk nie direk met ontwikkeling verband hou nie - toetsoutomatisering, implementering van beste ingenieurspraktyke, help met vrystellingbestuur, praat by konferensies, ens.
V. Die behoefte aan kognisie en selfaktualisering.
Baie programmeerders is gefokus op verskillende tipes programmeringsaktiwiteite in verskillende stadiums van hul lewens. Sommige mense hou daarvan om masjienleer te doen, nuwe datamodelle te ontwikkel, baie wetenskaplike literatuur te lees vir werk en iets nuuts van nuuts af te skep. Nog een is nader aan ontfouting en ondersteuning van 'n bestaande toepassing, waarin jy vir dae en weke diep in die bestaande kode moet delf, logs, stapelspore en netwerk-captchas moet bestudeer en byna geen nuwe kode moet skryf nie.
Beide prosesse verg groot intellektuele inspanning, maar hul praktiese uitset verskil. Daar word geglo dat programmeerders huiwerig is om bestaande oplossings te ondersteun; hulle is eerder gemotiveerd om nuwes te ontwikkel. Daar is 'n greintjie wysheid hierin. Aan die ander kant was die mees gemotiveerde en verenigde span waarmee ek nog gewerk het, toegewy daaraan om 'n bestaande produk te ondersteun, foute te vind en reg te stel nadat die ondersteuningspan hulle gekontak het. Die ouens het letterlik gelewe vir hierdie werk en was gereed om Saterdae en Sondae uit te gaan. Ons het eenkeer gretig met nog 'n dringende en komplekse probleem gehandel, hetsy op die aand van 31 Desember of die middag van 1 Januarie.
Verskeie faktore het hierdie hoë motivering beïnvloed. Eerstens was dit 'n maatskappy met 'n groot naam in die bedryf, die span het hulself daarmee geassosieer (sien “Die behoefte aan affiliasie”). Tweedens was hulle die laaste grens, daar was niemand agter hulle nie, daar was geen produkspan op daardie tydstip nie. Tussen hulle en die kliënte was daar twee vlakke van ondersteuning, maar as die probleem hulle bereik het, was daar nêrens om terug te trek nie, niemand was agter hulle nie, die hele korporasie was op hulle (vier jong programmeerders). Derdens het hierdie groot maatskappy baie groot kliënte gehad (landregerings, motor- en lugvaartondernemings, ens.) en baie grootskaalse installasies in verskeie lande. As gevolg hiervan, altyd komplekse en interessante probleme, is eenvoudige probleme opgelos deur die ondersteuning van vorige vlakke. Vierdens is die span se motivering grootliks beïnvloed deur die professionele vlak van die ondersteuningspan met wie hulle interaksie gehad het (daar was baie ervare en tegnies bekwame ingenieurs), en ons was altyd vol vertroue in die kwaliteit van die data wat hulle voorberei het, die ontleding wat hulle uitgevoer het. , ens. Vyfdens, en ek dink dit is die belangrikste punt – die span was baie jonk, al die ouens was aan die begin van hul loopbane. Hulle was geïnteresseerd in die bestudering van 'n groot en komplekse produk, die oplossing van ernstige probleme wat vir hulle nuut was in 'n nuwe omgewing, hulle het probeer om professioneel te pas by die vlak van die omliggende spanne, probleme en kliënte. Die projek blyk 'n uitstekende skool te wees, almal het later 'n goeie loopbaan in die maatskappy gemaak en tegniese leiers en senior bestuurders geword, een van die ouens is nou 'n tegniese bestuurder by Amazon Web Services, die ander het uiteindelik na Google oorgeskuif, en al van hulle onthou hierdie projek nog met warmte.
As hierdie span uit programmeerders met 15-20 jaar ondervinding agter hulle bestaan het, sou die motivering anders gewees het. Ouderdom en ervaring is natuurlik nie 100% bepalende faktore nie; dit hang alles af van die struktuur van motivering. In hierdie spesifieke geval het die begeerte na kennis en groei van jong programmeerders uitstekende resultate opgelewer.
Oor die algemeen, soos ons reeds verskeie kere genoem het, moet jy die verwagtinge van jou programmeerders ken, verstaan wie van hulle hul aktiwiteitsveld wil uitbrei of verander, en hierdie verwagtinge in ag neem.
Anderkant Maslow se piramide: sigbaarheid van resultate, gamification en kompetisie, geen snert nie
Daar is nog drie belangrike punte met betrekking tot die motivering van programmeerders wat beslis genoem moet word, maar om dit in Maslow se behoeftemodel in te trek sal te kunsmatig wees.
Die eerste is die sigbaarheid en nabyheid van die resultaat.
Sagteware-ontwikkeling is gewoonlik 'n marathon. Die resultate van R&D-pogings word na maande, soms jare, sigbaar. Dit is moeilik om na 'n doelwit te gaan wat ver buite die horison is, die hoeveelheid werk is skrikwekkend, die doelwit is ver weg, nie duidelik en nie sigbaar nie, "die nag is donker en vol gruwels." Dit is beter om die pad daarheen in dele te breek, 'n paadjie na die naaste boom te maak wat sigbaar, bereikbaar is, die buitelyne is duidelik, en dit is nie ver van ons af nie - en gaan na hierdie nabye doel. Ons wil 'n poging van 'n paar dae of weke aanwend, die resultaat kry en evalueer, en dan aanbeweeg. Daarom is dit die moeite werd om die werk in klein dele op te breek (naellope in agile dien hierdie doel goed). Ons het 'n deel van die werk voltooi - dit opgeneem, uitgeasem, bespreek, die skuldiges gestraf, die onskuldiges beloon - ons kan die volgende siklus begin.
Hierdie motivering is tot 'n mate soortgelyk aan wat spelers ervaar wanneer hulle rekenaarspeletjies voltooi: hulle ontvang van tyd tot tyd medaljes, punte, bonusse soos hulle elke vlak voltooi; dit kan "dopamienmotivering" genoem word.
Terselfdertyd is die sigbaarheid van die resultaat letterlik belangrik. 'n Geslote kenmerk in die lys moet groen word. As die kode geskryf, getoets, vrygestel word, maar daar is geen verandering in die visuele status sigbaar vir die programmeerder nie, sal hy onvolledig voel, sal daar geen gevoel van voltooiing wees nie. In een van die spanne in ons weergawebeheerstelsel het elke pleister deur drie opeenvolgende stadiums gegaan - die bou is saamgestel en die toetse geslaag, die pleister het die kode-oorsig geslaag, die pleister is saamgevoeg. Elke stadium is visueel gemerk met 'n groen regmerkie of rooi kruis. Sodra een van die ontwikkelaars gekla het dat die kodehersiening te lank geneem het, moes kollegas bespoedig, en pleisters het vir 'n paar dae gehang. Ek het gevra, wat verander dit nou eintlik vir hom? Na alles, wanneer die kode geskryf is, die bouwerk saamgestel is en die toetse geslaag het, hoef hy nie aandag te gee aan die gestuurde pleister as daar geen kommentaar is nie. Kollegas sal dit self hersien en goedkeur (indien daar weer geen opmerkings is nie). Hy het geantwoord: "Igor, ek wil so gou as moontlik my drie groen bosluise kry."
Die tweede punt is gamification en kompetisie.
Toe ons een van die produkte ontwikkel het, het ons ingenieurspan 'n doelwit gehad om 'n prominente posisie in die gemeenskap van een van die oopbronprodukte in te neem, om die top-3 te betree. Op daardie tydstip was daar geen objektiewe manier om iemand se sigbaarheid in die gemeenskap te assesseer nie; elkeen van die groot deelnemende maatskappye kon beweer (en periodiek beweer) dat dit die nommer een bydraer was, maar daar was geen werklike manier om die bydraes van deelnemers te vergelyk nie. onderling, om die dinamika daarvan in tyd te evalueer. Gevolglik was daar geen manier om 'n doelwit vir die span te stel wat in sommige papegaaie gemeet kon word, die graad van sy prestasie te assesseer, ens. Om hierdie probleem op te los, het ons span 'n instrument ontwikkel om die bydrae van maatskappye en individuele bydraers te meet en te visualiseer . Uit 'n motiveringsoogpunt het dit geblyk net 'n bom te wees. Dit was nie net ingenieurs en spanne wat voortdurend hul vordering en die vordering van hul kollegas en mededingers gemonitor het nie. Die topbestuur van ons maatskappy en alle groot mededingers het ook hul dag met stackalitics begin. Alles het baie deursigtig en visueel geword, almal kon hul vordering noukeurig monitor, met kollegas vergelyk, ens. Dit het gerieflik en maklik geword vir ingenieurs, bestuurders en spanne om doelwitte te stel.
'n Belangrike punt wat na vore kom wanneer enige stelsel van kwantitatiewe metrieke geïmplementeer word, is dat sodra jy dit geïmplementeer het, die stelsel outomaties daarna streef om die bereiking van hierdie kwantitatiewe metrieke te prioritiseer, tot nadeel van kwalitatiewe. Byvoorbeeld, die aantal kodebeoordelings wat voltooi is, word as een van die maatstawwe gebruik. Natuurlik kan kodehersiening op verskillende maniere gedoen word, jy kan 'n paar uur spandeer aan 'n deeglike hersiening en kontrolering van 'n komplekse pleister met toetse, dit op jou bank uitvoer, met dokumentasie nagaan, en plus een resensie in jou karma kry, of klik blindelings 'n paar dosyn in 'n paar minute kolle, gee elkeen +1 en kry plus twintig in karma. Daar was komiese gevalle toe ingenieurs so vinnig op pleisters geklik het dat hulle +1 gegee het aan outomatiese pleisters van die CI-stelsel. Soos ons later geskerts het, "gaan, gaan, jenkins." In die geval van commits, was daar ook baie mense wat deur die kode gegaan het met kodeformateringsinstrumente, kommentaar geredigeer het, periodes na kommas verander het en sodoende hul karma opgepomp het. Om dit te hanteer is redelik eenvoudig: ons gebruik gesonde verstand en, benewens kwantitatiewe maatstawwe, gebruik ook noodsaaklike, kwalitatiewe maatstawwe. Die mate van gebruik van die resultate van die span se werk, die aantal eksterne bydraers, die vlak van toetsdekking, die stabiliteit van modules en die hele produk, die resultate van skaal- en prestasietoetsing, die aantal ingenieurs wat kernresensentskouer ontvang het bandjies, die feit dat projekte in die kernprojekte-gemeenskap aanvaar is, voldoening aan die kriteria van verskillende stadiums van die ingenieursproses - al hierdie en baie ander faktore moet saam met eenvoudige kwantitatiewe statistieke beoordeel word.
En laastens, die derde punt - Geen snert nie.
Ontwikkelaars is baie slim mense en uiters logies in hul werk. Hulle spandeer 8-10 uur per dag om lang en komplekse logiese kettings te bou, sodat hulle kwesbaarhede in hulle op die vlieg sien. Wanneer hulle iets doen, wil hulle, soos almal anders, verstaan hoekom hulle dit doen, wat ten goede sal verander. Dit is uiters belangrik dat die doelwitte wat jy vir jou span stel eerlik en realisties is. Om 'n slegte idee aan 'n programmeringspan te probeer verkoop, is 'n slegte idee. ’n Idee is sleg as jy nie self daarin glo nie, of, in uiterste gevalle, jy nie die interne toestand het van verskil en verbind nie (ek stem nie saam nie, maar ek sal dit doen). Ons het eenkeer 'n motiveringstelsel in 'n maatskappy geïmplementeer, waarvan een van die elemente 'n elektroniese stelsel was om terugvoer te verskaf. Hulle het baie geld belê, mense na Amerika geneem vir opleiding, oor die algemeen het hulle ten volle belê. Een van die bestuurders het eenkeer in ’n gesprek ná die opleiding aan sy ondergeskiktes gesê: “Die idee is nie sleg nie, dit lyk of dit sal werk. Ek sal nie self vir jou elektroniese terugvoer gee nie, maar jy gee dit aan jou mense en eis dit van hulle.” Dis dit, niks kon verder geïmplementeer word nie. Die idee het natuurlik op niks geëindig nie.
Bron: will.com