Кто есть кто в ИТ-индустрии

На текущий момент в ИТ-индустрии наблюдается многообразие ролей. Их число растет с каждым годом и усложняется классификация. Как следствие усложняются процессы подбора специалистов и работа с кадровым персоналом.

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

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

Дискуссии на тему “Кто есть кто в ИТ” ведутся на практически всех площадках. Сама тема существует столько же сколько и сама индустрия. И столько же времени отсутствует единый ответ на этот вопрос. Попробуем в нем разобраться.

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

Я продолжил работу над этой темой и когда стал руководителем отдела веб-проектов, но уже на другом уровне. Мне пришлось по долгу работы общаться с выпускниками вызов приходящих на стажировки или устраивающихся на работу, руководителями и сотрудниками смежных отделов с которыми запускались совместные проекты. Такое общение дается очень непросто в основном в силу низкого уровня информированности собеседника о том как организован процесс разработки программного обеспечения, ну и как следствие – непонимание собеседником предмета диалога. Через 10-15 минут подобного диалога возникает чувство иностранца, который не может общаться без своего переводчика. В этот момент диалога зачастую собеседник подводит черту вида “Все равно все айтишники – программисты”. Но это миф, источники которого таковы:

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

Борьба с этим мифом напоминает бой с ветряными мельницами. Но для упрощения борьбы есть несколько аспектов которые необходимо проработать. Для начала у кадрового специалиста должна быть четкая картина ролей в ИТ-компании как в реальном так и в идеальном воплощении. Далее ему необходимо понимание как и когда можно эффективно задействовать внутренний ресурс компании. Ну и напоследок какие реальные методы могут повысить информированность как внутреннего ресурса так и участников рынка труда чтобы повысить развитие бренда. Рассмотрим эти аспекты.

Жизненный цикл ПО – основа для ролей

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

Для начала давайте рассмотрим этапы из которых состоит жизненный цикл ПО. В качестве источника этапов возьмем методологию RUP, так как в ней достаточно давно и хорошо сформированы этапы и все звенья жизненного цикла ПО особенно в части содержания и терминологии.

Всегда и везде производственный процесс начинается с бизнес-моделирования и формирования требований. Завершается же он консультированием пользователей и доработками ПО на основе хотелок пользователей.

Если окунуться в прошлое, то можно заметить, что ранее всем процессом создания ПО занимался программист-разработчик. Отсюда и пошел миф о том, что каждый айтишник – программист.

Однако с усложнением производственного процесса, появлением интегрированных платформ и переходом к комплексной автоматизации, реинжинирингом бизнес-процессов стало неизбежным появление отдельных специализированных ролей, связанных с определенными этапами жизненного цикла ПО. Так появились роли аналитика, тестировщика и специалиста поддержки.

Многообразие должностей на примере аналитика

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

Описывать постановку задачи для разработчика – такими словами можно вкратце охарактеризовать основную функцию аналитика. Аналитик это связующее звено между клиентом и разработчиком при: формировании требований, анализ и проектирование ПО. В реалиях производственных условий объем функций аналитика определяется способом организации производства, квалификацией специалиста и спецификой моделируемой предметной области.

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

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

Есть еще одна разновидность аналитиков – технические писатели. Они занимаются документированием в рамках процесса разработки программного обеспечения, составляют различные руководства и инструкции, обучающие материалы и т.п. Их основная задача – донести до пользователя информацию о работе программы и сложных технических вещах лаконичным и понятным языком. Как правило технические писатели хорошо владеют языком на котором необходимо писать, имеют техническое образование и аналитический склад ума. Для такого специалиста важными навыками являются: составление понятных, грамотных и подробных текстов, а также знания и владение инструментами документирования.

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

Брать со стороны или растить

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

Для бизнес-аналитиков важен опыт работы внутри реальных процессов предметной области и их подбор со стороны будет более эффективным, чем выращивание внутри компании. Но в этом случае HR-специалист должен знать какие организации можно рассматривать в качестве потенциального источника этого кадрового ресурса.

Для закрытия таких вакансий как системный аналитик и архитектор ПО, процесс подготовки кадров внутри компании играет очень важную роль. Эти специалисты должны сформироваться в условиях действующей производственной среды и специфики работы конкретной организации. Системные аналитики развиваются из бизнес-аналитиков, технических писателей и инженеров техподдержки. Архитекторы ПО – из проектировщиков и разработчиков ПО. Эти обстоятельства позволяют HR эффективно задействовать внутренние ресурсы компании.

Пересечение, объединение, эволюция производственных ролей

