Комментарии 12
Если инвестор не может выбрать эксперта в предметной области из своих людей, то тогда архитектор выполняет работу аналитика и идёт общаться со всеми менеджерами, чтобы изучить предметную область. Просто так дольше. Но если без посредничества, распилов и откатов, то может быть дешевле. :-)
Коронный вопрос здесь "А что вам потребуется, чтобы спроектировать вот это?".
А в предыдущем посте вы писали " Почему системный аналитик не должен заниматься проектированием"
Так ведь это Agile — подстраиваться под требования проекта, воспитание уверенного в себе «универсального солдата», который без ущерба для дела может заменить заболевшего или уехавшего в отпуск коллегу из любой Tier.
Аналитик не всегда должен проектировать, но должен собирать требования, на основе которых сотрудник с ролью архитектора (а может и разработчика) займется проектированием "вот этого".
Совершенно с вами согласен - системный аналитик, так же зачастую маркетинговый, продуктовый и проектные менеджеры должны быть уверенными ( от верить, а не знать) что они могут все. Иначе все участники будут сомневаться, а надо ли это вообще делать. В реальности, как и отмечено, аналитик прежде всего должен собирать требования, их ранжировать, и в конце концов понять, и объяснить в деталях команде разработчиков, да и верхнему руководству, ЧТО за продукт собственно надо сделать. А потом уже системный архитектор и разработчики компонент будут думать КАК это сделать. Кстати независимо от того какая модель используется при разработке - водопад или гибкая, конечная разница будет только в числе итераций. Это я по опыту создания автоматизированных измерительных систем сужу.
не очень понятно, как без опыта будущему джуну проходить собес))
Для джуна вопросы попроще. И многие на позицию джуна делают учебные проекты, в которых довольно обширная практика.
Вот посмотрите демо собеседование Яндекса на джуниор системного аналитика - очень грамотный интервьюер и много полезной инфы.
https://www.youtube.com/watch?v=5PtGTXd7uFk
С таким подходом системного аналитика вы никогда не найдете. Потому что вы проверяете владеет ли кандидат определенными инструментами и только. По сути вы ищите дрессированную собаку. Она тоже умеет делать разные штуки.
Не согласен с вашим мнением, тогда можно было бы сдавать просто по карточкам как в ГИБДД.
В SSP SOFT интервьюер - это действующий тимлид, он видит кандидата и спрашивает вещи, подстраиваясь под требования проекта и опыт кандидата.
Базовые вещи должен знать каждый кандидат, чем выше уровень специалиста, тем большее разнообразие инструментов в его арсенале.
Затем кандидату предоставляется право задать свои вопросы и этой возможностью не стоит пренебрегать.
Спасибо, что разрешили. Обычно, всё же сначала рассказывают про проект, а то смысл тратить время, если он не интересен.
Поскольку это техническое интервью, можно задавать вопросы о методологии работы системных аналитиков в компании, об инструментах и программном обеспечении, которые используют системные аналитики в компании для моделирования и анализа бизнес-процессов.
Обычно это собеседник сам рассказывает, особенно, если кандидат уровня Джун/мид-.
И в догонку цитирования выше, это рассказывают в начале, чтобы уточнить интерес и релевантность, иначе это может быть в пустую потраченное время.
Если сослаться, что hr все перед интервью расскажет, то нет, не расскажет, ибо он не погружен в ряд нюансов. Так же неплохо было бы рассказать про стек сразу, так как не совсем стеком все хотят работать.
В общем итоге имеем описание очень старого подхода к проведению собеседований, где собеседующий есть царь, а соискатель имеет возможность, по крайней мере из описания выше у меня именно такое мнение сложилось.
Не стоит делать выводы по одним только фразам. В целом, вопрос про комфортность собеседования для кандидата - это вопрос личного мироощущения.
Компания занимается заказным программированием для госов и федеральных компаний. Если делаешь свой продукт, то цена ошибки найма - это останется внутри компании. Если команда делает заказ для госзаказчика, то цена ошибки найма выше.
"Основной сценарий (main flow) в use case — это последовательность шагов по наиболее типичному пути выполнения операции или функции"
я бы сказала не "типичному", а "успешному" или "целевому", то есть сценарий, который выполняет цель пользователя, за которой он сюда и пришел. Типичный путь можно воспринять двояко
Как пройти техническое интервью (собеседование) на позицию системного аналитика