Як менеджери втрачають і витрачають потенціал розробників. Та як припинити це робити

Мене звуть Віталій Івлєв, я співпрацюю з ЕРАМ у ролі Delivery-менеджера. У цьому матеріалі поділюсь своїми роздумами щодо того, як варто розвивати експертів. Спиратимусь на власний досвід управління проєктами та командою системних інженерів, а також наводитиму приклади з реальної робочої практики.

Для деяких менеджерів потенціал розробників є чимось таким, що має розвиватися саме собою, без їхньої участі. Є й ті, для кого це важливий аспект співпраці з інженерами, якому завжди потрібно приділяти увагу. Але найбільша кількість управлінців в цілому розуміє важливість реалізації потенціалу команди, проте не приділяє багато уваги роботі з ним і фокусується в першу чергу на тому, як і коли команда імплементує очікуваний клієнтом результат.

Перш ніж ми зануримося у важливість роботи з потенціалом розробника, визначимо, про що саме йде мова.

Якщо говорити простими словами, то потенціалом інженера є сукупність досвіду, технічних знань та професійних навичок, які можуть бути використані для виконання поставлених задач. Але насправді все трохи складніше. Важливою складовою потенціалу спеціаліста також є швидкість, з якою він здобуває знання та формує професійний досвід. Ця навичка достатньо комплексна та індивідуальна для кожного, але саме вона дозволяє адаптуватися та знаходити потрібні рішення у постійно мінливому середовищі сьогодення.

Те, наскільки буде залучений потенціал і чи буде він збільшуватися, залежить великою мірою від менеджера розробника. Адже у більшості випадків саме керівник визначає, над яким рішенням інженер буде працювати і з використанням якого стеку технологій матиме справу, коли залучає його до того чи іншого проєкту.

Як переконатися, що потенціал розробника достатньо використовується

Оскільки поняття потенціалу досить комплексне, спроби прямого вимірювання відсотка залучених за останній час навичок та релевантного досвіду навряд чи допоможуть.

Інженер може на повну використовувати набутий досвід для вирішення конкретних задач, але якщо вони одноманітні й не потребують зусиль для знаходження нових підходів, то його потенціал, як і мотивація, будуть з часом деградувати.

Найкращим індикатором ефективного використання потенціалу є наявність професійного зростання. Якщо розробник з часом поповнює набір своїх навичок, успішно виконує все складніші задачі і наближається до переходу на наступний кар’єрний рівень — це є прямим свідченням того, що потенціал використовується продуктивно і збільшується. Чим швидше відбувається розвиток професіонала, тим краще реалізується його потенціал.

Як менеджер може впливати на розвиток потенціалу інженера

1. Першим кроком буде створення передумов або середовища для розвитку потенціалу, а саме:

  • створення персонального плану кар’єрного розвитку;
  • наявність програм навчання;
  • доступ до спільноти професіоналів та можливість мати персонального ментора;
  • Отримання якісного та регулярного зворотного зв’язку від колег, у якому відмічаються як позитивні аспекти співпраці, так і зони росту.

Сьогодні IT-компанії мають багато онлайн-сервісів для мінімізації часу, який менеджер має витрачати на організацію вище зазначених передумов. З власного досвіду, зокрема в ЕРАМ, можу стверджувати, що компанія, яка піклується про потенціал своїх інженерів, має автоматизовані інструменти для побудови плану професійного розвитку на основі наявних навичок конкретного співробітника та його кар’єрних вподобань. До того ж такі компанії розробляють внутрішні програми підвищення кваліфікації на основі власного досвіду та найкращих практик, які застосовуються на проєктах сьогодні та будуть мати попит у майбутньому. Менеджер у цьому випадку фокусується на допомозі у визначені кар’єрного шляху та контролі виконання індивідуальних планів розвитку, забезпеченні доступу своєї команди до внутрішніх професійних спільнот і менторів, а також роботі зі зворотнім зв’язком.

2. Наступним кроком є залучення інженера на проєкти з максимальним — наскільки це можливо — урахуванням обраного вектору розвитку та персональних уподобань. Звісно, далеко не завжди отримана роль буде повністю відповідати очікуванням інженера, але задача менеджера зробити все можливе, щоб ця відповідність була якомога вищою.