Еще одним непростым вопросом является установление четких границ между ролями. На первый взгляд все кажется очевидным: закончили внедрять, подписали документы о вводе в эксплуатацию и передали все техподдержке. Это все верно, однако часто возникают ситуации когда клиент находясь по привычке в тесном контакте с аналитиком видит в нем “палочку-выручалочку” и продолжает с ним активно общаться, несмотря на то, что внедрение уже закончилось и началось сопровождение. С точки зрения клиента, лучше и быстрее, чем аналитик, который вместе с ним ставил задачи, не ответит на его вопросы по работе с системой. Но с течением времени все налаживается, клиент привыкает общаться со службой поддержки, но в самом начале эксплуатации ПО такой “внутренний переход” не всегда получается сделать без затрат нервов и стрессов с обеих сторон.

Пересечению ролей аналитика и инженера поддержки способствует еще и поток требований на разработку в период этапа сопровождения. Если вернуться к жизненному циклу ПО, то будет видно несоответствие реалий производственных условий формальным требованиям к тому, что анализ требований и постановка задачи могут выполняться только аналитиком. В этом случае от кадрового специалиста требуется понимание идеальной картины ролей в рамках жизненного цикла ПО и их четкие границы, но в то же время обязательно иметь ввиду что возможно и пересечение ролей. При оценке навыков и знаний следует обращать внимание на наличие смежного опыта.

Помимо пересечения существует и объединение производственных ролей. Например бизнес-аналитик и технический писатель в одном лице. Наличие архитектора ПО обязательно при крупной промышленной разработке, но небольшие проекты вполне обойдутся без этой роли.

Эволюция в подходах и технологиях разработки ведет и к эволюции жизненного цикла ПО. В глобальном плане его этапы остаются неизменными, но происходит их детализация. Например, переход на Веб-решения и рост возможностей удаленной настройки привели к появлению роли специалиста по настройке ПО. На ранних исторических этапах этим занимались внедренцы (инженеры проводившие большую часть времени на рабочих местах клиентов). Требования к скорости выпуска версий и повышенному качеству ПО привели к появлению роли QA-инженера. Возросшие объемы и сложность ПО – архитектора ПО. Эволюция ролей на всех этапах организации производственного процесса тесно связана с развитием методов, технологий и инструментов.

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

Что плохого в многообразии должностей

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

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

Еще одной проблемой, которую создает многообразие должностей является подготовка и развитие кадров. В ИТ-компании нацеленной на развитие и формирование кадрового потенциала, а не на использование “работных” сайтов в качестве вечного источника, рано или поздно встает необходимость взаимодействия с учебными заведениями, как минимум находящимся в рейтинге ТОП-100.

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

Устранить эту проблему можно развеяв для вуза туман, который окружает ИТ-производство и изначально не направлять абитуриента по непригодному для него пути. Например специальность “Программная инженерия” готовит кадровый ресурс для разработчиков, в то время как “Прикладная информатика” – методологов, специалистов технической поддержки.

Можно ли прийти к общему знаменателю?

Возможно ли унифицировать роли производства и прийти к единому пониманию изнутри и снаружи компании? Конечно, да. И очень нужно это сделать. Так как накопленный коллективный опыт всех предприятий-разработчиков демонстрирует наличие общих концепций организации производственного процесса. Это является следствием однозначного трактования самого понятия “жизненный цикл ПО”. Появляющиеся новые производственные роли (Data Scientist, QA Engineer и т.д.) являются следствием уточнения и развития жизненного цикла ПО как такового.

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

Возможный путь построения эффективной кадровой работы в ИТ

Для HR в ИТ-компании важно знать следующее:

1. Понимать ситуацию с ролями в производстве характерную для этого предприятия. Кто как называется и чем занимается. Какое место отводится каждой роли в производственном процессе.
2. Гибкое представление о производственных ролях, то есть о значении этой роли не только в рамках текущего предприятия, но и в индустрии в целом. Должна быть идеальная картина производства, которая будет ему помогать разобраться в реальной. Основная сложность здесь как раз в том, что бы совместить идеальное представление с реальным.
3. Иметь представления о векторах развития каждого специалиста. Когда нужен внешний подбор, а где стоит вырастить сотрудника внутри.
4. Не забывать о том, что возможно предстоит неизбежная интеграция с вузовской образовательной деятельностью. В этом случае нужно развивать не только навыки прямого поиска и работы с анкетами и проведения интервью, но и ориентирования в среде вузовской подготовки специалистов. Какие специальности в каком вузе могут подготовить потенциальных кандидатов, кто за этим стоит и кто руководит.

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

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