Епіграф:
Чоловік, дивлячись на замурзаних дітей, каже дружині: ну що, цих відмиємо чи нових нарожаєм?
Під катом міркування нашого тимліда, а також директора з розвитку продукту RAS Ігоря Марната про особливості мотивації програмістів.
Секрет успіху у створенні класних програмних продуктів відомий: візьміть команду крутих програмістів, дайте команді класну ідею і не заважайте команді працювати. Круті розробники - хлопці рідкісні та затребувані. Деякі рекрутери навіть кажуть, що у них складається таке враження, що народити крутого програміста простіше, ніж найняти його з ринку. Крім труднощів із наймом як таким, досвід кожного конкретного розробника, його знання про існуючий продукт та історію його розробки часто незамінні або заповнюються важко і довго. Тому якщо вам пощастило, і у вас вже є крута команда програмістів, важливо працювати над їхньою мотивацією. Найняти, навчити нових розробників, зробити з них команду — майже так важко і довго, як народити та виростити дітей.
Розглянемо основні чинники мотивації програмістів (команди програмістів), використовуючи піраміду Маслоу для наочності та структурування викладу. Якщо раптом ви не чули про піраміду Маслоу - це не безперечна, але дуже популярна і наочна теорія американського психолога Абрахама Харольда Маслоу, який запропонував теорію мотивації особистості на основі ієрархії потреб людини (див. малюнок нижче).
Маслоу розташував потреби особистості в ієрархічному порядку, від фізіологічних потреб до потреби в розкритті потенціалу та самоактуалізації. Ключове припущення теорії Маслоу: «людина неспроможна відчувати потреби вищого рівня, доки задоволені його потреби нижчого рівня». Наприклад, особистість може бути рухома потребою у пізнанні чи естетичними потребами, якщо у своїй ця особистість три доби не спала чи їла.
Перед тим, як заглибитись у деталі, зупинимося на очевидному факті — команда складається з людей, усі люди різні, у кожного своя структура мотивації. Крім того, що кожна людина рухається різними інтересами, кожна людина ще й перебуває в різних життєвих умовах. Хтось знаходиться на початку кар'єри і думає про те, як її будувати, хтось збирається одружитися, а хтось хоче освоїти нову предметну область. Те, що важливе для одного, зовсім не важливо для іншого, а завтра все зміниться ще раз. Щоб правильно розуміти цей контекст, є простий засіб — про нього треба думати і з ним потрібно працювати. Найважливіше – спілкування.
Обов'язково розмовляйте зі своєю командою про щось, окрім роботи, будуйте неформальні стосунки.
Отже, тепер пройдемося по піраміді Маслоу і розглянемо її рівні щодо керування командою програмістів.
I: Фізіологічні, біологічні потреби:
Говорячи про мотивацію, багато хто, насамперед, часто думає про зарплату. Під зарплатою в цьому випадку я розумію постійну частину пакета компенсації, яка не залежить від результатів. Це не стосується бонусів, премій та акцій компанії. Саме зарплату я відніс би до рівня «фізіологічних потреб» у нашому випадку. Бонуси, премії за результатами роботи, опціони та акції компанії – все це я відніс би вже до інших рівнів.
На мій погляд, як це не дивно може прозвучати, зарплата швидше може бути демотивуючим фактором, ніж мотивуючим. Особливість роботи з програмістами в тому, що всі вони, по-перше, дуже розумні (особливість професії), по-друге, глибоко і/або широко освічені. Зазвичай програмісти крім своєї професії глибоко розуміються на одній чи кількох предметних областях, на яку вони виробляють продукти. Крім того, хороші програмісти цікавляться і добре знають історію розвитку програмування, алгоритми, стандарти і т.д. Те саме стосується і їх предметної області. Для людей такого рівня зарплата зазвичай не є основним мотивуючим фактором.
Водночас відсутність справедливої в їхньому розумінні зарплати програмістів демотивує і демотивує сильно. Наявність справедливої зарплати – це норма. Зарплата сильно вища за норму (ринок) – теж, як не дивно, фактор швидше демотивуючий. Один колега мені якось розповідав про команду програмістів в одній з великих анімаційних американських компаній, яка через низку обставин отримувала зарплати на рівні вдвічі-втричі більше ринку. Як він розповідав, більше заїли, лінивих і демотивованих програмістів він у своєму житті не бачив. Факт підвищення зарплати може мотивувати короткостроково, але за кілька місяців нова зарплата стає нормою і перестає мотивувати. Загалом, я сказав би, для програмістів на початку кар'єри фактор зарплати важливіший, у міру їхнього професійного зростання та розвитку — його важливість знижується, й інші чинники починають превалювати.
Другий важливий момент – наявність справедливого балансу у рівні зарплат у команді. Якщо команда відчуває, що внесок одного з учасників помітно нижчий, але рівень компенсації при цьому не відрізняється, це демотивуватиме всю команду. Іноді менеджери відчувають спокусу заливати пожежу грошима — утримувати людину, що вигоріла або демотивована, підвищуючи їй зарплату вище за норму. Це зазвичай тільки створює проблеми у довгостроковій перспективі — мотивація самої людини особливо не зросте, або підросте на кілька місяців, а ось мотивація решти команди впаде. У таких ситуаціях варто шукати інші підходи, якщо, звісно, це не унікальний фахівець, якого треба утримати за всяку ціну навіть на короткий час.
ІІ. Потреба безпеки, комфорт, сталість умов життя:
70 років тому наявність печі в автомобілі могло бути мотивуючим фактором при виборі машини, тоді це було вище за норму, було ознакою luxury. Зараз навіть відсутність кондиціонера - це нонсенс, і його наявність мотивуючим фактором при виборі автомобіля, ясна річ, не буде. Так ще 10-15 років тому зручний офіс, гарне залізо, смачна кава, фітнес, гнучкий графік, і т.д. могли бути хорошими мотивуючими факторами, зараз це швидше норма для роботи хорошого програміста. Водночас їхня відсутність знову ж таки демотивуватиме.
Важливий фактор демотивації — відсутність можливості сконцентруватися, галасливе робоче оточення. Робота програміста потребує тиші та зосередженості. Якщо офісний простір не дає можливості надати розробникам відокремлене робоче місце, необхідно хоча б забезпечити комфортну спільну роботу колег, які не заважають одне одному. Енергійних і голосних товаришів краще поєднати один з одним, давши можливість зосередитися тим, кому це необхідно.
Вартість часу програміста зараз помітно вища за вартість заліза, на якому він працює. Два-три монітори, потужні комп'ютери, зручне робоче місце для кожного розробника повинні бути нормою в будь-якій компанії. Ця тема добре розкрита в одній із статей Джоела Спольськи.The Joel Test: 12 steps to better code”.
Фізична складова комфорту — найосновніша і найпростіша, поговоримо тепер про решту.
У багатьох компаніях нормою для роботи програмістів є гнучкий графік роботи та відсутність дрес коду. Це добре і правильно, якщо особливості роботи команди дозволяють (наприклад, немає зустрічей із замовниками, політиками чи банкірами).
Важливим моментом є наявність певного вікна часу, коли вся команда працює разом локально, щоб люди могли спілкуватися та вирішувати питання в особистому спілкуванні. Програміст, по суті, з роботи не йде і після роботи. Зазвичай робочі моменти прокручуються в його розумі незалежно від присутності в офісі, і хороші рішення часто приходять поза ним. З урахуванням потреби бути добрим (на якій ми зупинимося трохи нижче), дріб'язковий контроль шкідливий. Мало того, що він демотивує, він ще й знижує продуктивність. Як показує практика, без контролю замотивована команда швидше працює довше, ніж потрібно. За наявності контролю розробники можуть сидіти за клавіатурою з дев'яти до шести, але результат, гадаю, буде гіршим. Як кажуть, привести коня на водопій може і одна людина, але навіть сотня не змусить його пити, якщо вона не хоче.
В описі цього рівня потреб згадується також свобода від тривоги та страху, відсутність хаосу, потреба у структурі та порядку. Це теж дуже важливі моменти, які сильно впливають на атмосферу в команді.
По-перше, відсутність хаосу, структура і порядок — команда повинна розуміти, хто за що відповідає, як розподілені ролі, що робити, кому, коли, які вимоги лежать в основі продукту, які очікування начальства і замовника… Більша частина цього повинна бути формально описана, все має періодично обговорюватись. Без обговорення та періодичного використання описи не працюють. Хорошою практикою є їх періодичне обговорення та оновлення за результатами postmortem аналізу після релізу.
По-друге, спокійна та дружня атмосфера. Усі ми проводимо на роботі більшу частину часу, і хочемо робити це без стресу, конфліктів, страху. Команда розробки і так зазвичай працює під тиском розкладу та замовників. Додатковий стрес з боку колег та начальства нікому не потрібен. Атмосфера в команді взагалі сам факт того, що група розробників може називатися і бути «командою» — пряма і важлива відповідальність менеджера, одне з найголовніших середньострокових і довгострокових завдань. Тому менеджеру важливо працювати, зокрема, з конфліктами у команді, не пускати їх розвиток на самоплив. Управління конфліктами — окрема тема, яка заслуговує на окреме вивчення.
Є два основні способи впливу на емоційний стан команди, на поведінку колег (якщо хтось доповнить у коментарях буде чудово). Перший – власна поведінка. Особистий приклад - дуже важливо для менеджера і команди. Як то кажуть, який піп, такий і парафія. Поводьтеся так, як ви очікуєте, щоб ваші колеги поводилися. Другий — заохочення правильної поведінки, і, так би мовити, заохочення неправильної. Спілкуйтеся з людьми, давайте їм фідбек, багато способів це робити. Загалом фідбек — це тема для окремої розмови, це велика та важлива частина роботи з мотивацією.
Ще зауваження про атмосферу, яка може здатися незвичайною, але на практиці вона важлива. Найчастіше у команді розробників дівчат менше, ніж чоловіків. Найчастіше колективи повністю чоловічі. У таких умовах, ще й під навантаженням, іноді в команді починає використовуватися лексика. Практика показує, що на атмосферу це негативно впливає, спілкування поступово стає грубим. Варто уникати її використання самому та не заохочувати її використання в команді.
Команди розробки нерідко називають R&D (research and development), у своїй research становить значну частину роботи. Це та частина, яку зазвичай важко запрограмувати та запланувати, інакше це не було б дослідження. Важливо, щоб команда мала право на помилку, на ініціативу, на випробування різних варіантів, які можуть закінчитись успіхом, а можуть і не закінчитись. Помилки – нормальна частина роботи, їх не можна уникнути, але можна вивчати, аналізувати, отримувати з них уроки на майбутнє та рухатися далі. Принцип 5 why's, що зародився в Toyota, добре допомагає дістатися вихідної причини проблеми. Карати за помилки – це чудовий спосіб створити атмосферу страху та невпевненості. Єдиний виняток — коли за результатами розбору виявляється, що помилка викликана непрофесійним ставленням до роботи, у такому разі, можливо, потрібно буде ухвалювати кадрові рішення.
На атмосферу в команді дуже впливають ваші очікування, емоційний стан на початок розмови. Перед початком складного обговорення, якогось розбору польотів або просто емоційної розмови важливим є ваш настрій, ставлення до людини, з якою ви збираєтеся говорити. Я завжди за умовчанням вважаю і дію, виходячи з того, що людина щиро намагалася зробити як краще. Якщо з вашої позиції бачиться, що це не так — треба спокійно та детально з'ясувати контекст і зрозуміти, що він зробив правильно, чому він вважав, що це правильно, і де наші очікування розходяться. Зазвичай виявляється, що вони й не особливо розходяться, просто його бачення контексту повніше чи свіжіше, і ви чогось не знали. Або навпаки, він чогось не знав. Особливо це важливо у розподіленій команді, коли люди рідше спілкуються особисто, використовують пошту та месенджери. Ще більше це критично в команді, що складається з програмістів із різних країн і розподілених між різними часовими зонами. Тут велику роль починають грати культурні відмінності.
У складній ситуації наїхати з ходу просто, дуже просто, але відїхати назад потім важко, і осад залишається надовго. Наведу простий приклад із недавнього досвіду. Одному з менеджерів команди терміново були потрібні коментарі з приводу якоїсь проблеми у замовника від менеджера із суміжної команди з іншої країни. Він пінганув колегу в месенджері, почекав хвилин 15, пінганув ще раз, потім хвилин через 15 пішов у великий чат, в якому були й інші менеджери, і злегка наїхав на колегу, з формулюванням на кшталт: “Якщо ти мені не зволить відповідати, може , І питання не таке вже термінове?”. У результаті виявилося, що наш корпоративний месенджер трохи затупив, і колега питання взагалі не бачив. Довелося вибачатися. Загалом краще виходити з хорошого. Помилитись у погану сторону і наїхати пізніше завжди вийде, проблем із цим немає (хоча робити цього не варто). Взагалі, за більш ніж 20 років роботи в нашій індустрії я зустрічав реально зловмисного колегу лише один (!) раз. На щастя, ми досить швидко розлучилися. Виходити з того, що колеги хочуть як краще, в міру свого бачення контексту, виявляється правильним у переважній більшості випадків.
Ваше завдання як менеджера – забезпечити синхронізацію контекстів, загальне розуміння очікувань, вимог, термінів, прийнятих у команді стандартів. Це може здаватися дрібницями, але атмосфера в команді будується саме з таких дрібниць. З погляду розподіленої команди, одним із важливих завдань є забезпечити періодичне особисте спілкування членів команди. Я не раз чув від програмістів, що після того, як, наприклад, інженери команди підтримки приїхали до них і попрацювали разом особисто, вони із задоволенням затримувалися на роботі, щоб допомогти у скрутному випадку особисто Паші, який до них нещодавно приїжджав, хоча раніше Паша був просто іконкою в месенждері, і затримуватися заради іконки ніхто не став би.
До речі, заговорив про команду підтримки та згадався канонічний для мене приклад. Якось у одного із замовників в Америці виникла проблема з продуктом, один із інженерів команди підтримки, які працювали у нього на впровадженні (відряджені з Росії), залишився після роботи, щоб допомогти, але проблема все не вирішувалася і не вирішувалася. Загалом він затримався і сидів там практично до ранку. У цей час менеджери замовника ескалували проблему, позначили її критичність для них і ввечері пішли з роботи. Процес ескалації набирав обертів вже в іншій тимчасовій зоні, менеджери підтримки в Росії почали намагатися допомогти, через певні складнощі в комунікації з офісом замовника (VPN, проблеми зі зв'язком, складнощі зі дзвінками між країнами, ...) вони не знали, що хлопець уже сидить в офісі і вирішує питання, і намагалися його розшукати. Знайшли тільки під ранок (американський), коли питання було їм вже практично вирішене, і продукт запрацював. З місця в кар'єр почали наїжджати, що якогось чорта, у замовника така ескалація, нічого не працює, де тебе носить, ми не можемо тебе знайти, і т.д. Чи треба говорити, що в результаті подібної поведінки хлопця сильно демотивували. Організація роботи розподіленої команди – окрема велика тема, але важливо пам'ятати про дві речі. По-перше, комунікації, атмосфера це дуже важливо, від цього залежить успіх роботи. По-друге, це не працює саме по собі, цим треба займатися окремо та поглиблено.
Ще один важливий момент, що стосується цього рівня потреб, це знову зарплата. Чи не розмір зарплати, як такої, але наявність певного порядку її зміни. У компанії має бути підхід до визначення вимог до позицій різних рівнів. Кожен розробник повинен мати можливість обговорити очікування до своєї роботи з компанією, розуміти, як і коли його зусилля можуть позначитися з його зарплаті. Періодичні зустрічі з менеджером, піврічні чи річні атестації служать цій меті. Це, знову ж таки, один із тих моментів, наявність яких не мотивує у явному вигляді, але їхня відсутність демотивує сильно.
З потреби до порядку та наявності правил випливає необхідність дотримуватись цих правил, дотримуватися прийнятих у команді норм, як формальних, так і неформальних. Узагальнено я назвав би її потребою «бути хорошим». Наявність цієї потреби підтверджує, що мікроменеджмент не потрібний, скоріше шкідливий. Достатньо забезпечити людину всім необхідним для роботи, дати їй знання контексту, пріоритетів і надати свободу дій та прийняття рішень на її рівні. У таких умовах він відчуватиме довіру, можливість приймати власні рішення, нестиме за них відповідальність і зможе розкрити свій потенціал.
Ще важливий момент, який варто віднести до потреби наявності порядку та відсутності хаосу – можливість концентрації на завданні, відсутність частих перемикань контексту. Робота програміста потребує часу та зосередженості. Програмісти дуже не люблять терміново кидати одне завдання та перемикатися на інше. Необхідною частиною роботи програміста зазвичай буває як безпосередньо розробка коду, а й баг фіксинг, і допомогу з обробкою звернень від замовників. Варто планувати такі речі заздалегідь, щоб дати можливість програмісту спокійно і повністю завершити роботу над одним завданням перед перемиканням на інше. Найкращий варіант — дати можливість планувати свою роботу самостійно, позначивши пріоритети та майбутні завдання заздалегідь, виділивши довгий час для роботи над одним типом завдань. Ця тема добре описана у книзі “Google — Site Reliability Engineering”, в якій добре описані підходи до планування роботи команд, що забезпечують експлуатацію та розвиток великих, високонавантажених відмовостійких систем, а також інженерів, які за діяльністю поєднують розробку програмного забезпечення та його підтримку.
Далі буде ...
Джерело: habr.com