У нас в компанії, до речі, є внутрішня система автоматичного добору позицій на проєктах відповідно до наявних навичок кандидата. Також існує команда стафінг-координаторів, які забезпечують ефективний процес подальшого інтерв’ювання на проєктах та остаточного вибору позиції кандидатом.

3. Коли мова йде про конкретні задачі, над якими працює розробник, то вони мають включати ті, які вимагають розширення або вдосконалення наявного набору навичок. Робота над викликами веде до професійного розвитку. Водночас їхня відсутність — навпаки — призводить до поступової деградації потенціалу, особливо у довгостроковій перспективі.

Прикладом може бути делегування лід-розробником задачі з пошуку оптимального рішення для імплементації нового функціоналу продуктивному мідл-інженеру.

Мотивація та потенціал

Для більшості інженерів, як і взагалі для багатьох спеціалістів у наш час, важливим є рух у напрямку вдосконалення своїх навичок та набуття цінного досвіду, який так чи інакше стане у пригоді в майбутньому.

Іншими словами, мотивація для більшості інженерів пов’язана з кар’єрним розвитком. Робота над проєктами, які цікаві розробнику, так чи інакше сприяє розвитку професійних навичок і отриманню цінного досвіду — це те, чого не купиш за гроші.

Такий підхід мотивує спеціаліста і природно розвиває його потенціал. Розуміння цього дозволяє менеджеру вибудовувати продуктивну співпрацю зі своєю командою.

Помилки управлінців, як їх виявити, виправити або й уникнути взагалі

Незнання або ігнорування індивідуальних особливостей членів команди

Робота з командою суто в площині поставлених задач та проєктних дедлайнів без урахування персональних відмінностей кожного з її членів рано чи пізно призводить до зменшення продуктивності та відчуження.

Слід постійно інвестувати час на індивідуальну комунікацію з колегами, щоб розуміти їхні сильні та слабкі сторони, професійні уподобання, мотивацію та можливі проблеми. Такий підхід підвищить довіру між вами й зробить легшою комунікацію, оскільки знання персональних особливостей кожного члена команди дозволяє швидше розв’язувати питання та запобігати багатьом проблемам з продуктивністю.

Погодження дедлайнів з клієнтом без консультації з командою розробників

Ми зараз говоримо не про набір типових задач з витратами часу, які відомі з минулих імплементацій, а про суб’єктивність персональної оцінки менеджера стосовно незнайомої для команди роботи.

Причини такого вчинку менеджера можуть бути різні, але наслідки одні й ті самі: демотивація команди, падіння продуктивності та небажання співпрацювати з таким керівником у майбутньому.

Управління очікуваннями клієнта має відбуватися на основі оцінки часу імплементації, яка надається командою-виконавцем. По-перше, при такому підході оцінки вочевидь реалістичніші, по-друге, команда таким чином бере на себе відповідальність за терміни виконання.

Забагато робочих зустрічей

Будь-яка зустріч, де присутня частина або вся проєктна команда, є досить витратною з точки зору ресурсів, оскільки на ній спливає робочий час одразу декількох колег. Що більше зустрічей, то нижча їхня ефективність і тим менше часу у команди для фокусування на задачах.

Будь-якому спеціалісту, який працює над інженерним питанням, для ефективної роботи потрібен час на концентрацію розумових зусиль. Тому мінімізація кількості комунікацій, особливо позапланових, йде тільки на користь. Важливо збалансувати календар зустрічей, як за їхньою кількістю, так і за тривалістю.

Для проведення продуктивної робочої зустрічі важлива її ефективна фасилітація і обов’язково підготовка: завчасне планування з висвітленням цілей і тем обговорення, залучення суто необхідних учасників команди тощо.

Заклики до команди швидше виконувати роботу

Роби краще/швидше! — подібні заклики можуть свідчити або про лінощі менеджера, або про відсутність часу на розв’язання реальної проблеми з продуктивністю інженера. В обох випадках це є перекладанням відповідальності за недостатній перформанс повністю на підлеглого.

