Управление на екип от програмисти: как и как правилно да ги мотивирате? Част две

мото:
Съпругът, гледайки мръсните деца, казва на жена си: добре, ще ги измием ли или ще родим нови?

Под изрезката е втората част от статия от ръководителя на нашия екип, както и директора за продуктово развитие на RAS Игор Марнат, за особеностите на мотивирането на програмистите. Първата част на статията можете да намерите тук - habr.com/ru/company/parallels/blog/452598

В първата част на статията се спрях на двете долни нива на пирамидата на Маслоу: физиологични нужди, потребности от безопасност, комфорт и постоянство и преминах към следващото, трето ниво, а именно:

III - Нужда от принадлежност и любов

Знаех, че италианската мафия се нарича "Коза Ностра", но бях много впечатлен, когато разбрах как се превежда "Коза Ностра". „Коза Ностра” в превод от италиански означава „Нашият бизнес”. Изборът на име е много сполучлив за мотивация (да оставим настрана професията, в случая ни интересува само мотивацията). Човек обикновено иска да е част от екип, да прави някакъв голям, общ, наш бизнес.

Отдава се голямо значение на задоволяването на потребността от принадлежност и любов в армията, флота и всякакви големи паравоенни формирования. И, както виждаме, в мафията. Това е разбираемо, защото трябва да принудите хора, които имат малко общо, които първоначално не формират екип от съмишленици, които са събрани чрез набор (а не доброволно), които имат различни нива на образование, различни лични ценности , буквално да посветят живота си, със смъртен риск, на някаква обща кауза, поверете живота си на другар по оръжие.

Това е много силна мотивация, за повечето хора е изключително важно да се чувстват като част от нещо по-голямо, да знаят, че са част от семейство, държава, екип. В армията за тези цели служат униформи, различни ритуали, паради, маршове, знамена и т.н. Приблизително едни и същи фактори са важни за всеки отбор. Важни са символи, корпоративна марка и корпоративни цветове, атрибути и сувенири.

Важно е значимите събития да имат свое видимо въплъщение, с което да бъдат свързани. В днешно време е по-скоро норма една компания да има собствени стоки, якета, тениски и т.н. Но също така е важно да подчертаете екипа в компанията. Често пускаме тениски въз основа на резултатите от изданието, които се дават на всички участници в изданието. Някои събития, съвместни тържества или дейности с целия екип са друг важен фактор за мотивация.

В допълнение към външните атрибути, няколко други фактора влияят върху чувството за принадлежност към екип.
Първо, наличието на обща цел, която всички разбират и споделят оценка за нейната важност. Програмистите обикновено искат да разберат, че правят готино нещо и го правят заедно, като екип.
Второ, екипът трябва да има комуникационно пространство, в което присъства целият екип и което принадлежи само на него (например чат в месинджъра, периодични екипни синхронизации). В допълнение към работните въпроси, неформалното общуване, понякога обсъждане на външни събития, лек офтоп - всичко това създава усещане за общност и екип.
На трето място бих откроил въвеждането на добри инженерни практики в екипа, желанието за повишаване на стандартите спрямо приетите в компанията. Прилагането на най-добрите подходи, приети в индустрията, първо в екипа, а след това и в компанията като цяло, дава възможност на екипа да почувства, че по някакъв начин изпреварва другите, води пътя, това създава чувство за принадлежност на готин екип.

Чувството за принадлежност се влияе и от участието на екипа в планирането и управлението. Когато членовете на екипа участват в обсъждането на целите на проекта, работните планове, екипните стандарти и инженерните практики и интервюирането на нови служители, те развиват чувство за участие, споделена собственост и влияние върху работата. Хората са много по-склонни да изпълняват решения, взети и изразени от самите тях, отколкото тези, предложени от други, дори и да са практически съгласувани.

