Epigraph:
Manžel při pohledu na ušmudlané děti říká své ženě: dobře, my je vypereme, nebo porodíme nové?
Pod sestřihem je druhá část článku našeho vedoucího týmu a také ředitele vývoje produktů RAS Igora Marnata o zvláštnostech motivace programátorů. První část článku najdete zde -
V první části článku jsem se dotkl dvou nižších úrovní Maslowovy pyramidy: fyziologických potřeb, potřeb bezpečí, pohodlí a stálosti a přešel jsem k další, třetí úrovni, konkrétně:
III - Potřeba sounáležitosti a lásky
Věděl jsem, že italská mafie se jmenuje „Cosa Nostra“, ale velmi na mě zapůsobilo, když jsem zjistil, jak se „Cosa Nostra“ překládá. „Cosa Nostra“ v překladu z italštiny znamená „Naše podnikání“. Výběr jména je pro motivaci velmi úspěšný (ponechme stranou povolání, v tomto případě nás zajímá pouze motivace). Člověk obvykle chce být součástí týmu, dělat nějaký velký, společný, náš byznys.
Velký význam je kladen na uspokojení potřeby sounáležitosti a lásky v armádě, námořnictvu a jakýchkoli velkých polovojenských formacích. A jak vidíme, v mafii. Je to pochopitelné, protože je potřeba nutit lidi, kteří mají málo společného, kteří zpočátku netvoří tým stejně smýšlejících lidí, které spojuje branná povinnost (ne dobrovolně), kteří mají různé úrovně vzdělání, jiné osobní hodnoty , doslova zasvětit své životy, se smrtelným nebezpečím, nějaké společné věci, svěřit svůj život soudruhovi ve zbrani.
To je velmi silná motivace, pro většinu lidí je nesmírně důležité cítit, že patří do něčeho většího, vědět, že jste součástí rodiny, země, týmu. V armádě k těmto účelům slouží uniformy, různé rituály, přehlídky, pochody, prapory a tak dále. Pro každý tým jsou důležité zhruba stejné faktory. Důležité jsou symboly, firemní značka a firemní barvy, pomůcky a suvenýry.
Je důležité, aby významné události měly své vlastní viditelné ztělesnění, se kterým mohou být spojeny. V dnešní době je spíše normou, že firma má vlastní zboží, bundy, trička atd. Důležité je ale také vyzdvihnout tým uvnitř firmy. Často vydáváme trička na základě výsledků vydání, které dostávají všichni, kdo se na vydání podílejí. Dalším důležitým faktorem motivace jsou některé akce, společné oslavy nebo aktivity s celým týmem.
Kromě vnějších atributů ovlivňuje pocit sounáležitosti s týmem několik dalších faktorů.
Za prvé, přítomnost společného cíle, kterému každý rozumí a sdílí hodnocení jeho důležitosti. Programátoři obvykle chtějí pochopit, že dělají skvělou věc, a dělají tuto skvělou věc společně, jako tým.
Za druhé, tým musí mít komunikační prostor, ve kterém je přítomen celý tým a který patří pouze jemu (například chat v messengeru, pravidelné synchronizace týmu). Kromě pracovních záležitostí, neformální komunikace, někdy diskuse o vnějších událostech, světlo offtop - to vše vytváří pocit komunity a týmu.
Za třetí bych vyzdvihl zavádění správných inženýrských postupů v rámci týmu, snahu zvýšit standardy ve srovnání s těmi, které jsou akceptovány ve společnosti. Implementace nejlepších přístupů akceptovaných v oboru, nejprve v týmu a poté ve společnosti jako celku, dává týmu příležitost cítit, že je nějakým způsobem napřed před ostatními, vede cestu, vytváří to pocit sounáležitosti. do cool týmu.
Pocit sounáležitosti ovlivňuje i participace týmu na plánování a řízení. Když jsou členové týmu zapojeni do diskusí o cílech projektu, pracovních plánech, týmových standardech a technických postupech a pohovorech s novými zaměstnanci, rozvíjejí pocit spoluúčasti, sdíleného vlastnictví a vlivu na práci. Lidé jsou mnohem ochotnější provádět rozhodnutí učiněná a vyslovená jimi než ta, která navrhují ostatní, i když jsou prakticky v souladu.
Narozeniny, výročí, významné události v životě kolegů - společná pizza, malý dárek od týmu dávají hřejivý pocit zapojení a vděčnosti. V některých firmách je zvykem dávat malé pamětní cedule za 5, 10, 15 let práce ve firmě. Na jednu stranu si nemyslím, že mě to tolik motivuje k novým úspěchům. Ale je zřejmé, že téměř každého potěší, že na něj nezapomněli. Jde o jeden z těch případů, kdy absence faktu demotivuje spíše než jeho přítomnost. Souhlas, může být docela ostuda, když se vám LinkedIn ráno připomněl a poblahopřál k 10. výročí na vašem pracovišti, ale ani jeden kolega z firmy vám nepogratuloval a nevzpomněl si na vás.
Samozřejmě podstatným bodem je změna složení týmu. Je jasné, že i když je příchod či odchod někoho z týmu ohlášen předem (například ve firemním či týmovém newsletteru, nebo na týmové poradě), nikoho to nijak zvlášť nemotivuje k novým úspěchům. Ale když jednoho krásného dne vedle sebe uvidíte nového člověka nebo neuvidíte starého, může to být překvapení, a pokud odejdete, přímo nepříjemné. Lidé by neměli tiše mizet. Zvlášť v rozloženém týmu. Zvláště pokud vaše práce závisí na kolegovi z jiné kanceláře, který se náhle objevil a zmizel. Takové momenty rozhodně stojí za to, abyste tým zvlášť předem informovali.
Důležitý faktor, který se v angličtině tzv vlastnictví (doslovný překlad „vlastnictví“ plně neodráží jeho význam). To není pocit vlastnictví, ale spíše pocit odpovědnosti za svůj projekt, ten pocit, kdy se emocionálně spojujete s produktem a produkt se sebou. To zhruba odpovídá modlitbě mariňáka ve filmu „Full Metal Jacket“: „Tohle je moje puška. Existuje mnoho takových pušek, ale tato je moje. Moje puška je můj nejlepší přítel. Ona je můj život. Musím se to naučit vlastnit stejně, jako vlastním svůj život. Beze mě je moje puška k ničemu. Bez pušky jsem k ničemu. Musím střílet z pušky rovně. Musím střílet přesněji než nepřítel, který se mě snaží zabít. Musím ho zastřelit, než zastřelí on mě. Nech to tak být… “.
Když člověk pracuje na produktu dlouhou dobu, má možnost nést plnou zodpovědnost za jeho vznik a vývoj, vidět, jak fungující věc vzniká z „ničeho“, jak ji lidé používají, vzniká tento silný pocit. Produktové týmy, které dlouhodobě spolupracují na jednom projektu, jsou obvykle motivovanější a soudržnější než týmy, které jsou sestaveny na krátkou dobu a pracují v režimu montážní linky, přecházejí z jednoho projektu na druhý, bez plné odpovědnosti za celý produkt , od začátku do konce.
IV. Potřeba uznání
Vlídné slovo kočku také potěší. Každý je motivován uznáním důležitosti odvedené práce a jejím pozitivním hodnocením. Promluvte si s programátory, poskytněte jim pravidelnou zpětnou vazbu, oslavte dobře odvedenou práci. Pokud máte velký a distribuovaný tým, jsou k tomu ideální pravidelné schůzky (tzv. jedna ku jedné); pokud je tým velmi malý a spolupracuje lokálně, je tato příležitost obvykle poskytována bez zvláštních schůzek v kalendáři (ačkoli periodické). na jeden je vše Je to stále potřeba, jen to můžete dělat méně často). Toto téma je dobře pokryto v podcastech pro manažery na manager-tools.com.
Nicméně stojí za to mít na paměti kulturní rozdíly. Některé přístupy známé americkým kolegům nebudou vždy fungovat s ruskými. Míra zdvořilosti přijímaná v každodenní komunikaci v týmech v západních zemích se zpočátku programátorům z Ruska zdá přehnaná. Určitá přímočarost charakteristická pro ruské kolegy může být jejich kolegy z jiných zemí vnímána jako hrubost. To je v komunikaci v interetnickém týmu velmi důležité, na toto téma se toho napsalo hodně, manažer takového týmu to musí pamatovat.
Ukázky funkcí, kde programátoři ukazují funkce vyvinuté během sprintu, jsou dobrou praxí pro realizaci této potřeby. Kromě toho, že se jedná o výbornou příležitost k pročištění komunikačních kanálů mezi týmy, seznámení produktových manažerů a testerů s novými funkcemi, je to také dobrá příležitost pro vývojáře ukázat výsledky své práce a uvést své autorství. No a vypilujte si samozřejmě své řečnické schopnosti, což není nikdy na škodu.
Významný přínos zvláště významných kolegů by bylo dobré oslavit na společných týmových setkáních certifikáty, pamětními cedulemi (alespoň vlídným slovem). Lidé si takových certifikátů a pamětních cedulí většinou velmi váží, berou je s sebou při stěhování a celkově o ně všemožně pečují.
K označení výraznějšího, dlouhodobého přínosu pro práci týmu, nasbíraných zkušeností a odborných znalostí se často používá systém známek (opět lze analogii se systémem vojenských hodností v armádě, který navíc k zajištění podřízenosti slouží také tomuto účelu). Mladí vývojáři často pracují dvakrát tak tvrdě, aby získali nové hvězdy na ramena (tj. přejít z juniorského vývojáře na vývojáře na plný úvazek atd.).
Znát očekávání vašich lidí je zásadní. Někoho motivuje spíše vysoká známka, možnost být nazýván řekněme architektem, jiným jsou naopak známky a tituly lhostejné a zvýšení platu budou považovat za projev uznání firmy. . Komunikujte s lidmi, abyste pochopili, co chtějí a jaká jsou jejich očekávání.
Demonstrace uznání, vyšší úrovně důvěry ze strany týmu, může být poskytnuta větší svobodou jednání nebo zapojením do nových oblastí práce. Například po získání určitých zkušeností a dosažení určitých výsledků může programátor kromě implementace svých funkcí v souladu se specifikací pracovat na architektuře nových věcí. Nebo se zapojte do nových oblastí, které nemusí přímo souviset s vývojem – automatizace testování, implementace nejlepších inženýrských postupů, pomoc se správou vydání, vystupování na konferencích atd.
V. Potřeba poznání a seberealizace.
Mnoho programátorů se zaměřuje na různé typy programátorských činností v různých fázích svého života. Někteří lidé rádi dělají strojové učení, vyvíjejí nové datové modely, čtou spoustu vědecké literatury pro práci a vytvářejí něco nového od začátku. Další je blíže k ladění a podpoře existující aplikace, ve které je potřeba se ponořit hluboko do stávajícího kódu, studovat logy, trasování zásobníku a síťové captcha po celé dny a týdny a psát téměř žádný nový kód.
Oba procesy vyžadují velké intelektuální úsilí, ale jejich praktický výstup je odlišný. Předpokládá se, že programátoři se zdráhají podporovat stávající řešení, jsou spíše motivováni k vývoji nových. Je v tom zrnko moudrosti. Na druhou stranu nejmotivovanější a nejjednotnější tým, se kterým jsem kdy pracoval, se věnoval podpoře existujícího produktu, hledání a opravě chyb poté, co je tým podpory kontaktoval. Chlapi pro tuto práci doslova žili a byli připraveni vyrazit o sobotách a nedělích. Jednou jsme se horlivě zabývali dalším naléhavým a složitým problémem, buď 31. prosince večer, nebo 1. ledna odpoledne.
Tuto vysokou motivaci ovlivnilo několik faktorů. Za prvé to byla společnost s velkým jménem v oboru, tým se s ní spojil (viz „Potřeba přidružení“). Za druhé, oni byli poslední hranice, za nimi nikdo nebyl, v té době neexistoval žádný produktový tým. Mezi nimi a zákazníky byly dvě úrovně podpory, ale pokud se k nim problém dostal, nebylo kam ustoupit, nikdo za nimi nebyl, byla na nich celá korporace (čtyři mladí programátoři). Za třetí, tato velká společnost měla velmi velké zákazníky (vlády zemí, automobilové a letecké koncerny atd.) a velmi rozsáhlé instalace v několika zemích. Výsledkem byly vždy složité a zajímavé problémy, jednoduché problémy byly vyřešeny podporou předchozích úrovní. Za čtvrté, motivaci týmu do značné míry ovlivnila profesionální úroveň podpůrného týmu, se kterým komunikovali (byli zde velmi zkušení a technicky zdatní inženýři), a my jsme si vždy byli jisti kvalitou dat, která připravovali, analýzou, kterou prováděli. , atd. Za páté, a to je myslím nejdůležitější bod – tým byl velmi mladý, všichni kluci byli na začátku své kariéry. Měli zájem studovat velký a komplexní produkt, řešit závažné problémy, které pro ně byly nové v novém prostředí, snažili se profesionálně vyrovnat úrovni okolních týmů, problémů a zákazníků. Projekt se ukázal jako vynikající škola, všichni později udělali ve firmě dobrou kariéru a stali se technickými lídry a senior manažery, jeden z kluků je nyní technickým manažerem v Amazon Web Services, druhý nakonec přešel do Googlu a všichni z nich dodnes na tento projekt s vřelostí vzpomínají.
Pokud by se tento tým skládal z programátorů s 15-20letou praxí za sebou, motivace by byla jiná. Věk a zkušenosti samozřejmě nejsou 100% určující faktory, vše závisí na struktuře motivace. V tomto konkrétním případě touha po znalostech a růstu mladých programátorů přinesla vynikající výsledky.
Obecně, jak jsme již několikrát zmínili, musíte znát očekávání svých programátorů, rozumět tomu, kdo z nich by chtěl rozšířit nebo změnit pole působnosti, a tato očekávání brát v úvahu.
Za Maslowovou pyramidou: viditelnost výsledků, gamifikace a konkurence, žádné kecy
Existují ještě tři důležité body týkající se motivace programátorů, které je rozhodně potřeba zmínit, ale jejich zapracování do Maslowova modelu potřeb by bylo příliš umělé.
Prvním je viditelnost a blízkost výsledku.
Vývoj softwaru je obvykle maratón. Výsledky výzkumného a vývojového úsilí jsou viditelné po měsících, někdy i letech. Je těžké jít k cíli, který je daleko za horizontem, množství práce je děsivé, cíl je daleko, není jasný a není vidět, „noc je temná a plná hrůz“. Je lepší rozbít cestu k němu na části, udělat cestu k nejbližšímu stromu, který je viditelný, dosažitelný, obrysy jasné a není daleko od nás - a jít k tomuto blízkému cíli. Chceme vynaložit úsilí několik dní nebo týdnů, získat a vyhodnotit výsledek a pak jít dál. Proto se vyplatí práci rozdělit na malé části (k tomuto účelu dobře poslouží sprinty v agilu). Část díla jsme dokončili – nahráli, vydechli, prodiskutovali, potrestali viníky, odměnili nevinné – můžeme začít další cyklus.
Tato motivace je do určité míry podobná té, kterou hráči zažívají při dokončování počítačových her: pravidelně dostávají medaile, body, bonusy, když dokončí každou úroveň; to lze nazvat „dopaminová motivace“.
Viditelnost výsledku je přitom doslova důležitá. Uzavřený prvek v seznamu by měl zezelenat. Pokud je kód napsán, testován, uvolněn, ale nedojde k žádné změně ve vizuálním stavu viditelném pro programátora, bude se cítit neúplný, nebude mít pocit dokončení. V jednom z týmů našeho systému správy verzí prošel každý patch třemi po sobě jdoucími fázemi – sestavení bylo sestaveno a testy prošly, oprava prošla kontrolou kódu, oprava byla začleněna. Každá etapa byla vizuálně označena zeleným zaškrtnutím nebo červeným křížkem. Jakmile si jeden z vývojářů stěžoval, že kontrola kódu trvala příliš dlouho, kolegové potřebovali zrychlit, záplaty několik dní visely. Ptal jsem se, co se tím pro něj vlastně mění? Koneckonců, když je napsán kód, sestava je sestavena a testy prošly, nemusí se věnovat odeslanému patchi, pokud nejsou žádné komentáře. Kolegové sami jej zkontrolují a schválí (pokud opět nejsou žádné připomínky). Odpověděl: "Igore, chci dostat svá tři zelená klíšťata co nejdříve."
Druhým bodem je gamifikace a konkurence.
Při vývoji jednoho z produktů měl náš inženýrský tým za cíl zaujmout prominentní místo v komunitě jednoho z open source produktů a dostat se mezi top 3. V té době neexistoval žádný objektivní způsob, jak posoudit něčí zviditelnění v komunitě, každá z velkých zúčastněných společností mohla tvrdit (a pravidelně prohlašovat), že je přispěvatelem číslo jedna, ale neexistoval žádný skutečný způsob, jak porovnat příspěvky účastníků. mezi sebou, vyhodnotit jeho dynamiku v čase. V souladu s tím neexistoval způsob, jak stanovit pro tým cíl, který by bylo možné u některých papoušků změřit, posoudit stupeň jeho dosažení atd. K vyřešení tohoto problému náš tým vyvinul nástroj pro měření a vizualizaci přínosu firem a jednotlivých přispěvatelů . Z motivačního hlediska to dopadlo prostě bomba. Nebyli to jen inženýři a týmy, kteří neustále sledovali svůj postup a postup svých kolegů a konkurentů. Svůj den se stackalytikou zahájilo i vrcholové vedení naší společnosti a všichni významní konkurenti. Vše se stalo velmi transparentním a vizuálním, každý mohl pečlivě sledovat svůj pokrok, porovnávat s kolegy atd. Pro inženýry, manažery a týmy se stalo pohodlné a snadné stanovovat cíle.
Důležitým bodem, který vyvstává při implementaci jakéhokoli systému kvantitativních metrik, je, že jakmile je implementujete, systém se automaticky snaží upřednostnit dosažení těchto kvantitativních metrik na úkor kvalitativních. Jako jedna z metrik se například používá počet dokončených kontrol kódu. Je zřejmé, že kontrola kódu může být provedena různými způsoby, můžete strávit několik hodin důkladnou kontrolou a kontrolou komplexní opravy s kontrolními testy, spuštěním na vašem pracovním stole, kontrolou s dokumentací a získat plus jednu kontrolu ve své karmě, nebo poslepu klikněte na několik desítek patchů za pár minut, každému dejte +1 a dostanete plus dvacet v karmě. Byly komické případy, kdy inženýři klikali na záplaty tak rychle, že dali +1 automatickým záplatám ze systému CI. Jak jsme později vtipkovali, „jdi, jdi, jenkinsi“. V případě commitů se také našlo mnoho lidí, kteří procházeli kód pomocí nástrojů pro formátování kódu, upravovali komentáře, měnili tečky na čárky a napumpovali si tak karmu. Vypořádat se s tím je celkem jednoduché: používáme zdravý rozum a kromě kvantitativních metrik používáme i ty zásadní, kvalitativní. Míra využití výsledků práce týmu, počet externích přispěvatelů, úroveň pokrytí testem, stabilita modulů a celého produktu, výsledky testování rozsahu a výkonu, počet inženýrů, kteří obdrželi jádro recenzenta popruhy, skutečnost, že projekty byly přijaty do komunity klíčových projektů, soulad s kritérii různých fází inženýrského procesu – to vše a mnoho dalších faktorů je nutné posuzovat spolu s jednoduchými kvantitativními metrikami.
A nakonec třetí bod – Bez keců.
Vývojáři jsou velmi chytří lidé a ve své práci extrémně logičtí. Tráví 8-10 hodin denně budováním dlouhých a složitých logických řetězců, takže v nich vidí zranitelnosti za chodu. Když něco dělají, chtějí, stejně jako všichni ostatní, pochopit, proč to dělají, co se změní k lepšímu. Je nesmírně důležité, aby cíle, které svému týmu stanovíte, byly upřímné a reálné. Snažit se prodat špatný nápad programátorskému týmu je špatný nápad. Nápad je špatný, pokud v něj sám nevěříte, nebo v extrémních případech nemáte vnitřní stav nesouhlasu a závazku (nesouhlasím, ale udělám to). Kdysi jsme ve firmě zavedli motivační systém, jehož jedním z prvků byl elektronický systém poskytování zpětné vazby. Investovali spoustu peněz, vzali lidi do Ameriky na školení, obecně investovali naplno. Jednou v rozhovoru po školení jeden z manažerů řekl svým podřízeným: „Nápad to není špatný, vypadá to, že bude fungovat. Sám vám elektronickou zpětnou vazbu neposkytnu, ale vy ji dáte svým lidem a požadujete ji od nich.“ To je vše, nic se nedalo dále implementovat. Myšlenka samozřejmě neskončila ničím.
Zdroj: www.habr.com