Как вдруг, мой начальник озадачил меня: «А вот нам на смежный проект нужен новый аналитик, давай ты будешь собеседовать кандидатов?»
Я, конечно, согласился.
А потом подумал и понял, что я понятия не имею как собеседовать аналитиков, а главное, как понять, хороши они или нет. Но отступать было уже поздно!
Тут же присланные мне резюме, помимо неподходящих, были практически одинаковы. Одни и те же качества, одни и те же навыки, одни и те же технологии. Поиск по интернету не обнадежил, найденные статьи по теме были словно написаны одним и тем же копирайтером и особо помочь не смогли.
Образовалась целая орда якобы важных параметров, которые часто противоречили друг другу.
Пораскинув мозгами и посоветовавшись с мудрыми людьми я приступил к плану собеседования.
Вместо поиска абстрактных «золотых» качеств и навыков аналитика, которые надо бы проверять на собеседовании я начал отсекать бесполезные.
В итоге, бесполезным оказалось всё связанное с технологиями и приложениями. Проект на который я искал человека был про бизнес-приложения для клиентов, так что проверять знание, например, SQL или JSON не было никакого резона, а научить рисовать картинки в Sparx можно и обезьяну за неделю. Знание же всяких UML и BPMN требовалось лишь в контексте понимания процесса работы, а не «как правильно рисовать кружочки и стрелочки».
Казалось бы, о чем спрашивать то тогда? Но в итоге образовался отличный план, через который прошли 17 соискателей.
План состоял из трех частей.
- Общие вступительные вопросы.
Какие требования бывают и какими свойствами обладают хорошие требования.
Они нужны чтобы понять, а аналитик ли передо мной?
Как выяснилось в процессе, за красивыми резюме скрывались и тестировщики и разработчики и даже люди не имеющие отношения к IT.
Вдобавок, эти простые вопросы дали еще один неожиданный эффект. Некоторые соискатели начинали психовать, когда им, обладателям таких шикарных резюме, задают такие простые вопросы. Ну, с такими разговор короткий, психованным в аналитиках не место. - Вопросы о процессе разработки и роли аналитика в команде.
Что должен делать аналитик, а что не должен. Какие у него отношения с девелоперами и QA, как он понимает методологии разработки в которых участовал и т.д. Практика показала, что далеко не все представляют себе весь цикл разработки приложения, свою роль в команде и зачем вообще бизнес заказывает софт у разработчиков. - Ситуационные вопросы.
Здесь мы моделировали как реальные ситуации в работе аналитика, так и выдуманные мной, чтобы проследить за ходом мысли соискателя. Рассматривали обычные проблемы аналитика: конфликт приоритетов или требований между несколькими заказчиками, конфликт внутри команды, нечеткое подчинение, интервьюирование заказчика, конфликт бизнес-интересов и т.п.
Самый полезный блок, т.к. проверял не только внимательность и сообразительность, но и способность уточнять неизвестные данные. В некоторых ситуациях я специально умалчивал некоторые вводные, однако только три(!) из семнадцати кандидатов хоть что-то уточняли у меня. Что, по моему мнению, печально.
Полностью абстрагировавшись от технических навыков, получился отличный фильтр для соискателей, все кандидаты прошедшие его были одобрены руководством и вызвали положительную оценку на последующих раундах.
Так что если вы с такой стороны еще не смотрели на найм аналитиков, посмотрите!
UPD: Привожу примеры задаваемых вопросов и ожидаемых ответов.
Из вступительных вопросов:
- Какой, по вашему, главный инструмент аналитика?
Самый первый вопрос. Я свято уверен что это голова. Но как оказалось, некоторые соискатели путают понятия «инструмент», «навык» и «компетенция»
- Какие требования бывают?
Здесь достаточно ответа что функциональные и нефункциональные. Что, нефункциональные можно разделить на бизнес-правила, ограничения и атрибуты качества. Что требования к отказоустойчивости — это атрибут качества, а требования к интеграции — это ограничения.
- Какими свойствами обладают хорошие требования?
Здесь ожидал услышать что-нибудь из этого списка: полные, однозначные, непротиворечивые, проверяемые и понимаемые. Можно еще, конечно, называть, но мне подойдет и так.
Из вопросов о роли аналитика в команде:
- Кто оценивает трудоемкость задач?
Команда разработки
- Кто пишет тест план и тест кейсы ?
QA. Несмотря на простоту ответа, некоторые соискатели удивили меня тут, сказав что все это делает аналитик. Для таких у меня был заготовлен вопрос: «Так что, по вашему QA — это такая бездумная обезьяна которая только и может что кнопки жать по готовым сценариям?» Но не смотря на подсказку, пара человек всё равно гордо ответила «Да!» на этот наводящий вопрос.
- Кто показывает демо клиенту (в случае scrum команды)?
Кто угодно из команды разработки, но не аналитик.
Разыгранные ситуации.
- Конфликт разработчика и QA
Вводная: Приходят к аналитику разработчик и QA и жалуются друг на друга. QA говорит что разработчик неправильно сделал, а разработчик говорит что это QA ничего не понимает.
Ожидаемые действия: Надо выяснить кто как понял, в чем проблема и в случае косяка со стороны аналитика уточнить требование, если оно трактуется неоднозначно.
- Конфликт приоритетов
Вводная: Релиз жестко запланирован по дате, разработки осталось месяц, всё вроде хорошо, но тут прибегает заказчик с новой пачкой требований и говорит срочно добавить их в релиз. При этом очевидно, что и новые и старые требования за месяц не сделать.
Ожидаемые действия: Выяснить что повлекло возникновение новых требований, проговорить потребности клиента, вдруг старые уже не актуальны, тогда их можно выкинуть. В случае если всё нужно, заставить клиента самому заново выставить приоритет и новым и старым и те что не влезают отложить на следующий релиз.
- «Убойное» требование
Вводная: На этапе оценки затрат разработчик говорит что это требование разрушит систему и чтобы его реализовать надо пару месяцев убить только на изменение архитектуры. А заказчик говорит: «Я, конечно, всё понимаю, но мне это нужно, по этому сделайте, вы же разработчики!»
Ожидаемые действия: Часто то что хочет заказчик — это лишь его личное видение ситуации и решения. За любым требованием лежит некая бизнес-потребность, задача её выявить и предложить более оптимальное решение, более дешевое в плане разработки.
- Интервью в слепую
Вводная: Аналитика отправляют опросить нового заказчика, однако о нем ничего не известно, даже не ясно еще, что за приложение ему нужно.
Какие главные вопросы задаст аналитик заказчику.
Следующие вопросы и их вариации я считаю правильными в такой ситуации:
Чем занимается заказчик и его сотрудники?
Зачем им понадобилось ПО? В чем вообще проблема?
Что он ожидает от этого ПО? Какой результат?
Как заказчик поймет что результат достигнут?
Какие ограничения есть у заказчика?
- Два директора
Вводная: Команда аналитика делает ПО для международной корпорации с офисами в Лондоне и Нью-Йорке. ПО будет использоваться клиентами этой корпорации. Директора этих офисов являются конечными заказчиками и для успешного релиза они оба должны подписаться. Однако, на одной из экранных форм один директор хочет чтобы была синяя кнопка и делала одно, а другой хочет чтобы была зеленая кнопка и делала совсем другое. Нужно найти аргументы, чтобы оба директора согласились на какое-то одно решение.
Ожидаемые действия: Через цепочку рассуждений прийти к выводу что раз директора управляют бизнесом, то и аргументы должны быть связаны с бизнесом компаний, а не «давайте сделаем две разные страницы» или «будем определять клиента по географическому положению». Идеальный вариант — соотношение выгоды, которую получит компания от разных функционалов с расходами на разработку и обслуживание этих функционалов.
Комментарии (21)
sshikov
31.05.2016 21:30На мой взгляд, вопросы реально хорошие. Причем годятся и для разработчика — с некоторыми изменениями, разумеется.
>Что, по моему мнению, печально.
Ну это вы зря, кстати. Есть такие люди, которым надо подумать, прежде чем задачать уточняющие вопросы. Думать в обстановке собеседования не очень комфортно, поэтому вопросы вполне могли возникнуть позже. Те кто уточнил сразу — наверное и вероятно лучше остальных, но браковать только по этому признаку преждевременно.avost
01.06.2016 08:28Но ведь им придётся общаться в куда худших условиях — с заказчиком, который зачастую сам не понимает чего хочет. И основной задачей аналитика будет как раз задавание этих вопросов в количестве сорока сороков. Так что отсекание людей не обладающих таким навыком более чем разумно. Другое дело, что для проверки этого навыка, возможно, надо в явном виде задавать контекст задачи, — представьте, я заказчик, — и тд. Из статьи непонятно в каком контексте интервьюер ожидал уточняющих вопросов, возможно, кандидат просто не понял, что от него хотят (может это тоже плохой признак, конечно).
sshikov
01.06.2016 08:41Общаться со сложным заказчиком и формулировать уточняющие вопросы на ходу прямо в процессе разговора — это все равно две разные вещи. Иногда полезно подумать, прежде чем уточнять.
avost
01.06.2016 09:57Наверное, я не понимаю ничего в работе аналитика. По-вашему, в процессе общения с заказчиком (или, с другой стороной — с разработчиками) аналитик просто сыплет заученную домашнюю заготовку, запоминает ответы, потом удаляется, дома обдумывает уточняющие вопросы, заучивает и на следующей фазе озвучивает их в режиме магнитофона? По-моему, это какой-то плохой аналитик. Или не аналитик вовсе.
sshikov
01.06.2016 10:42Вы что-то себе додумали из моего ответа, я такого не говорил. Я лишь сказал, что если у человека не возникли прямо сейчас уточняющие вопросы — это ровным счетом ничего пока не значит. Вот если они не возникли вообще — да, это плохо.
avost
01.06.2016 11:01Ну, это, как минимум, значит, что работа будет двигаться крайне медленно. Да и проверить возникли ли вопросы потом — возможности нет. :)
sshikov
01.06.2016 11:38Ну, про удалиться и додумать дома — это ведь тоже не я придумал. Я лишь говорю, что люди разные, а время интервью ограничено. Да, возможности проверить напрямую нет. Но и делать из этого сразу выводы рановато.
avost
01.06.2016 12:46Ну, разумеется, люди разные. Одни из них подходят для работы аналитиками, другие — нет. :)
И мне казалось, что способность к вытягиванию уточняющих деталей — это одно из основных свойств аналитика. И если он не проявляет этой способности в относительно комфортных условиях специально смоделированной для этого задачи, то я бы не поставил ни гроша на то, что он будет способен это сделать в реальных условиях.
На самом деле, тут ещё о терминах вопрос — сейчас аналитиком себя кто только не называет и должностные обязанности аналитиков в разных компаниях могут как небо от земли отличаться.
davvol
01.06.2016 11:23Ситуации разыгрывались как в ролевой игре.
Соискатель — это аналитик, а я за всех остальных персонажей.
summerwind
01.06.2016 04:00Скажите, а по вашему мнению, какой правильный ответ на вопрос «Что должен делать аналитик, а что не должен»?
Vadimyan
01.06.2016 10:21ИМХО, правильный ответ — это наличие ответа. Уверенный ответ. В каждой команде роли распределяются по-своему, но нужно представлять те обязаности, которые можешь взять на себя и которые видишь перспективным и выгодным для команды на себя брать.
Если же кандидат начинает тормозить, это признак губительной несамостоятельности и, возможно, излишней авторитарности со стороны руководителя проекта на предыдущих проектах.davvol
01.06.2016 11:26Чаще получалось что соискатели гребли всё под себя, совершенно не доверяя команде.
davvol
01.06.2016 11:25Это не вопрос, а целый ряд вопросов, в рамках которых хотелось бы услышать что аналитик не оценивает трудоемкость, не пишет тесты и не показывает демо клиенту (я искал аналитика в scrum команду)
Danov
01.06.2016 10:26Хороший подход. Интуитивный, не идеальный, но работает. Всё же 17 человек это не 170.
Сам подбирал себе в отдел аналитиков фильтруя студентов тестом на логическое мышление «шмурдик, запырка,...». Смотрел, на скорость и результат. Аналитик часто сталкиватся с незнакомой предметной областью и нужно быстро выстраивать непротиворечивые логические схемы. Недостаток: тест легко выучивается. Можно использовать лишь несколько раз, пока не начался активный обмен опытом между кандидатами.
Уровень EQ оценивал в процессе интервью, полагаясь на свой преподавательский опыт. Расспрашивал об интересе к различным предметам, курсовым работам. В итоге выяснялось отношение к сокурсникам, преподавателям и предметам, умение работать с конфликтами и пр.
Самое любопытное, то что тест на логическое мышление лучше всех проходили не студенты матфака. Скорее всего, это наша локальная флуктуация.
Профессиональные знания не рассматривал. Не нашел бы никого :)
Формирование требований, UML, BPMN, ARIS, уже в рабочем процессе изучали.davvol
01.06.2016 11:29Было у меня желание проверять логику, но я предварительно провел эксперимент, опросив свою команду и соседей.
Вопрос был простой «Является ли отсутствие доказательств присутствия доказательством отсутствия?»
Ответы никак не коррелировали с компетенцией или занимаемой ролью, так что я решил принципиально ничего такого не добавлять.
Amareis
01.06.2016 12:06+1Это скорее проверка на парсинг сложной словесной конструкции. Я даже в тексте дважды перечитал. прежде чем понял суть :)
Нет, не является. Доказательством отсутствия, вообще-то, ничего не является, а требование такого доказательства — логическая ошибка.terryP
01.06.2016 14:28Доказательством отсутствия, вообще-то, ничего не является, а требование такого доказательства — логическая ошибка.
Только в случае отсутствия в пределах всей Вселенной, то что определенного предмета нет в определенной пустой комнате — доказать можно, просто заглянув в эту комнату.
pan_KOST
01.06.2016 12:57Очень правильный подход, но, на мой личный взгляд, не рассмотрены следующие ситуации из других компаний:
- Разделение аналитиков на бизнес-аналитиков и системных аналитиков.Бизнес-аналитик детально прорабатывает бизнес-кейсы и все пути достижения целей заказчика с помощью системы, в то время как системный аналитик является частью команды разработки и заказчиков в глаза не видит, зато он делает техническое задание из функциональной спецификации бизнес-аналитика, жёстко привязанное к возможностям конкретной платформы
- Наличие в проекте Руководителя проекта или владельца продукта, который и формирует приоритеты выполняемых задач. На мой взгляд, аналитик не имеет возможности решать, что войдёт в релиз, а что нет. Как правило, сначала руководитель проекта договаривается с заказчиком о допсоглашении, в котором будет описано изменение обязательств компании-интегратора/разработчика и заказчика.
Аналогично, я не вижу для аналитика решения кейса «Два директора» — это проблема компании интегратора/разработчика в лице руководителя проекта так выстроить работу с заказчиком, где будет одно лицо или коллегиальный орган, принимающий проект со стороны заказчика. Т.е. заказчик сам должен решить — кому из директоров верить и как делать результат. Руководитель проекта может предложить варианты, но принять решение что делать должен Заказчикdavvol
01.06.2016 14:48Разделение аналитиков на бизнес-аналитиков и системных аналитиков.Бизнес-аналитик детально прорабатывает бизнес-кейсы и все пути достижения целей заказчика с помощью системы, в то время как системный аналитик является частью команды разработки и заказчиков в глаза не видит, зато он делает техническое задание из функциональной спецификации бизнес-аналитика, жёстко привязанное к возможностям конкретной платформы
У нас такого разделения нет.
К тому же вот это "детально прорабатывает бизнес-кейсы и все пути достижения целей заказчика с помощью системы" на мой взгляд задачи системного аналитика.
Бизнес-аналитик не привязан к системе. Он представитель заказчика который понимает как работают бизнес-процессы. Он (если он есть) выдает задачу, а уже системный аналитик работает с ней рамках своей системы.
Но тут есть опасность завязнуть в терминологии, т.к. часто люди даже в одном подразделении вкладывают совершенно разный смысл в понятия БА и СА.
На мой взгляд, аналитик не имеет возможности решать, что войдёт в релиз, а что нет.
Решают представители бизнеса когда расставляют приоритеты. Аналитик начинает работать от самого важного и ниже, таким образом наполняя релиз фичами.
Аналогично, я не вижу для аналитика решения кейса «Два директора» — это проблема компании интегратора/разработчика в лице руководителя проекта так выстроить работу с заказчиком, где будет одно лицо или коллегиальный орган, принимающий проект со стороны заказчика.
Не всегда это достижимая задача. Многое зависит от того как организационно устроен заказчик, как наполняется бюджет и т.д.
У меня вот прямо сейчас на проекте четыре стороны согласования (а не две, как в вымышленной ситуации), разделенные географически и по типам бизнеса. И ничего, хорошо работаем.
terryP
Как то очень коротко о главном. ИМХО, вы бы привели хотя бы пример вопросов и ответов по которым вы отсеивали кандидатов. И несколько реальных примеров собеседований. А то похоже на инструкцию по рисованию совы, сейчас нарисуем три кружка, а дальше вы сами разберетесь, не маленькие…
davvol
Обновил статью, привел примеры вопросов и ожидаемых ответов.