Рождени дни, годишнини, значими събития в живота на колегите - обща пица, малък подарък от екипа дават топло усещане за съпричастност и благодарност. В някои компании е обичайно да се дават малки мемориални знаци за 5, 10, 15 години работа в компанията. От една страна, не мисля, че това ме мотивира толкова много за нови постижения. Но очевидно почти всеки ще бъде доволен, че не е забравил за него. Това е един от случаите, когато липсата на факт демотивира, а не мотивира наличието му. Съгласете се, може да бъде доста жалко, ако LinkedIn ви напомни сутринта и ви поздрави за 10-годишнината на работното ви място, но нито един колега от компанията не ви поздрави или не ви запомни.

Разбира се, важен момент е промяната в състава на отбора. Ясно е, че дори пристигането или напускането на някой от екипа да бъде обявено предварително (например в бюлетин на компания или екип или на среща на екипа), това не мотивира особено никого за нови постижения. Но ако в един хубав ден видите нов човек до себе си или не видите стар, това може да бъде изненада, а ако си тръгнете, направо неприятно. Хората не трябва да изчезват тихо. Особено в разпределен екип. Особено ако работата ви зависи от колега от друг офис, който внезапно се появи и изчезна. За такива моменти определено си струва да информирате екипа отделно предварително.

Важен фактор, който на английски се нарича собственост (буквалният превод на „притежание“ не отразява напълно значението му). Това не е чувство за собственост, а по-скоро чувство за отговорност за вашия проект, това чувство, когато емоционално се свързвате с продукта и продукта със себе си. Това приблизително съответства на молитвата на морския пехотинец във филма „Full Metal Jacket“: „Това е моята пушка. Има много такива пушки, но тази е моя. Моята пушка е моят най-добър приятел. Тя е моят живот. Трябва да се науча да го притежавам по същия начин, по който притежавам живота си. Без мен пушката ми е безполезна. Безполезен съм без пушката си. Трябва да стрелям право с пушката си. Трябва да стрелям по-точно от врага, който се опитва да ме убие. Трябва да го застрелям, преди той да застреля мен. Нека бъде така…“.

Когато човек работи върху продукт дълго време, има възможността да носи пълната отговорност за неговото създаване и развитие, да види как едно работещо нещо възниква от „нищото“, как хората го използват, възниква това силно усещане. Продуктовите екипи, които работят заедно дълго време по един проект, обикновено са по-мотивирани и сплотени от екипи, които са събрани за кратък период от време и работят в режим на поточна линия, преминавайки от един проект към друг, без пълна отговорност за целия продукт. , от началото до края.

IV. Нужда от признание

Добрата дума също радва котката. Всеки е мотивиран от признаването на важността на свършената работа и нейната положителна оценка. Говорете с програмисти, давайте им периодична обратна връзка, празнувайте добре свършената работа. Ако имате голям и разпределен екип, периодичните срещи (наричани едно към едно) са идеални за това; ако екипът е много малък и работи заедно на местно ниво, тази възможност обикновено се предоставя без специални срещи в календара (макар и периодични). до един е всичко. Все още е необходимо, просто можете да го правите по-рядко). Тази тема е добре покрита в подкасти за мениджъри на manager-tools.com.

Въпреки това си струва да имате предвид културните различия. Някои подходи, познати на американските колеги, не винаги ще работят с руските. Нивото на учтивост, прието в ежедневната комуникация в екипите в западните страни, първоначално изглежда прекомерно за програмистите от Русия. Известна прямота, характерна за руските колеги, може да се възприеме като грубост от техните колеги от други страни. Това е много важно в комуникацията в междуетнически екип, много е писано по тази тема, мениджърът на такъв екип трябва да помни това.

Демонстрациите на функции, при които програмистите показват функции, разработени по време на спринт, са добра практика за реализиране на тази нужда. В допълнение към факта, че това е отлична възможност за изчистване на каналите за комуникация между екипите, запознаване на продуктови мениджъри и тестери с нови функции, това е и добра възможност за разработчиците да покажат резултатите от своята работа и да посочат своето авторство. Е, и полирайте уменията си за публично говорене, разбира се, което никога не е вредно.

