Уважаемые коллеги!
Поделитесь пожалуйста соображениями (или реальным опытом) проведения собеседования на системного аналитика. А точнее задаваемыми вопросами, требованиями к опыту и знаниям, наличия определенных личностных качеств.
Соображения необходимы применительно к следующему:
Мне предстоит собеседование на системного аналитика, из требований: знание принципов разработки ПО, опыт постановки задач программистам и тестировщикам ПО, знание реляционных СУБД на уровне пользователя, навыки написания техдокументации и инструкций пользователя.
Что имею: опыт работы в ИТ более 14 лет; разработка ПО для автоматизации основной деятельности с нуля в качестве "и жнец, и кузнец, и на дуде игрец", т.е. от бизнес-обследования до реализации и проведения тестирования и сдачи в промышленную эксплуатацию; участие в проектах автоматизации оперативного, бухгалтерского, финансового, управленческого учетов от выяснения требований до реализации и подготовки сопроводительной документации (крупный российский производитель ПО); сопровождение и доработка эксплуатирующейся ЕРП-системы с функциями бизнес-, системного аналитика, ПМ, архитектора; теория и практика ООП, теория и практика построения реляционных БД (вроде все перечислил из основного по теме).
Что смущает:
1) отсутствие в трудовой записи "системный аналитик";
2) на ранее задаваемые вопросы типа "а как проводили определение требований?", "а что делали после возникновения инцидента, давшего понимания отсутствия необходимого функционала?" я не смог дать ответа, кроме банального "общение с заказчиком" и "проведения бизнес-анализа". Сложилось впечатление, что мои ответы не впечатлили. Что же еще можно ответить в данной ситуации?
3) "наколенность" накопленного опыта (если можно так назвать). Бизнес-анализ без IDEF, моделирование без UML, ТЗ после реализации, ну и т.д. Думаю, меня многие поняли). В требованиях к вакансии нет ни одного инструмента - они действительно не так важны, либо же это способ получения неподготовленных вариантов ответов?
Что хотелось бы: понять возможные вопросы к моей практике и подготовить соответствующие ответы. Сделать это самостоятельно будет чрезвычайно трудно, к сожалению у меня всего два дня. Изучить весь это замечательный ресурс за такой короткий срок не представляю возможным. Искренне надеюсь в скором времени стать полноценным членом Вашего сообщества.

Мои пять копеек. На окончательную истину не претендую.
1. По поводу записи в трудовой – не думаю, что это так важно.
2. Что касается ваших ответов – судя по тексту, вы слишком сжато ответили. Можно сказать не просто «общение с заказчиком», а рассказать, как именно вы это делали. Брали интервью, делали фотографию рабочего дня, анализировали регламентирующие документы, проводили опросы, заставляли предоставить анкеты и т.п. Как документировали собранные требования, что делали при их изменениях. То есть перечислить методы и инструменты, которые вы использовали. Возможно, вы не упомянули различных «профессиональных» терминов и словосочетаний, а-ля «методы и инструменты», «чендж реквесты», «трассировки» и подобных, и именно это вас смущает? Если да, то отнеситесь к этому проще. В конце-концов – главное результат. А если он у вас есть – о нем и говорите. Чем проще расскажете, тем лучше.
3. Если в требованиях нет упоминаний конкретных инструментов – значит это не важно. Word’ом вы умеете пользоваться? Ну и достаточно для начала. А что касается «наколенности» - со временем это пройдет. Вы же не на Самого Главного Системного Аналитика устраиваетесь?

Ps. Сам я никогда не пытался настолько ответственно подойти к собеседованию – подготовить ответы на возможные вопросы и по ним двигаться. Как правило, я рассматриваю собеседование как разговор между заинтересованными людьми и полагаю, что разговором следует управлять на месте. К тому же меня на собеседовании едва ли не больше интересует возможность получить ответы на мои вопросы, нежели то, как я отвечу на вопросы собеседника.

Если речь идёт о позиции младшего системного аналитика или у вас есть опыт совмещения ролей, то отсутствие записи «системный аналитик» в трудовой — это не критерий. Более того, у вас её никто смотреть не будет.

Если не смогли развёрнуто ответить про методы выявления требований — ну что ж, такое бывает, что человек исключительно практик и теорией не занимался никогда и опыт свой не рефлексировал. Предложите тут же на месте пройти тестовое задание по разработке требований, например, одного варианта использования. Предложите показать примеры документов и рассказать, откуда что взялось в них. За 2 дня вы теоретическую базу вряд ли подтянете, да и врать нехорошо, но можно на досуге почитать книжку Discovering Requirements — там подробно описано, откуда и как можно добывать требования.

