Epigrafas:
Vyras, žiūrėdamas į nešvarius vaikus, sako žmonai: na, skalbsim šiuos ar gimdysime naujus?
Po pjūviu – antroji mūsų komandos vadovo, taip pat RAS produktų plėtros direktoriaus Igorio Marnato straipsnio apie programuotojų motyvavimo ypatumus dalis. Pirmąją straipsnio dalį rasite čia -
Pirmoje straipsnio dalyje paliečiau du žemesnius Maslow piramidės lygius: fiziologinius poreikius, saugumo, komforto ir pastovumo poreikius ir pereinau į kitą, trečią lygį, būtent:
III - Priklausymo ir meilės poreikis
Žinojau, kad italų mafija vadinasi „Cosa Nostra“, bet buvau labai sužavėta, kai sužinojau, kaip verčiama „Cosa Nostra“. „Cosa Nostra“ išvertus iš italų kalbos reiškia „Mūsų verslas“. Vardo pasirinkimas motyvacijai labai sėkmingas (užsiėmimą palikime nuošalyje, šiuo atveju mus domina tik motyvacija). Žmogus dažniausiai nori būti komandos dalimi, daryti kokį nors didelį, bendrą, mūsų verslą.
Didelė svarba teikiama priklausomybės ir meilės poreikiui patenkinti armijoje, laivyne ir visose didelėse sukarintuose junginiuose. Ir, kaip matome, mafijoje. Tai suprantama, nes reikia priversti žmones, kurie turi mažai ką bendro, kurie iš pradžių nesudaro bendraminčių komandos, kuriuos suburia šaukimas (ne savo noru), kurie turi skirtingą išsilavinimą, skirtingas asmenines vertybes. , pažodžiui pašvęsti savo gyvybes, rizikuodami mirtimi, kokiam nors bendram reikalui, patikėkite savo gyvenimą ginklo draugui.
Tai labai stipri motyvacija, daugumai žmonių nepaprastai svarbu jaustis kaip priklausantys kažkam didesniam, žinoti, kad esi šeimos, šalies, komandos dalis. Kariuomenėje šiems tikslams tarnauja uniformos, įvairūs ritualai, paradai, žygiai, vėliavos ir pan. Maždaug tie patys veiksniai svarbūs bet kuriai komandai. Svarbu simboliai, įmonės prekės ženklas ir įmonės spalvos, atributika ir suvenyrai.
Svarbu, kad reikšmingi įvykiai turėtų savo matomą įsikūnijimą, su kuriuo jie gali būti siejami. Šiais laikais labiau įprasta, kad įmonė turi savo prekes, švarkus, marškinėlius ir pan. Tačiau taip pat svarbu pabrėžti komandą įmonėje. Dažnai išleidžiame marškinėlius pagal išleidimo rezultatus, kurie įteikiami visiems išleidime dalyvaujantiems asmenims. Kai kurie renginiai, bendros šventės ar užsiėmimai su visu kolektyvu – dar vienas svarbus motyvacijos veiksnys.
Be išorinių savybių, priklausomybės komandai jausmą įtakoja ir keletas kitų veiksnių.
Pirma, bendro tikslo buvimas, kurį visi supranta ir vertina jo svarbą. Programuotojai paprastai nori suprasti, kad jie daro šaunų dalyką, ir jie tai daro kartu, kaip komanda.
Antra, komanda turi turėti bendravimo erdvę, kurioje yra visa komanda ir kuri priklauso tik jai (pavyzdžiui, pokalbis messengeryje, periodiniai komandos sinchronizavimas). Be darbo reikalų, neformalaus bendravimo, kartais ir išorinių įvykių aptarimo, šviesos offtopo – visa tai kuria bendruomeniškumo ir komandos jausmą.
Trečia, išskirčiau gerosios inžinerinės praktikos diegimą kolektyve, norą kelti standartus lyginant su priimtais įmonėje. Įgyvendinant geriausius pramonėje priimtus metodus, pirmiausia komandoje, o vėliau ir visoje įmonėje, komandai suteikiama galimybė pajusti, kad ji kažkaip lenkia kitus, pirmauja, tai sukuria priklausymo jausmą. į šaunią komandą.
Priklausomybės jausmui įtakos turi ir komandos dalyvavimas planavime ir valdyme. Kai komandos nariai dalyvauja diskutuojant apie projekto tikslus, darbo planus, komandos standartus ir inžinerinę praktiką bei apklausiant naujus darbuotojus, jie ugdo dalyvavimo jausmą, bendrą atsakomybę ir įtaką darbui. Žmonės daug labiau linkę vykdyti savo pačių priimtus ir išsakytus sprendimus, nei siūlo kitus, net jei jie praktiškai sutampa.
Gimtadieniai, jubiliejai, reikšmingi įvykiai kolegų gyvenime – bendra pica, nedidelė kolektyvo dovanėlė suteikia šiltą įsitraukimo ir dėkingumo jausmą. Kai kuriose įmonėse už 5, 10, 15 darbo įmonėje metų įprasta dovanoti nedidelius atminimo ženklus. Viena vertus, nemanau, kad tai mane taip motyvuoja naujiems pasiekimams. Tačiau akivaizdu, kad beveik kiekvienas bus patenkintas, kad jo nepamiršo. Tai vienas iš tų atvejų, kai fakto nebuvimas labiau demotyvuoja, o ne jo buvimas motyvuoja. Sutikite, gali būti labai gaila, jei LinkedIn jus ryte primins ir pasveikino su 10 metų jubiliejumi jūsų darbo vietoje, tačiau nei vienas kolega iš įmonės jus pasveikino ir neprisiminė.
Žinoma, reikšmingas momentas – komandos sudėties pasikeitimas. Akivaizdu, kad net jei apie atvykimą ar išvykimą iš komandos pranešama iš anksto (pavyzdžiui, įmonės ar komandos informaciniame biuletenyje ar komandos susirinkime), tai nieko ypač nemotyvuoja naujiems pasiekimams. Bet jei vieną gražią dieną pamatysite šalia savęs naują žmogų arba nepamatysite seno, tai gali būti staigmena, o jei išeisite – visiškai nemalonu. Žmonės neturėtų tyliai dingti. Ypač paskirstytoje komandoje. Ypač jei jūsų darbas priklauso nuo kolegos iš kito biuro, kuris staiga atsikėlė ir dingo. Tokias akimirkas tikrai verta iš anksto informuoti komandą atskirai.
Svarbus veiksnys, kuris angliškai vadinamas nuosavybė (pažodinis „turėjimo“ vertimas nevisiškai atspindi jo reikšmę). Tai ne nuosavybės jausmas, o atsakomybės už savo projektą jausmas, tas jausmas, kai emociškai susiejate save su produktu, o produktą – su savimi. Tai maždaug atitinka jūrų pėstininko maldą filme „Full Metal Jacket“: „Tai mano šautuvas. Tokių šautuvų yra daug, bet šis yra mano. Mano šautuvas yra geriausias mano draugas. Ji yra mano gyvenimas. Turiu išmokti jį valdyti taip pat, kaip ir savo gyvenimą. Be manęs mano šautuvas yra nenaudingas. Aš nenaudingas be šautuvo. Turiu šaudyti tiesiai iš šautuvo. Aš turiu šaudyti taikliau nei priešas, kuris bando mane nužudyti. Turiu jį nušauti, kol jis nešaudys mane. Tebūnie taip… “.
Kai žmogus ilgą laiką dirba su gaminiu, turi galimybę prisiimti visą atsakomybę už jo kūrimą ir vystymą, pamatyti, kaip iš „nieko“ atsiranda veikiantis daiktas, kaip žmonės jį naudoja, kyla šis galingas jausmas. Produktų komandos, kurios ilgą laiką dirba kartu prie vieno projekto, dažniausiai yra labiau motyvuotos ir darnesnės nei komandos, kurios suburtos trumpam laikui ir dirba surinkimo linijos režimu, pereindamos nuo vieno projekto prie kito, neprisiimdamos visos atsakomybės už visą produktą. , nuo pradžios iki pabaigos.
IV. Pripažinimo poreikis
Geras žodis taip pat džiugina katę. Visus motyvuoja atlikto darbo svarbos pripažinimas ir teigiamas jo įvertinimas. Kalbėkitės su programuotojais, periodiškai pateikite jiems atsiliepimus, švęskite gerai atliktą darbą. Jei turite didelę ir paskirstytą komandą, tam puikiai tinka periodiniai susitikimai (vadinami vienas prieš vieną), jei komanda labai maža ir dirba kartu vietoje, tokia galimybė dažniausiai suteikiama be specialių susitikimų kalendoriuje (nors ir periodiškai). Viskas, ko reikia vienam, vis tiek reikia, tik galite tai daryti rečiau). Ši tema gerai aptariama vadovams skirtose podcast'uose, adresu manager-tools.com.
Tačiau verta nepamiršti kultūrinių skirtumų. Kai kurie amerikiečių kolegoms žinomi metodai ne visada veiks su rusiškais. Mandagumo lygis, priimtas kasdieniame bendravime Vakarų šalių komandose, programišiams iš Rusijos iš pradžių atrodo perdėtas. Tam tikrą Rusijos kolegoms būdingą tiesmukumą kolegos iš kitų šalių gali suvokti kaip grubumą. Tai labai svarbu bendraujant tarpetninėje komandoje, šia tema daug parašyta, tokios komandos vadovas turi tai atsiminti.
Funkcijų demonstravimas, kai programuotojai parodo sprinto metu sukurtas funkcijas, yra gera praktika, padedanti įgyvendinti šį poreikį. Be to, kad tai puiki galimybė išvalyti komunikacijos kanalus tarp komandų, supažindinti produktų vadybininkus ir testuotojus su naujomis funkcijomis, tai taip pat gera proga kūrėjams parodyti savo darbo rezultatus ir nurodyti savo autorystę. Na, ir, žinoma, šlifuokite savo viešojo kalbėjimo įgūdžius, o tai niekada nekenkia.
Būtų gerai pasidžiaugti ypač pasižymėjusių kolegų reikšmingu indėliu pažymėjimais, atminimo ženklais (bent geru žodžiu) bendruose kolektyvų susibūrimuose. Žmonės dažniausiai tokius pažymėjimus, atminimo ženklus labai vertina, kraustydami pasiima su savimi, apskritai visaip rūpinasi.
Norint pažymėti reikšmingesnį, ilgalaikį indėlį į komandos darbą, sukauptą patirtį ir kompetenciją, dažnai naudojama pažymių sistema (vėlgi galima brėžti analogiją su karinių laipsnių sistema kariuomenėje, kuri, be to, pavaldumo užtikrinimui, taip pat tarnauja šiam tikslui). Dažnai jauni kūrėjai dirba dvigubai daugiau, kad gautų naujas žvaigždes ant pečių (ty pereiti iš jaunesniojo kūrėjo į nuolatinį kūrėją ir pan.).
Labai svarbu žinoti savo žmonių lūkesčius. Vienus labiau motyvuoja aukštas pažymys, galimybė vadintis, tarkime, architektu, o kiti, atvirkščiai, neabejingi pažymiams ir titulams ir atlyginimo padidinimą laikys įmonės pripažinimo ženklu. . Bendraukite su žmonėmis, kad suprastumėte, ko jie nori ir kokie jų lūkesčiai.
Pripažinimas, didesnis komandos pasitikėjimas gali būti parodytas suteikiant daugiau veiksmų laisvės ar įsitraukimo į naujas darbo sritis. Pavyzdžiui, sukaupęs tam tikrą patirtį ir pasiekęs tam tikrų rezultatų, programuotojas, be savo funkcijų įdiegimo pagal specifikaciją, gali dirbti prie naujų dalykų architektūros. Arba įsitraukti į naujas sritis, kurios galbūt nėra tiesiogiai susijusios su plėtra – testavimo automatizavimas, geriausios inžinerinės praktikos diegimas, pagalba su leidimų valdymu, kalbėjimas konferencijose ir kt.
V. Pažinimo ir savirealizacijos poreikis.
Daugelis programuotojų įvairiais savo gyvenimo etapais yra orientuoti į įvairias programavimo veiklas. Kai kurie žmonės mėgsta mokytis mašinoje, kurti naujus duomenų modelius, skaityti daug mokslinės literatūros ir kurti kažką naujo nuo nulio. Kitas būdas yra arčiau derinimo ir esamos programos palaikymo, kai reikia įsigilinti į esamą kodą, tyrinėti žurnalus, kaupti pėdsakus ir tinklo captchas dienas ir savaites bei beveik nerašyti naujo kodo.
Abu procesai reikalauja didelių intelektinių pastangų, tačiau jų praktinė produkcija skiriasi. Manoma, kad programuotojai nelinkę remti esamų sprendimų, jie yra labiau motyvuoti kurti naujus. Čia yra išminties grūdas. Kita vertus, labiausiai motyvuota ir vieningiausia komanda, su kuria aš kada nors dirbau, buvo skirta palaikyti esamą produktą, rasti ir ištaisyti klaidas, kai palaikymo komanda susisiekė su jais. Vaikinai tiesiogine prasme gyveno šiuo darbu ir buvo pasirengę išeiti šeštadieniais ir sekmadieniais. Kartą nekantriai sprendėme kitą skubią ir sudėtingą problemą – gruodžio 31 d. vakarą arba sausio 1 d. popietę.
Šiai aukštai motyvacijai įtakos turėjo keli veiksniai. Pirma, tai buvo įmonė, turinti didelį pavadinimą pramonėje, komanda susiejo save su ja (žr. „Prisijungimo poreikis“). Antra, jie buvo paskutinė siena, už jų nebuvo nė vieno, tuo metu nebuvo produktų komandos. Tarp jų ir klientų buvo du palaikymo lygiai, bet jei problema juos pasiekdavo, trauktis nebuvo kur, niekas nebuvo už jų, visa korporacija buvo ant jų (keturi jauni programuotojai). Trečia, ši didelė įmonė turėjo labai didelių klientų (šalių vyriausybių, automobilių ir aviacijos įmonių ir kt.) ir labai didelio masto įrenginių keliose šalyse. Dėl to visada sudėtingos ir įdomios problemos, paprastos problemos buvo išspręstos naudojant ankstesnių lygių palaikymą. Ketvirta, komandos motyvacijai didelę įtaką turėjo palaikymo komandos, su kuria bendravo, profesionalumas (buvo labai patyrę ir techniškai pajėgūs inžinieriai), o mes visada buvome tikri jų paruoštų duomenų kokybe, atlikta analize. ir kt. Penkta, ir manau, kad tai yra svarbiausias momentas – komanda buvo labai jauna, visi vaikinai buvo savo karjeros pradžioje. Jiems buvo įdomu studijuoti didelį ir sudėtingą produktą, naujoje aplinkoje spręsti rimtas jiems naujas problemas, siekta profesionaliai prilygti aplinkinių komandų, problemų, klientų lygiui. Projektas pasirodė puiki mokykla, vėliau visi įmonėje padarė gerą karjerą ir tapo techniniais vadovais bei vyresniaisiais vadovais, vienas iš vaikinų dabar yra „Amazon Web Services“ techninis vadovas, kitas ilgainiui perėjo į „Google“ ir viskas. iš jų vis dar su šiluma prisimena šį projektą.
Jei šią komandą sudarytų programuotojai, turintys 15-20 metų patirtį, motyvacija būtų kitokia. Amžius ir patirtis, žinoma, nėra 100% lemiantys veiksniai, viskas priklauso nuo motyvacijos struktūros. Šiuo konkrečiu atveju jaunų programuotojų žinių troškimas ir augimas davė puikių rezultatų.
Apskritai, kaip jau ne kartą minėjome, turite žinoti savo programuotojų lūkesčius, suprasti, kurie iš jų norėtų plėsti ar keisti savo veiklos sritį ir į šiuos lūkesčius atsižvelgti.
Už Maslow piramidės: rezultatų matomumas, žaidybiškumas ir konkurencija, jokios kvailystės
Yra dar trys svarbūs dalykai, susiję su programuotojų motyvacija, kuriuos būtinai reikia paminėti, tačiau įtraukti juos į Maslow poreikių modelį būtų pernelyg dirbtina.
Pirmasis yra rezultato matomumas ir artumas.
Programinės įrangos kūrimas paprastai yra maratonas. MTEP pastangų rezultatai tampa matomi po kelių mėnesių, kartais metų. Sunku eiti į tikslą, kuris yra toli už horizonto, darbo kiekis gąsdina, tikslas toli, neaiškus ir nematomas, „naktis tamsi ir pilna baisybių“. Geriau kelią iki jo išskaidyti į dalis, padaryti taką iki artimiausio medžio, kuris yra matomas, pasiekiamas, kontūrai aiškūs, ir jis nėra toli nuo mūsų – ir eiti į šį artimą tikslą. Norime pasistengti kelias dienas ar savaites, gauti ir įvertinti rezultatą, tada judėti toliau. Todėl darbą verta skaidyti į smulkias dalis (sprintai judrioje formoje tam puikiai pasitarnauja). Dalį darbo atlikome – įrašėme, iškvėpėme, aptarėme, nubaudėme kaltuosius, apdovanojome nekaltuosius – galime pradėti kitą ciklą.
Ši motyvacija tam tikru mastu yra panaši į tai, ką žaidėjai patiria žaisdami kompiuterinius žaidimus: jie periodiškai gauna medalius, taškus, premijas, kai baigia kiekvieną lygį; tai galima pavadinti „dopamino motyvacija“.
Tuo pačiu metu rezultato matomumas yra tiesiog svarbus. Uždaryta funkcija sąraše turėtų pasidaryti žalia. Jeigu kodas parašytas, išbandytas, išleistas, tačiau programuotojui matomos vizualinės būsenos pasikeitimo nepasikeitė, jis jausis neužbaigtas, neliks užbaigtumo jausmo. Vienoje iš mūsų versijos valdymo sistemos komandų kiekvienas pataisymas buvo per tris nuoseklius etapus – buvo surinkta versija ir išlaikyti testai, pataisa išlaikė kodo peržiūrą, pataisa buvo sujungta. Kiekvienas etapas buvo vizualiai pažymėtas žalia varnele arba raudonu kryžiumi. Kartą vienas kūrėjų pasiskundė, kad kodo peržiūra užtruko per ilgai, kolegoms reikia paspartinti, pleistrai kabo kelias dienas. Aš paklausiau, ką tai iš tikrųjų keičia jam? Juk kai parašomas kodas, surenkamas buildas ir praėjo testai, jam nereikia kreipti dėmesio į atsiųstą pataisą, jei nėra komentarų. Patys kolegos jį peržiūrės ir patvirtins (jei vėlgi nebus pastabų). Jis atsakė: „Igori, aš noriu kuo greičiau gauti savo tris žalias erkes“.
Antras dalykas yra žaidimai ir konkurencija.
Kurdama vieną iš produktų, mūsų inžinierių komanda turėjo tikslą užimti svarbią vietą vieno iš atvirojo kodo produktų bendruomenėje, patekti į geriausių 3-uką. Tuo metu nebuvo objektyvaus būdo įvertinti kažkieno matomumą bendruomenėje; kiekviena iš stambių dalyvaujančių įmonių galėjo teigti (ir periodiškai tvirtino), kad ji yra didžiausia pagalbininkė, tačiau nebuvo realaus būdo palyginti dalyvių indėlį. tarpusavyje, laiku įvertinti jos dinamiką. Atitinkamai nebuvo galimybės komandai išsikelti tikslo, kurį būtų galima išmatuoti kai kuriose papūgose, įvertinti jo pasiekimo laipsnį ir pan. Siekdama išspręsti šią problemą, mūsų komanda sukūrė įrankį, leidžiantį įvertinti ir vizualizuoti įmonių ir individualių bendradarbių indėlį . Motyvacijos požiūriu tai pasirodė tik bomba. Ne tik inžinieriai ir komandos nuolat stebėjo savo ir kolegų bei konkurentų pažangą. Aukščiausia mūsų įmonės vadovybė ir visi pagrindiniai konkurentai savo dieną taip pat pradėjo nuo stackalytics. Viskas tapo labai skaidru ir vaizdu, kiekvienas galėjo atidžiai stebėti savo progresą, lygintis su kolegomis ir pan. Inžinieriams, vadovams ir komandoms užsibrėžti tikslus tapo patogu ir lengva.
Svarbus momentas, kuris iškyla diegiant bet kokią kiekybinių metrikų sistemą, yra tai, kad kai tik jas įdiegiate, sistema automatiškai siekia pirmenybę teikti šių kiekybinių metrikų pasiekimui kokybinių nenaudai. Pavyzdžiui, užbaigtų kodo peržiūrų skaičius naudojamas kaip viena iš metrikų. Akivaizdu, kad kodo peržiūra gali būti atliekama įvairiais būdais, galite praleisti kelias valandas nuodugniai sudėtingo pataiso peržiūrai ir patikrinimui, tikrindami testus, paleisdami jį savo stende, patikrindami dokumentus ir gauti plius vieną peržiūrą savo karmoje arba aklai spustelėk porą dešimčių pataisų per porą minučių, kiekvienam duodi +1 ir gauk plius dvidešimt karmos. Buvo komiškų atvejų, kai inžinieriai taip greitai spustelėjo pataisas, kad automatinėms pataisoms iš CI sistemos duodavo +1. Kaip vėliau juokavome, „eik, eik, jenkinai“. Įsipareigojimų atveju taip pat buvo daug žmonių, kurie perėjo kodą naudodami kodo formatavimo įrankius, redagavo komentarus, keitė taškus į kablelius ir taip pumpavo savo karmą. Su tuo susitvarkyti gana paprasta: vadovaujamės sveiku protu ir, be kiekybinių metrikų, naudojame ir esminius, kokybinius. Komandos darbo rezultatų panaudojimo laipsnis, išorinių bendradarbių skaičius, testų aprėpties lygis, modulių ir viso produkto stabilumas, masto ir veikimo testavimo rezultatai, inžinierių, gavusių pagrindinio recenzento pečių, skaičius. dirželiai, tai, kad projektai buvo priimti į pagrindinių projektų bendruomenę, atitikimas skirtingų inžinerinio proceso etapų kriterijams – visa tai ir daugelis kitų faktorių turi būti vertinami kartu su paprastais kiekybiniais rodikliais.
Ir pabaigai trečias punktas – Jokių kvailysčių.
Kūrėjai yra labai protingi žmonės ir labai logiški savo darbe. Jie praleidžia 8–10 valandų per dieną kurdami ilgas ir sudėtingas logines grandines, todėl jose mato pažeidžiamumą. Kažką darydami jie, kaip ir visi, nori suprasti, kodėl tai daro, kas pasikeis į gerąją pusę. Labai svarbu, kad jūsų komandai keliami tikslai būtų sąžiningi ir realūs. Bandymas parduoti blogą idėją programavimo komandai yra bloga mintis. Idėja yra bloga, jei pats ja netiki arba, kraštutiniais atvejais, neturi vidinės nesutikimo ir įsipareigojimo būsenos (nesutinku, bet padarysiu). Kažkada įmonėje įdiegėme motyvavimo sistemą, kurios vienas elementų buvo elektroninė grįžtamojo ryšio teikimo sistema. Jie investavo daug pinigų, vežė žmones mokytis į Ameriką, apskritai investavo iki galo. Kartą vienas iš vadovų pokalbyje po mokymų pavaldiniams pasakė: „Idėja nebloga, panašu, kad pavyks. Aš pats neduosiu jums elektroninių atsiliepimų, bet jūs duodate juos savo žmonėms ir reikalaujate iš jų“. Tai viskas, toliau nieko nebuvo galima įgyvendinti. Idėja, žinoma, baigėsi niekuo.
Šaltinis: www.habr.com