Такий підхід до «вирішення» проблеми є деструктивним і демотивуючим, він може накласти негативний відбиток на професійні стосунки у довгостроковій перспективі, навіть попри знаходження адекватного розв’язання проблеми зараз. Не варто виключати і ймовірність надвисоких очікувань з боку менеджера, особливо у випадку, якщо він або вона не знає індивідуальних особливостей члена команди.

Управління продуктивністю — це процес регулярної комунікації лідера зі спеціалістом, який включає уточнення очікувань, постановку персональних цілей з урахуванням потреб компанії або конкретного проєкту, вивчення результатів роботи та планування наступних кроків на їхній основі. Вочевидь розв’язання проблем з продуктивністю команди чи окремих її членів потребує комплексного підходу та часу керівника.

Висновок

Якість роботи з потенціалом інженерів має великий вплив на їхню продуктивність у середньо- та довготерміновій перспективі. Наявність сприятливого для зростання робочого середовища дозволяє спеціалістам отримувати нові знання та досвід, а менеджеру — ефективно витрачати зусилля на стимулювання та підтримування цього процесу.

Наявність плану кар’єрного розвитку з одного боку та його урахування менеджером при доборі ролі на проєкті з іншого — виграшні як для самого інженера, так і для менеджера. Перший розвивається у потрібному йому напрямі, виконуючи поставленні перед ним проєктні задачі, а другий має вмотивованого співробітника, від якого навряд слід чекати проблем з продуктивністю та витрачати час на їх вирішення.

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Проблема в тому що людина не робот чи процесор, яких можна підтюнати щоб працював наприклад на 95% потужності замість 80%. Тим більше коли є багато розумової праці.

А в чому проблема, бо я з вашого пояснення не зрозумів?
Наприклад, коли в інженера є певні показники перформансу за декілька спринтів, то це як показник, на що можна орієнтуватися при плануванні наступного спринту, ... також автори Scrum пропонують резервувати до 25% часу спринту на багфікси, непередбачувані обставини та саморозвиток спеціалістів.
Про стабільний перформанс не можна говорити, коли в інженера періодично з’являються таски з високим % новизни, але з набуттям досвіду наступного разу подібне вирішується швидше, ... що переглядається потім в естімейтах.
Ви привели приклад, коли типу вимагається буст перформансу з 80 до 95%, а, наприклад, мені доводилося працювати із надзвичайно продуктивним спеціалістом, який пояснював свій результат => практикою йоги, що типу його мозок із-за цього суттєво продуктивніший мозку пересічного спеціаліста, а рішення певних тасків йому можуть приходити навіть під час сну🙃

надзвичайно продуктивним спеціалістом, який пояснював свій результат => практикою йоги

То виходить галера може просто всіх змусити займатись йогою? І може доплачувати за годину йоги як за овертайм?

До речі — це досить поширений бенефіт від компаній, коли оплачують заняття саме йогою чи культивують її серед своїх спеціалістів.
В наведеному від мене прикладі — це особиста справа спеціаліста, а не нав’язування від компанії, ... і я не адепт йоги, але в підсумку виходило, що даний спеціалістне не вживав алкоголь і обирав більш здорове харчування, мав регулярні фізичні вправи та медитацію, тому його мозок був точно продуктивнішим чим спеціаліста, що мав легке похмілля зранку після вчорашнього футболу з пивом, а із-за недостатньої фізичної активності => зайву вагу та гіпертонію, ... тобто потрібно комплексно розглядати, що може впливати на продуктивність мозку конкретного спеціаліста

Чергове корпоративне булщіт бінго

Статтю точно самі писали?
Віталій, чим відрізняється робота Delivery-менеджера в Oracle та epam? Які є переваги у epam, що краще організовано в Oracle і навпаки?

Напевно, що некоректно порівнювати Delivery-менеджера в Oracle та EPAM, так само, як у випадках відмінності Delivery-процесів у product та outsource компаніях

А чому власне не коректно ? За багато якими процесами такі самі ІТ компанії, більш того це платинові партнери. Я щось таке чув, що з багатьма клієнтами компанії працюють одночасно місяцями в одних командах зустрічаються на загальних зборах в різних країнах в таке інше. І про продукти, різних компаній і хто їх робить на чиє замовлення і не тільки Oracle багато слухів ходить.

