Правильный ли я делаю вывод, что для вас кандидат, прошедший тестирование с использованием нейронки, является обладателем базовых знаний? Кстати, если не секрет, что показывает ваша статистика об изменении квалификации кандидатов, попавших на техсобес, за последние пару лет?
ИТ-сфера сильно помолодела. Если в 21-м году практически половине соискателей было от 25 до 34 лет, то теперь не более 37%. А доля 18-24 лет увеличилась с 15% до 24%. Остальные возрастные категории (35-44 и 45+) колеблются незначительно (27-29% и 9-11% соответственно).
Это не отрасль "помолодела", а менее возрастных соискателей стало больше. Почему так - можно выдвинуть несколько гипотез, но вряд ли у вас есть данные для из проверки.
Уж если мы обсуждаем статью на ИТ ресурсе, то воспринимаю её как подспорье для айтишников прежде всего. Но у меня есть серьёзные сомнения, что опыт работы в ИТ (не в менеджерских ролях) сколько-нибудь помогает при входе в другие домены. Вот наоборот как раз почти всегда было в плюс айтишнику: если он знаком с предметной областью, то проще понимать заказчика и предмет автоматизации.
Ссылка на вакансии системного аналитика ведёт на поисковый запрос по ключевой фразе с фильтрацией по нескольким специализациям, связанным с анализом; для бэкенд разработчика иначе - в фильтре задана одна соответствующая специализация. Поэтому в результатах поиска СА попадаются БА, дата-аналитики и т.д. Интересно, выборка для исследования так же криво формировалась?
Много раз упоминаются микросервисы - и потому складывается впечатление, что С4 полезна только для иллюстрации таких архитектур. Кстати, на компонентной диаграмме с примером границы микросервисов явно не обозначены, хотя у автора нотации есть рекомендация на сей счёт. На диаграммах также есть неточности, вроде непоследовательности в использовании подписей к стрелкам (REST vs API) или пропущенных названий технологий для реализации компонентов (например: Spring, Rails).
Полагаю, имелось в виду: доказать руководству, что в команде необходим выделенный специалист, который занимается требованиями и проектированием?
Как ни крути, эти активности почти всегда существуют в ИТ проекте; отличие лишь в том, кто их выполняет. Понятно, что обычно владелец бюджета старается минимизировать затраты, в айти - прежде всего ФОТ. И не каждому из них может быть очевидна необходимость в наличии выделенного аналитика (или архитектора, или девопса).
С другой стороны, не на каждом проекте в этом действительно есть смысл: например, при поддержке небольшого продукта, где команда хорошо знает предметку, системный аналитик скорее всего сам будет скучать.
Но если аналитик всё-таки нужен, то это скорее доказывается не через метрики его работы (его привлечение в проект ведь ещё нужно обосновать, верно?), а через оценку негативных последствий того, что члены команды занимаются не профильной для них деятельностью (хотя в некоторых случаях им может быть это даже в кайф).
Вы хорошо описали сам инструмент и даже кратко обозначили пользу от его применения для основных заинтересованных лиц - специалиста и руководителя. Но совсем не раскрыта тема "Зачем это бизнесу?". Я разумеется не рассчитываю на откровения (вроде: иметь больше формальных оснований не повышать сотруднику грейд/зарплату). Скорее хотелось убедиться, что решение было реализовано по явным требованиям внутреннего заказчика, а не просто потому что предыдущий инструмент был неудобным в использовании.
Так как описанное поможет джуну дорасти хотя бы до миддла? Вот ссылаетесь вы на профстандарт... Но взяли из него в осноном лишь обязанности ("трудовые действия"), причём почти везде они относятся к начальному уровню квалификации; остальное как-то осталось за бортом - не пригодится?
Теперь джуниор должен уметь разбираться в устройстве баз данных, проектировать и работать с интеграциями. Важно понимать, как пишется код: ориентироваться в ООП, понимать основные алгоритмы. В общем, сегодня новичкам приходится погружаться в концепции и термины разработки куда глубже, чем при простом формулировании требований по Вигерсу.
Это не от джунов компании стали требовать большего, а в целом произошло смещение фокуса в обязанностях системного аналитика: если раньше они концентрировались на "требованиях", то теперь в большей степени на "решениях". Отсюда и сложность входа в профессию увеличилась - нужно иметь больше навыков, связанных с технологиями, а не только образом мышления.
Ну тут рецепт простой: не надо брать первую десятку из отранжированного списка, а чуть ниже. Это если втупую поступать. А по-хорошему нужно обучить модель оценивать также правдоподобность резюме, используя все тех же рекрутеров.
Почему регуляторный риск применим только для провайдеров из ЕС? Только потому что законодательство в области ИИ там стало формироваться раньше, чем в других регионах?
Нет единого "правильного" набора артефактов и тем более наполнения шаблонов для постановок. Потому что это всё слишком зависит от контекста, в котором эти артефакты планируется применять: состава и компетенций команды, особенностей рабочих процессов, используемых технологий и пр. Поэтому когда в начале статьи вы пишете, что хотите поделиться своим видением, там же где-то надо было обозначить специфику организации работы на вашем проекте.
Делюсь тем, что имею. Если качественно подходить к анализу, то нужно сравнивать данные год к году, конечно. Но по памяти, в абсолютном выражении количество вакансий снизилось за год в несколько раз.
Правильный ли я делаю вывод, что для вас кандидат, прошедший тестирование с использованием нейронки, является обладателем базовых знаний? Кстати, если не секрет, что показывает ваша статистика об изменении квалификации кандидатов, попавших на техсобес, за последние пару лет?
Вывод такого же рода, как например заявить, что в ритейле работают не только кассиры.
Это не отрасль "помолодела", а менее возрастных соискателей стало больше. Почему так - можно выдвинуть несколько гипотез, но вряд ли у вас есть данные для из проверки.
Уж если мы обсуждаем статью на ИТ ресурсе, то воспринимаю её как подспорье для айтишников прежде всего. Но у меня есть серьёзные сомнения, что опыт работы в ИТ (не в менеджерских ролях) сколько-нибудь помогает при входе в другие домены. Вот наоборот как раз почти всегда было в плюс айтишнику: если он знаком с предметной областью, то проще понимать заказчика и предмет автоматизации.
Ссылка на вакансии системного аналитика ведёт на поисковый запрос по ключевой фразе с фильтрацией по нескольким специализациям, связанным с анализом; для бэкенд разработчика иначе - в фильтре задана одна соответствующая специализация. Поэтому в результатах поиска СА попадаются БА, дата-аналитики и т.д. Интересно, выборка для исследования так же криво формировалась?
Много раз упоминаются микросервисы - и потому складывается впечатление, что С4 полезна только для иллюстрации таких архитектур. Кстати, на компонентной диаграмме с примером границы микросервисов явно не обозначены, хотя у автора нотации есть рекомендация на сей счёт. На диаграммах также есть неточности, вроде непоследовательности в использовании подписей к стрелкам (REST vs API) или пропущенных названий технологий для реализации компонентов (например: Spring, Rails).
Полагаю, имелось в виду: доказать руководству, что в команде необходим выделенный специалист, который занимается требованиями и проектированием?
Как ни крути, эти активности почти всегда существуют в ИТ проекте; отличие лишь в том, кто их выполняет. Понятно, что обычно владелец бюджета старается минимизировать затраты, в айти - прежде всего ФОТ. И не каждому из них может быть очевидна необходимость в наличии выделенного аналитика (или архитектора, или девопса).
С другой стороны, не на каждом проекте в этом действительно есть смысл: например, при поддержке небольшого продукта, где команда хорошо знает предметку, системный аналитик скорее всего сам будет скучать.
Но если аналитик всё-таки нужен, то это скорее доказывается не через метрики его работы (его привлечение в проект ведь ещё нужно обосновать, верно?), а через оценку негативных последствий того, что члены команды занимаются не профильной для них деятельностью (хотя в некоторых случаях им может быть это даже в кайф).
Вы хорошо описали сам инструмент и даже кратко обозначили пользу от его применения для основных заинтересованных лиц - специалиста и руководителя. Но совсем не раскрыта тема "Зачем это бизнесу?". Я разумеется не рассчитываю на откровения (вроде: иметь больше формальных оснований не повышать сотруднику грейд/зарплату). Скорее хотелось убедиться, что решение было реализовано по явным требованиям внутреннего заказчика, а не просто потому что предыдущий инструмент был неудобным в использовании.
Так как описанное поможет джуну дорасти хотя бы до миддла? Вот ссылаетесь вы на профстандарт... Но взяли из него в осноном лишь обязанности ("трудовые действия"), причём почти везде они относятся к начальному уровню квалификации; остальное как-то осталось за бортом - не пригодится?
Распределение навыков по грейдам сделано исключительно на основе персонального опыта?
Насколько корректно экстраполировать данные из вакансий в одном ТГ-канале на весь рынок найма QA-специалистов?
Это не от джунов компании стали требовать большего, а в целом произошло смещение фокуса в обязанностях системного аналитика: если раньше они концентрировались на "требованиях", то теперь в большей степени на "решениях". Отсюда и сложность входа в профессию увеличилась - нужно иметь больше навыков, связанных с технологиями, а не только образом мышления.
Что-то мне подсказывает, что в этом уравнении учитывается только объём выполненной работы, но не качество результата.
Ну тут рецепт простой: не надо брать первую десятку из отранжированного списка, а чуть ниже. Это если втупую поступать. А по-хорошему нужно обучить модель оценивать также правдоподобность резюме, используя все тех же рекрутеров.
Почему регуляторный риск применим только для провайдеров из ЕС? Только потому что законодательство в области ИИ там стало формироваться раньше, чем в других регионах?
Подождите ещё лет 10, и возможно, Гугл и такое сообразит сделать. :-)
Нет единого "правильного" набора артефактов и тем более наполнения шаблонов для постановок. Потому что это всё слишком зависит от контекста, в котором эти артефакты планируется применять: состава и компетенций команды, особенностей рабочих процессов, используемых технологий и пр. Поэтому когда в начале статьи вы пишете, что хотите поделиться своим видением, там же где-то надо было обозначить специфику организации работы на вашем проекте.
Делюсь тем, что имею. Если качественно подходить к анализу, то нужно сравнивать данные год к году, конечно. Но по памяти, в абсолютном выражении количество вакансий снизилось за год в несколько раз.
Чем эта иллюстрация из первоисточника не устраивает?