Epigraf:
Mož, ko gleda umazane otroke, reče ženi: no, ali naj te operemo ali rodimo nove?
Pod rezom je drugi del članka našega vodje ekipe, pa tudi direktorja produktnega razvoja RAS Igorja Marnata, o posebnostih motiviranja programerjev. Prvi del članka najdete tukaj -
V prvem delu članka sem se dotaknila dveh spodnjih ravni Maslowljeve piramide: fizioloških potreb, potreb po varnosti, udobju in konstantnosti ter prešla na naslednjo, tretjo raven, in sicer:
III - Potreba po pripadnosti in ljubezni
Vedel sem, da se italijanska mafija imenuje "Cosa Nostra", vendar sem bil zelo navdušen, ko sem izvedel, kako se prevaja "Cosa Nostra". "Cosa Nostra" v prevodu iz italijanščine pomeni "Naš posel". Izbira imena je motivacijsko zelo uspešna (pustimo poklic ob strani, v tem primeru nas zanima le motivacija). Človek si ponavadi želi biti del ekipe, delati nek velik, skupen, naš posel.
Velik pomen je zadovoljevanje potrebe po pripadnosti in ljubezni v vojski, mornarici in morebitnih večjih paravojaških formacijah. In, kot vidimo, v mafiji. To je razumljivo, saj morate prisiliti ljudi, ki imajo malo skupnega, ki na začetku ne tvorijo ekipe enako mislečih ljudi, ki jih združuje vpoklic (ne prostovoljno), ki imajo različne stopnje izobrazbe, različne osebne vrednote. , da dobesedno posvetijo svoje življenje, ob smrtni nevarnosti, neki skupni stvari, zaupajo svoje življenje tovarišu.
To je zelo močna motivacija, za večino ljudi je izjemno pomembno, da čutijo, da pripadajo nečemu večjemu, da vedo, da ste del družine, države, ekipe. V vojski temu služijo uniforme, razni obredi, parade, pohodi, prapori itd. Za vsako ekipo so pomembni približno enaki dejavniki. Pomembni so simboli, korporativna blagovna znamka in korporativne barve, pripomočki in spominki.
Pomembno je, da imajo pomembni dogodki svojo vidno utelešenje, s katerim jih je mogoče povezati. Dandanes je običajno, da ima podjetje lastno blago, jakne, majice itd. Pomembno pa je izpostaviti tudi ekipo znotraj podjetja. Pogosto izdamo majice na podlagi rezultatov objave, ki jih prejmejo vsi, ki sodelujejo pri objavi. Nekateri dogodki, skupna praznovanja ali aktivnosti s celotno ekipo so še en pomemben dejavnik motivacije.
Na občutek pripadnosti ekipi poleg zunanjih lastnosti vpliva še več drugih dejavnikov.
Prvič, prisotnost skupnega cilja, ki ga vsi razumejo in delijo oceno njegove pomembnosti. Programerji običajno želijo razumeti, da delajo kul stvar, in to kul stvar počnejo skupaj, kot ekipa.
Drugič, ekipa mora imeti komunikacijski prostor, v katerem je prisotna celotna ekipa in ki pripada samo njej (na primer klepet v messengerju, občasne sinhronizacije ekipe). Poleg delovnih vprašanj, neformalna komunikacija, včasih razprava o zunanjih dogodkih, svetloba offtop - vse to ustvarja občutek skupnosti in ekipe.
Tretjič bi izpostavil uvajanje dobrih inženirskih praks v ekipo, željo po dvigovanju standardov glede na tiste, ki so sprejeti v podjetju. Implementacija najboljših pristopov, sprejetih v panogi, najprej v ekipi, nato pa v podjetju kot celoti, daje ekipi možnost, da se počuti, da je na nek način pred drugimi, vodi, to ustvarja občutek pripadnosti v kul ekipo.
Na občutek pripadnosti vpliva tudi sodelovanje tima pri načrtovanju in upravljanju. Ko so člani skupine vključeni v razpravo o projektnih ciljih, delovnih načrtih, timskih standardih in inženirskih praksah ter v intervjuje z novimi zaposlenimi, razvijejo občutek sodelovanja, skupnega lastništva in vpliva na delo. Ljudje so veliko bolj pripravljeni izvajati odločitve, ki jih sprejmejo in izrazijo sami, kot tiste, ki jih predlagajo drugi, tudi če so praktično usklajene.
Rojstni dnevi, obletnice, pomembni dogodki v življenju sodelavcev - skupna pica, majhno darilo ekipe daje topel občutek vpletenosti in hvaležnosti. V nekaterih podjetjih je običajno dati majhne spominske znake za 5, 10, 15 let dela v podjetju. Po eni strani mislim, da me to ne motivira toliko za nove dosežke. A očitno bo skoraj vsakdo vesel, da niso pozabili nanj. To je eden tistih primerov, ko odsotnost dejstva demotivira, ne pa njegova prisotnost. Se strinjate, zna biti kar škoda, če vas je LinkedIn zjutraj spomnil in vam na delovnem mestu čestital za 10. obletnico, pa vam niti en sodelavec iz podjetja ni čestital ali se spomnil na vas.
Seveda je pomembna točka sprememba sestave ekipe. Jasno je, da tudi če je prihod ali odhod nekoga iz ekipe vnaprej najavljen (na primer v glasilu podjetja ali ekipe ali na sestanku ekipe), to nikogar posebej ne motivira za nove dosežke. Če pa nekega lepega dne poleg sebe zagledate novo osebo ali pa ne vidite stare, je to lahko presenečenje, če odidete, pa naravnost neprijetno. Ljudje ne bi smeli tiho izginiti. Še posebej v porazdeljeni ekipi. Še posebej, če je vaše delo odvisno od sodelavca iz druge pisarne, ki je nenadoma vstal in izginil. Takšne trenutke je vsekakor vredno vnaprej posebej obvestiti ekipo.
Pomemben dejavnik, ki se v angleščini imenuje lastništvo (dobesedni prevod »posedovanja« ne odraža v celoti njegovega pomena). To ni občutek lastništva, temveč občutek odgovornosti za svoj projekt, tisti občutek, ko sebe čustveno povežeš z izdelkom in izdelek s seboj. To približno ustreza molitvi marinca v filmu "Full Metal Jacket": "To je moja puška. Takih pušk je veliko, a tale je moja. Moja puška je moj najboljši prijatelj. Ona je moje življenje. Moram se ga naučiti imeti v lasti na enak način kot svoje življenje. Brez mene je moja puška neuporabna. Brez puške sem neuporaben. Moram streljati naravnost iz puške. Streljati moram natančneje kot sovražnik, ki me hoče ubiti. Moram ga ustreliti, preden on ustreli mene. Naj bo tako… «.
Ko človek dolgo časa dela na izdelku, ima možnost nositi polno odgovornost za njegovo ustvarjanje in razvoj, videti, kako delujoča stvar nastane iz »nič«, kako jo ljudje uporabljajo, se pojavi ta močan občutek. Produktne ekipe, ki dolgo delajo skupaj na enem projektu, so običajno bolj motivirane in povezane kot ekipe, ki so sestavljene za kratek čas in delajo po tekočem traku, preklapljajo z enega projekta na drugega, brez popolne odgovornosti za celoten izdelek. , od začetka do konca.
IV. Potreba po priznanju
Prijazna beseda prija tudi mački. Vsakdo je motiviran s prepoznavanjem pomena opravljenega dela in njegovo pozitivno oceno. Pogovarjajte se s programerji, občasno jim dajte povratne informacije, proslavite dobro opravljeno delo. Če imate veliko in porazdeljeno ekipo, so občasni sestanki (tako imenovani ena na ena) kot nalašč za to; če je ekipa zelo majhna in sodeluje lokalno, je ta priložnost običajno zagotovljena brez posebnih sestankov na koledarju (čeprav občasnih enemu je vse Še vedno je potrebno, le redkeje lahko). Ta tema je dobro obravnavana v podcastih za upravitelje na manager-tools.com.
Vendar je vredno upoštevati kulturne razlike. Nekateri pristopi, ki jih poznajo ameriški kolegi, ne bodo vedno delovali z ruskimi. Stopnja vljudnosti, sprejeta v vsakodnevni komunikaciji v ekipah v zahodnih državah, se programerjem iz Rusije sprva zdi pretirana. Nekaj neposrednosti, značilne za ruske kolege, lahko kolegi iz drugih držav dojemajo kot nesramnost. To je zelo pomembno pri komunikaciji v medetničnem kolektivu, o tej temi je bilo že veliko napisanega, vodja takega tima se mora tega zavedati.
Predstavitve funkcij, kjer programerji prikažejo funkcije, razvite med sprintom, so dobra praksa za uresničitev te potrebe. Poleg tega, da je to odlična priložnost za čiščenje komunikacijskih kanalov med ekipami, seznanitev produktnih menedžerjev in preizkuševalcev z novostmi, je tudi dobra priložnost za razvijalce, da pokažejo rezultate svojega dela in navedejo svoje avtorstvo. No, in seveda pili svoje veščine javnega nastopanja, kar nikoli ne škodi.
Pomemben prispevek posebej uglednih sodelavcev bi bilo dobro proslaviti s priznanji, spominskimi znamenji (vsaj prijazno besedo) na skupnih kolektivnih druženjih. Ljudje običajno zelo cenijo takšne certifikate in spominske znake, jih vzamejo s seboj, ko se preselijo, in na splošno skrbijo zanje na vse možne načine.
Za označevanje pomembnejšega, dolgoročnejšega prispevka k delu ekipe, nabranih izkušenj in strokovnega znanja se pogosto uporablja ocenjevalni sistem (spet lahko potegnemo analogijo s sistemom vojaških činov v vojski, ki poleg temu namenu služi tudi zagotavljanje podrejenosti). Pogosto mladi razvijalci delajo dvakrat več, da bi pridobili nove zvezde na svojih naramnicah (tj. prehod iz mlajšega razvijalca v razvijalca s polnim delovnim časom itd.).
Poznavanje pričakovanj vaših ljudi je ključnega pomena. Nekateri bodo bolj motivirani z visoko oceno, možnostjo, da se imenujejo, recimo, arhitekt, medtem ko so drugi, nasprotno, ravnodušni do ocen in nazivov in bodo zvišanje plače ocenili kot znak priznanja podjetja. . Komunicirajte z ljudmi, da boste razumeli, kaj si želijo in kakšna so njihova pričakovanja.
Izkaz prepoznavnosti, višje stopnje zaupanja s strani ekipe je mogoče dati z večjo svobodo delovanja ali vključevanja na nova področja dela. Na primer, po pridobitvi določenih izkušenj in doseganju določenih rezultatov lahko programer poleg izvajanja svojih funkcij v skladu s specifikacijo dela na arhitekturi novih stvari. Ali pa se vključite v nova področja, ki morda niso neposredno povezana z razvojem – avtomatizacija testiranja, izvajanje najboljših inženirskih praks, pomoč pri upravljanju izdaj, govorjenje na konferencah itd.
V. Potreba po spoznavanju in samoaktualizaciji.
Mnogi programerji so v različnih življenjskih obdobjih osredotočeni na različne vrste programskih dejavnosti. Nekateri ljudje se radi ukvarjajo s strojnim učenjem, razvijajo nove podatkovne modele, berejo veliko znanstvene literature za delo in ustvarjajo nekaj novega iz nič. Drugi je bližje odpravljanju napak in podpori obstoječe aplikacije, pri kateri se morate poglobiti v obstoječo kodo, preučevati dnevnike, sledi skladov in omrežne captche dneve in tedne ter skoraj ne napisati nove kode.
Oba procesa zahtevata velik intelektualni napor, vendar je njun praktični učinek drugačen. Menijo, da programerji neradi podpirajo obstoječe rešitve, temveč so bolj motivirani za razvoj novih. V tem je zrno modrosti. Po drugi strani pa je bila najbolj motivirana in enotna ekipa, s katero sem kdaj delal, predana podpori obstoječega izdelka, iskanju in odpravljanju napak, potem ko je ekipa za podporo stopila v stik z njimi. Fantje so dobesedno živeli za to delo in so bili pripravljeni na sobote in nedelje. Nekoč smo se vneto ukvarjali z drugim perečim in kompleksnim problemom, bodisi 31. decembra zvečer ali 1. januarja popoldne.
Na to visoko motivacijo je vplivalo več dejavnikov. Prvič, bilo je podjetje z velikim imenom v industriji, ekipa se je povezala z njim (glejte »Potreba po povezovanju«). Drugič, bili so zadnja meja, za njimi ni bilo nikogar, produktne ekipe takrat ni bilo. Med njimi in strankami sta bili dve ravni podpore, a če je problem dosegel njih, se ni bilo kam umakniti, nihče ni stal za njimi, na njih je bila cela korporacija (štirje mladi programerji). Tretjič, to veliko podjetje je imelo zelo velike stranke (vlade držav, avtomobilski in letalski koncerni itd.) in zelo obsežne instalacije v več državah. Kot rezultat, vedno zapleteni in zanimivi problemi, preprosti problemi so bili rešeni s podporo prejšnjih ravni. Četrtič, na motivacijo ekipe je močno vplivala strokovna raven podporne ekipe, s katero so sodelovali (bili so zelo izkušeni in tehnično sposobni inženirji), vedno pa smo bili prepričani v kakovost podatkov, ki so jih pripravili, analize, ki so jih izvedli itd. Petič, in mislim, da je to najpomembnejša točka - ekipa je bila zelo mlada, vsi fantje so bili na začetku kariere. Zanimalo jih je preučevanje velikega in kompleksnega izdelka, reševanje resnih problemov, ki so bili zanje novi v novem okolju, skušali so se strokovno ujemati z nivojem okoliških ekip, problemov in strank. Projekt se je izkazal za odlično šolo, vsi so pozneje v podjetju naredili dobro kariero in postali tehnični vodje in višji menedžerji, eden od fantov je zdaj tehnični vodja pri Amazon Web Services, drugi se je sčasoma preselil k Googlu in vsi med njimi se še vedno s toploto spominjajo tega projekta.
Če bi to ekipo sestavljali programerji s 15-20 let izkušenj za sabo, bi bila motivacija drugačna. Starost in izkušnje seveda niso 100% odločilni faktor, vse je odvisno od strukture motivacije. V konkretnem primeru je želja po znanju in rasti mladih programerjev obrodila odlične rezultate.
Na splošno, kot smo že večkrat omenili, morate poznati pričakovanja vaših programerjev, razumeti, kateri od njih bi želeli razširiti ali spremeniti svoje področje delovanja, in ta pričakovanja upoštevati.
Onstran Maslowove piramide: vidnost rezultatov, igrifikacija in konkurenca, brez sranja
Obstajajo še tri pomembne točke glede motivacije programerjev, ki jih je vsekakor treba omeniti, vendar bi bilo njihovo vključevanje v Maslowov model potreb preveč umetno.
Prva je vidnost in bližina rezultata.
Razvoj programske opreme je običajno maraton. Rezultati raziskav in razvoja postanejo vidni po mesecih, včasih letih. Težko je iti do cilja, ki je daleč za obzorjem, količina dela je grozljiva, cilj je daleč, ni jasen in neviden, »noč je temna in polna grozot«. Bolje je, da razbijemo pot do njega na dele, naredimo pot do najbližjega drevesa, ki je vidno, dosegljivo, obrisi so jasni in ni daleč od nas - in pojdite do tega bližnjega cilja. Želimo se potruditi več dni ali tednov, dobiti in ovrednotiti rezultat, nato pa iti naprej. Zato je vredno delo razdeliti na majhne dele (temu dobro služijo sprinti v agilu). Del dela smo opravili - posneli, izdihnili, obravnavali, krive kaznovali, nedolžne nagradili - lahko začnemo naslednji ciklus.
Ta motivacija je do neke mere podobna tisti, ki jo doživljajo igralci, ko dokončajo računalniške igre: občasno prejmejo medalje, točke, bonuse, ko zaključijo vsako raven; temu lahko rečemo "dopaminska motivacija".
Ob tem je vidnost rezultata dobesedno pomembna. Zaprta funkcija na seznamu mora postati zelena. Če je koda napisana, preizkušena, izdana, vendar programerju ni vidnih sprememb v vizualnem stanju, se bo počutil nepopolnega, ne bo občutka dokončanja. V eni od skupin v našem sistemu za nadzor različic je vsak popravek šel skozi tri zaporedne stopnje - graditev je bila sestavljena in testi opravljeni, popravek je prestal pregled kode, popravek je bil združen. Vsaka stopnja je bila vizualno označena z zeleno kljukico ali rdečim križem. Ko se je eden od razvijalcev pritožil, da je pregled kode trajal predolgo, kolegi so morali pospešiti, popravki so viseli več dni. Vprašal sem, kaj to pravzaprav spremeni zanj? Konec koncev, ko je koda napisana, zgradba sestavljena in so testi opravljeni, mu ni treba biti pozoren na poslani popravek, če ni pripomb. Kolegi sami ga bodo pregledali in potrdili (če spet ne bo pripomb). Odgovoril je: "Igor, čim prej želim dobiti svoje tri zelene kljukice."
Druga točka je igrifikacija in konkurenca.
Pri razvoju enega od produktov je imela naša inženirska ekipa cilj zavzeti vidno mesto v skupnosti enega izmed odprtokodnih produktov, da bi se uvrstila med top-3. Takrat ni bilo objektivnega načina za oceno prepoznavnosti nekoga v skupnosti; vsako od velikih sodelujočih podjetij je lahko trdilo (in občasno trdilo), da prispeva številka ena, vendar ni bilo pravega načina za primerjavo prispevkov udeležencev. med seboj, da ocenijo njeno dinamiko v času. V skladu s tem ni bilo mogoče postaviti cilja za ekipo, ki bi ga lahko izmerili v nekaterih papagajih, ocenili stopnjo njegovega doseganja itd. Za rešitev tega problema je naša ekipa razvila orodje za merjenje in vizualizacijo prispevka podjetij in posameznikov. . Z motivacijskega vidika se je izkazalo, da je to samo bomba. Niso bili samo inženirji in ekipe tisti, ki so nenehno spremljali svoj napredek ter napredek svojih kolegov in tekmecev. Tudi vodstvo našega podjetja in vsi večji konkurenti so dan začeli s stackalytics. Vse je postalo zelo pregledno in vizualno, vsak je lahko skrbno spremljal svoj napredek, se primerjal s kolegi itd. Za inženirje, menedžerje in ekipe je postalo priročno in preprosto postavljanje ciljev.
Pomembna točka, ki se pojavi pri izvajanju katerega koli sistema kvantitativnih metrik, je, da takoj, ko jih implementirate, sistem samodejno stremi k prednostnemu doseganju teh kvantitativnih metrik, na škodo kvalitativnih. Na primer, število opravljenih pregledov kode se uporablja kot ena od metrik. Očitno je pregledovanje kode mogoče opraviti na različne načine, lahko porabite več ur za temeljit pregled in preverjanje kompleksnega popravka s preverjanjem testov, izvajanjem na vaši napravi, preverjanjem z dokumentacijo in dobite plus en pregled v svoji karmi ali na slepo kliknite nekaj ducatov v nekaj minutah popravkov, vsakemu dajte +1 in dobite plus dvajset v karmi. Bilo je komičnih primerov, ko so inženirji klikali na popravke tako hitro, da so samodejnim popravkom iz sistema CI dali +1. Kot smo se kasneje šalili, "pojdi, pojdi, jenkins." Pri commitih je bilo tudi veliko ljudi, ki so šli skozi kodo z orodji za oblikovanje kode, urejali komentarje, spreminjali pike v vejice in tako črpali svojo karmo. Spopadanje s tem je povsem preprosto: uporabljamo zdrav razum in poleg kvantitativnih meritev uporabljamo tudi bistvene, kvalitativne. Stopnja uporabe rezultatov dela ekipe, število zunanjih sodelavcev, stopnja pokritosti testa, stabilnost modulov in celotnega izdelka, rezultati obsega in testiranja zmogljivosti, število inženirjev, ki so prejeli ramo osrednjega pregledovalca. jermeni, dejstvo, da so bili projekti sprejeti v skupnost osrednjih projektov, skladnost z merili različnih stopenj inženirskega procesa - vse te in številne druge dejavnike je treba oceniti skupaj s preprostimi kvantitativnimi meritvami.
In končno, tretja točka - Brez sranja.
Razvijalci so zelo pametni ljudje in izjemno logični pri svojem delu. 8-10 ur na dan gradijo dolge in zapletene logične verige, zato v njih sproti vidijo ranljivosti. Ko nekaj delajo, želijo, tako kot vsi drugi, razumeti, zakaj to počnejo, kaj se bo spremenilo na bolje. Izredno pomembno je, da so cilji, ki si jih zastavite svoji ekipi, pošteni in realni. Poskušati prodati slabo idejo programski ekipi je slaba ideja. Ideja je slaba, če sami vanjo ne verjamete ali, v skrajnem primeru, nimate notranjega stanja nestrinjanja in zaveze (ne strinjam se, ampak bom naredil). Nekoč smo v podjetju implementirali motivacijski sistem, katerega eden od elementov je bil elektronski sistem za posredovanje povratnih informacij. Vložili so veliko denarja, peljali ljudi na usposabljanje v Ameriko, na splošno so vložili na polno. Nekoč je eden od menedžerjev v pogovoru po izobraževanju svojim podrejenim rekel: »Ideja ni slaba, zdi se, da bo delovala. Sam vam ne bom posredoval elektronskih povratnih informacij, ampak vi jih dajte svojim ljudem in jih zahtevajte od njih.« To je to, nič več ni bilo mogoče izvajati. Ideja se je seveda končala v nič.
Vir: www.habr.com