Робота напряму із замовником за вищу винагороду мотивує значно краще, ніж внутрішні системи аутсорсерів.

Це до моменту поки такий замовник не заборгує тобі гроші. На «галєру» ще можна впливати репутаційно, бо є залежність від місцевого ринку праці. А от західному замовнику репутація його шлюпки в Україні може бути абсолютно пофіг. При цьому, одна зарплата навіть з топу наймів Джинні — це, зазвичай, не та сума, за яку має сенс судитися (на юристів витратиш десь стільки ж, скільки заробив).

Шлюпки так само кидають)

Яка там репутацiя, я вас благаю)))
Пишеться стандартне простирадло про заподiянi збитки вiд недолугого делiверi от i всi втрати)

Тут нема срiбноi кулi.

Шлюпки так само кидають)
Яка там репутацiя, я вас благаю)))

Хіба що «одноднівки». Бо якщо компанія планує далі наймати «гребців» на українському ринку праці, гучний зашквар скандал та/або погані відгуки на тому ж ДОУ можуть досить потужно вплинути на бажання йти туди працювати.

Та шо ти верзеш, люди працюють навіть у найогидніших галерах, абсолютно незважаючи на репутацію

По-перше, не треба хамити. По-друге, якісь люди, мабуть, працюють — можливо, ті, яких не беруть у більш пристойні компанії.

Але це у галери повинна бути дуже специфічна бізнес-модель, яка не потребує наявності у команді досвідчених експертів (які до будь-якої ноунейм галери не підуть бо мають вибір з більш цікавих пропозицій)

Усі хто опинився у стартапі (я з них починав) про таке чомусь не думають від початку, що їх можуть елементарно кинути. Скажімо — не сплатити за роботу, чи зламати їх продукт через те, що ніхто не подумав про безпеку і захист коли створював першу версію, чи прикинутись опенсурсом якому надається безкоштовна анлімітна ліцензія тощо. Певний рівень наївності є в усіх. Між іншим у великих контор, такі знання по майже підписані контракти, письмове підтвердження забов’язань і т.д. і т.п. передаються в якості фольклору від одного до іньшого.

Майже всю професійну кар’єру працюю напряму з компаніями з-за бугра, і чомусь ніхто не додумався мене кидати. Магічне словосполучення «західний замовник» не дорівнює «працювати аби де, тільки не в компанії з юрособою в Україні». Адекватні компанії треба шукати в будь-якому випадку.

зокрема в ЕРАМ, можу стверджувати, що компанія, яка піклується про потенціал своїх інженерів, має автоматизовані інструменти для побудови плану професійного розвитку на основі наявних навичок конкретного співробітника та його кар’єрних вподобань.

і для побудови плану відтермінування росту компенсації, бо гребець не вивчив новий фреймворк :D

Це не від компанії залежить, а від конкретного керівника. Такої аутстафінгової компанії, яка би хотіла щоб її гребці були не конкурентноздатними на ринку не володіючи затребуваними фреймверками не існує. А от керівники, які вважають, що краще бюджет витрачати на оборот із ринком праці, чим на навчання наявного персоналу повно. І у величезній компанії буває усяке, в тому числі власний внутрішній ринок вакансій і система яка його забеспечує. В малих компаніях теж буває усяке, особливо коли над продуктом працюєш і за три роки жодного фреймверку по роботі не засвоїв — бо це зовсім не потрібно, тільки за власний рахунок.

не від компанії залежить, а від конкретного керівника

ну над керівником є ще один керівник який деклайне будь що, ще й люлей випише :D
про фреймворк я мабуть перебільшив, але давайте продовжимо ваш стейтмент

Такої аутстафінгової компанії, яка би хотіла щоб її гребці були не конкурентноздатними на ринку не володіючи затребуваними фреймверками

не просили переглядів компенсацій та не тормозячи цей процес різними ассесментами, рівнем англійської, персонал девелопмент планами — не існує.
Проблеми розвитку — це проблеми інженера, керівник потрібен лише для того, щоб менеджити делівері продукту в дедлайн та з певною якістю, а не займатись бейбісітнгом. Більшість менеджерів навіть не задумуються, що їх оцінюють лише за перформансом їхньої команди, а не як інженерів за індивідуальні показники. Ех, тому бути контрактором це найкращий варіант, ніхто не іпе мізки різним булшитом.

