Кто есть кто в ИТ?



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

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

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


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

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

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

    Комментарии 15

      0
      Странно, что аналитиков классифицировали. А разработчиков под одну гребенку. Системные аналитики есть, а системных архитекторов нет. Однобоко. А бизнес-аналитик — это чаще всего не IT.
        0

        В данном контексте не важно есть ли бизнес-аналитики не в ИТ, важно что они нужны во многих бизнес-моделях ИТ.

          +1
          Бизнес-аналитики крайне необходимы в тех ИТ-продуктах, где терминологически и методологически сложные предметные области (финансы, банковское ПО и т.д.) и эти сложные процессы должны быть квалифицировано описаны (кем? — аналитиком), в таких проектах (продуктах) без аналитиков просто не обойтись.
          0
          Архитекторы упомянуты на самом деле, когда речь идет про разработчиков, в том контексте, что как раз архитектора лучше вырастить в своем коллективе, из действующих разработчиков, нежели взять со стороны.
          Про бизнес-аналитиков — да, действительно они не ИТ, но они же участвуют непосредственно в создании ИТ-продукта, ставят задачи разработчикам, описывают предметную область, по всей видимости, их можно все-таки отнести к непосредственным участникам ЖЦ ПО.
            0

            Тут наверное все слишком кастомно для каждого проекта. В отличие от аналитиков которые как то более менее чётко делятся на роля или роли.

            0
            Меня одного порадовал Инженер-ТП и прилагающиеся к нему картинки?
              0

              Хорошая статья, хоть и не совсем по своему названию

                +2

                Классификация около-ИТ-шных технарей.


                • По специализации, грубо, с привязкой к жизненному циклу.
                  1. Проектирование и разработка: инженеры-проектировщики (это вот, которые в статье выведены, как все и всяческие аналитики обозваны): техники-программисты (это вот те, которые разработчиками называются);
                  2. Тестирование: инженеры-тестировщики (разработка тестовых ситуаций и проектирование тестовых сценариев); техники-тестировщики (автоматизация тестовых сценариев);
                  3. Эксплуатация: инженеры по эксплуатации (у иностранцев это 3-я линия техподдержки, потребность весьма невелика), техники-эксплуататоры — это вот, которые именуются системными администраторами; операторы-эксплуататоры, в этом направлении данная категория бывает необходима;
                  4. и за всем этим безобразием на всех этапах бдит информационная безопасность.

                Когда уделяется недостаточное внимание хотя бы одной составляющей, на выходе получается неэксплуатабельное непотребство. Примеров — ж/д состав и маленькая тележка.


                • по квалификации:
                  1. инженер — проектирование, главный рабочий орган — голова, нашпигованная нужными знаниями; образование — советское профильное высшее; (ОБРАЗОВАНИЕ, а не диплом о таковом!)
                  2. техник — реализация проектов, главный рабочий орган — руки, управляемые СОБСТВЕННОЙ головой; образование — советское профильное незаконченное высшее (профильная советская вышка на этом уровне квалификации — существенно излишне), современное профильное высшее, советское профильное среднеспециальное, среднетехническое;
                  3. оператор — принеси, подай, отвали и не мешай, главный рабочий орган — руки под ВНЕШНИМ управлением (техника/инженера), думать на этом уровне квалификации сотруднику должно быть запрещено, ибо нечего.

                Более развёрнуто по квалификации — это весьма объёмно и сильно не вдруг. Основная проблема отрасли в том, что в Советском Союзе, по многим причинам, не сформировалась методология и прочая дисциплина (не говоря уже о культуре!) производства ПО.
                Ибо производство, как таковое, имеет свои законы, независимые от предметной области. Когда эти законы попираются, на выходе получается что попало, чем пользоваться весьма затруднительно. А те, кто должен был, по идее, формировать эту методологию и культуру в ИТ, вместо этого закопались в кодинг на различных языках программирования. Но это ещё один материал, ещё более объёмный и более не вдруг. Ибо пинать аксакалов (а их пинать надо!) — дело тяжкое, т.к. надо перелопать горы воспоминаний, и неблагодарное: как?! Аксакала пинать?! Да ты кто такое?!


                Ну и по самой статье:


                Информационные технологии (ИТ) – это сфера высококвалифицированных трудовых ресурсов

                У меня серьёзные сомнения в соответствии этого заявления действительному положению вещей.


                народный миф из 90-х: «Всё равно, все айтишники – программисты».

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

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

                  И что-же по поводу отмеченных в статье выше аналитиков – те, которые именно бизнес и системные (а не «все и всяческие»)? Какова реальная потребность в них?

                  Почему сильно интересует этот вопрос – матерые программисты зачастую начинают сильно возмущаться в комментариях на Хабре, когда слышат о новом кандидате «войти в ИТ». Но ведь не одними программистами держится индустрия ИТ.
                    0
                    Процентное соотношение около-ИТ-шных специальностей сильно зависит от того ИТ-продукта, который производит компания, чем сложнее предметная область (финансы, банки и т.д), чем больше у ИТ-продукта пользователей экспертного уровня в предметке, тем выше процент около-ИТшных специалистов в производственном процессе. Примерно можно обозначить: 20-30% — удельный вес разработчиков в общем объеме производственных сотрудников (именно производственных, т.е. тех кто участвует в ЖЦ ПО). Этот показатель справедлив для методологически и терминологически сложных предметных областей, основан на опыте нашем и не только, но без претензии на абсолютную справедливость.
                      +1
                      матерые программисты зачастую начинают сильно возмущаться в комментариях на Хабре, когда слышат о новом кандидате «войти в ИТ»

                      И это совсем неудивительно. ИТ — это ТЕХНИЧЕСКАЯ отрасль. А это значит, что, как в любой другой технической отрасли, необходимо получить базовые знания и умения в соответствующем учебном заведении. Ибо одни и те же вопросы новичков, которые решили, что в ИТ мёдом намазано, а образование — это такая прихоть, они, эти вопросы:


                      1. освещаются в учебном заведении;
                      2. одинаковы до безобразия.

                      По несколько раз в день в, например, чате читать: я новичок, что мне почитать для начала — это очень сильно не для слабонервных; Новичок? Иди-ка, родной, в учебное заведение, получи образование.


                      И что-же по поводу отмеченных в статье выше аналитиков – те, которые именно бизнес и системные (а не «все и всяческие»)? Какова реальная потребность в них?

                      Те современные аналитики, что системные, что прикладные, которые мне встречаются лично, о/и которых я читаю, в моё время были прикладными инженерами-проектировщиками. Т.е. нас с самого первого курса натаскивали на то, что основная задача такого инженера — это перевод человеческого языка/профсленга заказчика на понятный техникам-программистам язык ТЗ. У таких ребят, де-факто, две вышки: 1-я — наша (программное обеспечение вычислительной техники и автоматизированных систем и смежные) и прикладная; потребность — зависит от сложности прикладного продукта, на тиражируемый коммерческий, как минимум, один быть в наличии обязан. Но это в каком-то совсем простом и узконишевом продукте, обычно же на приличную систему нужно несколько человек. Пусть сами аналитики расскажут, если захотят. :) Тут ещё профдеформация: отказоустойчивость, в данном случае к пропаданию кадра — это вот резервирование ресурсов, т.е. один аналитик — это не отказоустойчивый продукт. Фигура, на самом деле, как и все остальные инженеры — из ключевых.


                      Не могли бы раскрыть потребность отрасли (хотя бы очень примерно) в процентном соотношении в упомянутых вами специалистах.

                      Тяжело. Очень тяжело. Но попробую.


                      • Операторы. Очень мало. Только в ДЦ и крупных интеграторах, когда техника гонять ставить сервера в стойки, втыкать МАРКИРОВАННЫЕ патч-корды по утверждённой схеме — это сильно непродуктивно для компании. Как я уже писал, имеют смысл только в эксплуатации.
                      • Техники — самый многочисленный слой, ~90%, если не больше, всех ИТ-технарей: это разработка по ТЗ; это автоматизация тестирования по разработанным тестовым случаям и ситуациям; это эксплуатация во всех её проявлениях, от установки систем до решения проблем в процессе эксплуатации.
                      • Инженеры. Мало.
                        Разработка. Я сказал выше, добавлю, что на инженера-проектировщика ложится задача выбора ЯП.
                        Тестирование. Инженер-тестировщик в предметной области должен соображать не вот уж хуже, чем инженер-проектировщик. И его задача — 1) при проработке ТЗ тестировать условия на непротиворечивость; 2) прокачивать тестовые ситуации, как положительные, так и отрицательные (вот, кстати, отрицательные тестовые ситуации — они, при отсутствии выделенного тестировщика, очень, ОЧЕНЬ часто не рассматриваются, а зря!);
                        Безопасность. Мало. Если есть безопасники-технари, пусть лучше сами чего-нибудь скажут.
                        Эксплуатация. Исчезающе мало. Сфера — крупные ЦОД-ы, интеграторы, операторы связи, проекты, использующие сотни и тысячи физических узлов. При эксплуатации коммерческих систем, образующих гомогенную структуру, в подавляющем большинстве случаев, не требуются от слова совсем. Просто потому, что решения инженерных задач такие системы не предусматривают. Эти задачи решаются разработчиками компании-производителя разворачиваемой системы.
                        0
                        Обстоятельно отвечаете. Впечатлен глубиной вашего вовлечения в данную тему. Повезло вашим коллегам как по горизонтали, так и по вертикали – при внимательном прочтении текста (а мне почему-то кажется, что и в рабочем процессе используете такой письменный подход) последующие вопросы должны сами собой отпадать. Мне самому симпатизирует такой подход, поскольку не перестаёт доказывать свою практичность.

                        Бизнес-аналитики – отпишитесь, как добываете свой хлеб в полях.

                        По поводу реакции отторжения к вновь прибывшим в ИТ после штурмовых курсов (кем-то тут на Хабре такое название было введено) – это вполне закономерное явление. К сожалению, мало кто из возмущённых ведёт просветительскую работу в части дальнейшего расширения кругозора в предметной области.
                      +1
                      Абсолютно верно сказано, что бухгалтеры, кадровики и т.д. не должны владеть навыками кодирования, но коль скоро мы все-таки ограничены этапами жизненного цикла ПО, то они все (бухи, кадры и др.) остаются за его пределами, вот насчет ИТ-шников-околопрограммистов — вопрос дискуссионный — возможно они должны хотя бы иметь представление об алгоритмизации, о том какие есть инструменты разработки и в чем их суть, но это из раздела «знания», а вот нужны ли им реальные навыки разработки — наверное даже нет, ну или в минимальном объеме.
                      Насчет пробелов Советского Союза в части формирования культуры — как мы помним он почил в конце 1991 года, когда ИТ-отрасль только зарождалась. К тому же, отрасль абсолютно новая для всей экономики, поскольку сфера нематериального производства, применить к ней подходы материальных отраслей экономики возможно и пытались, поскольку многие нынешние софтверные компании начинали со сборки ПК, но мы же с вами понимаем, что все непросто.
                        0
                        вот насчет ИТ-шников-околопрограммистов — вопрос дискуссионный

                        Если речь про сисадминов, то переход в облака (SaaS/PaaS) может вновь повысить требования к их квалификации, так как провайдеры убирают тупую рутину по обслуживанию ПО и закрывают кучу вакансий, поэтому компании смогут выбирать лучших из лучших.
                      0
                      Можно ли унифицировать производственные роли и прийти к единому пониманию их изнутри и снаружи компании?

                      Конечно, можно и нужно


                      image

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое