Как стать автором
Обновить

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

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

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

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

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

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

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

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


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

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


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

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


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


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

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


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

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

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

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

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

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


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

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


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

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


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

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


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

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

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

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

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


image
Зарегистрируйтесь на Хабре, чтобы оставить комментарий