Да какая разница, каким способом написана статья? Если в ней мало пользы (солянка из нескольких случайно выбранных сложностей в работе аналитика), то как она появилась на свет, уже не принципиально.
Дело не в желании потешить самолюбие, а банальном отсутствии понимания, как правильно проводить собеседование. Поэтому обычно и задают груду теоретических вопросов, которые не выявляют опыт и не раскрывают потенциал к решению практических задач.
Верно подмечено! Не хватает анализа корреляции от предметной области, вида системы и ключевых задач. Но видимо, такая информация не собиралась. Хотя приписка, что опрос проводился в группах финтех-компаний отчасти объясняет полученную картину.
Видимо, это как раз те команды (см. первую таблицу), где уже есть сотрудники, которые просто пересказывают слова заказчика, потому что не смогли разобраться в предметной области, и тем самым увеличивают сроки и стоимость разработки.
Как по мне, так "самое ненавистное" в работе аналитика - знать, что твой коллега когда-то не оформил требования/постановку должным образом; и теперь ты должен тратить своё и его время (а часто ещё и других участников проекта) на восстановление этих знаний.
Можете рассказать чуть подробнее, каким образом экспертная группа оценивала кандидатов, чтобы избежать субъективности? Ведь если у "оценщиков" нет формальной методики, то избежать неточности результатов весьма непросто; тем более в ситуации, когда состав такой группы меняется время от времени.
Это не вопрос из разряда бинарных: можно обойтись без документации или нет? В такой постановке сразу читается две крайности, где "справа" - тонны текста и картинок. А дело в необходимом и достаточном наборе артефактов и степени детализации их содержания! Ведь на каком-то проекте хватит user stories + BDD, а на другом нужно готовить ТЗ, ЧТЗ, ТП и далее C4 схемы, набор use cases с sequence diagram, ER диаграммы и т.п.
Хочется вот какой момент отметить, отталиваясь от обозначенного контекста - подбор системного аналитика в Европе.
Как утверждают многие коллеги по цеху, за границей позиция системного аналитика большая редкость - технические задачи по проектированию берут на себя разработчики и архитекторы. И ваш кейс, пожалуй, это весьма подтверждает: качество ответов на технические вопросы со стороны кандидатов оставляет желать лучшего; уж точно это не уровень senior analyst.
Поэтому хочется спросить: вам точно в команду нужен был системный аналитик, в том понимании профессии, которое распространено в РФ?
В конце статьи правильно подмечено, что состояние документации (да в принципе её наличие) зависит от уровня зрелости команды. Вообще вся эта затея с восстановлением документации действительно имеет смысл только в том случае, если инициатива не только была поддержана и одобрена проектным руководством, но и был выстроен процесс постоянного поддержания документации в актуальном состоянии, с которым согласились все заинтересованные лица. Иначе аналитики окажутся в ситуации худшем, чем Алиса из Страны чудес.
Да какая разница, каким способом написана статья? Если в ней мало пользы (солянка из нескольких случайно выбранных сложностей в работе аналитика), то как она появилась на свет, уже не принципиально.
В российских современных ЖК так же делают. Но учитывая общее качество строительных работ, лично я решил всё же кинуть трубку до канализации.
Дело не в желании потешить самолюбие, а банальном отсутствии понимания, как правильно проводить собеседование. Поэтому обычно и задают груду теоретических вопросов, которые не выявляют опыт и не раскрывают потенциал к решению практических задач.
Верно подмечено! Не хватает анализа корреляции от предметной области, вида системы и ключевых задач. Но видимо, такая информация не собиралась. Хотя приписка, что опрос проводился в группах финтех-компаний отчасти объясняет полученную картину.
Видимо, это как раз те команды (см. первую таблицу), где уже есть сотрудники, которые просто пересказывают слова заказчика, потому что не смогли разобраться в предметной области, и тем самым увеличивают сроки и стоимость разработки.
Оставьте в покое уже тему с Use Cases! Технике более 20 лет, но нет - аналитики продолжают про неё рассказывать, будто это что-то невиданное.
SMART не методология, а техника постановки целей или задач. Применяйте инструмент по назначению, и не будет возникать вопрос "Почему оно не работает?"
Как по мне, так "самое ненавистное" в работе аналитика - знать, что твой коллега когда-то не оформил требования/постановку должным образом; и теперь ты должен тратить своё и его время (а часто ещё и других участников проекта) на восстановление этих знаний.
Минтруда с вами не согласно https://profstandart.rosmintrud.ru/obshchiy-informatsionnyy-blok/natsionalnyy-reestr-professionalnykh-standartov/reestr-professionalnykh-standartov/index.php?ELEMENT_ID=126779
Почему "чатом" называют возможность отправить в одну сторону предопределённое сообщение?
В статье - да. Но на почту присылаете ссылку на Яндек.Диск, где выложены книги.
Можете рассказать чуть подробнее, каким образом экспертная группа оценивала кандидатов, чтобы избежать субъективности? Ведь если у "оценщиков" нет формальной методики, то избежать неточности результатов весьма непросто; тем более в ситуации, когда состав такой группы меняется время от времени.
В джентельменском наборе моделей почему-то отсутствует архитектура системы. Хотя тот же С4 упомянут.
А вы литературу для подготовки распространяете, конечно же, с разрешения правообладателей? ;)
Это не вопрос из разряда бинарных: можно обойтись без документации или нет? В такой постановке сразу читается две крайности, где "справа" - тонны текста и картинок. А дело в необходимом и достаточном наборе артефактов и степени детализации их содержания! Ведь на каком-то проекте хватит user stories + BDD, а на другом нужно готовить ТЗ, ЧТЗ, ТП и далее C4 схемы, набор use cases с sequence diagram, ER диаграммы и т.п.
Хочется вот какой момент отметить, отталиваясь от обозначенного контекста - подбор системного аналитика в Европе.
Как утверждают многие коллеги по цеху, за границей позиция системного аналитика большая редкость - технические задачи по проектированию берут на себя разработчики и архитекторы. И ваш кейс, пожалуй, это весьма подтверждает: качество ответов на технические вопросы со стороны кандидатов оставляет желать лучшего; уж точно это не уровень senior analyst.
Поэтому хочется спросить: вам точно в команду нужен был системный аналитик, в том понимании профессии, которое распространено в РФ?
Название статьи поменяйте на "Типовые задачи аналитика данных"
В конце статьи правильно подмечено, что состояние документации (да в принципе её наличие) зависит от уровня зрелости команды. Вообще вся эта затея с восстановлением документации действительно имеет смысл только в том случае, если инициатива не только была поддержана и одобрена проектным руководством, но и был выстроен процесс постоянного поддержания документации в актуальном состоянии, с которым согласились все заинтересованные лица. Иначе аналитики окажутся в ситуации худшем, чем Алиса из Страны чудес.
А в чём были сложности с использованием ссылок в JSON Schema?
Почти. В OpenAPI используется синтаксис, который является надмножеством JSON Schema Specification Draft 2020-12.