motto:
Manžel pri pohľade na špinavé deti hovorí svojej žene: dobre, my ich umyjeme, alebo porodíme nové?
Pod zostrihom je druhá časť článku nášho vedúceho tímu, ako aj riaditeľa vývoja produktov RAS Igora Marnata, o zvláštnostiach motivovania programátorov. Prvú časť článku nájdete tu -
V prvej časti článku som sa dotkol dvoch nižších úrovní Maslowovej pyramídy: fyziologických potrieb, potrieb bezpečia, pohodlia a stálosti a prešiel som na ďalšiu, tretiu úroveň, konkrétne:
III - Potreba spolupatričnosti a lásky
Vedel som, že talianska mafia sa volá „Cosa Nostra“, ale veľmi ma zaujalo, keď som zistil, ako sa prekladá „Cosa Nostra“. „Cosa Nostra“ v preklade z taliančiny znamená „Naša firma“. Výber mena je pre motiváciu veľmi úspešný (necháme bokom povolanie, v tomto prípade nás zaujíma iba motivácia). Človek zvyčajne chce byť súčasťou tímu, robiť nejaký veľký, spoločný, náš biznis.
Veľký význam sa kladie na uspokojenie potreby spolupatričnosti a lásky v armáde, námorníctve a akýchkoľvek veľkých polovojenských formáciách. A ako vidíme, v mafii. Je to pochopiteľné, pretože treba nútiť ľudí, ktorí majú málo spoločného, ktorí spočiatku netvoria tím rovnako zmýšľajúcich ľudí, ktorých spája branná povinnosť (nie dobrovoľne), ktorí majú rôzne úrovne vzdelania, iné osobné hodnoty. , doslova zasvätiť svoje životy, so smrteľným rizikom, nejakej spoločnej veci, zverte svoj život súdruhovi v zbrani.
Je to veľmi silná motivácia, pre väčšinu ľudí je nesmierne dôležité cítiť, že patria do niečoho väčšieho, vedieť, že ste súčasťou rodiny, krajiny, tímu. V armáde na tieto účely slúžia uniformy, rôzne rituály, prehliadky, pochody, transparenty atď. Pre každý tím sú dôležité približne rovnaké faktory. Dôležité sú symboly, firemná značka a firemné farby, príslušenstvo a suveníry.
Je dôležité, aby významné udalosti mali svoje vlastné viditeľné stelesnenie, s ktorým môžu byť spojené. V dnešnej dobe je skôr normou, že firma má vlastný tovar, bundy, tričká atď. Dôležité je ale vyzdvihnúť aj tím v rámci firmy. Tričká často vydávame na základe výsledkov vydania, ktoré dostanú všetci, ktorí sa na vydaní podieľajú. Niektoré akcie, spoločné oslavy či aktivity s celým tímom sú ďalším dôležitým faktorom motivácie.
Pocit spolupatričnosti k tímu ovplyvňuje okrem vonkajších atribútov aj niekoľko ďalších faktorov.
Po prvé, prítomnosť spoločného cieľa, ktorému každý rozumie a zdieľa hodnotenie jeho dôležitosti. Programátori zvyčajne chcú pochopiť, že robia skvelú vec, a robia túto skvelú vec spoločne, ako tím.
Po druhé, tím musí mať komunikačný priestor, v ktorom je prítomný celý tím a ktorý patrí len jemu (napríklad chat v messengeri, pravidelné synchronizácie tímu). Okrem pracovných záležitostí, neformálna komunikácia, niekedy diskusia o externých udalostiach, svetlo offtop - to všetko vytvára pocit komunity a tímu.
Po tretie, vyzdvihol by som zavedenie dobrej inžinierskej praxe v rámci tímu, túžbu zvýšiť štandardy v porovnaní s tými, ktoré sú akceptované v spoločnosti. Implementácia najlepších prístupov akceptovaných v odvetví, najprv v tíme a potom v spoločnosti ako celku, dáva tímu príležitosť cítiť, že je nejakým spôsobom pred ostatnými, vedie cestu, vytvára to pocit spolupatričnosti. do skvelého tímu.
Pocit spolupatričnosti ovplyvňuje aj participácia tímu na plánovaní a riadení. Keď sú členovia tímu zapojení do diskusie o projektových cieľoch, pracovných plánoch, tímových štandardoch a inžinierskych postupoch a rozhovoroch s novými zamestnancami, rozvíjajú si zmysel pre participáciu, spoločné vlastníctvo a vplyv na prácu. Ľudia sú oveľa ochotnejší vykonávať rozhodnutia, ktoré urobia a vyslovia sami, ako tie, ktoré navrhujú iní, aj keď sú prakticky zladení.
Narodeniny, výročia, významné udalosti v živote kolegov - spoločná pizza, malý darček od tímu dávajú teplý pocit zapojenia a vďačnosti. V niektorých firmách je zvykom dávať malé pamätné tabule za 5, 10, 15 rokov práce vo firme. Na jednej strane si nemyslím, že ma to až tak motivuje k novým úspechom. Ale očividne takmer každého poteší, že na neho nezabudli. Toto je jeden z tých prípadov, keď absencia faktu skôr demotivuje ako jeho prítomnosť. Súhlaste, môže byť dosť hanba, ak vám LinkedIn ráno pripomenul a zablahoželal vám k 10. výročiu na vašom pracovisku, no ani jeden kolega z firmy vám nezablahoželal ani si na vás nespomenul.
Samozrejme, podstatným bodom je zmena v zložení tímu. Je jasné, že aj keď je príchod alebo odchod niekoho z tímu vopred oznámený (napríklad vo firemnom alebo tímovom newsletteri, alebo na tímovom stretnutí), nikoho to nijak zvlášť nemotivuje k novým úspechom. Ale ak jedného pekného dňa uvidíte vedľa seba nového človeka alebo nevidíte starého, môže to byť prekvapenie, a ak odídete, priam nepríjemné. Ľudia by nemali potichu miznúť. Najmä v rozloženom tíme. Najmä ak vaša práca závisí od kolegu z inej kancelárie, ktorý sa náhle zdvihol a zmizol. O takýchto chvíľach sa určite oplatí informovať tím zvlášť vopred.
Dôležitým faktorom, ktorý v angličtine je tzv vlastníctva (doslovný preklad „vlastníctva“ úplne neodráža jeho význam). Toto nie je pocit vlastníctva, ale skôr pocit zodpovednosti za svoj projekt, ten pocit, keď sa emocionálne spájate s produktom a produkt so sebou. To zhruba zodpovedá modlitbe námorníka vo filme „Full Metal Jacket“: „Toto je moja puška. Existuje veľa takýchto pušiek, ale táto je moja. Moja puška je môj najlepší priateľ. Ona je môj život. Musím sa to naučiť vlastniť tak, ako vlastním svoj život. Bezo mňa je moja puška zbytočná. Bez pušky som zbytočný. Musím strieľať z pušky priamo. Musím strieľať presnejšie ako nepriateľ, ktorý sa ma snaží zabiť. Musím ho zastreliť skôr, ako on zastrelí mňa. Nech je to tak...“
Keď človek dlho pracuje na produkte, má možnosť niesť plnú zodpovednosť za jeho vznik a vývoj, vidieť, ako fungujúca vec vzniká „z ničoho“, ako ju ľudia používajú, vzniká tento silný pocit. Produktové tímy, ktoré dlhodobo spolupracujú na jednom projekte, sú zvyčajne motivovanejšie a súdržnejšie ako tímy, ktoré sú zostavené na krátky čas a pracujú v režime montážnej linky, prechádzajú z jedného projektu na druhý bez toho, aby mali plnú zodpovednosť za celý projekt. produkt, od začiatku do konca.
IV. Potreba uznania
Milé slovo poteší aj mačku. Každého motivuje uznanie dôležitosti vykonanej práce a jej pozitívne hodnotenie. Porozprávajte sa s programátormi, poskytnite im pravidelnú spätnú väzbu, oslavujte dobre vykonanú prácu. Ak máte veľký a distribuovaný tím, pravidelné stretnutia (nazývané jedna ku jednej) sú na to ideálne; ak je tím veľmi malý a spolupracuje lokálne, táto príležitosť sa zvyčajne poskytuje bez špeciálnych stretnutí v kalendári (hoci pravidelných stretnutí). na jedno je všetko Je to stále potrebné, len to môžete robiť menej často). Táto téma je dobre pokrytá v podcastoch pre manažérov na manager-tools.com.
Stojí však za to mať na pamäti kultúrne rozdiely. Niektoré prístupy známe americkým kolegom nebudú vždy fungovať s ruskými. Miera zdvorilosti akceptovaná v každodennej komunikácii v tímoch v západných krajinách sa programátorom z Ruska spočiatku zdá prehnaná. Určitú priamosť charakteristickú pre ruských kolegov môžu ich kolegovia z iných krajín vnímať ako hrubosť. V komunikácii v interetnickom tíme je to veľmi dôležité, o tejto téme sa toho popísalo veľa, manažér takéhoto tímu si to musí pamätať.
Ukážky funkcií, kde programátori ukazujú funkcie vyvinuté počas sprintu, sú dobrým postupom na realizáciu tejto potreby. Okrem toho, že ide o výbornú príležitosť na prečistenie komunikačných kanálov medzi tímami, predstavenie produktových manažérov a testerov s novými funkciami, je to aj dobrá príležitosť pre vývojárov ukázať výsledky svojej práce a uviesť svoje autorstvo. No a vyleštite si svoje rečnícke schopnosti, samozrejme, čo nikdy nie je na škodu.
Významný prínos obzvlášť významných kolegov by bolo dobré osláviť certifikátmi, pamätnými tabuľami (aspoň milým slovom) na spoločných tímových stretnutiach. Ľudia si takéto certifikáty a pamätné tabule väčšinou veľmi vážia, berú si ich so sebou pri sťahovaní a celkovo sa o ne všemožne starajú.
Na označenie výraznejšieho, dlhodobého prínosu k práci tímu, nazbieraných skúseností a odbornosti sa často používa systém známok (opäť možno vyvodiť analógiu so systémom vojenských hodností v armáde, ktorý navyše na zabezpečenie podriadenosti slúži aj tomuto účelu). Mladí vývojári často pracujú dvakrát tak tvrdo, aby získali nové hviezdy na ramenách (t. j. prejsť z juniorského vývojára na vývojára na plný úväzok atď.).
Poznať očakávania vašich ľudí je rozhodujúce. Niektorých motivuje skôr vysoká trieda, možnosť byť nazývaný povedzme architektom, iným sú naopak známky a tituly ľahostajné a zvýšenie platu budú považovať za prejav uznania zo strany firmy. . Komunikujte s ľuďmi, aby ste pochopili, čo chcú a aké sú ich očakávania.
Ukážka uznania, vyššej úrovne dôvery zo strany tímu, môže byť poskytnutá väčšou voľnosťou konania alebo zapojením sa do nových oblastí práce. Napríklad po získaní určitých skúseností a dosiahnutí určitých výsledkov môže programátor okrem implementácie svojich funkcií v súlade so špecifikáciou pracovať na architektúre nových vecí. Alebo sa zapojte do nových oblastí, ktoré nemusia priamo súvisieť s vývojom – automatizácia testovania, implementácia najlepších inžinierskych praktík, pomoc so správou vydania, vystupovanie na konferenciách atď.
V. Potreba poznávania a sebaaktualizácie.
Mnoho programátorov sa zameriava na rôzne typy programovacích činností v rôznych fázach svojho života. Niektorí ľudia radi robia strojové učenie, vyvíjajú nové dátové modely, čítajú veľa vedeckej literatúry a vytvárajú niečo nové od začiatku. Iný je bližšie k ladeniu a podpore existujúcej aplikácie, v ktorej sa musíte hlboko ponoriť do existujúceho kódu, študovať denníky, trasovanie zásobníkov a sieťové captcha celé dni a týždne a nepísať takmer žiadny nový kód.
Oba procesy vyžadujú veľké intelektuálne úsilie, ale ich praktický výstup je odlišný. Predpokladá sa, že programátori sa zdráhajú podporovať existujúce riešenia, sú skôr motivovaní vyvíjať nové. Je v tom zrnko múdrosti. Na druhej strane, najmotivovanejší a najjednotnejší tím, s ktorým som kedy pracoval, sa venoval podpore existujúceho produktu, hľadaniu a odstraňovaniu chýb po tom, čo ich tím podpory kontaktoval. Chlapi pre túto prácu doslova žili a boli pripravení vyraziť v sobotu a nedeľu. Raz sme sa horlivo zaoberali ďalším naliehavým a zložitým problémom, či už 31. decembra večer, alebo 1. januára popoludní.
Túto vysokú motiváciu ovplyvnilo viacero faktorov. Po prvé, bola to spoločnosť s veľkým menom v odvetví, tím sa s ňou spájal (pozri „Potreba pridruženia“). Po druhé, boli poslednou hranicou, za nimi nebol nikto, v tom čase neexistoval produktový tím. Medzi nimi a zákazníkmi existovali dve úrovne podpory, ale ak ich problém zasiahol, nebolo kam ustúpiť, nikto za nimi nestál, bola na nich celá korporácia (štyria mladí programátori). Po tretie, táto veľká spoločnosť mala veľmi veľkých zákazníkov (vlády krajín, automobilové a letecké koncerny atď.) a veľmi rozsiahle inštalácie v niekoľkých krajinách. Výsledkom boli vždy zložité a zaujímavé problémy, jednoduché problémy boli vyriešené podporou predchádzajúcich úrovní. Po štvrté, motiváciu tímu do značnej miery ovplyvnila profesionálna úroveň podporného tímu, s ktorým komunikovali (boli tam veľmi skúsení a technicky zdatní inžinieri), a vždy sme si boli istí kvalitou údajov, ktoré pripravili, analýzou, ktorú vykonali. , atď. Po piate, a to je podľa mňa najdôležitejší bod – tím bol veľmi mladý, všetci chalani boli na začiatku kariéry. Mali záujem študovať veľký a komplexný produkt, riešiť vážne problémy, ktoré boli pre nich nové v novom prostredí, snažili sa odborne zodpovedať úrovni okolitých tímov, problémov, zákazníkov. Projekt sa ukázal ako výborná škola, všetci neskôr urobili v spoločnosti dobrú kariéru a stali sa technickými lídrami a senior manažérmi, jeden z chalanov je teraz technickým manažérom v Amazon Web Services, druhý nakoniec prešiel do Googlu a všetci z nich dodnes s vrúcnosťou spomínajú na tento projekt.
Ak by tento tím tvorili programátori s 15-20 ročnou praxou, motivácia by bola iná. Vek a skúsenosti samozrejme nie sú stopercentne určujúce, všetko závisí od štruktúry motivácie. V tomto konkrétnom prípade túžba po vedomostiach a raste mladých programátorov priniesla vynikajúce výsledky.
Vo všeobecnosti, ako sme už niekoľkokrát spomenuli, musíte poznať očakávania svojich programátorov, pochopiť, ktorí z nich by chceli rozšíriť alebo zmeniť pole pôsobnosti, a tieto očakávania zohľadniť.
Za Maslowovou pyramídou: viditeľnosť výsledkov, gamifikácia a súťaž, žiadne kecy
Sú tu ešte tri dôležité body týkajúce sa motivácie programátorov, ktoré rozhodne treba spomenúť, no ich začlenenie do Maslowovho modelu potrieb by bolo príliš umelé.
Prvým je viditeľnosť a blízkosť výsledku.
Vývoj softvéru je zvyčajne maratón. Výsledky výskumu a vývoja sú viditeľné po mesiacoch, niekedy až rokoch. Je ťažké ísť k cieľu, ktorý je ďaleko za horizontom, množstvo práce je desivé, cieľ je ďaleko, nie je jasný a nie je viditeľný, „noc je temná a plná hrôz“. Je lepšie rozbiť cestu k nej na časti, urobiť cestu k najbližšiemu stromu, ktorý je viditeľný, dosiahnuteľný, obrysy sú jasné a nie je ďaleko od nás - a ísť k tomuto blízkemu cieľu. Chceme vynaložiť úsilie na niekoľko dní alebo týždňov, získať a vyhodnotiť výsledok a potom ísť ďalej. Preto sa oplatí prácu rozdeliť na malé časti (na tento účel dobre slúžia šprinty v agile). Časť práce sme dokončili – nahrali, vydýchli, diskutovali, potrestali vinníkov, odmenili nevinných – môžeme začať ďalší cyklus.
Táto motivácia je do určitej miery podobná tomu, čo hráči zažívajú pri dokončovaní počítačových hier: pravidelne dostávajú medaily, body, bonusy, keď dokončia každú úroveň; toto sa dá nazvať „dopamínová motivácia“.
Viditeľnosť výsledku je zároveň doslova dôležitá. Uzavretý prvok v zozname by sa mal zmeniť na zelenú. Ak je kód napísaný, testovaný, uvoľnený, ale nedôjde k žiadnej zmene vizuálneho stavu viditeľnej programátorom, bude sa cítiť neúplný, nebude mať pocit dokončenia. V jednom z tímov nášho systému na správu verzií prešla každá oprava tromi po sebe nasledujúcimi fázami – zostavenie bolo zostavené a testy prešli, oprava prešla kontrolou kódu, oprava bola zlúčená. Každá etapa bola vizuálne označená zeleným začiarknutím alebo červeným krížikom. Raz sa jeden z vývojárov sťažoval, že kontrola kódu trvala príliš dlho, kolegovia potrebovali zrýchliť, záplaty niekoľko dní viseli. Pýtal som sa, čo sa tým pre neho vlastne mení? Koniec koncov, keď je kód napísaný, zostava je zostavená a testy prešli, nemusí venovať pozornosť odoslanej záplate, ak nie sú žiadne pripomienky. Posúdia a schvália ho samotní kolegovia (ak opäť neexistujú žiadne pripomienky). Odpovedal: "Igor, chcem čo najskôr dostať svoje tri zelené kliešte."
Druhým bodom je gamifikácia a súťaž.
Pri vývoji jedného z produktov mal náš inžiniersky tím za cieľ zaujať popredné miesto v komunite jedného z produktov s otvoreným zdrojovým kódom a dostať sa medzi top 3. V tom čase neexistoval žiadny objektívny spôsob, ako posúdiť niekoho viditeľnosť v komunite; každá z veľkých zúčastnených spoločností mohla tvrdiť (a pravidelne tvrdila), že je hlavným prispievateľom, ale neexistoval skutočný spôsob, ako porovnať príspevky účastníkov. medzi sebou, aby zhodnotili jeho dynamiku v čase. V súlade s tým neexistoval spôsob, ako stanoviť cieľ tímu, ktorý by sa dal zmerať u niektorých papagájov, posúdiť stupeň jeho dosiahnutia atď. Na vyriešenie tohto problému náš tím vyvinul nástroj na meranie a vizualizáciu prínosu firiem a individuálnych prispievateľov . Z motivačného hľadiska to dopadlo jednoducho bomba. Neboli to len inžinieri a tímy, ktorí neustále sledovali svoj pokrok a pokrok svojich kolegov a konkurentov. So stackalytikou začal svoj deň aj vrcholový manažment našej spoločnosti a všetci významní konkurenti. Všetko sa stalo veľmi transparentným a vizuálnym, každý mohol pozorne sledovať svoj pokrok, porovnávať s kolegami atď. Stanovenie cieľov sa pre inžinierov, manažérov a tímy stalo pohodlným a jednoduchým.
Dôležitým bodom, ktorý vzniká pri implementácii akéhokoľvek systému kvantitatívnych metrík, je, že akonáhle ich implementujete, systém sa automaticky snaží uprednostniť dosiahnutie týchto kvantitatívnych metrík na úkor kvalitatívnych. Napríklad počet dokončených kontrol kódu sa používa ako jedna z metrík. Je zrejmé, že kontrola kódu môže byť vykonaná rôznymi spôsobmi, môžete stráviť niekoľko hodín dôkladnou kontrolou a kontrolou komplexnej opravy s kontrolnými testami, spustením na vašom počítači, kontrolou s dokumentáciou a získať plus jednu kontrolu vo svojej karme, alebo naslepo kliknite na pár desiatok patchov za pár minút, dajte každému +1 a dostanete plus dvadsať v karme. Boli komické prípady, keď inžinieri klikali na záplaty tak rýchlo, že dali +1 automatickým záplatám z CI systému. Ako sme neskôr žartovali, „choď, choď, jenkins“. V prípade commitov sa tiež našlo veľa ľudí, ktorí si kód prešli nástrojmi na formátovanie kódu, upravovali komentáre, menili bodky na čiarky a napumpovali si tak karmu. Vyrovnať sa s tým je celkom jednoduché: používame zdravý rozum a okrem kvantitatívnych metrík používame aj podstatné, kvalitatívne. Miera využitia výsledkov práce tímu, počet externých prispievateľov, úroveň pokrytia testami, stabilita modulov a celého produktu, výsledky testovania rozsahu a výkonu, počet inžinierov, ktorí dostali kmeňový recenzent popruhy, skutočnosť, že projekty boli prijaté do komunity kľúčových projektov, súlad s kritériami rôznych fáz inžinierskeho procesu – všetky tieto a mnohé ďalšie faktory je potrebné posudzovať spolu s jednoduchými kvantitatívnymi metrikami.
A na záver tretí bod – No bullshit.
Vývojári sú veľmi inteligentní ľudia a vo svojej práci mimoriadne logickí. Strávia 8-10 hodín denne budovaním dlhých a zložitých logických reťazcov, takže v nich za behu vidia zraniteľné miesta. Keď niečo robia, tak ako všetci ostatní chcú pochopiť, prečo to robia, čo sa zmení k lepšiemu. Je mimoriadne dôležité, aby ciele, ktoré si stanovíte pre svoj tím, boli čestné a reálne. Pokúšať sa predať zlý nápad programátorskému tímu je zlý nápad. Myšlienka je zlá, ak v ňu sami neveríte, alebo v extrémnych prípadoch nemáte vnútorný stav nesúhlasu a záväzku (nesúhlasím, ale urobím to). Kedysi sme vo firme zaviedli motivačný systém, ktorého jedným z prvkov bol elektronický systém poskytovania spätnej väzby. Investovali veľa peňazí, zobrali ľudí do Ameriky na školenie, celkovo investovali naplno. Raz v rozhovore po školení jeden z manažérov povedal svojim podriadeným: „Nápad to nie je zlý, zdá sa, že bude fungovať. Sám vám elektronickú spätnú väzbu neposkytnem, ale vy ju dáte svojim ľuďom a požadujete ju od nich.“ To je všetko, nič sa nedalo ďalej implementovať. Myšlienka, samozrejme, neskončila ničím.
Zdroj: hab.com