Нотации моделирования IDEF и UML. Важно понимать, что подобные нотации — это всего лишь инструмент обеспечения качества требований и облегчения коммуникации (в довольно редких случаях, впрочем). Если вы понимаете как и умеете обеспечивать высокое качество требований за счёт работы со структурированным текстом, таблицами и наколеночными методами (которые могут быть весьма эффективны — например, маркерная доска, неформальные диаграммы и фотоаппарат) — то и прекрасно.

Со своей стороны могу сказать, что вопросы у меня были бы следующие:
1. Почему вам интересна позиция СА?
2. Почему вы думаете, что справитесь?
3. Что вы цените в работе СА?
4. Готовы ли вы работать с пониженной относительно предыдущих мест работы зп для набора квалификации и опыта?
В ответах на эти вопросы мы вам не помощники.

Вот мой ТОП-3 вопросов на собеседовании:
Что делать, если требования Пользователя1 конфликтуют с требованиями Пользователя2?
Как бы вы организовали работу тестеров (касаемо тестирования бизнес-процессов, например)?
Как определить приоритетность функционала для попадания в релиз? А для попадания в ТЗ?

Я бы прочитал основные моменты из:
Д.Леффингуэлл, Д.Уидриг 'Принципы работы с требованиями к ПО'
Алистер Коберн - Современные методы описания функциональных требований

Вообще - главное хорошо выспаться и не бояться Я обычно смотрю на реакцию потенциального работодателя - интересен ли ему разговор или скучен, достаточен ли ответ на вопрос или необходимо привести ещё факты и примеры.

Сегодня общался с HR-манагером. Вакансия мне оочень понравилась. Фактически суть в том, что все ИТ-проекты связанные с ПО будут начинаться с СА. Поступает глобальная задача, СА проводит анализ существующей бизнес-модели, определяет требования к технической реализации, вырабатывает пути ее решения и передает на разработку. После реализации руководит этапом тестирования, обучения и ввода в эксплуатацию. Моя анкета с резюме ейчара уйдет сегодня на рассмотрение. Дня через два будет результат первого этапа. В случае успеха, второй этап будет с непосредственным руководителем, т.е. техническим специалистом.

474 по поводу инструментов Вы правы. Стандартов нет. Есть свои плюсы, ну и минусы тоже. Ваша фраза "слишком сжато ответили" максимально отражает мое тогдашнее состояние. Боюсь, что оно мало отличается от сегодняшнего( Хотя совет "говорить о результате" вселяет спокойствие).
Ontology Nazi с решением примера я уже думал. Благо на этом ресурсе есть масса примеров разбора задачек. За это Вам спасибо!
kas шикарные вопросы! на аналогичном собеседовании привели меня в тупик, хотя постоянно с подобным (противоречивостью) имею дело. Но ответа так до сих пор и не могу найти, кроме "как-то разруливаю"). Разве это не "наколенность"?

Всем огромное спасибо за ВАШИ посты. Уверенности они точно прибавляют, а ее мне так не хватает(

Что делать, если требования Пользователя1 конфликтуют с требованиями Пользователя2?

на аналогичном собеседовании привели меня в тупик, хотя постоянно с подобным (противоречивостью) имею дело. Но ответа так до сих пор и не могу найти, кроме "как-то разруливаю"). Разве это не "наколенность"?

Вообще, странный ответ. Существует масса способов того, как разрешить "конфликт" интересов.
Причем они могут лежать как в области технического разрешения, например путем параметризации, так и организационного.
Я бы сначала посмотрел в чем состоит противоречие, потом попытался ответить почему оно существует, в области чего оно лежит: возможно извращенная практика, возможно ошибочное представление пользователей, отсюда кажущее противоречие.
Всегда можно эскалировать ситуацию. Пользователь он и есть пользователь. Нужно обращаться к тому, кто платит, кто будет владеть, в интересах кого система создается

Уважаемый Galogen, именно так все и происходит.
Поставил задачу пополнения словарного запаса, путем прочтения соответствующей литературы.

но можно на досуге почитать книжку Discovering Requirements — там подробно описано, откуда и как можно добывать требования.

Денис, ты имеешь в виду эту книгу? http://www.ozon.ru/context/detail/id/2559658/

Денис, ты имеешь в виду эту книгу? http://www.ozon.ru/context/detail/id/2559658/