Би било добра идея да отпразнувате значителния принос на особено отличени колеги с грамоти, паметни знаци (поне добра дума) на съвместни екипни срещи. Хората обикновено много ценят такива сертификати и мемориални знаци, вземат ги със себе си, когато се преместват, и като цяло се грижат за тях по всякакъв възможен начин.

За отбелязване на по-значим, дългосрочен принос в работата на екипа, натрупан опит и експертиза, често се използва степенна система (отново може да се направи аналогия със системата на военните звания в армията, която освен за осигуряване на субординация, също служи за тази цел). Често младите разработчици работят два пъти повече, за да получат нови звезди на презрамките си (т.е. преминават от младши програмист към програмист на пълен работен ден и т.н.).

Познаването на очакванията на вашите хора е от решаващо значение. Някои са по-склонни да бъдат мотивирани от висока оценка, възможността да бъдат наречени, да речем, архитект, докато други, напротив, са безразлични към степени и титли и ще считат увеличението на заплатата за знак за признание от компанията . Общувайте с хората, за да разберете какво искат и какви са техните очаквания.

Демонстрация на признание, по-високо ниво на доверие от страна на екипа, може да се даде чрез даване на повече свобода на действие или участие в нови области на работа. Например, след натрупване на определен опит и постигане на определени резултати, програмистът, в допълнение към внедряването на своите функции в съответствие със спецификацията, може да работи върху архитектурата на нови неща. Или се включете в нови области, които може да не са пряко свързани с разработката - автоматизация на тестове, прилагане на най-добри инженерни практики, помощ при управлението на версиите, изказвания на конференции и т.н.

V. Потребност от познание и самоактуализация.

Много програмисти са фокусирани върху различни видове дейности по програмиране на различни етапи от живота си. Някои хора обичат да се занимават с машинно обучение, да разработват нови модели на данни, да четат много научна литература за работа и да създават нещо ново от нулата. Друг е по-близо до отстраняването на грешки и поддръжката на съществуващо приложение, в което трябва да копаете дълбоко в съществуващия код, да изучавате регистрационни файлове, проследяване на стекове и мрежови captcha дни и седмици и почти да не пишете нов код.

И двата процеса изискват големи интелектуални усилия, но практическият им резултат е различен. Смята се, че програмистите не са склонни да поддържат съществуващи решения, те са по-скоро мотивирани да разработват нови. В това има зрънце мъдрост. От друга страна, най-мотивираният и обединен екип, с който някога съм работил, беше посветен на поддръжката на съществуващ продукт, намирането и коригирането на грешки, след като екипът за поддръжка се свърже с тях. Момчетата буквално живееха за тази работа и бяха готови да излизат събота и неделя. Веднъж с нетърпение се заехме с друг неотложен и сложен проблем, или вечерта на 31 декември, или следобед на 1 януари.

Няколко фактора повлияха на тази висока мотивация. Първо, това беше компания с голямо име в индустрията, екипът се асоциира с нея (вижте „Необходимостта от присъединяване“). Второ, те бяха последната граница, нямаше никой зад тях, нямаше продуктов екип по това време. Между тях и клиентите имаше две нива на поддръжка, но ако проблемът ги стигнеше, нямаше къде да се оттеглят, никой не стоеше зад тях, цялата корпорация беше върху тях (четирима млади програмисти). Трето, тази голяма компания имаше много големи клиенти (правителства на държави, автомобилни и авиационни концерни и т.н.) и много мащабни инсталации в няколко страни. В резултат на това винаги сложни и интересни проблеми, прости проблеми бяха решени с помощта на предишни нива. Четвърто, мотивацията на екипа беше силно повлияна от професионалното ниво на екипа за поддръжка, с който те взаимодействаха (имаше много опитни и технически способни инженери) и ние винаги бяхме уверени в качеството на данните, които подготвиха, анализа, който извършиха и т.н. Пето, и смятам, че това е най-важният момент - отборът беше много млад, всички момчета бяха в началото на кариерата си. Те се интересуваха от изучаването на голям и сложен продукт, решаването на сериозни проблеми, които бяха нови за тях в нова среда, те се стремяха да отговарят професионално на нивото на заобикалящите ги екипи, проблеми и клиенти. Проектът се оказа отлично училище, всички по-късно направиха добра кариера в компанията и станаха технически лидери и висши мениджъри, едно от момчетата сега е технически мениджър в Amazon Web Services, другото в крайна сметка се премести в Google и всички от тях все още си спомнят този проект с топлина.

