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

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

По-долу е дискусията на нашия ръководител на екипа, както и на директора за развитие на продуктите на RAS, Игор Марнат, относно особеностите на мотивирането на програмистите.

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

Нека разгледаме основните фактори за мотивация на програмистите (екипи от програмисти), използвайки пирамидата на Маслоу за яснота и структуриране на презентацията. Ако не сте чували за пирамидата на Маслоу, това не е безспорна, но много популярна и илюстративна теория на американския психолог Ейбрахам Харолд Маслоу, който предлага теория за личната мотивация, основана на йерархията на човешките потребности (вижте снимката по-долу).

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

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

И така, нека сега да преминем през пирамидата на Маслоу и да разгледаме нейните нива, приложени към управлението на екип от програмисти.

I: Физиологични, биологични нужди:

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

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

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

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

II. Необходимост от безопасност, комфорт, последователност на условията на живот:

Преди 70 години наличието на печка в автомобила можеше да бъде мотивиращ фактор при избора на автомобил, тогава това беше над нормата и беше признак на лукс. Сега дори липсата на климатик е глупост и наличието му, разбира се, няма да бъде мотивиращ фактор при избора на кола. Значи преди 10-15 години удобен офис, добра техника, вкусно кафе, фитнес, гъвкаво работно време и т.н. може да са добри мотивиращи фактори, но сега това е по-скоро норма за работата на добър програмист. В същото време липсата им отново ще бъде демотивираща.

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

Цената на времето на един програмист вече е значително по-висока от цената на хардуера, върху който той работи. Два или три монитора, мощни компютри, удобно работно място за всеки разработчик - трябва да са норма във всяка компания. Тази тема е добре засегната в една от статиите на Джоел Сполски „Тестът на Джоел: 12 стъпки към по-добър код.“

Физическият компонент на комфорта е най-основният и прост; сега нека поговорим за останалото.

В много компании нормата за програмистите е гъвкав работен график и липса на дрескод. Това е добре и правилно, ако спецификата на работата на екипа го позволява (например няма срещи с клиенти, политици или банкери).

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

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

Първо, липсата на хаос, структура и ред – екипът трябва да разбере кой за какво отговаря, как са разпределени ролите, какво трябва да се направи, към кого, кога, какви изисквания са в основата на продукта, какви са очакванията на ръководството и клиента... Повечето от това трябва да бъде формално описано, всичко трябва да се обсъжда периодично. Без обсъждане и периодично използване описанията не работят. Добра практика е те периодично да се обсъждат и актуализират въз основа на резултатите от следсмъртния анализ след освобождаването.

Второ, спокойна и приятелска атмосфера. Всички прекарваме по-голямата част от времето си на работа и искаме да го правим без стрес, конфликти или страх. Екипът за разработка обикновено работи под натиск от графици и клиенти. Никой не се нуждае от допълнителен стрес от колеги и началници. Атмосферата в екипа, като цяло самият факт, че една група разработчици може да се нарече и да бъде „екип“ е пряка и важна отговорност на мениджъра, една от най-важните средносрочни и дългосрочни задачи. Ето защо е важно мениджърът да работи по-специално с конфликтите в екипа и да не оставя развитието им да върви по своя път. Управлението на конфликти е отделна тема, която заслужава отделно изследване.

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

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

Екипите за разработка често се наричат ​​R&D (изследване и развитие), като изследванията съставляват значителна част от работата. Това е частта, която обикновено е трудна за програмиране и планиране, иначе не би било изследване. Важно е отборът да има право на грешки, да поема инициатива, да опитва различни варианти, които може да завършат или да не завършат с успех. Грешките са нормална част от работата, те не могат да бъдат избегнати, но можете да изучавате, анализирате, да се поучите от тях за в бъдеще и да продължите напред. Принципът на 5 защо, възникнал в Toyota, е добър начин да стигнете до първопричината за даден проблем. Наказването на грешки е чудесен начин да създадете атмосфера на страх и несигурност. Единственото изключение е, когато въз основа на резултатите от анализа се окаже, че грешката е причинена от непрофесионално отношение към работата, в този случай може да се наложи да се вземат кадрови решения.

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

