На етапі розвитку промислової розробки програмного забезпечення можна спостерігати різноманіття виробничих ролей. Їхня кількість зростає, класифікація ускладнюється з кожним роком, і, природно, ускладнюються процеси підбору фахівців та роботи з кадровим потенціалом. Інформаційні технології (ІТ) – це сфера висококваліфікованих трудових ресурсів та кадрового дефіциту. Тут процес вирощування кадрів, необхідність планомірної роботи з кадровим потенціалом бувають значно ефективнішими за прямий підбір за допомогою інтернет-ресурсів.
У статті розглядаються питання, актуальні для фахівців з роботи з персоналом ІТ-компаній: причинно-наслідкові зв'язки в еволюції виробничих ролей, наслідки неправильного тлумачення змісту ролей для кадрової роботи загалом, а також можливі варіанти підвищення ефективності підбору фахівців.
ІТ-виробництво для непосвячених
Хто є хто в ІТ – це тема для дискусій на різних майданчиках. Вона існує стільки, скільки взагалі вся ІТ-індустрія, тобто з появи на споживчому ринку перших компаній-розробників софту на початку 90-х років минулого століття. І стільки ж часу немає єдиного погляду на це питання, що створює труднощі та знижує ефективність кадрової роботи. Спробуймо в ньому розібратися.
Для мене тема виробничих ролей в ІТ-сфері стала актуальною та цікавою з моменту мого приходу в ІТ-компанію. Мною було витрачено багато часу та нервової енергії на те, щоб розібратися у виробничому процесі. Ці витрати перевищили мої очікування та витрати на адаптацію до процесів в інших сферах: освіті, матеріальному виробництві, малому бізнесі. У мене було розуміння, що процеси складні й незвичні, оскільки, загалом, людина адаптованіша до матеріального світу, ніж до віртуального. Але був інтуїтивний опір: здавалося, що щось тут не те, то не повинно бути. Процес адаптації зайняв, напевно, рік, що, на мою думку, просто космічна величина. У результаті у мене склалося досить чітке уявлення про ключові ролі в ІТ-виробництві.
На даний час я продовжую працювати над цією темою, але вже на іншому рівні. У ролі керівника центру розробки ІТ-компанії мені часто доводиться спілкуватися зі студентами, викладачами вузів, абітурієнтами, школярами та іншими бажаючими взяти участь у створенні ІТ-продукту для просування бренду роботодавця на ринку праці нової території (м. Ярославль). Це спілкування дається непросто через низьку поінформованість співрозмовників у тому, як організований процес розробки програмного забезпечення (ПЗ), і, як наслідок, нерозуміння ними предмета розмови. Через 5 – 10 хвилин діалогу перестаєш отримувати зворотний зв'язок і починаєш почуватися іноземцем, мова якого вимагає перекладу. Як правило, серед співрозмовників перебуває хтось, який підбиває межу в діалозі і озвучує народний міф з 90-х: «Все одно, всі айтішники – програмісти». Джерела виникнення міфу такі:
- ІТ-галузь бурхливо розвивається, у умовах всі основні смисли і принципи перебувають у стадії формування;
- в умовах невизначеності існувати складно, тому людина намагається полегшити розуміння невідомого, створюючи міфи;
- людина більш звична до сприйняття матеріального світу, ніж віртуального, у зв'язку з чим йому складно давати визначення поняттям, що знаходяться за межами його сприйняття.
Спроби боротьби з цим міфом іноді нагадують бій з вітряками, оскільки є кілька аспектів проблеми, які потребують опрацювання. Кадровому фахівцю необхідно, по-перше, мати чітку картину виробничих ролей в ІТ-компанії в ідеальному та реальному втіленні, по-друге, розуміти, як і коли може бути найбільш ефективно задіяний внутрішній ресурс компанії, по-третє, які реальні методи допоможуть підвищити поінформованість учасників ринку праці та сприятимуть розвитку бренду роботодавця. Розглянемо ці аспекти докладніше.
Життєвий цикл ПЗ як основа виробничих ролей
Не секрет, що в цілому всі виробничі ролі в будь-якій ІТ-компанії мають як джерело життєвий цикл програмного забезпечення. Тому, якщо ставити концептуальне завдання домовитися про єдність сприйняття цього питання в рамках усієї ІТ-галузі, треба спиратися саме на життєвий цикл ПЗ як на смислову основу, що приймається і однозначно розуміється всіма. Обговорення конкретних варіантів реалізації питання про виробничі ролі лежить у площині нашого творчого ставлення до життєвого циклу програмного забезпечення.
Отже, розглянемо етапи, які включає життєвий цикл ПЗ, на прикладі RUP-методології. Вони є досить сформованими ланками у частині змісту та термінології. Виробничий процес завжди і скрізь починається з бізнес-моделювання та формування вимог, а завершується (умовно, звичайно) консультуванням користувачів та доопрацюванням програмного забезпечення на основі «хотелок» користувачів.
Якщо здійснити історичний екскурс наприкінці минулого століття (як відомо, це був період «острівцевої автоматизації»), то можна побачити, що всім процесом створення програмного забезпечення займався програміст-розробник. Тут коріння міфу у тому, кожен айтішник – це програміст.
З ускладненням виробничих процесів, появою інтегрованих платформ та переходом до комплексної автоматизації предметних областей, з реінжинірингом бізнес-процесів стає неминучою поява спеціалізованих ролей, прив'язаних до етапів життєвого циклу. Ось так з'являються аналітик, тестувальник та спеціаліст техпідтримки.
Розмаїття посад з прикладу ролі аналітика
Аналітик (він же інженер-аналітик, він постановник, методолог, бізнес-аналітик, системний-аналітик і т.д.) допомагає «подружитися» бізнес-завданням і технологіям їх реалізації. Опис постановки завдання розробника – так можна охарактеризувати основну функцію абстрактного аналітика. Він виступає сполучною ланкою між клієнтом та розробником у процесах формування вимог, аналізу та проектування ПЗ. У реальних виробничих умовах перелік функцій аналітика визначається способом організації виробництва, кваліфікацією спеціаліста, специфікою предметної області, що моделюється.
Частина аналітиків знаходиться ближче до клієнта. Це бізнес-аналітики (Business Analyst). Вони глибоко розуміють бізнес-процеси предметної галузі і є експертами автоматизованих процесів. Дуже важливою є наявність таких фахівців у штаті підприємства, особливо при автоматизації методологічно складних предметних областей. Зокрема, для нас як автоматизаторів бюджетного процесу держави просто необхідно, щоби серед аналітиків були експерти предметної галузі. Це висококваліфіковані співробітники з гарною фінансово-економічною освітою та досвідом роботи у фінансових органах, бажано у ролі провідних фахівців. Вкрай важливий досвід роботи над ІТ-сфері, саме у предметної області.
Інша частина аналітиків більш наближена до розробників. Це системні аналітики (System Analyst). Їхнє основне завдання — виявлення, систематизація та аналіз вимог клієнта щодо можливості їх задоволення, підготовка технічних завдань та опис постановок завдання. Вони розбираються не тільки в бізнес-процесах, але і в інформаційних технологіях, добре представляють можливості програмного забезпечення, що поставляється клієнту, мають навички проектування і, відповідно, розуміють, як краще донести розробнику інтереси клієнта. Ці співробітники обов'язково мають освіту у сфері ІКТ та інженерно-технічний склад розуму, бажано – досвід роботи в ІТ. При підборі таких спеціалістів явним плюсом буде наявність навичок проектування із застосуванням сучасних інструментів.
Ще один різновид аналітиків – технічні письменники (Technical Writer). Вони займаються документуванням у рамках процесів розробки програмного забезпечення, готують посібники користувача та адміністратора, технологічні інструкції, навчальні відеоматеріали тощо. Їхнє основне завдання – зуміти донести до користувачів та інших зацікавлених осіб інформацію про роботу програми, описати технічно складні речі лаконічно та зрозуміло. Технічні письменники, у своїй масі, чудово володіють російською мовою, при цьому мають технічну освіту та аналітичний склад розуму. Для таких фахівців найбільше значення мають навички складання зрозумілих, грамотних, докладних технічних текстів відповідно до стандартів, а також знання та володіння інструментами документування.
Таким чином, ми бачимо ту саму роль (і, до речі, посаду в штатному розкладі) – аналітик, але в різних її конкретно-прикладних втіленнях. Пошук фахівців кожного з них має свої особливості. Важливо знати, що ці різновиди аналітиків повинні володіти найчастіше несумісними в одній людині навичками та знаннями. Один – гуманітарій, схильний до аналітичної роботи з великими обсягами текстових документів, з розвиненою мовою та комунікабельністю, інший – «технар» з інженерним мисленням та інтересами у сфері ІТ.
Беремо збоку чи ростимо?
Для великого представника ІТ-індустрії ефективність прямого підбору з інтернет-ресурсів знижується зі зростанням проектів. Відбувається це, зокрема, з таких причин: неможлива швидка адаптація до складних процесів усередині компанії, швидкість освоєння специфічних інструментів виявляється нижчою за швидкість розвитку проекту. Тому HR-фахівцеві важливо знати не тільки кого шукати зовні, але і як можна задіяти внутрішні ресурси компанії, з кого і як виростити фахівця.
Для бізнес-аналітиків дуже важливий досвід роботи всередині реальних процесів предметної галузі, тому їхній підбір «з боку» ефективніший, ніж вирощування всередині компанії. При цьому HR-фахівцеві важливо знати перелік організацій, які можуть бути джерелами цього кадрового ресурсу, та при підборі зосереджуватись на пошуку резюме з них.
Для закриття таких вакансій, як системний аналітик і архітектор ПЗ, процес підготовки кадрів усередині компанії має величезне значення. Ці фахівці мають сформуватися за умов діючого виробничого середовища та специфіки конкретної організації. Системні аналітики (System Analyst) розвиваються із бізнес-аналітиків (Business Analyst), технічних письменників (Technical Writer) та інженерів техпідтримки (Technical Support Engineer). Архітектори ПЗ (Software Architect) - з проектувальників (System Designer) та розробників ПЗ (Software Developer) у міру накопичення досвіду та розширення кругозору. Ця обставина дозволяє HR-фахівцю ефективно задіяти внутрішні ресурси компанії.
Перетин, об'єднання та еволюція виробничих ролей
Є ще одне непросте з погляду реалізації у виробничому процесі питання – встановлення чітких меж між ролями. На перший погляд може здатися, що все очевидно: закінчилося впровадження, підписали документи про введення програмного забезпечення у промислову експлуатацію та передали все на техпідтримку. Все вірно, проте часто виникають ситуації, коли клієнт, за звичкою перебуваючи в тісному контакті з аналітиком і бачачи в ньому «паличку-виручалочку», продовжує активно спілкуватися з ним, незважаючи на те, що і система вже впроваджена, і формально йде етап супроводу . Однак, з погляду клієнта, хто ж кращий і швидший, ніж аналітик, який разом з ним ставив завдання, відповість на питання щодо роботи з системою. І ось тут постає питання про часткове дублювання ролей інженера техпідтримки та аналітика. З часом все налагоджується, клієнт звикає спілкуватися зі службою техпідтримки, але на самому початку експлуатації ПЗ такий «внутрішній перехід» не завжди виходить без стресів з обох сторін.
Перетин ролей аналітика та інженера техпідтримки виникає ще й тоді, коли потік вимог на розробку йде в рамках етапу супроводу. Повертаючись до життєвого циклу, ми бачимо невідповідність реальних виробничих умов і формальних установок на те, що аналіз вимог і постановка завдання можуть бути виконані виключно аналітиком. Фахівцю з кадрової роботи, безумовно, треба розуміти ідеальну картину ролей у рамках життєвого циклу ПЗ, вони мають чіткі межі. Але в той же час обов'язково слід мати на увазі, що можливе перетинання. При оцінці знань та навичок претендента слід звертати увагу на наявність суміжного досвіду, тобто при пошуку інженерів техпідтримки можуть бути розглянуті кандидати з досвідом аналітика і навпаки.
Крім перетину, часто спостерігається об'єднання виробничих ролей. Наприклад, бізнес-аналітик та технічний письменник можуть існувати в одній особі. Наявність архітектора ПЗ (Software Architect) є обов'язковою у великій промисловій розробці, тоді як зовсім невеликі проекти можуть обійтися без цієї ролі: там функції архітектора виконують розробники (Software Developer).
Зміна історичних періодів у підходах та технологіях розробки неминуче призводить до того, що життєвий цикл ПЗ теж еволюціонує. Глобально, звичайно, основні його етапи залишаються незмінними, але відбувається їх деталізація. Наприклад, з переходом на Web-рішення та зростанням можливостей віддаленого налаштування з'явилася роль фахівця з налаштування ПЗ. На ранньому історичному етапі це були впровадженці, тобто інженери, які більшість робочого часу проводили на робочих місцях клієнтів. Збільшені обсяги та складність ПЗ призвели до появи ролі архітектора ПЗ (Software Architect). Вимоги до прискорення випуску версій та підвищення якості ПЗ сприяли розвитку автоматизованого тестування та появі нової ролі – QA-інженера (Quality Assurance Engineer) тощо. Еволюція ролей усім етапах організації виробничого процесу істотно пов'язані з розвитком методів, технологій і інструментів.
Отже, ми розглянули деякі цікаві моменти щодо розподілу виробничих ролей усередині компанії-розробника ПЗ у контексті життєвого циклу ПЗ. Очевидно, що це погляд зсередини, який є специфічним для кожної компанії. Для нас усіх як учасників ринку праці ІТ-галузі та відповідальних за просування бренду роботодавця особливо важливим буде і погляд зовні. І ось тут існує велика проблема не лише у пошуку смислів, а й у донесенні цієї інформації до цільової аудиторії.
Чим поганий «зоопарк» ІТ-посад?
Плутанина у свідомості HR-фахівців, організаторів виробництва та різноманіття підходів призводять до дуже широкого розмаїття, прямо «зоопарку» ІТ-посад. Досвід співбесід та просто професійних контактів показує, що часто у людей не буває однозначного розуміння смислового навантаження, яке має випливати з назви посад. Наприклад, у нашій організації посади, що включають поняття «інженер-аналітик», припускають, що це є постановником завдань. Однак виявляється, що не скрізь це так: є організації-розробники, де інженер-аналітик – це впроваджений. Зовсім інше розуміння, погодьтеся?
По-перше, «зоопарк» ІТ-посад, безперечно, знижує ефективність підбору персоналу. Кожен роботодавець при розвитку та просуванні свого бренду хоче в стислій формі донести всі сенси, які існують у його виробництві. І якщо він сам часто не може чітко сказати, хто є хто, природно, що він транслюватиме у зовнішнє середовище невизначеність.
По-друге, «зоопарк» ІТ-посад створює величезні проблеми при підготовці та розвитку ІТ-кадрів. Кожна серйозна ІТ-компанія, націлена на те, щоб формувати та розвивати кадровий потенціал, а не просто «доїти» робітні сайти, рано чи трохи пізніше зустрічається із необхідністю взаємодії з навчальними закладами. Для висококваліфікованих ІТ-кадрів, це сегмент вузів, до того ж найкращих, які як мінімум перебувають у рейтингу ТОП-100.
Проблема інтеграції з вузами при вибудовуванні безперервного процесу підготовки ІТ-фахівців полягає приблизно наполовину у відсутності вузів розуміння того, хто є хто всередині ІТ-компанії. Вони мають про це дуже поверхове уявлення. Як правило, вузи мають кілька спеціальностей зі словом «інформатика» в назвах, і часто буває так, що при проведенні ними приймальної кампанії опора робиться на тезу про те, що всі спеціальності по суті про те саме. І це виглядає так само, як якщо спиратися на народний міф про те, що всі айтішники – програмісти.
Досвід нашої тісної співпраці з вишами показує, що спеціальність «Прикладна інформатика (за галузями)» постачає нам кадри для відділів методології та техпідтримки, але аж ніяк не розробки. У той час як "Фундаментальна інформатика", "Програмна інженерія" готують чудовий кадровий ресурс для розробників. Щоб не спрямувати абітурієнта спочатку непридатним для нього шляхом, необхідно «розсіювати туман», що оточує ІТ-виробництво.
Чи можна все привести до спільного знаменника?
Чи можна уніфікувати виробничі ролі та дійти єдиного розуміння їх зсередини та зовні компанії?
Звичайно, можна і потрібно, тому що накопичений колективний досвід усіх підприємств-розробників демонструє наявність спільних концепцій організації виробничого процесу, що об'єднують. Це наслідок того, що все-таки є однозначно всіма поняття життєвого циклу ПЗ, що трактується, і знову з'являються виробничі ролі (DataScientist, QA-Engineer, MachineLearning Engineer і т.д.) є наслідком уточнення та розвитку життєвого циклу ПЗ як такого, що відбуваються з удосконаленням технологій та інструментів, а також з розвитком та укрупненням бізнес-завдань.
У той же час, важко уніфікувати виробничі ролі, тому що ІТ – одна з наймолодших галузей економіки, що бурхливо розвиваються. У певному сенсі це хаос, з якого виник всесвіт. Чітка організаційна структура тут неможлива та недоречна, тому що ІТ – це інтелектуальна, але дуже творча сфера. З одного боку, айтішник – це «фізик»-інтелектуал із розвиненим алгоритмічним та математичним мисленням, з іншого боку, це «лірик»-творець, носій та просуватель ідей. Він, як і художник, немає чіткого плану написання картини, неспроможна розкласти образ на частини, оскільки останній перестане існувати. Він король інформаційних процесів, які самі собою абстрактні, невловимі, важковимірні, але стрімкі.
Шляхи побудови ефективної кадрової роботи у ІТ-виробництві
Отже, важливо знати HR-фахівцю для побудови ефективної кадрової роботи в умовах різноманіття ролей ІТ-виробництва.
По-перше, будь-який фахівець з кадрів ІТ-компанії повинен мати уявлення про ту ситуацію, яка характерна саме для його підприємства: хто і чим займається, хто і як називається, і головне – який сенс вкладається у ці ролі в умовах конкретного виробництва.
По-друге, HR-фахівець повинен мати гнучке уявлення про виробничі ролі. Тобто спочатку у нього формується про них ідеальне розуміння, яке дозволяє йому самому розібратися у всьому. Потім обов'язково має бути реальна картина виробництва: де й у ролі перетинаються, об'єднуються, яке сприйняття цих ролей існує у виробничих керівників. Складність для кадрового фахівця полягає в тому, щоб поєднати у свідомості реальну та ідеальну ситуації, не намагатися насильно перебудовувати процеси під ідеальне їх розуміння, а допомагати виробництву задовольнити потреби в ресурсах.
По-третє, обов'язково слід мати уявлення про можливі траєкторії розвитку тих чи інших фахівців: у якому разі може бути ефективний зовнішній підбір, а коли краще виростити співробітника у своєму колективі, надавши йому можливості для розвитку, які якості кандидатів дозволять їм розвиватися у конкретному напрямку. які з якостей не можуть бути сумісні в одній людині, що спочатку важливо для вибору траєкторії розвитку.
По-четверте, повернемося до тези про те, що ІТ – це сфера висококваліфікованих кадрів, де для більш ефективної кадрової роботи неминуча рання інтеграція з вузівським освітнім середовищем. У цій ситуації кожен HR-фахівець повинен розвивати не тільки навички прямого пошуку, роботи з анкетами та інтерв'ювання, а й обов'язково орієнтуватися в середовищі вузівської підготовки фахівців: які вузи готують кадри для компанії, які спеціальності всередині конкретних вузів закривають кадрові потреби, і що важливо, хто за цим стоїть, хто керує та здійснює підготовку фахівців у вишах.
Таким чином, якщо цілеспрямовано розвінчувати міф про те, що всі айтішники – це програмісти, необхідно зробити цілу низку кроків у цьому напрямку та звернути особливу увагу на наші виші, де закладаються основи сприйняття майбутньої професії. Іншими словами, потрібна постійна взаємодія з освітнім середовищем, наприклад, із використанням сучасного формату спільної роботи в коворкінг-центрах, «точках кипіння», участі в освітніх інтенсивах. Це дозволить зруйнувати невірні уявлення про ІТ-підприємство, підвищить ефективність кадрової роботи та створить умови для спільної діяльності під час підготовки різних спеціалістів нашої галузі.
Висловлюю подяку колегам, які взяли участь у підготовці та підтримці актуальності цієї статті: Валентині Вершиніної та Юрію Крупіну.
Джерело: habr.com