Уж если мы обсуждаем статью на ИТ ресурсе, то воспринимаю её как подспорье для айтишников прежде всего. Но у меня есть серьёзные сомнения, что опыт работы в ИТ (не в менеджерских ролях) сколько-нибудь помогает при входе в другие домены. Вот наоборот как раз почти всегда было в плюс айтишнику: если он знаком с предметной областью, то проще понимать заказчика и предмет автоматизации.
Ссылка на вакансии системного аналитика ведёт на поисковый запрос по ключевой фразе с фильтрацией по нескольким специализациям, связанным с анализом; для бэкенд разработчика иначе - в фильтре задана одна соответствующая специализация. Поэтому в результатах поиска СА попадаются БА, дата-аналитики и т.д. Интересно, выборка для исследования так же криво формировалась?
Много раз упоминаются микросервисы - и потому складывается впечатление, что С4 полезна только для иллюстрации таких архитектур. Кстати, на компонентной диаграмме с примером границы микросервисов явно не обозначены, хотя у автора нотации есть рекомендация на сей счёт. На диаграммах также есть неточности, вроде непоследовательности в использовании подписей к стрелкам (REST vs API) или пропущенных названий технологий для реализации компонентов (например: Spring, Rails).
Полагаю, имелось в виду: доказать руководству, что в команде необходим выделенный специалист, который занимается требованиями и проектированием?
Как ни крути, эти активности почти всегда существуют в ИТ проекте; отличие лишь в том, кто их выполняет. Понятно, что обычно владелец бюджета старается минимизировать затраты, в айти - прежде всего ФОТ. И не каждому из них может быть очевидна необходимость в наличии выделенного аналитика (или архитектора, или девопса).
С другой стороны, не на каждом проекте в этом действительно есть смысл: например, при поддержке небольшого продукта, где команда хорошо знает предметку, системный аналитик скорее всего сам будет скучать.
Но если аналитик всё-таки нужен, то это скорее доказывается не через метрики его работы (его привлечение в проект ведь ещё нужно обосновать, верно?), а через оценку негативных последствий того, что члены команды занимаются не профильной для них деятельностью (хотя в некоторых случаях им может быть это даже в кайф).
Вы хорошо описали сам инструмент и даже кратко обозначили пользу от его применения для основных заинтересованных лиц - специалиста и руководителя. Но совсем не раскрыта тема "Зачем это бизнесу?". Я разумеется не рассчитываю на откровения (вроде: иметь больше формальных оснований не повышать сотруднику грейд/зарплату). Скорее хотелось убедиться, что решение было реализовано по явным требованиям внутреннего заказчика, а не просто потому что предыдущий инструмент был неудобным в использовании.
Так как описанное поможет джуну дорасти хотя бы до миддла? Вот ссылаетесь вы на профстандарт... Но взяли из него в осноном лишь обязанности ("трудовые действия"), причём почти везде они относятся к начальному уровню квалификации; остальное как-то осталось за бортом - не пригодится?
Теперь джуниор должен уметь разбираться в устройстве баз данных, проектировать и работать с интеграциями. Важно понимать, как пишется код: ориентироваться в ООП, понимать основные алгоритмы. В общем, сегодня новичкам приходится погружаться в концепции и термины разработки куда глубже, чем при простом формулировании требований по Вигерсу.
Это не от джунов компании стали требовать большего, а в целом произошло смещение фокуса в обязанностях системного аналитика: если раньше они концентрировались на "требованиях", то теперь в большей степени на "решениях". Отсюда и сложность входа в профессию увеличилась - нужно иметь больше навыков, связанных с технологиями, а не только образом мышления.
Ну тут рецепт простой: не надо брать первую десятку из отранжированного списка, а чуть ниже. Это если втупую поступать. А по-хорошему нужно обучить модель оценивать также правдоподобность резюме, используя все тех же рекрутеров.
Почему регуляторный риск применим только для провайдеров из ЕС? Только потому что законодательство в области ИИ там стало формироваться раньше, чем в других регионах?
Нет единого "правильного" набора артефактов и тем более наполнения шаблонов для постановок. Потому что это всё слишком зависит от контекста, в котором эти артефакты планируется применять: состава и компетенций команды, особенностей рабочих процессов, используемых технологий и пр. Поэтому когда в начале статьи вы пишете, что хотите поделиться своим видением, там же где-то надо было обозначить специфику организации работы на вашем проекте.
Делюсь тем, что имею. Если качественно подходить к анализу, то нужно сравнивать данные год к году, конечно. Но по памяти, в абсолютном выражении количество вакансий снизилось за год в несколько раз.
Честно, не уловил, какой классификации нет у Вигерса. Но более принципиально вот что: как ваши дополнения упрощают практическое применение этой классификации требований?
Надо как минимум сравнить ответы на отклики на сеньорские позиции. Для этого можно сделать два резюме: условного молодого специалиста (скажем, 32 лет) и "возрастного" (те же 52 года); у обоих должен быть на бумаге одинаковый опыт в ИТ, но если первый сразу после универа попал в отрасль, то второй через 15-20 лет работы в другой сфере (не обязательно смежной).
Кому интересно глубже понять принцип работы матрицы цифрового фотика и как отличается "проявка" кадра в digital-эру от "плёночных" времён, советую послушать запись лекции создателей RAW Photo Processor: https://raw-rpp.livejournal.com/3604.html
Уж если мы обсуждаем статью на ИТ ресурсе, то воспринимаю её как подспорье для айтишников прежде всего. Но у меня есть серьёзные сомнения, что опыт работы в ИТ (не в менеджерских ролях) сколько-нибудь помогает при входе в другие домены. Вот наоборот как раз почти всегда было в плюс айтишнику: если он знаком с предметной областью, то проще понимать заказчика и предмет автоматизации.
Ссылка на вакансии системного аналитика ведёт на поисковый запрос по ключевой фразе с фильтрацией по нескольким специализациям, связанным с анализом; для бэкенд разработчика иначе - в фильтре задана одна соответствующая специализация. Поэтому в результатах поиска СА попадаются БА, дата-аналитики и т.д. Интересно, выборка для исследования так же криво формировалась?
Много раз упоминаются микросервисы - и потому складывается впечатление, что С4 полезна только для иллюстрации таких архитектур. Кстати, на компонентной диаграмме с примером границы микросервисов явно не обозначены, хотя у автора нотации есть рекомендация на сей счёт. На диаграммах также есть неточности, вроде непоследовательности в использовании подписей к стрелкам (REST vs API) или пропущенных названий технологий для реализации компонентов (например: Spring, Rails).
Полагаю, имелось в виду: доказать руководству, что в команде необходим выделенный специалист, который занимается требованиями и проектированием?
Как ни крути, эти активности почти всегда существуют в ИТ проекте; отличие лишь в том, кто их выполняет. Понятно, что обычно владелец бюджета старается минимизировать затраты, в айти - прежде всего ФОТ. И не каждому из них может быть очевидна необходимость в наличии выделенного аналитика (или архитектора, или девопса).
С другой стороны, не на каждом проекте в этом действительно есть смысл: например, при поддержке небольшого продукта, где команда хорошо знает предметку, системный аналитик скорее всего сам будет скучать.
Но если аналитик всё-таки нужен, то это скорее доказывается не через метрики его работы (его привлечение в проект ведь ещё нужно обосновать, верно?), а через оценку негативных последствий того, что члены команды занимаются не профильной для них деятельностью (хотя в некоторых случаях им может быть это даже в кайф).
Вы хорошо описали сам инструмент и даже кратко обозначили пользу от его применения для основных заинтересованных лиц - специалиста и руководителя. Но совсем не раскрыта тема "Зачем это бизнесу?". Я разумеется не рассчитываю на откровения (вроде: иметь больше формальных оснований не повышать сотруднику грейд/зарплату). Скорее хотелось убедиться, что решение было реализовано по явным требованиям внутреннего заказчика, а не просто потому что предыдущий инструмент был неудобным в использовании.
Так как описанное поможет джуну дорасти хотя бы до миддла? Вот ссылаетесь вы на профстандарт... Но взяли из него в осноном лишь обязанности ("трудовые действия"), причём почти везде они относятся к начальному уровню квалификации; остальное как-то осталось за бортом - не пригодится?
Распределение навыков по грейдам сделано исключительно на основе персонального опыта?
Насколько корректно экстраполировать данные из вакансий в одном ТГ-канале на весь рынок найма QA-специалистов?
Это не от джунов компании стали требовать большего, а в целом произошло смещение фокуса в обязанностях системного аналитика: если раньше они концентрировались на "требованиях", то теперь в большей степени на "решениях". Отсюда и сложность входа в профессию увеличилась - нужно иметь больше навыков, связанных с технологиями, а не только образом мышления.
Что-то мне подсказывает, что в этом уравнении учитывается только объём выполненной работы, но не качество результата.
Ну тут рецепт простой: не надо брать первую десятку из отранжированного списка, а чуть ниже. Это если втупую поступать. А по-хорошему нужно обучить модель оценивать также правдоподобность резюме, используя все тех же рекрутеров.
Почему регуляторный риск применим только для провайдеров из ЕС? Только потому что законодательство в области ИИ там стало формироваться раньше, чем в других регионах?
Подождите ещё лет 10, и возможно, Гугл и такое сообразит сделать. :-)
Нет единого "правильного" набора артефактов и тем более наполнения шаблонов для постановок. Потому что это всё слишком зависит от контекста, в котором эти артефакты планируется применять: состава и компетенций команды, особенностей рабочих процессов, используемых технологий и пр. Поэтому когда в начале статьи вы пишете, что хотите поделиться своим видением, там же где-то надо было обозначить специфику организации работы на вашем проекте.
Делюсь тем, что имею. Если качественно подходить к анализу, то нужно сравнивать данные год к году, конечно. Но по памяти, в абсолютном выражении количество вакансий снизилось за год в несколько раз.
Чем эта иллюстрация из первоисточника не устраивает?
Честно, не уловил, какой классификации нет у Вигерса. Но более принципиально вот что: как ваши дополнения упрощают практическое применение этой классификации требований?
Надо как минимум сравнить ответы на отклики на сеньорские позиции. Для этого можно сделать два резюме: условного молодого специалиста (скажем, 32 лет) и "возрастного" (те же 52 года); у обоих должен быть на бумаге одинаковый опыт в ИТ, но если первый сразу после универа попал в отрасль, то второй через 15-20 лет работы в другой сфере (не обязательно смежной).
Кому интересно глубже понять принцип работы матрицы цифрового фотика и как отличается "проявка" кадра в digital-эру от "плёночных" времён, советую послушать запись лекции создателей RAW Photo Processor: https://raw-rpp.livejournal.com/3604.html