В трудна ситуация карането в движение е лесно, много лесно, но след това движението назад е трудно и утайката остава за дълго време. Нека ви дам прост пример от скорошен опит. Един от мениджърите на екипи спешно се нуждаеше от коментари за някакъв проблем с клиент от мениджър от сроден екип в друга държава. Той пингва колега в месинджъра, изчаква 15 минути, пингва отново, след което 15 минути по-късно отива в голям чат, в който са и другите мениджъри, и леко атакува колегата, с формулировка от рода на: „тъй като не благоволете да ми отговорите, може би и въпросът не е толкова спешен? Накрая се оказа, че корпоративният ни месинджър е леко тъп, а колегата изобщо не видя въпроса. Трябваше да се извиня. Като цяло е по-добре да започнете с доброто. Винаги е възможно да направите лоша грешка и да се сблъскате с проблеми по-късно; няма проблем с това (въпреки че не трябва да го правите). Като цяло, за повече от 20 години работа в нашия бранш, съм срещал наистина злонамерен колега само веднъж (!). За щастие се разделихме доста бързо. Оказва се, че в по-голямата част от случаите е правилно да се приеме, че колегите искат най-доброто, доколкото разбират контекста.

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

Между другото, започнах да говоря за екипа за поддръжка и си спомних един каноничен пример за мен. Веднъж един от клиентите в Америка имаше проблем с продукта, един от инженерите от екипа за поддръжка, който работеше по внедряването му (командирован от Русия), остана след работа, за да помогне, но проблемът не беше решен и не беше решен. Като цяло той се забави и седеше там почти до сутринта. По това време мениджърите на клиента ескалираха проблема, идентифицираха неговата критичност за тях и напуснаха работа вечерта. Процесът на ескалация вече набираше скорост в различна часова зона, мениджърите по поддръжката в Русия започнаха да се опитват да помогнат, поради определени трудности в комуникацията с офиса на клиента (VPN, проблеми с връзката, затруднения с обаждания между държави, ...) те не знаех, че човекът вече е в затвора в офиса и решава проблема, и се опита да го намери. Откриха го чак сутринта (американски), когато проблемът вече беше практически решен и продуктът работеше. Веднага започнаха да казват, че какво, по дяволите, клиентът има такава ескалация, нищо не работи, къде си, не можем да те намерим и т.н. Излишно е да казвам, че в резултат на подобно поведение човекът беше силно демотивиран. Организацията на работата на разпределен екип е отделна голяма тема, но е важно да запомните две неща. Първо, комуникациите и атмосферата са много важни, от това зависи успехът на работата. Второ, това не работи само по себе си; трябва да се разглежда отделно и задълбочено.

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

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

Друг важен момент, който трябва да се припише на необходимостта от ред и липсата на хаос, е способността да се концентрирате върху дадена задача, липсата на честа смяна на контекста. Да бъдеш програмист изисква време и фокус. Програмистите наистина не обичат спешно да се отказват от една задача и да преминават към друга. Необходима част от работата на програмиста обикновено е не само действителното разработване на кода, но и коригиране на грешки и помощ при обработката на заявки от клиенти. Струва си да планирате такива неща предварително, по такъв начин, че да позволите на програмиста спокойно и напълно да завърши работата по една задача, преди да премине към друга. Най-добрият вариант е да си дадете възможност сами да планирате работата си, като предварително идентифицирате приоритетите и предстоящите задачи, разпределяйки дълги, продължителни периоди от време за работа по един тип задачи. Тази тема е добре описана в книгата „Google – Инженеринг за надеждност на сайта”, който добре описва подходите за планиране на работата на екипи, които осигуряват работата и развитието на големи, високо натоварени, отказоустойчиви системи, както и инженери, чиято професия съчетава разработка на софтуер и неговата поддръжка.

За да се продължи ...

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