Эпіграф:
Муж, гледзячы на мурзатых дзяцей, кажа жонцы: ну, што, гэтых адмыем або новых нараджаем?
Пад катам другая частка артыкула нашага тымліда, а таксама дырэктара па развіцці прадукта RAS – Ігара Марната аб асаблівасцях матывацыі праграмістаў. З першай часткай артыкула можна азнаёміцца тут.
У першай частцы артыкула я крануў двух ніжніх узроўняў па пірамідзе Маслоу: фізіялагічных запатрабаванняў, запатрабаванняў у бяспецы, камфорце і сталасці і пераходжу да наступнага, трэцяга ўзроўня, а менавіта:
III - Запатрабаванне ў прыналежнасці і каханні
Я ведаў, што італьянская мафія называецца “Cosa Nostra”, але я быў моцна ўражаны, калі даведаўся, як перакладаецца “Cosa Nostra”. "Cosa Nostra" у перакладзе з італьянскага - "Наша справа". Вельмі ўдалы для матывацыі выбар назову (пакінем убаку род заняткаў, у дадзеным выпадку нас цікавіць толькі матывацыя). Чалавек звычайна хоча быць часткай каманды, рабіць нейкую вялікую, агульную, нашу справу.
Вялікае значэнне задавальненню патрэбнасці ў прыналежнасці і кахання надаюць у арміі, на флоце, у любых вялікіх ваенізаваных фарміраваннях. І, як мы бачым, у мафіі. Гэта вытлумачальна, бо трэба прымусіць людзей, у якіх мала агульнага, якія першапачаткова не складаюць каманду аднадумцаў, сабраны разам па закліку (не добраахвотна), маюць розныя ўзроўні адукацыі, розныя асабістыя каштоўнасці, прысвяціць літаральна сваё жыццё, са смяротнай рызыкай, нейкай агульнай справе , даверыць жыццё таварышу па зброі.
Гэта вельмі моцная матывацыя, для большасці людзей вельмі важна адчуваць прыналежнасць да чагосьці большага, ведаць, што ты частка сям'і, краіны, каманды. У войску гэтым мэтам служаць форма, розныя рытуалы, парады, маршы, сцягі, і гэтак далей. Прыкладна тыя ж фактары важныя для любой каманды. Важныя знакі, карпаратыўны брэнд і карпаратыўныя колеры, атрыбутыка і сувеніры.
Важна, каб значныя падзеі мелі сваё бачнае ўвасабленне, з якім яны маглі б асацыявацца. Цяпер для кампаніі мець сваю атрыбутыку, курткі, футболкі, і інш - хутчэй норма. Але важна таксама выдзяляць каманду ўнутры кампаніі. Мы часта выпускаем футболкі па выніках рэлізу, якія выдаюцца ўсім тым, хто да гэтага рэлізу датычны. Нейкія падзеі, сумесныя адзнакі ці мерапрыемствы ўсёй камандай - яшчэ адзін важны фактар матывацыі.
Апроч вонкавых атрыбутаў, на адчуванне прыналежнасці да каманды ўплываюць яшчэ некалькі момантаў.
Па-першае, наяўнасць агульнай мэты, якую ўсё разумеюць, падзяляюць адзнаку яе важнасці. Праграмісты звычайна хочуць разумець, што яны робяць крутую штуку, і гэтую крутую штуку яны робяць разам, усёй камандай.
Па-другое, у каманды павінна быць прастора для камунікацый, у якой ёсць уся каманда, і якая належыць толькі ёй (да прыкладу, чацік ў мэсэнджэры, перыядычныя камандныя сінкапы). Апроч працоўных пытанняў, нефармальныя зносіны, часам абмеркаванне вонкавых падзей, лёгкі offtop — усё гэта фармуе адчуванне агульнасці і каманды.
Па-трэцяе, я б вылучыў ўкараненне ўнутры каманды добрых інжынерных практык, імкненне да павышэння стандартаў, у параўнанні з тымі, якія прыняты ў кампаніі. Укараненне лепшых падыходаў, прынятых у індустрыі, спачатку ў камандзе, а потым і ў кампаніі ў цэлым, дае камандзе магчымасць адчуць, што яна ў чымсьці апярэджвае іншых, ідзе на чале, гэта стварае пачуццё прыналежнасці да крутой каманды.
На адчуванне прыналежнасці таксама ўплывае ўдзел каманды ў планаванні і кіраванні. Калі члены каманды ўцягнуты ў абмеркаванне мэт праекта, плана работ, стандартаў і інжынерных практык каманды, сумоўе новых супрацоўнікаў, у іх узнікае адчуванне ўдзелу, сумеснага валодання, уплыву на працу. Людзі нашмат больш ахвотна выконваюць рашэнні, прынятыя і агучаныя імі самімі, чым прапанаваныя са боку, нават калі яны практычна сугучныя.
Дні нараджэння, юбілеі, значныя падзеі ў жыцці калег - сумесная піца, невялікі падарунак ад каманды дораць цёплае пачуццё дачынення і ўдзячнасці. У некаторых кампаніях прынята дарыць невялікія памятныя знакі на 5, 10, 15 гадоў працы ў кампаніі. З аднаго боку, не думаю, што гэта так ужо моцна матывуе на новыя здзяйсненні. Але, відаць, амаль любому будзе прыемна, што пра яго не забыліся. Гэта адзін з тых выпадкаў, калі хутчэй за адсутнасць факту дэматывуе, чым яго наяўнасць матывуе. Пагодзіцеся, можа быць даволі крыўдна, калі linkedin з раніцы нагадаў і павіншаваў вас з 10-летнім юбілеем на месцы працы, а з кампаніі ніводны калега не павіншаваў і не ўспомніў.
Безумоўна, значным момантам з'яўляецца змена складу каманды. Зразумела, што нават калі пра прыход ці сыход кагосьці з каманды будзе абвешчана загадзя (напрыклад, у рассылцы па кампаніі ці камандзе, ці на камандным мітынгу), гэта нікога асабліва не матывуе на новыя здзяйсненні. Але калі ў адзін цудоўны дзень вы ўбачыце побач з сабой новага чалавека, ці не ўбачыце старога, гэта можа стаць сюрпрызам, і ў выпадку догляду - проста-такі непрыемным. Людзі не павінны знікаць цішком. Асабліва ў размеркаванай камандзе. Асабліва, калі Ваша праца залежыць ад калегі з іншага офіса, які раптам узяў і раптоўна знік. Такія моманты адназначна каштуюць асобнага інфармавання ўнутры каманды загадзя.
Важны фактар, які па-англійску называецца ўласнасць (літаральны пераклад "валоданне" не цалкам адлюстроўвае яго сэнс). Гэта не пачуццё ўладання, а, хутчэй, пачуццё адказнасці за свой праект, тое пачуццё, калі ты эмацыйна асацыюеш сябе з прадуктам і прадукт з сабой. Гэта прыкладна адпавядае малітве марпеха з фільма “Суцэльнаметалічная абалонка”: “Гэта мая вінтоўка. Такіх вінтовак шмат, але гэтая — мая. Мая вінтоўка - мой лепшы сябар. Яна - маё жыццё. Я мушу навучыцца валодаць ёю гэтак жа, як я валодаю сваім жыццём. Без мяне мая вінтоўка бескарысная. Без маёй вінтоўкі я бескарысны. Я павінен страляць з маёй вінтоўкі трапна. Я павінен страляць дакладней, чым вораг, які спрабуе забіць мяне. Я павінен застрэліць яго перш, чым ён застрэліць мяне. Ды будзе так… ”.
Калі чалавек працуе над прадуктам доўга, мае магчымасць несці поўную адказнасць за яго стварэнне і развіццё, бачыць, як з «нічога» узнікае працавальная рэч, як людзі ёй карыстаюцца, узнікае гэтае магутнае пачуццё. Прадуктовыя каманды, якія доўга працуюць разам над адным праектам, звычайна больш матываваныя і згуртаваныя, чым каманды, сабраныя на кароткі тэрмін і якія працуюць у рэжыме канвеера з пераключэннем з аднаго праекту над іншай, не маючы поўнай адказнасці за прадукт цалкам, ад пачатку да канца.
IV. Патрэба ў прызнанні
Добрае слова і котцы прыемна. Кожнага матывуе прызнанне важнасці зробленай ім працы, яе станоўчая ацэнка. Размаўляйце з праграмістамі, давайце ім перыядычны фідбэк, адзначайце добра зробленую працу. Калі ў вас вялікая і размеркаваная каманда, для гэтага выдатна падыдуць перыядычныя сустрэчы (тое, што завецца one to one), калі каманда зусім невялікая і працуе разам лакальна, такая магчымасць звычайна падаецца і без адмысловых сустрэч па календары (хоць перыядычны one to one усё роўна патрэбен, проста можна праводзіць яго радзей). Гэтая тэма добра раскрытая ў падкастах для мэнэджэраў на сайце manager-tools.com.
Пры гэтым варта трымаць у розуме культурныя адрозненні. Некаторыя падыходы, звыклыя для амерыканскіх калег, не заўсёды будуць працаваць з расейскімі. Узровень ветлівасці, прыняты ў штодзённых зносінах у камандах у заходніх краінах, спачатку здаецца залішнім праграмістам з Расіі. Некаторая прамалінейнасць, уласцівая расійскім калегам, можа ўспрымацца як грубасць іх калегамі з іншых краін. Гэта вельмі важна ў зносінах у міжнацыянальнай камандзе, на гэтую тэму шмат напісана, мэнэджэру такой каманды абавязкова трэба пра гэта памятаць.
Дэманстрацыя фіч, на якіх праграмісты паказваюць распрацаваныя за спрынт фічы – добрая практыка для рэалізацыі гэтага запатрабавання. Акрамя таго, што гэта выдатная магчымасць прачысціць камунікацыйныя каналы паміж камандамі, пазнаёміць продакт мэнэджараў і тэсціроўшчыкаў з новымі фічамі, гэта яшчэ і добрая магчымасць для распрацоўшчыкаў паказаць вынікі сваёй працы, пазначыць сваё аўтарства. Ну і папаліраваць навыкі публічнага выступу, вядома, што заўсёды не шкодна.
Добрай ідэяй будзе адзначаць прыкметны ўклад асоба якія праславіліся калег граматамі, памятнымі знакамі (хоць бы добрым словам) на сумесных тусоўках каманды. Такія граматы і памятныя знакі людзі звычайна вельмі шануюць, возяць з сабой пры пераездах, і наогул усяляк берагуць.
Каб адзначыць больш значны, працяглы ўклад у працу каманды, назапашаны вопыт і экспертызу, часта выкарыстоўваюць сістэму грэйдаў (зноў можна правесці аналаг з сістэмай воінскіх званняў у арміі, якая, акрамя забеспячэння субардынацыі, служыць і для гэтай мэты). Часта маладыя распрацоўшчыкі ўкалываюць з падвоенай сілай, каб атрымаць новыя зорачкі на пагоны (ie перайсці са прыступкі малодшага распрацоўніка на штатнага распрацоўніка, і г.д.).
Вельмі важна ведаць чаканні вашых людзей. Кагосьці хутчэй матывуе высокі грэйд, магчымасць называцца, скажам, архітэктарам, а хтосьці, наадварот, абыякавы да грэйдаў і званняў і будзе лічыць прыкметай прызнання з боку кампаніі павышэнне зарплаты. Майце зносіны з людзьмі, каб разумець, чаго яны хочуць, якія іх чаканні.
Дэманстрацыяй прызнання, праяўленнем больш высокага ўзроўню даверу з боку каманды можа служыць прадастаўленне большай свабоды дзеянняў або ўключэння ў новыя вобласці працы. Да прыкладу, пры назапашванні вызначанага досведу, дасягненні вызначаных вынікаў, праграміст апроч імплементацыі сваіх фіч у адпаведнасці са спецыфікацыяй можа працаваць над архітэктурай новых рэчаў. Або прыцягвацца да працы над новымі абласцямі, магчыма, непасрэдна не звязанымі з распрацоўкай - аўтаматызацыя тэставання, укараненне лепшых інжынерных практык, дапамога ў кіраванні рэлізамі, выступы на канферэнцыях, і г.д.
V. Патрэба ў спазнанні і самаактуалізацыі.
Многія праграмісты арыентаваны на розных этапах свайго жыцця на розныя віды дзейнасці ў праграмаванні. Камусьці падабаецца займацца машынным навучаннем, распрацоўваць новыя мадэлі звестак, пры гэтым чытаць для працы шмат навуковай літаратуры, ствараць новае з нуля. Іншаму бліжэй адладка і падтрымка існуючага прыкладання, пры якім трэба глыбока закопвацца ў існуючы код, днямі і тыднямі вывучаць логі, стектрэйсы і сеткавыя капчы, і новага кода амаль не пісаць.
Абодва працэсы патрабуюць вялікіх інтэлектуальных намаганняў, але практычны выхад у іх розны. Лічыцца, што праграмісты неахвотна займаюцца падтрымкай існуючых рашэнняў, яны хутчэй матываваны на распрацоўку новых. У гэтым ёсць разумнае збожжа. З іншага боку, самая матываваная і згуртаваная каманда, з якой я калі-небудзь працаваў, займалася менавіта падтрымкай існуючага прадукта, пошукам і ўхіленнем багаў пасля звароту каманды падтрымкі. Хлопцы літаральна жылі гэтай працай, былі гатовы выходзіць па суботах і нядзелях. Мы неяк ахвотна разбіраліся з чарговай тэрміновай і складанай праблемай ці то ўвечары 31 снежня, ці то днём 1 студзеня.
На такую высокую матывацыю паўплывалі некалькі фактараў. Па-першае, гэта была кампанія з гучным імем у індустрыі, каманда асацыявала сябе з ёй (гл. "Патрэбнасць у прыналежнасці"). Па-другое, яны былі апошняй мяжой, за імі нікога не было, прадуктовай каманды ўжо не было на той момант. Паміж імі і заказчыкамі было два ўзроўні падтрымкі, але, калі ўжо праблема даходзіла да іх - адыходзіць няма куды, ззаду нікога, уся карпарацыя на іх (чатыры маладых праграміста). Па-трэцяе, у гэтай вялікай кампаніі былі вельмі вялікія заказчыкі (урады краін, аўтамабільныя і авіяцыйныя канцэрны, і г.д.) і вельмі маштабныя інсталяцыі, на некалькі краін. Як следства, заўжды складаныя і цікавыя праблемы, простыя праблемы вырашаліся падтрымкай папярэдніх узроўняў. У чацвёртых, на матывацыю каманды вельмі моцна ўплываў прафесійны ўзровень каманды падтрымкі, з якімі яны ўзаемадзейнічалі (там былі вельмі дасведчаныя і тэхнічна крутыя інжынеры), і мы былі заўсёды ўпэўненыя ў якасці падрыхтаваных імі дадзеных, праведзенага аналізу, і т.д. У пятых, і, думаю, гэта найважнейшы момант — каманда была вельмі маладая, усе хлопцы былі ў пачатку сваёй кар'еры. Ім было цікава вывучаць вялікі і складаны прадукт, вырашаць новыя для іх сур'ёзныя праблемы ў новым для іх асяроддзі, яны імкнуліся прафесійна адпавядаць узроўню навакольных каманд, праблем, і замоўцаў. Праект аказаўся выдатнай школай, усе потым зрабілі добрую кар'еру ў кампаніі і сталі тэхнічнымі лідэрамі і старэйшымі мэнэджэрамі, адзін з хлопцаў зараз тэхнічны менеджэр у Amazon Web Services, іншы з часам перайшоў у Google, і гэты праект усе з іх да гэтага часу ўспамінаюць з цеплынёй .
Калі б гэтая каманда складалася з праграмістаў з 15-20 гадовым вопытам за спіной, матывацыя была б іншай. Узрост і досвед не з'яўляюцца, вядома, 100% вызначальнымі фактарамі, усё залежыць ад структуры матывацыі. У гэтым канкрэтным выпадку імкненне да спазнання і росту маладых праграмістаў дало выдатны вынік.
Увогуле, як мы ўжо неаднаразова згадвалі, вы павінны ведаць чаканні сваіх праграмістаў, разумець, хто з іх хацеў бы пашырыць або змяніць сферу дзейнасці і ўлічваць гэтыя чаканні.
Па-за пірамідамі Маслоу: бачнасць выніку, гейміфікацыя і спаборнічанне, no bullshit
Ёсць яшчэ тры важныя моманты адносна матывацыі праграмістаў, пра якія абавязкова трэба згадаць, але прыцягваць іх да мадэлі запатрабаванняў Маслоу было б занадта штучным.
Першае - бачнасць і блізкасць выніку.
Распрацоўка софту - гэта звычайна марафон. Вынікі намаганняў у R&D становяцца бачныя праз месяцы, часам гады. Цяжка ісці да мэты, якая знаходзіцца далёка за гарызонтам, колькасць працы жахае, мэта далёка, не ясная і не бачная, "ноч цёмная і поўная жахаў". Лепш разбіць дарогу да яе на часткі, пракласці шлях да бліжэйшага дрэва, якое відаць, дасягальна, абрысы ясныя, і яно недалёка ад нас - і ісці да гэтай блізкай мэты. Мы хочам зрабіць намаганне даўжынёй у некалькі дзён ці тыдняў, атрымаць і ацаніць вынік, потым рухацца далей. Таму працу варта разбіваць на маленькія часткі (гэтай мэты добра служаць спрынты ў agile). Выканалі частку працы - зафіксавалі, выдыхнулі, абмеркавалі, пакаралі вінаватых, узнагародзілі недатычных - можна пачынаць наступны цыкл.
Такая матывацыя да нейкай ступені аналагічная той, што адчуваюць гульцы пры праходжанні камп'ютарных гульняў: яны перыядычна атрымліваюць медалі, акуляры, бонусы пры праходжанні кожнага ўзроўню, гэта можна назваць "дофамінавай матывацыяй".
Пры гэтым бачнасць выніку важная літаральна. Закрытая фіча ў спісе павінна стаць зялёнай. Калі код напісаны, пратэставаны, смерджаны, але бачнай для праграміста змены ў візуальным статусе няма - ён будзе адчуваць няскончанасць, не будзе пачуцця завершанасці. У адной з каманд у нашай сістэме кантролю версій кожны патч праходзіў тры паслядоўныя стадыі - білд сабраўся і тэсты прайшлі, патч прайшоў код рэўю, патч смержен. Кожная стадыя візуальна адзначалася зялёнай галачкай ці чырвоным крыжыкам. Неяк адзін з распрацоўшчыкаў паскардзіўся, што код рэўю доўжыцца занадта доўга, калегам трэба паскорыцца, патчы вісяць па некалькі дзён. Я спытаў, што гэта, па сутнасці, для яго мяняе? Бо калі код напісаны, білд сабраўся і тэсты мінулі, яму не трэба зважаць на адпраўлены патч, калі не будзе зацемак. Калегі самі зробяць рэўю і смержаць (калі, зноў жа, няма заўваг). Ён адказаў - "Ігар, я хачу хутчэй атрымаць свае тры зялёныя галачкі".
Другі момант - гейміфікацыя і спаборнічанне.
Пры распрацоўцы аднаго з прадуктаў перад нашай інжынернай камандай стаяла мэта заняць прыкметную пазіцыю ў супольнасці аднаго з прадуктаў з адчыненым зыходным кодам, увайсці ў top-3. На той момант аб'ектыўнага спосабу ацэньваць чыю-небудзь прыкметнасць у супольнасці не было, кожная з буйных якія ўдзельнічаюць кампаній магла заяўляць (і перыядычна заяўляла), што яна кантрыб'ютар нумар адзін, але не было ніякага рэальнага спосабу параўнаць уклад удзельнікаў паміж сабой, ацаніць яго дынаміку ва часу. Адпаведна, не было і спосабу паставіць перад камандай мэту, якую можна было б вымераць у нейкіх папугаях, ацаніць ступень яе дасягнення, і г.д. Для вырашэння гэтай праблемы наша каманда распрацавала інструмент вымярэння і візуалізацыі ўкладу кампаній і індывідуальных кантрыбутараў . З пункту гледжання матывацыі, гэта аказалася проста бомбай. Не толькі інжынеры і каманды ўвесь час сачылі за сваім прагрэсам і прагрэсам калег і канкурэнтаў. Топ-мэнэджмент нашай кампаніі і ўсіх буйных канкурэнтаў таксама пачынаў свой дзень са stackalytics. Усё стала вельмі празрыста і наглядна, кожны мог уважліва адсочваў свой прагрэс, параўноўваў з калегамі і г.д. Стала зручна і проста ставіць мэты інжынерам, менеджэрам і камандам.
Важны момант, які ўзнікае пры ўкараненні любой сістэмы колькасных метрык - як толькі вы іх укаранілі, сістэма аўтаматычна імкнецца паставіць у раздзел кута дасягненне гэтых колькасных метрык, у шкоду якасным. Да прыкладу, у якасці адной з метрык выкарыстоўваецца колькасць выкананых рэўю кода. Відавочна, код рэўю можна рабіць па-рознаму, можна выдаткаваць некалькі гадзін на стараннае рэўю і праверку складанага патча з праверкай тэстаў, прагонам на сваім стэндзе, зверкай з дакументацыяй, і атрымаць плюс адно рэўю ў карму, альбо ўсляпую за пару хвілін праклікаць пару дзясяткаў патчаў, паставіць кожнаму 1 і атрымаць у карму плюс дваццаць. Былі камічныя выпадкі, калі інжынеры пракліквалі патчы настолькі хутка, што ставілі 1 аўтаматычным патчам ад CI сістэмы. Як мы потым жартавалі, "go, go, jenkins". У выпадку з камітамі таксама было шмат дзеячаў, якія праходзілі па кодзе інструментамі фарматавання кода, рэдагавалі каментары, мянялі кропкі на коскі і такім чынам прапампоўвалі сабе карму. Дужацца з гэтым досыць проста: уключаем разумны сэнс і акрамя колькасных метрык выкарыстоўваны таксама сутнасныя, якасныя. Ступень выкарыстання вынікаў працы каманды, колькасць знешніх кантрыбютараў, узровень пакрыцця тэстамі, стабільнасць модуляў і ўсяго прадукта, вынікі scale і performance тэсціравання, колькасць інжынераў, якія атрымалі пагоны core reviewer, факт прыняцця праектаў у склад core projects кам'юніці, захаванне крытэрыяў розных этапаў інжынернага працэсу. усе гэтыя і многія іншыя фактары падлягаюць ацэнцы нараўне з простымі колькаснымі метрыкамі.
І нарэшце, трэці момант - No bullshit.
Распрацоўнікі - людзі вельмі разумныя, і па родзе дзейнасці экстрэмальна лагічныя. Яны па 8-10 гадзін у дзень будуюць доўгія і складаныя лагічныя ланцужкі, таму на лёце бачаць уразлівасці ў іх. Робячы нешта, яны, як і ўсе, жадаюць разумець, навошта яны гэта робяць, што зменіцца ў лепшы бок. Мегаважна, каб мэты, якія вы ставіце перад камандай, былі сумленнымі і рэальнымі. Паспрабаваць прадаць дрэнную ідэю камандзе праграмістаў - дрэнная ідэя. Ідэя дрэнная, калі вы не верыце ў яе самі, альбо, у крайнім выпадку, у вас няма ўнутранага стану disagree and commit (я не згодзен, але я зраблю). Мы неяк укаранялі сістэму матывацыі ў кампаніі, адным з элементаў якой была электронная сістэма для прадастаўлення фідбэка. Уклалі кучу грошай, звазілі людзей на трэнінгі ў Амерыку, увогуле, уклаліся па поўнай. Неяк у размове пасля трэнінгу адзін з менеджэраў сказаў сваім падначаленым: «Ідэя нядрэнная, здаецца, будзе працаваць. Я сам вам даваць электронны фідбэк не буду, але вы сваім людзям давайце, і з іх патрабуйце». Усё, далей можна было ўжо нічога не ўкараняць. Задума, зразумела, скончылася нічым.
Крыніца: habr.com