«Це безглузде витрачання нашого часу». «Маячня. Дитячий садок». «У нас є важливіші справи! Ми взагалі-то розробниками працюємо, а не спікерами». На такі та подібні фрази можна натрапити у пабліках для розробників або почути в реальності. Проєктного менеджера або SCRUM-майстра, який має завдання залучити розробників до інших активностей, крім їхньої основної роботи, така позиція девелопера щонайменше засмучує. А може й ввести у ступор. Що ж робити? Давайте розберемося, за яких умов у розробників буде мотивація не тільки кодити.
Позаробоча діяльність корисна всім
Працівники вчаться самостійно ухвалювати рішення, а подекуди творчо підходити до вирішення задач. Цьому сприяють регулярні сесії з підвищення кваліфікації чи лекції всередині команди. Корисні й певні активності з тімбілдінгів. Наприклад, проведення майстер-класу з активного слухання, спільна гра в онлайн або офлайн ігри (Code Names/Bingo/Detective quest game тощо). Якщо ви впевнено володієте технічною базою, то можна спрямувати активність команди в цей напрям. Наприклад, спільний пошук багів або розгляд кейсів, де команда мала труднощі, і спільний пошук рішення.
Якщо команда проєкту створена відносно нещодавно, можна спланувати сесію-знайомство або поглиблення у те, що знають та вміють учасники. Так вони краще дізнаються про скіли колег і зможуть напряму звертатися за допомогою один до одного.
Формування спільних цілей і планів також розкриває команду та кожного учасника по-новому. Обговоріть, які зони розвитку виділяє для себе кожен розробник, і визначте одну ціль серед того, що зустрічатиметься найчастіше.
Серед інших переваг можна виокремити:
- Можливість побудувати довірливі відносини між співробітниками. З людьми, мотивованими не лише роботою, набагато легше працювати. Вони стають більш довірливими, відкритими до пропозицій проєктних менеджерів.
- Отримати більше можливостей для навчання та розвитку.
- Покращити ефективність, продуктивність і креативність.
- Розвинути в собі гнучкість та адаптивність до змін. Наприклад, коли клієнт часто змінює свою думку або в нього виникають нові потреби, команда швидко зреагує на це і буде готова запропонувати різноманітні рішення.
- Підвищити особисту відповідальність кожного, покращити моральний дух та мотивацію команди для успішної реалізації проєктів.
- Впровадити нові підходи до ведення проєктів та аналізу відгуків клієнтів.
«Позитивне» підкріплення як шлях до мотивації
Існує два основних види мотивації співробітників – матеріальна та нематеріальна. Якщо з першою все зрозуміло, то друга – вимагає креативного підходу і певного часу на реалізацію.
Слід пам’ятати, що всі ми люди, і нам не чужі будь-які людські емоції та почуття. Нехай це буде відправною точкою у вашій комунікації з командою. Нам же всім приємно чути щось позитивне про себе. Тож пам’ятайте: на ініціативу команди і кожного фахівця завжди позитивно впливають схвальні відгуки.
Помітивши, як хтось із розробників бере участь в активностях, не пов’язаних із його безпосередніми задачами, похваліть цю людину. Можливо, фахівець сам організував ретроспективу на проєкті, вирішив спланувати спринт або ініціював додаткові зустрічі з колегами чи регулярно підтримує спілкування з командою на дотичні до ІТ теми.
Похвала одного як стимул для всіх найкраще працює за присутності інших членів команди. Підхід називається «Позитивне підкріплення». Ця система заохочень перейшла у бізнес із неочікуваної сфери – дитячої психології. Суть у тому, щоб через похвалу показати дитині, яка її поведінка є бажаною й очікується від неї.
З розвитком психології цей підхід поступово перейшов у корекцію поведінки військових, коли генерали привселюдно звертали увагу на одяг, швидкість реакції на команди й інші персональні показники солдатів, ставлячи їх у приклад усій роті. З часом аналогічний патерн поведінки науковці відмічали й серед інших військових.
Американський клінічний психолог Беррес Скіннер зазначає: все, що допомагає нам підкріпити бажану поведінку, вважається позитивним підкріпленням. І, коли це проявляється у групі людей, воно є дієвішим.
«Кудос тижня», «Нашивка найактивнішого члена команди», «Кубок активності» – для своєї команди можете вигадати будь-яку фізичну або віртуальну нагороду, щоб заохотити учасників до схожих дій та показати: їхня ініціативність схвально сприймається на рівні компанії та може позитивно вплинути на професійний ріст.
Не кодингом єдиним. Покажіть девелоперу, що ще робить його класним фахівцем
Часто розробники підкреслюють, що їхня робота приносить суттєвий результат, який можна побачити й оцінити. Інші ж дії не мають такого наочного ефекту. В такому разі покажіть результативність інших практик, які не пов’язані з кодингом.
Технічні фахівці цінують факти та цифри. Почніть цей експеримент, поєднавши його початок із вхідними даними, тобто на якому рівні розвитку спеціаліст перебуває в певний момент. Це можуть бути результати закриття певної кількості задач або сторі пойнтів, вирішення окремих завдань самостійно чи з іншими розробниками.
Нехай це будуть «сухі» факти, орієнтовна статистика, але це вже стане аргументом у розмові – як нова активність допоможе людині покращити свої власні та проєктні результати. І ви вже побачите в очах колег зацікавлення. А з інтересом поступово зменшиться скептицизм до того, що ви пропонуєте.
Як приклад застосування цього підходу згадаю власний досвід. Була у моїй практиці співпраця з одним Junior-розробником. Хлопець неохоче займався будь-якою роботою, крім кодингу, але при цьому мав неабиякі цілі – стати сеньйором. Під час однієї з наших бесід я запропонувала йому провести експеримент, спираючись на показники швидкості й обсягу його роботи. За місяць активної участі у просвітницькій діяльності – Lessons learned сесії, де він ділився своїми злетами та падіннями під час спрінта, – розробник набув чимало нових знань. Адже пояснюючи різні кейси, він спирався на технічну базу. Його колеги зауважили, що не очікували такої активності від цього девелопера, навіть не знали, що він настільки професійний і до нього можна звертатися з приводу тих чи інших питань.
Через певний час ми з ним порівняли кількість задач та закритих сторі пойнтів за декілька ітерацій. Різниця була помітна не тільки мені, але і йому, і приємно вразила його.
Впевнені у собі люди краще беруться за важкі задачі й охочіше звертаються за допомогою, а також із більшим бажанням діляться знаннями з іншими. Як результат – маємо особисту та загальну, командну результативність.
У цій історії розробнику раніше не вистачало впевненості, а мої слова без фактів не були достатньо авторитетними для нього. Однак щойно ми спробували – девелопер впевнився у дієвості запропонованого підходу.
Поясніть колегам, як вони можуть професійно зростати у додаткових активностях
Не будьте РМ-мамою. Дайте їм більше свободи рішень і дій. Підтримуйте їхні пропозиції, навіть якщо здається, що вони не «злетять».
Будьте з ними чесними і визнавайте свої помилки. Бо тільки знаючи, що можна зробити помилку, не будучи засудженим, значно легше пропонувати щось нове та бути залученим у вже наявні ініціативи.
Створіть для колег атмосферу в команді, де вони знайдуть однодумців, де вони будуть почутими, а не лише «інструментом», що виконує певні задачі.
Розробники мають розуміти, що soft skills є не менш важливими за hard ones. Часто саме «м’які» навички відіграють вирішальну роль в ухваленні рішень щодо підвищення доходу або пропозиції нової перспективної посади.
Будучи активним учасником зустрічей з клієнтом, презентуючи продукт чи проміжні результати роботи, працівник «пробиває» собі дорогу до нової ролі у проєкті чи в компанії. Також цінною є участь у «відкритих мікрофонах» на технічні теми, сесії із застосуванням різних підходів щодо підтримки, покращення продукту.
Але зверніть увагу: при застосуванні цього підходу слід впевнитися, що залишитися на поточному кар’єрному рівні дійсно не є мрією усього життя певного розробника. У такому випадку ця порада не має сенсу. Однак і таке рішення цілком нормальне. Кожному з нас комфортно на тому чи іншому рівні.
Перш ніж спробувати щось, проведіть one-to-one сесії з кожним працівником. Поговоріть про його/її цілі, бачення себе в команді, на проєкті, через кілька років в ІТ або взагалі, до чого людина прагне по життю.
Поясніть колезі, що пропонуючи стати активнішим, ви не намагаєтесь використовувати його працю «понаднормово». Навпаки – прагнете дати йому нові можливості для професійного росту.
Обговоріть разом, скільки часу людина може й хоче присвятити додатковим активностям, що саме її цікавить і чому. Візьміть це до уваги при плануванні активностей та пошуку нових ідей.
Не обтяжуйте колег, коли розумієте, що строки «горять». Усьому свій час. Якщо зараз додаткова активність є зайвою, і з нею людина просто фізично не встигатиме все робити якісно, краще притримайте ваші менеджерські амбіції, зачекайте.
Щойно побачите, що у роботі над проєктом настало відносне затишшя, тобто розробники «не зашиваються» чи команда добилася лояльності клієнта, проєкт довготривалий, і команда вже має достатньо досвіду в межах цього проєкту – тут-то ваш «зірковий» час настав.
Виходьте до команди з ідеями активностей. Почніть із досвідчених учасників – сеньйорів. Вони є прикладом для інших, і з ними зазвичай легше домовитись про додаткові активності. Здебільшого вони вже знають, що саме може зацікавити інших, і це може стати приводом для тих же Lessons learned сесій. Та й за рахунок досвіду подібні виступи даються їм легше, природніше.
Наостанок наголошу на одному з ключових принципів Agile: люди та взаємодія між ними є важливішими за процеси й інструменти. Пам’ятайте, що ера роботів ще не настала, і ви працюєте з людьми. Кожен із них – особистість зі своїми сильними та слабкими сторонами, з власними вміннями й прагненнями. Використайте це задля їхнього розвитку. Так ви ще й зробите робочі будні цікавішими.
Підбираючи активності для колег, зважайте, що кожна ваша ідея має допомогти їм відкрити у собі нові грані для професійного й особистісного розвитку.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодну публікацію!
