Хочется вот какой момент отметить, отталиваясь от обозначенного контекста - подбор системного аналитика в Европе.
Как утверждают многие коллеги по цеху, за границей позиция системного аналитика большая редкость - технические задачи по проектированию берут на себя разработчики и архитекторы. И ваш кейс, пожалуй, это весьма подтверждает: качество ответов на технические вопросы со стороны кандидатов оставляет желать лучшего; уж точно это не уровень senior analyst.
Поэтому хочется спросить: вам точно в команду нужен был системный аналитик, в том понимании профессии, которое распространено в РФ?
В конце статьи правильно подмечено, что состояние документации (да в принципе её наличие) зависит от уровня зрелости команды. Вообще вся эта затея с восстановлением документации действительно имеет смысл только в том случае, если инициатива не только была поддержана и одобрена проектным руководством, но и был выстроен процесс постоянного поддержания документации в актуальном состоянии, с которым согласились все заинтересованные лица. Иначе аналитики окажутся в ситуации худшем, чем Алиса из Страны чудес.
Список ключевых навыков для работы аналитика в зависимости от продуктовой/проектной деятельности не приведён, хотя напрашивается из введения. Важность погружения в предметную область и коммуникации с командой подмечена - но, вроде, уже давно не является откровением. Если хотелось сфокусироваться на особенностях разработки ПО для разных типов устройств, то пары примеров вроде как недостаточно, чтобы быть полезным для коллег по цеху. Так о чём всё же статья?
Вы не учли специфику организации работ в госкомпаниях.
Очень часто бизнес-требования до ИТ команды спускаются сверху в виде ТЗ, которое вполне добротно составил бизнес-аналитик и на которое предварительно уже посмотрели ключевые айтишные персоны (тот же архитектор и рукпроекта), чтобы оценить реализуемость и бюджет. Но дальше этот артефакт передаётся на вход системного аналитика и архитектора для детального анализа требований проектирования системы.
Получается, что в силу организационной структуры и устоявшихся бизнес-процессов автоматизации деятельности крайне затруднительно тесно сплести этапы выявления потребностей и проектирования решения.
Как удобно говорить от своего имени за всю ИТ индустрию в стране!
Работа с требованиями важная, но далеко не единственная деятельность аналитика.
Советую хотя бы ознакомиться с Профстандартом на специальность "Системный аналитик", где значительная доля обязанностей аналитика связана с проектированием системы.
То есть по вашему выходит, что если в ходе классического "системного анализа" выявить подсистемы и реализовать их по-отдельности, а потом совершить "синтез", то есть собрать всё в одном билде, то свойство "эмерджентности" испарится? Всё, потеряли целевую систему?
"Министр финансов Антон Силуанов в ходе слушаний в Госдуме уже говорил, что дополнительные средства пойдут на финансирование нацпроектов «Семья», «Молодежь России», «Продолжительная и активная жизнь», повышение социальных выплат, продление материнского капитала, поддержку здоровья женщин и т.д."
Очень интересно узнать, был ли предложенный шаблон испробован на практике. Если да, то в какого рода проектах, с какого типа заказчиками, какой был процесс согласования документа и как он затем применялся в разработке и тестировании?
Этой статье явно не хватает примера "бизнес-истории".
Делитесь в комментариях, каких правил вы придерживаетесь при написании и проверке бизнес-историй. Очень интересно узнать ваш опыт и использовать его на практике!
Призыв видится мне неосуществимым, потому как большинство читатей, уверен, столкнулись с данным термином в первый раз.
У вас несколько устаревшее представление об обязанностях СА: в перечне отсутствует проектирование системы и её частей. Выявление, анализ и документирование требований давно уже не ключевой аспект в работе аналитика.
Я вот не делаю вывод, что они пытаются заменить техсобес опросом со стороны рекрутера. Больше похоже на устный опросник, чтоб выяснить, где описание в резюме расходится с реальным опытом; плюс собрать больше деталей по используемым технологиям. Это и правда может помочь отсеить кандидатов, которые приукрасили резюме (например, проектировали REST API, но один раз два года назад) или наоборот описали слишком обобщенно ("использовал нотацию UML").
Рассказ о своём опыте тоже нужно адаптировать к вакансии. Странным будет делать акцент, например, на задачах по разработке какого-нибудь ETL конвейера, когда предлагаемый проект, скажем, про интеграцию с ГосУслугами.
А чтобы узнать детали о новом проекте, нужно как раз задавать их после тех. собеседования. Рекрутер обычно очень поверхностно знает специфику. Впрочем, не факт, что и собеседующий на техническом сможет подробно ответить на такие вопросы - тут скорее их надо запасти для интервью с командой / руководством.
Хочется вот какой момент отметить, отталиваясь от обозначенного контекста - подбор системного аналитика в Европе.
Как утверждают многие коллеги по цеху, за границей позиция системного аналитика большая редкость - технические задачи по проектированию берут на себя разработчики и архитекторы. И ваш кейс, пожалуй, это весьма подтверждает: качество ответов на технические вопросы со стороны кандидатов оставляет желать лучшего; уж точно это не уровень senior analyst.
Поэтому хочется спросить: вам точно в команду нужен был системный аналитик, в том понимании профессии, которое распространено в РФ?
Название статьи поменяйте на "Типовые задачи аналитика данных"
В конце статьи правильно подмечено, что состояние документации (да в принципе её наличие) зависит от уровня зрелости команды. Вообще вся эта затея с восстановлением документации действительно имеет смысл только в том случае, если инициатива не только была поддержана и одобрена проектным руководством, но и был выстроен процесс постоянного поддержания документации в актуальном состоянии, с которым согласились все заинтересованные лица. Иначе аналитики окажутся в ситуации худшем, чем Алиса из Страны чудес.
А в чём были сложности с использованием ссылок в JSON Schema?
Почти. В OpenAPI используется синтаксис, который является надмножеством JSON Schema Specification Draft 2020-12.
Список ключевых навыков для работы аналитика в зависимости от продуктовой/проектной деятельности не приведён, хотя напрашивается из введения. Важность погружения в предметную область и коммуникации с командой подмечена - но, вроде, уже давно не является откровением. Если хотелось сфокусироваться на особенностях разработки ПО для разных типов устройств, то пары примеров вроде как недостаточно, чтобы быть полезным для коллег по цеху. Так о чём всё же статья?
Вы не учли специфику организации работ в госкомпаниях.
Очень часто бизнес-требования до ИТ команды спускаются сверху в виде ТЗ, которое вполне добротно составил бизнес-аналитик и на которое предварительно уже посмотрели ключевые айтишные персоны (тот же архитектор и рукпроекта), чтобы оценить реализуемость и бюджет. Но дальше этот артефакт передаётся на вход системного аналитика и архитектора для детального анализа требований проектирования системы.
Получается, что в силу организационной структуры и устоявшихся бизнес-процессов автоматизации деятельности крайне затруднительно тесно сплести этапы выявления потребностей и проектирования решения.
Зашёл прочитать про ситуацию в айтишной компании, но и здесь не обошлось без комментария о Манчестер Юнайтед!
Как удобно говорить от своего имени за всю ИТ индустрию в стране!
Работа с требованиями важная, но далеко не единственная деятельность аналитика.
Советую хотя бы ознакомиться с Профстандартом на специальность "Системный аналитик", где значительная доля обязанностей аналитика связана с проектированием системы.
Ссылка на курс "как пройти собеседование на системного аналитика с з/п 400т.руб" видимо будет в следующем посте
Это +2-5% "хук справа"? Гм. Вы сравните ставки НФДЛ в тех же странах БРИКС https://www.rbc.ru/economics/04/06/2024/665c2bac9a79476dd8701a58
То есть по вашему выходит, что если в ходе классического "системного анализа" выявить подсистемы и реализовать их по-отдельности, а потом совершить "синтез", то есть собрать всё в одном билде, то свойство "эмерджентности" испарится? Всё, потеряли целевую систему?
"Министр финансов Антон Силуанов в ходе слушаний в Госдуме уже говорил, что дополнительные средства пойдут на финансирование нацпроектов «Семья», «Молодежь России», «Продолжительная и активная жизнь», повышение социальных выплат, продление материнского капитала, поддержку здоровья женщин и т.д."
Остаётся только верить :)
А что, инфляция на доходы бюджета не действует?
Можете дать хотя бы одну ссылку на первоисточник, где в практику анализа вводится такая техника?
Очень интересно узнать, был ли предложенный шаблон испробован на практике. Если да, то в какого рода проектах, с какого типа заказчиками, какой был процесс согласования документа и как он затем применялся в разработке и тестировании?
Этой статье явно не хватает примера "бизнес-истории".
Призыв видится мне неосуществимым, потому как большинство читатей, уверен, столкнулись с данным термином в первый раз.
У вас несколько устаревшее представление об обязанностях СА: в перечне отсутствует проектирование системы и её частей. Выявление, анализ и документирование требований давно уже не ключевой аспект в работе аналитика.
Я вот не делаю вывод, что они пытаются заменить техсобес опросом со стороны рекрутера. Больше похоже на устный опросник, чтоб выяснить, где описание в резюме расходится с реальным опытом; плюс собрать больше деталей по используемым технологиям. Это и правда может помочь отсеить кандидатов, которые приукрасили резюме (например, проектировали REST API, но один раз два года назад) или наоборот описали слишком обобщенно ("использовал нотацию UML").
Рассказ о своём опыте тоже нужно адаптировать к вакансии. Странным будет делать акцент, например, на задачах по разработке какого-нибудь ETL конвейера, когда предлагаемый проект, скажем, про интеграцию с ГосУслугами.
А чтобы узнать детали о новом проекте, нужно как раз задавать их после тех. собеседования. Рекрутер обычно очень поверхностно знает специфику. Впрочем, не факт, что и собеседующий на техническом сможет подробно ответить на такие вопросы - тут скорее их надо запасти для интервью с командой / руководством.