Epigraph:
Manžel při pohledu na ušmudlané děti říká své ženě: dobře, my je vypereme, nebo porodíme nové?
Pod střihem je diskuse vedoucího našeho týmu a ředitele vývoje produktů RAS Igora Marnata o zvláštnostech motivace programátorů.
Tajemství úspěchu při vytváření skvělých softwarových produktů je dobře známé – vezměte tým skvělých programátorů, dejte týmu skvělý nápad a nezasahujte do práce týmu. Cool vývojáři jsou vzácní a žádaní. Někteří personalisté dokonce říkají, že mají dojem, že je snazší vyrobit skvělého programátora, než si ho najmout z trhu. Kromě úskalí s náborem jako takovým jsou často nenahraditelné nebo obtížně a časově náročné doplňování zkušeností každého konkrétního vývojáře, jeho znalost stávajícího produktu a historie jeho vývoje. Proto, pokud máte to štěstí a už máte skvělý tým programátorů, je důležité zapracovat na jejich motivaci. Najímání a školení nových vývojářů, sestavení týmu z nich je téměř stejně obtížné a časově náročné jako porod a výchova dětí.
Podívejme se na hlavní faktory motivace pro programátory (týmy programátorů), pomocí Maslowovy pyramidy pro přehlednost a strukturování prezentace. Pokud jste ještě neslyšeli o Maslowově pyramidě, není to nesporná, ale velmi oblíbená a názorná teorie amerického psychologa Abrahama Harolda Maslowa, který navrhl teorii osobní motivace založenou na hierarchii lidských potřeb (viz obrázek níže).
Maslow uspořádal potřeby jednotlivce do hierarchického řádu, od fyziologických potřeb po potřebu potenciálního rozvoje a sebeaktualizace. Klíčovým předpokladem Maslowovy teorie je, že „člověk nemůže zažívat potřeby vyšší úrovně, dokud nejsou uspokojeny jeho potřeby nižší úrovně“. Člověk se například nemůže nechat řídit potřebou znalostí nebo estetických potřeb, pokud zároveň tento člověk tři dny nespal a nejedl.
Než půjdeme do detailů, zaměřme se na zřejmý fakt – tým se skládá z lidí, všichni lidé jsou jiní, každý má svou vlastní strukturu motivace. Kromě toho, že každého člověka řídí jiné zájmy, každý člověk je také v jiných životních podmínkách. Někdo je na začátku kariéry a přemýšlí, jak ji vybudovat, někdo se bude vdávat a někdo chce zvládnout nový obor. To, co je pro jednoho důležité, je pro druhého zcela nedůležité a zítra se zase všechno změní. Abyste správně pochopili tento kontext, existuje jednoduchá náprava – je třeba o ní přemýšlet a pracovat s ní. Nejdůležitější je komunikace.
Určitě si se svým týmem promluvte o něčem jiném než o práci, budujte neformální vztahy.
Pojďme si tedy nyní projít Maslowovu pyramidu a zvážit její úrovně jako aplikované na řízení týmu programátorů.
I: Fyziologické, biologické potřeby:
Když se mluví o motivaci, mnoho lidí často myslí především na plat. Platem v tomto případě rozumím trvalou součást kompenzačního balíčku, který nijak nezávisí na výsledcích. To neplatí pro bonusy, bonusy a firemní akce. Je to mzda, kterou bych v našem případě přisoudil k úrovni „fyziologických potřeb“. Bonusy, bonusy na základě výkonu, opcí a podílů společnosti – to vše bych zařadil do jiných úrovní.
Dle mého názoru, ať to zní jakkoli divně, plat by spíše mohl být demotivující faktor spíše než motivační faktor. Zvláštností práce s programátory je, že jsou to všichni lidé, zaprvé velmi chytří (vlastnost této profese) a zadruhé hluboce a/nebo široce vzdělaní. Obvykle mají programátoři kromě své profese hluboké znalosti o jedné nebo více oblastech, pro které vytvářejí produkty. Dobří programátoři se navíc zajímají a dobře znají historii vývoje programování, algoritmy, standardy atd. Totéž platí pro jejich předmětovou oblast. Pro lidi na této úrovni není plat většinou hlavním motivačním faktorem.
Zároveň nedostatek spravedlivého platu pro programátory v jejich chápání velmi demotivuje a demotivuje. Mít spravedlivý plat je normou. Mzda je mnohem vyšší, než je norma (trh) - také kupodivu dost demotivující faktor. Kolega mi kdysi vyprávěl o týmu programátorů v jedné z velkých amerických animačních firem, která díky řadě okolností dostávala platy na úrovni dvakrát až třikrát vyšší než trh. Jak sám řekl, v životě neviděl nudnější, línější a demotivovanější programátory. Skutečnost zvýšení platu může krátkodobě motivovat, ale po několika měsících se nový plat stane normou a přestane motivovat. Obecně bych řekl, že pro programátory na začátku kariéry je důležitější platový faktor, jak profesně rostou a vyvíjejí se, jeho význam klesá a začínají převažovat jiné faktory.
Druhým důležitým bodem je přítomnost spravedlivé rovnováhy ve výši platů v týmu. Pokud má tým pocit, že příspěvek jednoho člena je znatelně nižší, ale výše kompenzace je stejná, bude to demotivovat celý tým. Někdy jsou manažeři v pokušení podlévat oheň penězi – udržet vyhořelého nebo demotivovaného člověka zvýšením jeho platu nad normál. To většinou dělá problémy jen v dlouhodobém horizontu - motivace samotného člověka se moc nezvýší, nebo se na pár měsíců zvýší, ale u zbytku týmu klesne motivace. V takových situacích se vyplatí hledat jiné přístupy, pokud se ovšem nejedná o jedinečného specialistu, kterého je třeba za každou cenu, byť jen krátkodobě, udržet.
II. Potřeba bezpečí, pohodlí, konzistence životních podmínek:
Před 70 lety mohla být přítomnost kamen v autě motivačním faktorem při výběru auta, tehdy byla nadstandardní a byla známkou luxusu. Nyní je i absence klimatizace nesmysl a její přítomnost samozřejmě nebude motivačním faktorem při výběru vozu. Takže před 10-15 lety pohodlná kancelář, dobrý hardware, lahodná káva, fitness, flexibilní pracovní doba atd. mohou být dobrými motivačními faktory, ale nyní je to spíše norma pro práci dobrého programátora. Zároveň bude jejich absence opět demotivující.
Důležitým demotivujícím faktorem je neschopnost koncentrace a hlučné pracovní prostředí. Práce programátora vyžaduje ticho a soustředění. Pokud kancelářský prostor neposkytuje možnost poskytnout vývojářům odloučenou pracovní plochu, je nutné zajistit alespoň pohodlnou spolupráci mezi kolegy, kteří si navzájem nepřekáží. Je lepší spojit energické a hlasité kamarády mezi sebou a dát příležitost soustředit se těm, kteří to potřebují.
Náklady na čas programátora jsou nyní výrazně vyšší než náklady na hardware, na kterém pracuje. Dva nebo tři monitory, výkonné počítače, pohodlné pracoviště pro každého vývojáře – to by mělo být standardem v každé společnosti. Toto téma je dobře pokryto v jednom z článků Joela Spolského “Joelův test: 12 kroků k lepšímu kódu.“
Fyzická složka pohodlí je nejzákladnější a nejjednodušší, nyní si promluvme o zbytku.
V mnoha společnostech je normou pro programátory flexibilní pracovní doba a žádný dress code. To je dobré a správné, pokud to specifika práce týmu dovolují (například se nekonají schůzky se zákazníky, politiky nebo bankéři).
Důležité je mít konkrétní časové období, kdy celý tým spolupracuje lokálně, aby lidé mohli komunikovat a řešit problémy tváří v tvář. Programátor v podstatě neodchází z práce ani po práci. Pracovní problémy se mu obvykle přehrávají bez ohledu na jeho přítomnost v kanceláři a dobrá rozhodnutí často přicházejí mimo kancelář. Vzhledem k potřebě být dobrý (o čemž budeme hovořit níže) je drobná kontrola škodlivá. Nejen, že je to demotivující, ale také to snižuje produktivitu. Jak ukazuje praxe, při absenci kontroly je pravděpodobnější, že motivovaný tým bude pracovat déle, než je nutné. Pokud je ovládání, mohou vývojáři sedět u klávesnice od devíti do šesti, ale výsledek, myslím, bude horší. Jak se říká, jeden člověk dovede koně k vodě, ale ani sto ho nedonutí pít, když nechce.
Popis této úrovně potřeb také zmiňuje svobodu od úzkosti a strachu, absenci chaosu a potřebu struktury a řádu. To jsou také nesmírně důležité body, které velmi ovlivňují atmosféru v týmu.
Za prvé absence chaosu, struktury a řádu – tým musí rozumět tomu, kdo je za co zodpovědný, jak jsou rozděleny role, co je potřeba udělat, komu, kdy, jaké požadavky jsou základem produktu, jaká jsou očekávání vedení a zákazník... Většina z toho by měla být formálně popsána, vše by se mělo pravidelně projednávat. Bez diskuze a pravidelného používání popisy nefungují. Je dobrou praxí o nich pravidelně diskutovat a aktualizovat je na základě výsledků posmrtné analýzy po propuštění.
Za druhé, klidná a přátelská atmosféra. Všichni trávíme většinu času v práci a chceme ji dělat bez stresu, konfliktů nebo strachu. Vývojový tým obvykle pracuje pod tlakem plánů a zákazníků. Nikdo nepotřebuje další stres od kolegů a nadřízených. Atmosféra v týmu, obecně samotná skutečnost, že skupina vývojářů může být nazývána a být „týmem“, je přímou a důležitou odpovědností manažera, jedním z nejdůležitějších střednědobých a dlouhodobých úkolů. Proto je důležité, aby manažer pracoval zejména s konflikty v týmu a nenechal jejich rozvoj volný průběh. Řízení konfliktů je samostatné téma, které si zaslouží samostatné studium.
Existují dva hlavní způsoby, jak ovlivnit emoční stav týmu a chování kolegů (pokud se někdo přidá v komentářích, bylo by to skvělé). První je vaše vlastní chování. Osobní příklad je pro manažera a tým velmi důležitý. Jak se říká, jaký je kněz, takový je příchod. Chovejte se tak, jak očekáváte, že se budou chovat vaši kolegové. Druhým je podpora správného chování a takříkajíc odvrácení nesprávného chování. Komunikujte s lidmi, dávejte jim zpětnou vazbu, existuje mnoho způsobů, jak to udělat. Obecně je zpětná vazba tématem na samostatnou diskusi, je velkou a důležitou součástí práce s motivací.
Ještě poznámka k atmosféře, která se může zdát nezvyklá, ale v praxi je důležitá. Častěji je ve vývojovém týmu méně dívek než mužů. Často jsou skupiny zcela mužské. V takových podmínkách, také při zátěži, se v týmu začíná používat někdy obscénní jazyk. Praxe ukazuje, že to má negativní dopad na atmosféru, komunikace se postupně stává neslušnou. Měli byste se vyhnout jeho používání sami a odrazovat od jeho používání ve vašem týmu.
Vývojové týmy se často nazývají R&D (výzkum a vývoj), přičemž výzkum tvoří významnou část práce. To je ta část, která se většinou těžko naprogramuje a naplánuje, jinak by to nebyl výzkum. Je důležité, aby tým měl právo dělat chyby, převzít iniciativu, zkoušet různé možnosti, které mohou a nemusí skončit úspěchem. Chyby jsou běžnou součástí práce, nelze se jim vyhnout, ale můžete je studovat, analyzovat, poučit se z nich do budoucna a jít dál. Princip 5 Why's, který vznikl v Toyotě, je dobrým způsobem, jak se dostat ke kořenové příčině problému. Trestání chyb je skvělý způsob, jak vytvořit atmosféru strachu a nejistoty. Jedinou výjimkou je situace, kdy se na základě výsledků rozboru ukáže, že chyba byla způsobena neprofesionálním přístupem k práci, v tomto případě může být nutné personální rozhodnutí.
Atmosféru v týmu do značné míry ovlivňují vaše očekávání a emoční rozpoložení před začátkem rozhovoru. Před zahájením náročné diskuse, nějakého debriefingu nebo jen emotivního rozhovoru je důležitá vaše nálada a postoj k osobě, se kterou budete mluvit. Vždy standardně věřím a jednám na základě toho, co se ten člověk upřímně snažil udělat co nejlépe. Pokud se z vaší pozice zdá, že tomu tak není, je třeba v klidu a detailně zjistit souvislosti a pochopit, co udělal správně, proč to považoval za správné a kde se naše očekávání rozcházejí. Obvykle se ukáže, že se ve skutečnosti nerozcházejí, jen je jeho vize kontextu úplnější nebo svěží a je tu něco, co jste nevěděli. Nebo naopak něco nevěděl. To je zvláště důležité v distribuovaném týmu, kdy lidé méně často komunikují osobně a používají e-mail a instant messenger. To je ještě důležitější v týmu složeném z programátorů z různých zemí a distribuovaných v různých časových pásmech. Zde začínají hrát velkou roli kulturní rozdíly.
V obtížné situaci je jízda v pohybu snadná, velmi snadná, ale pak je jízda zpět obtížná a sediment zůstává po dlouhou dobu. Uvedu jednoduchý příklad z nedávné zkušenosti. Jeden z manažerů týmu naléhavě potřeboval komentáře k nějakému problému se zákazníkem od manažera z příbuzného týmu v jiné zemi. Pingl na kolegu v messengeru, počkal 15 minut, pingnul znovu, pak po 15 minutách šel do velkého chatu, ve kterém byli i ostatní manažeři, a mírně na kolegu zaútočil slovy: „protože ty ne možná mi odpovíš a ta otázka není tak naléhavá?" Nakonec se ukázalo, že náš firemní messenger byl lehce tupý a kolega dotaz vůbec neviděl. Musel jsem se omluvit. Obecně je lepší začít tím dobrým. Vždy je možné udělat špatnou chybu a později se dostat do problémů; s tím není žádný problém (i když byste to dělat neměli). Obecně platí, že za více než 20 let práce v naší branži jsem potkal skutečně zlomyslného kolegu pouze jednou (!). Naštěstí jsme se docela rychle rozešli. Ukazuje se jako správné v naprosté většině případů předpokládat, že kolegové chtějí to nejlepší, podle svého nejlepšího porozumění kontextu.
Vaším úkolem jako manažera je zajistit synchronizaci kontextů, společné chápání očekávání, požadavků, termínů a standardů akceptovaných v týmu. Možná se to zdá jako maličkosti, ale právě z takových maličkostí se buduje atmosféra v týmu. Z pohledu distribuovaného týmu je jedním z důležitých úkolů zajistit, aby členové týmu pravidelně komunikovali tváří v tvář. Nejednou jsem od programátorů slyšel, že poté, co za nimi přišli například inženýři z podpůrného týmu a osobně spolupracovali, rádi zůstali v práci, aby pomohli v těžkém případě osobně Pašovi, který k nim nedávno přišel, ačkoli dříve byl Pasha jen ikonou v poslu a nikdo by se kvůli ikoně nezastavil.
Mimochodem, začal jsem mluvit o podpůrném týmu a vzpomněl jsem si na kanonický příklad pro mě. Jednou měl jeden ze zákazníků v Americe problém s produktem, jeden z inženýrů z podpůrného týmu, který pracoval na jeho implementaci (vyslaný z Ruska), zůstal po práci pomáhat, ale problém se nevyřešil a nevyřešil. Obecně se zdržel a seděl tam skoro až do rána. V tuto chvíli manažeři zákazníka problém eskalovali, identifikovali pro ně jeho závažnost a večer odešli z práce. Proces eskalace již nabíral na obrátkách v jiném časovém pásmu, manažeři podpory v Rusku se začali snažit pomoci, kvůli určitým potížím v komunikaci s kanceláří zákazníka (VPN, problémy s připojením, potíže s hovory mezi zeměmi, ...) nevěděl, že ten chlap už byl ve vězení v kanceláři a řeší problém, a pokusil se ho najít. Našli ho až ráno (americké), kdy už byl problém prakticky vyřešen a produkt fungoval. Hned zkraje začali říkat, že sakra, zákazník má takovou eskalaci, nic nefunguje, kde jste, nemůžeme vás najít atd. Netřeba dodávat, že v důsledku takového chování byl chlap značně demotivovaný. Organizace práce distribuovaného týmu je samostatné velké téma, ale je důležité pamatovat na dvě věci. Za prvé je velmi důležitá komunikace a atmosféra, na které závisí úspěch práce. Zadruhé to nefunguje samo o sobě, musí se to řešit samostatně a do hloubky.
Dalším důležitým bodem souvisejícím s touto úrovní potřeb je opět mzda. Ne velikost platu jako takového, ale přítomnost určitého postupu pro jeho změnu. Společnost musí mít přístup ke stanovení požadavků na pozice na různých úrovních. Každý vývojář by měl být schopen prodiskutovat očekávání od své práce se společností, pochopit, jak a kdy může jeho úsilí ovlivnit jeho plat. K tomu slouží pravidelné schůzky s manažerem, pololetní nebo roční hodnocení výkonnosti. To je opět jeden z těch momentů, jejichž přítomnost vysloveně nemotivuje, ale jejich nepřítomnost je velmi demotivující.
Z potřeby pořádku a přítomnosti pravidel vyplývá nutnost tato pravidla dodržovat, dodržovat normy přijaté v týmu, formální i neformální. Obecně bych to nazval potřebou „být dobrý“. Přítomnost této potřeby potvrzuje, že mikromanagement není nutný, ale spíše škodlivý. Stačí poskytnout člověku vše potřebné k práci, dát mu znalost souvislostí, priorit a poskytnout svobodu jednání a rozhodování na jeho úrovni. V takových podmínkách pocítí důvěru, možnost činit vlastní rozhodnutí, nést za ně zodpovědnost a bude moci odhalit svůj potenciál.
Dalším důležitým bodem, který je třeba připsat potřebě pořádku a absenci chaosu, je schopnost soustředit se na úkol, absence častých přepínání kontextu. Být programátorem vyžaduje čas a soustředění. Programátoři opravdu neradi naléhavě vzdávají jeden úkol a přecházejí na jiný. Nezbytnou součástí práce programátora je většinou nejen samotný vývoj kódu, ale také oprava chyb a pomoc s vyřizováním požadavků od zákazníků. Takové věci se vyplatí naplánovat předem tak, aby programátor mohl klidně a úplně dokončit práci na jednom úkolu, než přejde na jiný. Nejlepší možností je dát si příležitost naplánovat si práci sami, určit priority a nadcházející úkoly předem a vyčlenit si na práci na jednom typu úkolu dlouhé a dlouhé časové úseky. Toto téma je dobře popsáno v knize „Google – Site Reliability Engineering“, která dobře popisuje přístupy k plánování práce týmů, které zajišťují provoz a vývoj velkých, vysoce zatížených, poruchových systémů, i inženýrů, jejichž povolání spojuje vývoj softwaru a jeho podporu.
Chcete-li se pokračovat ...
Zdroj: www.habr.com