Ако този екип се състоеше от програмисти с 15-20 години опит зад гърба си, мотивацията щеше да е друга. Възрастта и опитът, разбира се, не са 100% определящи фактори, всичко зависи от структурата на мотивацията. В конкретния случай желанието за знания и израстване на младите програмисти даде отлични резултати.

Като цяло, както вече споменахме няколко пъти, трябва да знаете очакванията на вашите програмисти, да разберете кой от тях би искал да разшири или промени сферата си на дейност и да вземете предвид тези очаквания.

Отвъд пирамидата на Маслоу: видимост на резултатите, геймификация и конкуренция, без глупости

Има още три важни момента по отношение на мотивацията на програмистите, които определено трябва да бъдат споменати, но включването им в модела на нуждите на Маслоу би било твърде изкуствено.

Първият е видимостта и близостта на резултата.

Разработката на софтуер обикновено е маратон. Резултатите от усилията за научноизследователска и развойна дейност стават видими след месеци, понякога години. Трудно е да се върви към цел, която е далеч отвъд хоризонта, обемът на работата е ужасяващ, целта е далечна, неясна и невидима, „нощта е тъмна и пълна с ужаси“. По-добре е да разбием пътя до него на части, да направим пътека до най-близкото дърво, което е видимо, достъпно, очертанията са ясни и не е далеч от нас - и отидете до тази близка цел. Искаме да положим усилия от няколко дни или седмици, да получим и оценим резултата, след което да продължим. Затова си струва да разделите работата на малки части (спринтовете в пъргавината служат добре за тази цел). Свършихме част от работата - записахме, издишахме, обсъдихме, наказахме виновните, наградихме невинните - можем да започнем следващия цикъл.

Тази мотивация е до известна степен подобна на това, което играчите изпитват, когато завършват компютърни игри: те периодично получават медали, точки, бонуси, докато завършват всяко ниво; това може да се нарече „допаминова мотивация“.

В същото време видимостта на резултата е буквално важна. Затворен елемент в списъка трябва да стане зелен. Ако кодът е написан, тестван, пуснат, но няма промяна във визуалния статус, видим за програмиста, той ще се почувства незавършен, няма да има усещане за завършеност. В един от екипите в нашата система за контрол на версиите всеки пач премина през три последователни етапа - компилацията беше сглобена и тестовете преминаха, пачът премина през преглед на кода, пачът беше обединен. Всеки етап беше визуално маркиран със зелена отметка или червен кръст. Веднъж един от разработчиците се оплака, че прегледът на кода отнема твърде много време, колегите трябваше да ускорят, пачовете висят няколко дни. Попитах какво всъщност променя това за него? В крайна сметка, когато кодът е написан, компилацията е сглобена и тестовете са преминали, той не трябва да обръща внимание на изпратения пач, ако няма коментари. Самите колеги ще го прегледат и одобрят (ако пак няма забележки). Той отговори: „Игор, искам да получа моите три зелени отметки възможно най-скоро.“

Втората точка е геймификацията и конкуренцията.