Це мені холівар нагадує про таби та пробіли. Реальність така — не в компанії діло, діло в конкретному керівникові та його особистих якостях, в незалежності від типу компанії. Хтось задля отримання результату (особистого заробітку) обирає стратегію «ростити своїх» , хтось навпаки — переманювати чужих, а хтось просто винаймати тимчасових робітників контакторів, фрілансерів, аустаферів тощо. Так само і у виконавця такий самий вибір від одного місця, джампінг серед контор чи фріланс, стартаперство тощо.

Некомпетентні менеджери — це вже культ. І так, діло в компанії також, яка пережує та виплює твої особисті якості та змусить робити те способом, що дядьки зверху вирішили, це не добре і не погано — просто факт.
Решту поінтів, цілком з вами згідний.

Якщо можна вчитися в робочий час це великий плюс.
Але це швидше буде залежати від навантаженості та власних пріоритетів.
Найкращий менеджер не нависатиме просто

Цікаве припущення. Проте якщо план розвитку вибудовується з урахуванням вподобань інженера і затверджується за його згоди, то такий сценарій вкрай малоймовірний.

Ми пахали я і трактор

Схоже на статтю про успішний успіх. Віталій, якщо ви бажаєте, можемо подискутувати по тезах, викладених в статті, але на перший погляд виглядає дуже ... не дуже. Начебто вас змусили написати цю статтю для виконання плану.

Заради цього тексту й писалась ціла «стаття»:

У нас в компанії, до речі, є внутрішня система автоматичного добору позицій на проєктах відповідно до наявних навичок кандидата.

У EPAM-а стільки бруду, що варто оминати: чорні списки, Дія.City, EPAM чий Крим?

Мотивація та потенціал

Епам такий Епам. Є тільки одна мотивація — гроші. Якщо ти супер-пупер інженеру запропануєш за 20 тисяч робити КРУДи, то він буде робити КРУДи й срати йому на нові технології та реалізацію.

Наявність плану кар’єрного розвитку з одного боку та його урахування менеджером при доборі ролі на проєкті з іншого — виграшні як для самого інженера, так і для менеджера. Перший розвивається у потрібному йому напрямі, виконуючи поставленні перед ним проєктні задачі, а другий має вмотивованого співробітника, від якого навряд слід чекати проблем з продуктивністю та витрачати час на їх вирішення.

Наявність плану з прив’язкою до грошей. А інакше це ЕПАМ стайл.

Вочевидь, тобі не завадило б пройти воркшоп від компанії про бізнес-орієнтед-майндсеттінг, бо ти схоже думаєш, шо розвиток — це твій рейт, а не збільшення зони відповідальності і лояльності до компанії.

Так а может наоборот — сначало увеличение рейта, а как результат — увеличение лояльности от сотрудника ? Обещать — не значит жениться. Это относительно обещаний компании.

шо розвиток — це твій рейт, а не збільшення зони відповідальності і лояльності до компанії.

А що, одне виключає інше?

Боже, тугенько тут із іронією

Не туго: це в тебе подача така.

Тебе люди не розуміють, як бачиш.
Не вперше, і точно не востаннє.

Ти такий душніла. Мені це подобається.

Як подобається, можеш піти свого гуся десь передьорнути.

А в цілому все нормально: якщо раніше хтось із покерфейсом чи то жартував, чи то серйозно говорив, але на обличчі жодної емоції — такі лише в офісі траплялись, то тепер, дякуючи ремоуту, лише інколи на форумі.

Дякую за точку зору. Звісно, матеріальна мотивація є найочевиднішою. Проте розвиток потенціалу дуже важливий у довготерміновій перспективі і він теж впливає на мотивацію. Знання і навики, які роблять спеціаліста більш досвідченим, можна згодом конвертувати у гроші. А от навпаки це не працює.

В большинстве случаев про перспективы говорят те, кто не может платить в данный момент (либо хотят экономить). В нашем аутсорсе об этом говорят по причине того, что на молодом специалисте маржа заработка высока (аутстафф — он такой, развращает в плане лёгких денег).

Підписатись на коментарі