Epigraaf:
Abikaasa, vaadates räämas lapsi, ütleb oma naisele: no kas peseme need ära või sünnitame uued?
Lõike all on teine osa meie tiimijuhi, aga ka RAS-i tootearendusdirektori Igor Marnati artiklist programmeerijate motiveerimise iseärasustest. Artikli esimese osa leiate siit -
Artikli esimeses osas puudutasin Maslow püramiidi kahte madalamat tasandit: füsioloogilisi vajadusi, ohutuse, mugavuse ja püsivuse vajadusi ning liikusin edasi järgmisele, kolmandale tasemele, nimelt:
III - Vajadus kuuluvuse ja armastuse järele
Teadsin, et Itaalia maffiat kutsutakse “Cosa Nostraks”, kuid mulle avaldas suurt muljet, kui sain teada, kuidas “Cosa Nostra” tõlgitakse. "Cosa Nostra" tähendab itaalia keelest tõlkes "meie äri". Nimevalik on motivatsiooniks väga edukas (jätkem amet kõrvale, sel juhul huvitab meid ainult motivatsioon). Inimene tahab tavaliselt olla osa meeskonnast, teha mingit suurt, ühist, meie äri.
Suurt tähtsust omistatakse kuuluvus- ja armastusvajaduse rahuldamisele armees, mereväes ja suurtes poolsõjaväelistes koosseisudes. Ja nagu näeme, maffias. See on arusaadav, sest tuleb sundida inimesi, kellel on vähe ühist, kes esialgu ei moodusta mõttekaaslaste meeskonda, keda koondab ajateenistus (mitte vabatahtlikult), kellel on erinev haridustase, erinevad isiklikud väärtused. , et pühendada oma elu surmaohus sõna otseses mõttes mõnele ühisele eesmärgile, usaldada oma elu võitluskaaslasele.
See on väga tugev motivatsioon, enamiku inimeste jaoks on ülimalt oluline tunda, et nad kuuluvad millessegi suuremasse, teades, et oled osa perest, riigist, meeskonnast. Sõjaväes täidavad neid eesmärke vormirõivad, erinevad rituaalid, paraadid, marsid, plakatid jne. Ligikaudu samad tegurid on olulised iga meeskonna jaoks. Olulised on sümbolid, ettevõtte bränd ja ettevõtte värvid, atribuutika ja suveniirid.
On oluline, et olulistel sündmustel oleks oma nähtav kehastus, millega neid seostada. Tänapäeval on pigem tavaline, et ettevõttel on oma kaup, jakid, T-särgid jne. Kuid oluline on esile tõsta ka meeskonda ettevõtte sees. Tihti anname välja T-särgid väljalaske tulemuste põhjal, mis antakse kõigile väljalaskmisega seotud isikutele. Mõned üritused, ühised pidustused või tegevused kogu meeskonnaga on teine oluline motivatsioonitegur.
Lisaks välistele omadustele mõjutavad meeskonda kuulumise tunnet ka mitmed muud tegurid.
Esiteks ühise eesmärgi olemasolu, mida kõik mõistavad ja jagavad hinnangut selle olulisusele. Programmeerijad tahavad tavaliselt aru saada, et nad teevad lahedat asja ja teevad seda lahedat asja koos, meeskonnana.
Teiseks peab meeskonnal olema suhtlusruum, milles viibib kogu meeskond ja mis kuulub ainult talle (näiteks vestlus messengeris, perioodilised meeskonna sünkroonid). Lisaks tööasjadele, mitteametlikule suhtlusele, vahel ka väliste sündmuste arutelule, light offtopile – kõik see loob kogukonna- ja meeskonnatunnet.
Kolmandaks tõstaksin esile heade inseneritavade juurutamist meeskonna sees, soovi tõsta standardeid võrreldes ettevõttes aktsepteerituga. Valdkonnas aktsepteeritud parimate lähenemisviiside rakendamine, esmalt meeskonnas ja seejärel ettevõttes tervikuna, annab meeskonnale võimaluse tunda, et ta on mõnes mõttes teistest ees, teed juhatades, see loob kuuluvustunde. lahedasse meeskonda.
Kuuluvustunnet mõjutab ka meeskonna osalemine planeerimises ja juhtimises. Kui meeskonnaliikmed osalevad projekti eesmärkide, tööplaanide, meeskonnastandardite ja inseneritavade arutamises ning uute töötajate küsitlemises, tekib neil osalustunne, jagatud omanditunne ja mõju tööle. Inimesed on palju valmis ellu viima enda tehtud ja välja öeldud otsuseid kui teiste pakutud otsuseid, isegi kui need on praktiliselt kooskõlas.
Sünnipäevad, tähtpäevad, märgilised sündmused kolleegide elus - ühine pitsa, väike kingitus kollektiivilt annavad sooja kaasatuse ja tänutunde. Mõnes ettevõttes on kombeks anda väikesed mälestusmärgid 5, 10, 15 tööaasta eest ettevõttes. Ühest küljest ma ei usu, et see mind nii palju uuteks saavutusteks motiveerib. Kuid ilmselt on peaaegu kõigil hea meel, et nad pole teda unustanud. See on üks neist juhtudest, kus fakti puudumine pigem demotiveerib kui selle olemasolu motiveerib. Nõus, võib olla päris kahju, kui LinkedIn sulle hommikul meelde tuletas ja töökohas 10. juubeli puhul õnnitles, aga mitte ükski kolleeg ettevõttest ei õnnitlenud ega mäletanud.
Märkimisväärne punkt on muidugi koondise koosseisu muutus. Selge on see, et isegi kui mõne meeskonnaliikme tulekust või lahkumisest ette teatatakse (näiteks ettevõtte või meeskonna uudiskirjas või meeskonna koosolekul), ei motiveeri see kedagi eriti uuteks saavutusteks. Kui aga ühel ilusal päeval näete enda kõrval uut inimest või ei näe vana, võib see olla üllatus ja lahkumine lausa ebameeldiv. Inimesed ei tohiks vaikselt kaduda. Eriti hajutatud meeskonnas. Eriti kui teie töö sõltub ootamatult üles tõusnud ja kadunud kolleegist teisest kontorist. Sellistest hetkedest tasub kindlasti meeskonda eelnevalt teavitada.
Oluline tegur, mida inglise keeles nimetatakse omandiõigus ("valduse" sõnasõnaline tõlge ei kajasta täielikult selle tähendust). See ei ole omanikutunne, vaid pigem vastutustunne oma projekti eest, see tunne, kui seod end emotsionaalselt tootega ja toodet iseendaga. See vastab ligikaudu merejalaväe palvele filmis "Full Metal Jacket": "See on minu püss. Selliseid vintpüsse on palju, aga see on minu oma. Mu püss on mu parim sõber. Ta on minu elu. Pean õppima seda omama samamoodi nagu oma elu. Ilma minuta pole mu püss kasutu. Ma olen ilma püssita kasutu. Ma pean püssist otse tulistama. Ma pean tulistama täpsemalt kui vaenlane, kes üritab mind tappa. Ma pean teda tulistama, enne kui ta mind tulistab. Las see olla nii..."
Kui inimene töötab toote kallal pikka aega, tal on võimalus kanda täit vastutust selle loomise ja arendamise eest, näha, kuidas „eimillestki“ tekib töötav asi, kuidas inimesed seda kasutavad, tekib see võimas tunne. Tootemeeskonnad, kes töötavad ühe projekti kallal pikka aega koos, on tavaliselt motiveeritumad ja ühtsemad kui lühikeseks ajaks kokku pandud meeskonnad, kes töötavad konveierirežiimil, lülitudes ühelt projektilt teisele, ilma täieliku vastutuseta kogu toote eest. , algusest lõpuni.
IV. Tunnustamise vajadus
Hea sõna teeb ka kassile heameelt. Igaüht motiveerib tunnustamine tehtud töö olulisusele ja selle positiivne hinnang. Rääkige programmeerijatega, andke neile perioodilist tagasisidet, tähistage hästi tehtud tööd. Kui teil on suur ja hajutatud meeskond, sobivad selleks suurepäraselt perioodilised koosolekud (mida nimetatakse üks ühele), kui meeskond on väga väike ja töötab kohapeal koos, on see võimalus tavaliselt ilma kalendris erikoosolekuteta (kuigi perioodiline). üks on kõik. Seda on ikka vaja, saate seda teha harvemini). Seda teemat käsitletakse hästi juhtidele mõeldud taskuhäälingusaadetes saidil manager-tools.com.
Siiski tasub silmas pidada kultuurilisi erinevusi. Mõned Ameerika kolleegidele tuttavad lähenemisviisid ei tööta alati Venemaa omadega. Lääneriikide meeskondades igapäevases suhtluses aktsepteeritud viisakuse tase tundub Venemaalt pärit programmeerijatele esialgu liigne. Vene kolleegidele omast otsekohesust võivad teistest riikidest pärit kolleegid tajuda ebaviisakusena. See on rahvustevahelise meeskonna suhtlemisel väga oluline, sellel teemal on palju kirjutatud, sellise meeskonna juht peab seda meeles pidama.
Funktsioonide tutvustamine, kus programmeerijad näitavad sprindi käigus välja töötatud funktsioone, on hea tava selle vajaduse realiseerimiseks. Lisaks sellele, et see on suurepärane võimalus meeskondadevahelisi suhtluskanaleid puhastada, tootejuhtidele ja testijatele uusi funktsioone tutvustada, on see ka hea võimalus arendajatele näidata oma töö tulemusi ja näidata oma autorsust. Noh, ja lihvige muidugi oma avaliku esinemise oskusi, mis pole kunagi kahjulik.
Eriti silmapaistvate kolleegide märkimisväärset panust oleks hea tähistada tunnistuste, mälestussiltidega (vähemalt hea sõnaga) ühistel kollektiivi koosviibimistel. Inimesed hindavad selliseid tunnistusi ja mälestusmärke tavaliselt väga kõrgelt, võtavad need kolimisel kaasa ja üldiselt hoolitsevad nende eest igati.
Märkimaks olulisemat, pikaajalisemat panust meeskonna töösse, kogutud kogemusi ja asjatundlikkust, kasutatakse sageli hindesüsteemi (jällegi võib tuua analoogia sõjaväeliste auastmete süsteemiga sõjaväes, mis lisaks alluvuse tagamisele, teenib ka seda eesmärki). Tihti näevad noored arendajad kaks korda rohkem vaeva, et uusi staare õlarihmadele saada (st nooremarendajalt täiskohaga arendajaks jne).
Oma inimeste ootuste tundmine on ülioluline. Mõnda motiveerib tõenäolisemalt kõrge hinne, võimalus kutsuda näiteks arhitektiks, teised, vastupidi, on hinnete ja tiitlite suhtes ükskõiksed ning peavad palgatõusu ettevõtte tunnustuse märgiks. . Suhelge inimestega, et mõista, mida nad tahavad ja millised on nende ootused.
Tunnustuse demonstratsiooni, meeskonna suuremat usaldust saab anda rohkem tegutsemisvabadust või kaasamist uutesse töövaldkondadesse. Näiteks pärast teatud kogemuste omandamist ja teatud tulemuste saavutamist saab programmeerija lisaks oma funktsioonide spetsifikatsioonile vastavale rakendamisele töötada ka uute asjade arhitektuuriga. Või kaasa lüüa uutes valdkondades, mis ei pruugi arendusega otseselt seotud olla – testimise automatiseerimine, parimate inseneritavade juurutamine, väljalaskehalduse abistamine, konverentsidel esinemine jne.
V. Tunnetuse ja eneseteostuse vajadus.
Paljud programmeerijad on oma elu eri etappidel keskendunud erinevat tüüpi programmeerimistegevustele. Mõnele inimesele meeldib teha masinõpet, arendada uusi andmemudeleid, lugeda töö jaoks palju teaduskirjandust ja luua midagi uut nullist. Teine on lähemal silumisele ja olemasoleva rakenduse toetamisele, mille puhul peate süvenema olemasolevasse koodi, uurima logisid, virnastama jälgi ja võrgu captchasid päevade ja nädalate jooksul ning kirjutama peaaegu mitte ühtegi uut koodi.
Mõlemad protsessid nõuavad suurt intellektuaalset pingutust, kuid nende praktiline väljund on erinev. Arvatakse, et programmeerijad ei soovi toetada olemasolevaid lahendusi, pigem on nad motiveeritud uusi välja töötama. Selles on tarkusetera. Teisest küljest oli kõige motiveeritum ja ühtsem meeskond, kellega olen kunagi töötanud, pühendunud olemasoleva toote toetamisele, vigade leidmisele ja parandamisele pärast seda, kui tugimeeskond nendega ühendust võttis. Poisid elasid sõna otseses mõttes selle töö nimel ja olid valmis laupäeviti ja pühapäeviti välja minema. Kunagi tegelesime innukalt veel ühe pakilise ja keerulise probleemiga, kas 31. detsembri õhtul või 1. jaanuari pärastlõunal.
Seda kõrget motivatsiooni mõjutasid mitmed tegurid. Esiteks oli see tööstuses suure nimega ettevõte, meeskond seostas end sellega (vt “Seostumise vajadus”). Teiseks olid nad viimane piir, nende taga polnud kedagi, tootemeeskonda tol ajal polnud. Nende ja klientide vahel oli kaks tugitasandit, kuid kui probleem nendeni jõudis, polnud enam kuhugi taanduda, nende taga polnud kedagi, kogu korporatsioon oli nende peal (neli noort programmeerijat). Kolmandaks oli sellel suurel ettevõttel väga suured kliendid (riikide valitsused, auto- ja lennunduskontsernid jne) ning väga suuremahulised rajatised mitmes riigis. Selle tulemusena lahendati alati keerukad ja huvitavad probleemid, lihtsad probleemid eelmiste tasemete toel. Neljandaks mõjutas meeskonna motivatsiooni suuresti tugimeeskonna professionaalne tase, kellega nad suhtlesid (seal olid väga kogenud ja tehniliselt võimekad insenerid) ning olime alati kindlad nende koostatud andmete kvaliteedis, nende tehtud analüüsides. , jne. Viiendaks ja see on minu arvates kõige olulisem punkt – meeskond oli väga noor, kõik poisid olid oma karjääri alguses. Nad olid huvitatud suure ja keeruka toote uurimisest, nende jaoks uute tõsiste probleemide lahendamisest uues keskkonnas, püüdsid professionaalselt sobitada ümbritsevate meeskondade, probleemide ja klientide taset. Projekt osutus suurepäraseks kooliks, kõik tegid hiljem ettevõttes head karjääri ja said tehnilisteks juhtideks ja tippjuhtideks, üks meestest on nüüd Amazon Web Servicesi tehniline juht, teine kolis lõpuks Google'isse ja kõik neist mäletavad seda projekti siiani soojalt .
Kui see meeskond koosneks programmeerijatest, kellel on seljataga 15-20 aastane kogemus, oleks motivatsioon teine. Vanus ja kogemused ei ole muidugi 100% määravad, kõik sõltub motivatsiooni struktuurist. Antud juhul andis noorte programmeerijate teadmiste- ja kasvamissoov suurepäraseid tulemusi.
Üldiselt, nagu oleme juba korduvalt maininud, peate teadma oma programmeerijate ootusi, mõistma, kes neist sooviks oma tegevusvaldkonda laiendada või muuta, ning nende ootustega arvestada.
Väljaspool Maslow püramiidi: tulemuste nähtavus, mängulisus ja konkurents, ei mingit jama
Programmeerijate motivatsiooni osas on kindlasti veel kolm olulist punkti, mida tuleb kindlasti mainida, kuid nende tõmbamine Maslow vajaduste mudelisse oleks liiga kunstlik.
Esimene on tulemuse nähtavus ja lähedus.
Tarkvaraarendus on tavaliselt maraton. Teadus- ja arendustegevuse tulemused on nähtavad kuude, mõnikord aastate pärast. Raske on minna eesmärgini, mis jääb silmapiiri taha, töömaht on hirmuäratav, siht on kaugel, pole selge ja pole nähtav, "öö on pime ja õudusi täis." Parem on murda tee selleni osadeks, teha tee lähima puu juurde, mis on nähtav, ligipääsetav, piirjooned on selged ja see pole meist kaugel - ja minge selle lähedase eesmärgi poole. Tahame mitu päeva või nädalat pingutada, saada ja hinnata tulemust, et siis edasi liikuda. Seetõttu tasub töö jagada väikesteks osadeks (sprint agiilses täidab seda eesmärki hästi). Oleme osa tööst lõpetanud – salvestanud, välja hinganud, arutanud, süüdlasi karistanud, süütuid premeerinud – saame alustada järgmist tsüklit.
See motivatsioon on mingil määral sarnane sellega, mida mängijad arvutimänge mängides kogevad: iga taseme läbimisel saavad nad perioodiliselt medaleid, punkte, boonuseid; seda võib nimetada "dopamiini motivatsiooniks".
Samas on tulemuse nähtavus sõna otseses mõttes oluline. Loendis olev suletud funktsioon peaks muutuma roheliseks. Kui kood on kirjutatud, testitud, vabastatud, kuid programmeerijale nähtavat visuaalset staatust ei toimu, tunneb ta end puudulikuna, lõpetatuse tunnet ei teki. Ühes meie versioonihaldussüsteemi meeskonnas läbis iga plaaster kolm järjestikust etappi – ehitamine pandi kokku ja testid läbisid, plaaster läbis koodi ülevaatuse, plaaster liideti. Iga etapp oli visuaalselt tähistatud rohelise linnukese või punase ristiga. Kord kurtis üks arendajatest, et koodi ülevaatamine võttis liiga kaua aega, kolleegid peavad kiirendama, plaastrid rippusid mitu päeva. Küsisin, mida see tema jaoks tegelikult muudab? Lõppude lõpuks, kui kood on kirjutatud, build kokku pandud ja testid läbitud, ei pea ta saadetud plaastrile tähelepanu pöörama, kui kommentaare pole. Kolleegid ise vaatavad selle üle ja kinnitavad (kui jällegi kommentaare ei ole). Ta vastas: "Igor, ma tahan oma kolm rohelist puuki võimalikult kiiresti kätte saada."
Teine punkt on mängulisus ja konkurents.
Ühe toote arendamisel oli meie insenerimeeskonnal eesmärk võtta ühe avatud lähtekoodiga toote kogukonnas silmapaistev koht, pääseda esikolmikusse. Sel ajal ei olnud objektiivset võimalust hinnata kellegi nähtavust kogukonnas; kõik osalevad suured ettevõtted võisid väita (ja väitsid perioodiliselt), et on panustajate number üks, kuid osalejate panuse võrdlemiseks polnud reaalset võimalust. omavahel, et hinnata selle dünaamikat õigeaegselt. Sellest lähtuvalt ei olnud võimalik seada meeskonnale eesmärki, mida saaks mõnes papagois mõõta, hinnata selle saavutamise astet jne. Selle probleemi lahendamiseks on meie meeskond välja töötanud tööriista ettevõtete ja üksikute panustajate panuse mõõtmiseks ja visualiseerimiseks . Motivatsiooni seisukohalt osutus see lihtsalt pommiks. Mitte ainult insenerid ja meeskonnad ei jälginud pidevalt enda ning kolleegide ja konkurentide edusamme. Ka meie ettevõtte tippjuhtkond ja kõik suuremad konkurendid alustasid oma päeva stackalyticsiga. Kõik muutus väga läbipaistvaks ja visuaalseks, igaüks sai hoolega oma edusamme jälgida, kolleegidega võrrelda jne. Inseneride, juhtide ja meeskondade jaoks on eesmärkide seadmine muutunud mugavaks ja lihtsaks.
Oluline punkt, mis ilmneb mis tahes kvantitatiivsete mõõdikute süsteemi rakendamisel, on see, et niipea, kui olete need juurutanud, püüab süsteem automaatselt seada prioriteediks nende kvantitatiivsete mõõdikute saavutamise kvalitatiivsete arvelt. Näiteks kasutatakse ühe mõõdikuna lõpetatud koodiülevaatuste arvu. Ilmselgelt saab koodi ülevaatust teha erineval viisil, võite kulutada mitu tundi keeruka plaastri põhjalikule ülevaatamisele ja kontrollimisele koos testide kontrollimisega, selle tööpingil käivitamisega, dokumentatsiooniga kontrollimisega ja pluss ühe arvustuse saamiseks oma karmas või kliki pimesi paarikümne minuti jooksul paarkümmend plaastrit, anna igaühele +1 ja saad pluss kakskümmend karmat. Oli koomilisi juhtumeid, kui insenerid klõpsasid plaastritel nii kiiresti, et andsid CI-süsteemi automaatsetele paikadele +1. Nagu hiljem naljatasime, "mine, mine, jenkins." Komitee puhul oli ka palju inimesi, kes käisid koodi vormindamise vahenditega läbi, toimetasid kommentaare, muutsid punktid komadeks ja pumpasid sellega oma karmat üles. Sellega tegelemine on üsna lihtne: kasutame tervet mõistust ja lisaks kvantitatiivsetele mõõdikutele ka olulisi, kvalitatiivseid. Meeskonna töö tulemuste kasutusaste, väliste panustajate arv, testimise tase, moodulite ja kogu toote stabiilsus, mastaabi- ja jõudlustestimise tulemused, põhiarvustaja õla saanud inseneride arv. rihmad, tõsiasi, et projektid võeti vastu põhiprojektide kogukonda, vastavus projekteerimisprotsessi erinevate etappide kriteeriumidele – kõiki neid ja paljusid muid tegureid tuleb hinnata koos lihtsate kvantitatiivsete mõõdikutega.
Ja lõpuks kolmas punkt – Ei mingit jama.
Arendajad on väga targad inimesed ja oma töös äärmiselt loogilised. Nad veedavad 8-10 tundi päevas pikkade ja keeruliste loogiliste ahelate ehitamisel, nii et nad näevad neis haavatavust lennult. Midagi tehes tahavad nad nagu kõik teisedki aru saada, miks nad seda teevad, mis muutub paremaks. On äärmiselt oluline, et meeskonnale seatud eesmärgid oleksid ausad ja realistlikud. Proovida programmeerimismeeskonnale halba ideed maha müüa on halb mõte. Idee on halb, kui sa ise sellesse ei usu või äärmisel juhul pole sul sisemist eriarvamust ja pühendumust (ma ei ole nõus, aga teen seda). Kunagi juurutasime ühes ettevõttes motivatsioonisüsteemi, mille üheks elemendiks oli elektrooniline tagasiside andmise süsteem. Nad investeerisid palju raha, viisid inimesi Ameerikasse koolitusele, üldiselt investeerisid nad täiel rinnal. Kord pärast koolitust vesteldes ütles üks juht oma alluvatele: «Idee pole halb, eks paistab, kas see läheb korda. Ma ei anna sulle ise elektroonilist tagasisidet, aga sa annad seda oma inimestele ja nõuad neilt. See on kõik, edasi ei saanud midagi rakendada. Mõte ei lõppenud muidugi mitte millegagi.
Allikas: www.habr.com