Нет, вот эту: http://avaxhome.ws/ebooks/engeneering_technology/discovering_requirements_products.html

Денис, ты имеешь в виду эту книгу? http://www.ozon.ru/context/detail/id/2559658/

В аттаче небольшой mind-map по книге "Discovering Real Business Requirements For Software Project Success" by Robin F. Goldsmith. Возможно, кому-то будет интересен.

P.S. Английский у меня посредственный, поэтому возможны ошибки при переводе.

P.P.S. Возможно стоит вынести эти файлы в отдельную тему. К теме "Как пройти собеседование на системного аналитика" они имеют опосредованное отношение.

Все рассказывают, расскажу как у нас
У нас собеседование аналитиков происходит в несколько этапов (3-4).
Сначала даем кандидату тестовое задание, смотрим на результат обычно не с точки зрения способа выполнения (шаблоны или нотации), а с точки зрения "широты" взгляда, способностей увидеть "не описанное" в задании
После этого с кандидатом встречается представитель HR, потом мы (обычно несколько аналитиков) задаем вопросы по тестовому заданию, я люблю по теории погонять и выяснить представление кандидата о работе аналитика, его месте в процессе разработке, используемых при работе техник и прочего. В параллель смотрим коммуникативные навыки и психологические моменты. Спрашиваем, как бы вы стали работать, если бы попали в определенную ситуацию (кейсы)
Ну и просим сделать на встрече что-нибудь вроде описания на салфетке концептуальной модели стиральной машины или газовой плиты
Один хороший критерий услышал от девушки-HR - "Если аналитик не задает вопросов, меня это настораживает!"

Ну и напоследок, кандидатам не стоит рассказывать про Коберна, Вигерса или РУП если они сами не читали этих книг
Я конечно понимаю, что это модные слова, но если не уверены, лучше либо сказать прямо, что не читали, либо вообще не упоминать, иначе можно нарваться на лишние каверзные вопросы

Один хороший критерий услышал от девушки-HR - "Если аналитик не задает вопросов, меня это настораживает!"

Ну и напоследок, кандидатам не стоит рассказывать про Коберна, Вигерса или РУП если они сами не читали этих книг
Я конечно понимаю, что это модные слова, но если не уверены, лучше либо сказать прямо, что не читали, либо вообще не упоминать, иначе можно нарваться на лишние каверзные вопросы

т.е девушка не допускает момента чтения (ну или по сути прогнозирования) ее мыслей?
ммм, весьма недальновидно с её стороны в общем-то!
на любом собесдовании лучше говорить правду, иначе в чем суть доверительных отношений тогда между такими партнерами каканалитик и владелец (представитель владельца) организации.

т.е девушка не допускает момента чтения (ну или по сути прогнозирования) ее мыслей?
ммм, весьма недальновидно с её стороны в общем-то!

Не совсем понял про чтение мыслей. Вообще как мне кажется это хороший критерий. Приходит человек на собеседование и молчит. Его спрашивают он отвечает. Все вроде бы логично и так советуют вести себя на любом собеседовании. Но когда подходит время задавать вопросы компании, многие либо не могут сформулировать вопросов, либо не имеют таковых вообще. Не очень хорошее качество для людей, суть работы которых заключается в умении поставить вопрос и найти ответ.
Тоже самое и с заданием "на салфетке" - кандидат начинает сразу делать, без каких либо доп вопросов. Типа я и сам все знаю, фигня какая концептуальная модель электрического чайника . ИМХО точные и грамотные вопросы позволяют намного упростить работу себе и очертить границы задания

Да, и кстати еще такое наблюдение.
Ни в одну компанию с "многоступенчатым" собеседованием и разнокалиберными тестовыми заданиями я ни разу не устраивалась работать Обычно брали в те, где выбор был практически очевиден уже на собеседовании - примеры работ запрашивали почти всегда, но они служили только подтверждением впечатлений от собеседования.

Может это у меня такие харизматичные и проницательные работодатели просто, но тем не менее - может кому-то будет интересно такое наблюдение...

ida, в точку...

есть люди, которые получали образование доже в советское  постсоветское время методом олимпиад и интервью, а есть те кто сдавал типовые задачи...суть олимпиад в стиле решения, те комании которые ищут неординарных сотрудников и берут тех  о ком было написано выше...

а чтение мыслей,это прямая обязанность аналитика...уж простите, если нет прогнозирования на лету поведения HR  то жить скучно ведь , на работе мы проводим почти все время...о работе думаем вообще круглосуточно...ну те кто умеют!