При разработването на един от продуктите, нашият инженерен екип имаше за цел да заеме видно място в общността на един от продуктите с отворен код, за да влезе в топ 3. По това време нямаше обективен начин да се оцени видимостта на някого в общността; всяка от големите участващи компании можеше да твърди (и периодично твърдеше), че е сътрудник номер едно, но нямаше реален начин да се сравнят приносите на участниците помежду си, за да оценят динамиката му във времето. Съответно нямаше как да се постави цел на отбора, която да се измери в някои папагали, да се оцени степента на нейното постигане и т.н. За да реши този проблем, нашият екип разработи инструмент за измерване и визуализиране на приноса на компании и индивидуални сътрудници www.stackalytics.com. От мотивационна гледна точка се оказа просто бомба. Не само инженерите и екипите непрекъснато наблюдаваха напредъка си и напредъка на своите колеги и конкуренти. Висшето ръководство на нашата компания и всички големи конкуренти също започнаха деня си със stackalytics. Всичко стана много прозрачно и визуално, всеки можеше внимателно да следи напредъка си, да сравнява с колеги и т.н. Стана удобно и лесно за инженери, мениджъри и екипи да си поставят цели.

Важен момент, който възниква при внедряването на всяка система от количествени показатели е, че веднага след като ги внедрите, системата автоматично се стреми да приоритизира постигането на тези количествени показатели, в ущърб на качествените. Например броят на завършените прегледи на кода се използва като един от показателите. Очевидно прегледът на кода може да се извърши по различни начини, можете да прекарате няколко часа в задълбочен преглед и проверка на сложна корекция с тестове за проверка, да го пуснете на вашата пейка, да проверите с документация и да получите плюс един преглед във вашата карма, или щракнете сляпо върху няколко дузини лепенки за няколко минути, дайте на всяка +1 и вземете плюс двадесет в кармата. Имаше комични случаи, когато инженерите щракаха върху пачове толкова бързо, че дадоха +1 на автоматичните пачове от CI системата. Както по-късно се шегувахме, „давай, давай, Дженкинс“. В случая с ангажиментите също имаше много хора, които преминаха през кода с инструменти за форматиране на код, редактираха коментари, промениха точките на запетаи и по този начин изпомпваха кармата си. Справянето с това е съвсем просто: ние използваме здрав разум и в допълнение към количествените показатели използваме и съществени, качествени. Степента на използване на резултатите от работата на екипа, броят на външните сътрудници, нивото на тестово покритие, стабилността на модулите и целия продукт, резултатите от тестването на мащаба и производителността, броят на инженерите, които са получили рамото на основния рецензент каишки, фактът, че проектите са приети в общността на основните проекти, съответствие с критериите на различни етапи от инженерния процес - всички тези и много други фактори трябва да бъдат оценени заедно с прости количествени показатели.

И накрая, третата точка - Без глупости.

Разработчиците са много умни хора и изключително логични в работата си. Те прекарват 8-10 часа на ден в изграждането на дълги и сложни логически вериги, така че виждат уязвимостите в тях в движение. Когато правят нещо, те, както всички останали, искат да разберат защо го правят, какво ще се промени към по-добро. Изключително важно е целите, които поставяте пред екипа си, да са честни и реалистични. Опитът да се продаде лоша идея на програмен екип е лоша идея. Една идея е лоша, ако вие самите не вярвате в нея или, в краен случай, нямате вътрешното състояние на несъгласие и обвързване (не съм съгласен, но ще го направя). Веднъж внедрихме система за мотивация в една компания, един от елементите на която беше електронна система за обратна връзка. Инвестираха много пари, водеха хора на обучение в Америка, въобще инвестираха максимално. Веднъж в разговор след обучението един от ръководителите каза на подчинените си: „Идеята не е лоша, изглежда ще проработи. Аз лично няма да ви дам електронна обратна връзка, но вие я дайте на вашите хора и я изисквайте от тях. Това е всичко, нищо не може да бъде приложено по-нататък. Идеята, разбира се, завърши с нищо.

Източник: www.habr.com