Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
Как то очень коротко о главном. ИМХО, вы бы привели хотя бы пример вопросов и ответов по которым вы отсеивали кандидатов. И несколько реальных примеров собеседований. А то похоже на инструкцию по рисованию совы, сейчас нарисуем три кружка, а дальше вы сами разберетесь, не маленькие…
На мой взгляд, вопросы реально хорошие. Причем годятся и для разработчика — с некоторыми изменениями, разумеется.
>Что, по моему мнению, печально.
Ну это вы зря, кстати. Есть такие люди, которым надо подумать, прежде чем задачать уточняющие вопросы. Думать в обстановке собеседования не очень комфортно, поэтому вопросы вполне могли возникнуть позже. Те кто уточнил сразу — наверное и вероятно лучше остальных, но браковать только по этому признаку преждевременно.
>Что, по моему мнению, печально.
Ну это вы зря, кстати. Есть такие люди, которым надо подумать, прежде чем задачать уточняющие вопросы. Думать в обстановке собеседования не очень комфортно, поэтому вопросы вполне могли возникнуть позже. Те кто уточнил сразу — наверное и вероятно лучше остальных, но браковать только по этому признаку преждевременно.
Но ведь им придётся общаться в куда худших условиях — с заказчиком, который зачастую сам не понимает чего хочет. И основной задачей аналитика будет как раз задавание этих вопросов в количестве сорока сороков. Так что отсекание людей не обладающих таким навыком более чем разумно. Другое дело, что для проверки этого навыка, возможно, надо в явном виде задавать контекст задачи, — представьте, я заказчик, — и тд. Из статьи непонятно в каком контексте интервьюер ожидал уточняющих вопросов, возможно, кандидат просто не понял, что от него хотят (может это тоже плохой признак, конечно).
Общаться со сложным заказчиком и формулировать уточняющие вопросы на ходу прямо в процессе разговора — это все равно две разные вещи. Иногда полезно подумать, прежде чем уточнять.
Наверное, я не понимаю ничего в работе аналитика. По-вашему, в процессе общения с заказчиком (или, с другой стороной — с разработчиками) аналитик просто сыплет заученную домашнюю заготовку, запоминает ответы, потом удаляется, дома обдумывает уточняющие вопросы, заучивает и на следующей фазе озвучивает их в режиме магнитофона? По-моему, это какой-то плохой аналитик. Или не аналитик вовсе.
Вы что-то себе додумали из моего ответа, я такого не говорил. Я лишь сказал, что если у человека не возникли прямо сейчас уточняющие вопросы — это ровным счетом ничего пока не значит. Вот если они не возникли вообще — да, это плохо.
Ну, это, как минимум, значит, что работа будет двигаться крайне медленно. Да и проверить возникли ли вопросы потом — возможности нет. :)
Ну, про удалиться и додумать дома — это ведь тоже не я придумал. Я лишь говорю, что люди разные, а время интервью ограничено. Да, возможности проверить напрямую нет. Но и делать из этого сразу выводы рановато.
Ну, разумеется, люди разные. Одни из них подходят для работы аналитиками, другие — нет. :)
И мне казалось, что способность к вытягиванию уточняющих деталей — это одно из основных свойств аналитика. И если он не проявляет этой способности в относительно комфортных условиях специально смоделированной для этого задачи, то я бы не поставил ни гроша на то, что он будет способен это сделать в реальных условиях.
На самом деле, тут ещё о терминах вопрос — сейчас аналитиком себя кто только не называет и должностные обязанности аналитиков в разных компаниях могут как небо от земли отличаться.
И мне казалось, что способность к вытягиванию уточняющих деталей — это одно из основных свойств аналитика. И если он не проявляет этой способности в относительно комфортных условиях специально смоделированной для этого задачи, то я бы не поставил ни гроша на то, что он будет способен это сделать в реальных условиях.
На самом деле, тут ещё о терминах вопрос — сейчас аналитиком себя кто только не называет и должностные обязанности аналитиков в разных компаниях могут как небо от земли отличаться.
Ситуации разыгрывались как в ролевой игре.
Соискатель — это аналитик, а я за всех остальных персонажей.
Соискатель — это аналитик, а я за всех остальных персонажей.
Скажите, а по вашему мнению, какой правильный ответ на вопрос «Что должен делать аналитик, а что не должен»?
ИМХО, правильный ответ — это наличие ответа. Уверенный ответ. В каждой команде роли распределяются по-своему, но нужно представлять те обязаности, которые можешь взять на себя и которые видишь перспективным и выгодным для команды на себя брать.
Если же кандидат начинает тормозить, это признак губительной несамостоятельности и, возможно, излишней авторитарности со стороны руководителя проекта на предыдущих проектах.
Если же кандидат начинает тормозить, это признак губительной несамостоятельности и, возможно, излишней авторитарности со стороны руководителя проекта на предыдущих проектах.
Это не вопрос, а целый ряд вопросов, в рамках которых хотелось бы услышать что аналитик не оценивает трудоемкость, не пишет тесты и не показывает демо клиенту (я искал аналитика в scrum команду)
Хороший подход. Интуитивный, не идеальный, но работает. Всё же 17 человек это не 170.
Сам подбирал себе в отдел аналитиков фильтруя студентов тестом на логическое мышление «шмурдик, запырка,...». Смотрел, на скорость и результат. Аналитик часто сталкиватся с незнакомой предметной областью и нужно быстро выстраивать непротиворечивые логические схемы. Недостаток: тест легко выучивается. Можно использовать лишь несколько раз, пока не начался активный обмен опытом между кандидатами.
Уровень EQ оценивал в процессе интервью, полагаясь на свой преподавательский опыт. Расспрашивал об интересе к различным предметам, курсовым работам. В итоге выяснялось отношение к сокурсникам, преподавателям и предметам, умение работать с конфликтами и пр.
Самое любопытное, то что тест на логическое мышление лучше всех проходили не студенты матфака. Скорее всего, это наша локальная флуктуация.
Профессиональные знания не рассматривал. Не нашел бы никого :)
Формирование требований, UML, BPMN, ARIS, уже в рабочем процессе изучали.
Сам подбирал себе в отдел аналитиков фильтруя студентов тестом на логическое мышление «шмурдик, запырка,...». Смотрел, на скорость и результат. Аналитик часто сталкиватся с незнакомой предметной областью и нужно быстро выстраивать непротиворечивые логические схемы. Недостаток: тест легко выучивается. Можно использовать лишь несколько раз, пока не начался активный обмен опытом между кандидатами.
Уровень EQ оценивал в процессе интервью, полагаясь на свой преподавательский опыт. Расспрашивал об интересе к различным предметам, курсовым работам. В итоге выяснялось отношение к сокурсникам, преподавателям и предметам, умение работать с конфликтами и пр.
Самое любопытное, то что тест на логическое мышление лучше всех проходили не студенты матфака. Скорее всего, это наша локальная флуктуация.
Профессиональные знания не рассматривал. Не нашел бы никого :)
Формирование требований, UML, BPMN, ARIS, уже в рабочем процессе изучали.
Было у меня желание проверять логику, но я предварительно провел эксперимент, опросив свою команду и соседей.
Вопрос был простой «Является ли отсутствие доказательств присутствия доказательством отсутствия?»
Ответы никак не коррелировали с компетенцией или занимаемой ролью, так что я решил принципиально ничего такого не добавлять.
Вопрос был простой «Является ли отсутствие доказательств присутствия доказательством отсутствия?»
Ответы никак не коррелировали с компетенцией или занимаемой ролью, так что я решил принципиально ничего такого не добавлять.
Очень правильный подход, но, на мой личный взгляд, не рассмотрены следующие ситуации из других компаний:
Аналогично, я не вижу для аналитика решения кейса «Два директора» — это проблема компании интегратора/разработчика в лице руководителя проекта так выстроить работу с заказчиком, где будет одно лицо или коллегиальный орган, принимающий проект со стороны заказчика. Т.е. заказчик сам должен решить — кому из директоров верить и как делать результат. Руководитель проекта может предложить варианты, но принять решение что делать должен Заказчик
- Разделение аналитиков на бизнес-аналитиков и системных аналитиков.Бизнес-аналитик детально прорабатывает бизнес-кейсы и все пути достижения целей заказчика с помощью системы, в то время как системный аналитик является частью команды разработки и заказчиков в глаза не видит, зато он делает техническое задание из функциональной спецификации бизнес-аналитика, жёстко привязанное к возможностям конкретной платформы
- Наличие в проекте Руководителя проекта или владельца продукта, который и формирует приоритеты выполняемых задач. На мой взгляд, аналитик не имеет возможности решать, что войдёт в релиз, а что нет. Как правило, сначала руководитель проекта договаривается с заказчиком о допсоглашении, в котором будет описано изменение обязательств компании-интегратора/разработчика и заказчика.
Аналогично, я не вижу для аналитика решения кейса «Два директора» — это проблема компании интегратора/разработчика в лице руководителя проекта так выстроить работу с заказчиком, где будет одно лицо или коллегиальный орган, принимающий проект со стороны заказчика. Т.е. заказчик сам должен решить — кому из директоров верить и как делать результат. Руководитель проекта может предложить варианты, но принять решение что делать должен Заказчик
Разделение аналитиков на бизнес-аналитиков и системных аналитиков.Бизнес-аналитик детально прорабатывает бизнес-кейсы и все пути достижения целей заказчика с помощью системы, в то время как системный аналитик является частью команды разработки и заказчиков в глаза не видит, зато он делает техническое задание из функциональной спецификации бизнес-аналитика, жёстко привязанное к возможностям конкретной платформы
У нас такого разделения нет.
К тому же вот это "детально прорабатывает бизнес-кейсы и все пути достижения целей заказчика с помощью системы" на мой взгляд задачи системного аналитика.
Бизнес-аналитик не привязан к системе. Он представитель заказчика который понимает как работают бизнес-процессы. Он (если он есть) выдает задачу, а уже системный аналитик работает с ней рамках своей системы.
Но тут есть опасность завязнуть в терминологии, т.к. часто люди даже в одном подразделении вкладывают совершенно разный смысл в понятия БА и СА.
На мой взгляд, аналитик не имеет возможности решать, что войдёт в релиз, а что нет.
Решают представители бизнеса когда расставляют приоритеты. Аналитик начинает работать от самого важного и ниже, таким образом наполняя релиз фичами.
Аналогично, я не вижу для аналитика решения кейса «Два директора» — это проблема компании интегратора/разработчика в лице руководителя проекта так выстроить работу с заказчиком, где будет одно лицо или коллегиальный орган, принимающий проект со стороны заказчика.
Не всегда это достижимая задача. Многое зависит от того как организационно устроен заказчик, как наполняется бюджет и т.д.
У меня вот прямо сейчас на проекте четыре стороны согласования (а не две, как в вымышленной ситуации), разделенные географически и по типам бизнеса. И ничего, хорошо работаем.
На последнем AnalystDays был хороший доклад Дениса Гобова про проведение собеседований на позицию аналитика: http://analystdays.ru/ru/talk/39215
Кто показывает демо клиенту (в случае scrum команды)?
Кто угодно из команды разработки, но не аналитик.
Не могли бы вы пояснить свою точку зрения? Я спрашивал мнение по этому поводу в BA community, и там большинство считают, что именно бизнес-аналитик лучше всего способен показать демо.
Привет!
Да, именно бизнес-аналитик лучше всего способен показать демо, с этим я не спорю.
Однако, когда демо показывает команда, то ей приходится вникать во всё то что сделано в спринте. Не только в свой кусочек кода, а понять весь инкремент, прежде всего с бизнесовой точки зрения. И благодаря этому команда еще лучше и глубже погружается в контекст бизнеса заказчика и того продукта который для него делает, что идет на пользу качеству решения которое делает команда.
Т.е. демо в данном случае — это инструмент погружения команды в контекст бизнес-задачи которую они решают.
Да, именно бизнес-аналитик лучше всего способен показать демо, с этим я не спорю.
Однако, когда демо показывает команда, то ей приходится вникать во всё то что сделано в спринте. Не только в свой кусочек кода, а понять весь инкремент, прежде всего с бизнесовой точки зрения. И благодаря этому команда еще лучше и глубже погружается в контекст бизнеса заказчика и того продукта который для него делает, что идет на пользу качеству решения которое делает команда.
Т.е. демо в данном случае — это инструмент погружения команды в контекст бизнес-задачи которую они решают.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как аналитику найти другого хорошего аналитика