П'ять системних проблем, які заважають аутсорсинговим IT-компаніям розвивати свій бізнес

Автор статті – експерт у сфері IT-технологій з 25-ти річним стажем та виконавчий директор Інституту Емоційного Інтелекту, автор зареєстрованої методології використання телеметрії емоційно-життєвих показників інтелекту HR-менеджментом для досягнення єдиної парадигми мислення команд IT-фахівців. 

 

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

 

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

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

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

1. Технічне інтерв'ю не розкриває бізнес-вимоги замовника

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

2. HR менеджмент не розвиває професійне зростання команди

Вкрай зрідка, коли HR-менеджери IT-компанії є професійними IT-фахівцями, вони мають інший спектр навичок. Та й основна їхня робота, на жаль, полягає в демонстрації KPI найму нового складу, або «привіт-як-справи»-менеджменту. Зрозуміти, що новий кандидат зможе закрити собою системний розрив нестачі компетенцій для реалізації проблеми – вкрай нетривіальний виклик, оскільки кожен новий учасник команди підвищує феноменальний рівень безглуздих дій колективу – чим більше команд(и), тим вищий рівень загальної некомпетентності.

У зв'язку з цими фундаментальними обмеженнями є сукупність системних помилок, що призводять до парадоксу перегрітого ринку та непрацевлаштованих IT-фахівців:

1. Оцінка компетенцій з досвіду

Компетентний та досвідчений – це як теплий та м'який. Легко сплутати. Крім того, неможливо визначити досвід розробки та час, витрачений на проект. Коли програміст каже: «Та в мене 3 роки у банківському секторі!» – звучить вражаюче. Це означає, що за цей час він зустрічався з різними кейсами з транзакцій та різними типами ORM, це добре і корисно. Але, якщо він не вивчав сучасні технології і не розвивав професійні навички, то його ефективність на проекті, що вимагає компетенції SQL, буде не вище Junior: той теж знає про SQL і вміє писати базові запити.

Мені зустрічалися розробники зі стажем, які абсолютно безграмотно і неефективно керували СУБД через ORM фреймворки, проект працював та існував виключно завдяки фінансовому ресурсу, який вливався замовником. Але продуктивність могла би бути набагато вищою, а витрати відповідно - нижчими.

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

2. Оцінка компетенцій за знаннями.

Оцінюючи програміста за знаннями, ми фактично граємо в «Обдури мене, якщо зможеш». Ми завжди намагаємося використовувати найкращі практики. І нам здається, - знайдемо програміста зі знаннями, котрий створив класний продукт, і він нам теж зробить крутий проект. Це ж логічно. Не зробить. Якщо ви шукаєте чарівників, насправді, знайдете казкарів.

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

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

3. Помилка мотивації

Поставте собі питання: а навіщо вам новий IT-фахівець у проекті? Якщо для розвитку нових фіч, що дає поле для його зростання та розвитку відповідно до глобальних планів замовника – питань немає. Але найчастіше переважають інші цілі. Реальні цілі.

Перша популярна мета – «підтримка проекту» у поточному стані. Справа важлива. Найчастіше процес даної дії замовник бачить наступним чином: потрібна його інтеграція в новий продукт, яка працюватиме так само, як і в старому. Тобто є поточна інтеграція, що працює. А нова має працювати так само легко, як і стара. Але не працює, хоча проект працює зі старою без проблем. Тому, мені потрібен хтось, хто робитиме те саме, але з новою. І щоб нічого не змінив, а то зламає все, адже проект уже працює та приносить гроші!

Досвідчені HR про такі запити знають, тому під час рекрутингу включають режим - «робота зі зрілим продуктом, який треба лише підтримувати та трохи доопрацьовувати». Оскільки й раніше вони знаходили не те, що треба з точки зору стратегії, а те, що хоче замовник. А ми пам'ятаємо перше обмеження. Тому, спочатку шукаємо і знаходимо не компетентного фахівця, який здатний принести свою евристику у вирішення бізнес-завдань, а комфортного розробника, який апріорі ніколи не зможе ідеально створити нову інтеграцію на старій кодовій базі. І, з великою ймовірністю, його ефективність буде однозначно меншою, ніж у створювача, яка не факт, що була високою. Винайнятий програміст буде чимось середнім між Іваньком Нечупайлом та Ікаром. Але не компетентним учасником команди, який зможе вирішити поставлену бізнес-мету, вплинувши на зміни підходів замовника.

Інша популярна мета – коли на проекті величезний техборг, нескінченний багфіксінг, упереміш з амбітними фічами. І треба це виправляти. Компанії, по суті, потрібен експерт, але це справа недешева. Здається, що найпростіше найняти нового PM, щоб він «навів порядок»: описав процеси, вигадав нову борду, розписав мітинги, впровадив найкращі практики. І шукають епічних PM, які вміють занурюватися у технічні деталі.

На виході ми маємо два результати. Перший – найняті програмісти швидко вигоряють від такого набору нетривіальних вимог та йдуть у перші 3-6 місяців. Другий – трапляються бойові молодці, які знають і вміють, із залізною волею, які реально досягають цих завдань, але… їх звільняють!

Оскільки Авгієві стайні прибрані, техборг розібраний, проблем щодо подальшої розробки вже немає, отже, мега-айтішник більше не потрібен. Більше з тим, він надто розумний та незручний. Ставить неприємні запитання, змінює думку менеджменту. Все, що він зробив допомогло, але всередині щемливої душі менеджмент відчуває неприємність. Він переміг? А раптом підсидить? Ну ні. Краще на його місце поставити більш передбачуваного, але менш талановитого розробника. Дякувати Богу, все що було потрібно - вже створено і працює «саме собою». Через кілька років, коли Авгієві стайні знову наповняться якоюсь речовиною, можна буде знову найняти епічного айтішника.

4. Пошук «довгосидячих»

Є поширена логічна девіація в процесі найму. HR-менеджери звертають увагу в резюме на те, як довго програміст працював на одному місці. Нібито це логічно: якщо людина довго не затримується в компанії, означає, проблеми з нею самою. Сволота така нетовариська. Псих скандальний. Або провалює дедлайн постійно і самостійно не розвивається. Негідник, одним словом – «Дякуємо, ми Вам зателефонуємо».

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

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

 

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

5. Нерозуміння психології IT-фахівців

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

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

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

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

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

Саме для цього ми пропонуємо методику для HR-менеджменту, яка допоможе краще зрозуміти наступні нюанси у роботі з IT-фахівцями:

1. Більш швидкий та якісний добір нових фахівців
2. Розуміння їх бажань та стурбованості
3. Більш ефективне управління розподіленими командами в дистанційному режимі
Методика не містить ніяких антинаукових «проривних технологій». Вона оперує відомими та підтвердженими фактами з практики та дозволяє поглянути на проблему під різними кутами, формуючи безліч альтернативних шляхів вирішення завдань.

Оформити замовлення зі  можна безпосередньо на сайті автора: https://rogovsky.net/product/hr/

 Роговський Андрій, Одеса