Епіграф:
Чоловік, дивлячись на замурзаних дітей, каже дружині: ну що, цих відмиємо чи нових нарожаєм?
Під катом друга частина статті нашого тимліду, а також директора з розвитку продукту 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