На современном этапе развития промышленной разработки программного обеспечения можно наблюдать многообразие производственных ролей. Их число растет, классификация усложняется с каждым годом, и, естественно, усложняются процессы подбора специалистов и работы с кадровым потенциалом. Информационные технологии (ИТ) – это сфера высококвалифицированных трудовых ресурсов и кадрового дефицита. Здесь процесс выращивания кадров, необходимость планомерной работы с кадровым потенциалом бывают значительно эффективнее прямого подбора с помощью интернет-ресурсов.

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

ИТ-производство для непосвященных

Кто есть кто в ИТ – эта тема для дискуссий на разных площадках. Она существует столько же, сколько вообще вся ИТ-индустрия, то есть с появления на потребительском рынке первых компаний-разработчиков софта в начале 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-специалист должен развивать не только навыки прямого поиска, работы с анкетами и интервьюирования, но и обязательно ориентироваться в среде вузовской подготовки специалистов: какие вузы готовят кадры для компании, какие специальности внутри конкретных вузов закрывают кадровые потребности, и, что важно, кто за этим стоит, кто руководит и осуществляет подготовку специалистов в вузах.

Таким образом, если целенаправленно развенчивать миф о том, что все айтишники – это программисты, необходимо проделать целый ряд шагов в этом направлении и обратить особое внимание на наши вузы, где закладываются основы восприятия будущей профессии. Другими словами, нужно постоянное взаимодействие с образовательной средой, например, с использованием современного формата совместной работы в коворкинг-центрах, «точках кипения», участия в образовательных интенсивах. Это позволит разрушить неверные представления об ИТ-предприятии, повысит эффективность кадровой работы и создаст условия для совместной деятельности при подготовке разных специалистов нашей отрасли.

Выражаю благодарность коллегам, принявшим участие в подготовке и поддержке актуальности этой статьи: Валентине Вершининой и Юрию Крупину.