Однажды, ничего не предвещало беды.
Как вдруг, мой начальник озадачил меня: «А вот нам на смежный проект нужен новый аналитик, давай ты будешь собеседовать кандидатов?»
Я, конечно, согласился.
А потом подумал и понял, что я понятия не имею как собеседовать аналитиков, а главное, как понять, хороши они или нет. Но отступать было уже поздно!
Тут же присланные мне резюме, помимо неподходящих, были практически одинаковы. Одни и те же качества, одни и те же навыки, одни и те же технологии. Поиск по интернету не обнадежил, найденные статьи по теме были словно написаны одним и тем же копирайтером и особо помочь не смогли.
Образовалась целая орда якобы важных параметров, которые часто противоречили друг другу.
Пораскинув мозгами и посоветовавшись с мудрыми людьми я приступил к плану собеседования.
Вместо поиска абстрактных «золотых» качеств и навыков аналитика, которые надо бы проверять на собеседовании я начал отсекать бесполезные.
В итоге, бесполезным оказалось всё связанное с технологиями и приложениями. Проект на который я искал человека был про бизнес-приложения для клиентов, так что проверять знание, например, SQL или JSON не было никакого резона, а научить рисовать картинки в Sparx можно и обезьяну за неделю. Знание же всяких UML и BPMN требовалось лишь в контексте понимания процесса работы, а не «как правильно рисовать кружочки и стрелочки».
Казалось бы, о чем спрашивать то тогда? Но в итоге образовался отличный план, через который прошли 17 соискателей.
План состоял из трех частей.
Полностью абстрагировавшись от технических навыков, получился отличный фильтр для соискателей, все кандидаты прошедшие его были одобрены руководством и вызвали положительную оценку на последующих раундах.
Так что если вы с такой стороны еще не смотрели на найм аналитиков, посмотрите!
UPD: Привожу примеры задаваемых вопросов и ожидаемых ответов.
Из вступительных вопросов:
Из вопросов о роли аналитика в команде:
Разыгранные ситуации.
Как вдруг, мой начальник озадачил меня: «А вот нам на смежный проект нужен новый аналитик, давай ты будешь собеседовать кандидатов?»
Я, конечно, согласился.
А потом подумал и понял, что я понятия не имею как собеседовать аналитиков, а главное, как понять, хороши они или нет. Но отступать было уже поздно!
Тут же присланные мне резюме, помимо неподходящих, были практически одинаковы. Одни и те же качества, одни и те же навыки, одни и те же технологии. Поиск по интернету не обнадежил, найденные статьи по теме были словно написаны одним и тем же копирайтером и особо помочь не смогли.
Образовалась целая орда якобы важных параметров, которые часто противоречили друг другу.
Пораскинув мозгами и посоветовавшись с мудрыми людьми я приступил к плану собеседования.
Вместо поиска абстрактных «золотых» качеств и навыков аналитика, которые надо бы проверять на собеседовании я начал отсекать бесполезные.
В итоге, бесполезным оказалось всё связанное с технологиями и приложениями. Проект на который я искал человека был про бизнес-приложения для клиентов, так что проверять знание, например, SQL или JSON не было никакого резона, а научить рисовать картинки в Sparx можно и обезьяну за неделю. Знание же всяких UML и BPMN требовалось лишь в контексте понимания процесса работы, а не «как правильно рисовать кружочки и стрелочки».
Казалось бы, о чем спрашивать то тогда? Но в итоге образовался отличный план, через который прошли 17 соискателей.
План состоял из трех частей.
- Общие вступительные вопросы.
Какие требования бывают и какими свойствами обладают хорошие требования.
Они нужны чтобы понять, а аналитик ли передо мной?
Как выяснилось в процессе, за красивыми резюме скрывались и тестировщики и разработчики и даже люди не имеющие отношения к IT.
Вдобавок, эти простые вопросы дали еще один неожиданный эффект. Некоторые соискатели начинали психовать, когда им, обладателям таких шикарных резюме, задают такие простые вопросы. Ну, с такими разговор короткий, психованным в аналитиках не место. - Вопросы о процессе разработки и роли аналитика в команде.
Что должен делать аналитик, а что не должен. Какие у него отношения с девелоперами и QA, как он понимает методологии разработки в которых участовал и т.д. Практика показала, что далеко не все представляют себе весь цикл разработки приложения, свою роль в команде и зачем вообще бизнес заказывает софт у разработчиков. - Ситуационные вопросы.
Здесь мы моделировали как реальные ситуации в работе аналитика, так и выдуманные мной, чтобы проследить за ходом мысли соискателя. Рассматривали обычные проблемы аналитика: конфликт приоритетов или требований между несколькими заказчиками, конфликт внутри команды, нечеткое подчинение, интервьюирование заказчика, конфликт бизнес-интересов и т.п.
Самый полезный блок, т.к. проверял не только внимательность и сообразительность, но и способность уточнять неизвестные данные. В некоторых ситуациях я специально умалчивал некоторые вводные, однако только три(!) из семнадцати кандидатов хоть что-то уточняли у меня. Что, по моему мнению, печально.
Полностью абстрагировавшись от технических навыков, получился отличный фильтр для соискателей, все кандидаты прошедшие его были одобрены руководством и вызвали положительную оценку на последующих раундах.
Так что если вы с такой стороны еще не смотрели на найм аналитиков, посмотрите!
UPD: Привожу примеры задаваемых вопросов и ожидаемых ответов.
Из вступительных вопросов:
- Какой, по вашему, главный инструмент аналитика?
Самый первый вопрос. Я свято уверен что это голова. Но как оказалось, некоторые соискатели путают понятия «инструмент», «навык» и «компетенция»
- Какие требования бывают?
Здесь достаточно ответа что функциональные и нефункциональные. Что, нефункциональные можно разделить на бизнес-правила, ограничения и атрибуты качества. Что требования к отказоустойчивости — это атрибут качества, а требования к интеграции — это ограничения.
- Какими свойствами обладают хорошие требования?
Здесь ожидал услышать что-нибудь из этого списка: полные, однозначные, непротиворечивые, проверяемые и понимаемые. Можно еще, конечно, называть, но мне подойдет и так.
Из вопросов о роли аналитика в команде:
- Кто оценивает трудоемкость задач?
Команда разработки
- Кто пишет тест план и тест кейсы ?
QA. Несмотря на простоту ответа, некоторые соискатели удивили меня тут, сказав что все это делает аналитик. Для таких у меня был заготовлен вопрос: «Так что, по вашему QA — это такая бездумная обезьяна которая только и может что кнопки жать по готовым сценариям?» Но не смотря на подсказку, пара человек всё равно гордо ответила «Да!» на этот наводящий вопрос.
- Кто показывает демо клиенту (в случае scrum команды)?
Кто угодно из команды разработки, но не аналитик.
Разыгранные ситуации.
- Конфликт разработчика и QA
Вводная: Приходят к аналитику разработчик и QA и жалуются друг на друга. QA говорит что разработчик неправильно сделал, а разработчик говорит что это QA ничего не понимает.
Ожидаемые действия: Надо выяснить кто как понял, в чем проблема и в случае косяка со стороны аналитика уточнить требование, если оно трактуется неоднозначно.
- Конфликт приоритетов
Вводная: Релиз жестко запланирован по дате, разработки осталось месяц, всё вроде хорошо, но тут прибегает заказчик с новой пачкой требований и говорит срочно добавить их в релиз. При этом очевидно, что и новые и старые требования за месяц не сделать.
Ожидаемые действия: Выяснить что повлекло возникновение новых требований, проговорить потребности клиента, вдруг старые уже не актуальны, тогда их можно выкинуть. В случае если всё нужно, заставить клиента самому заново выставить приоритет и новым и старым и те что не влезают отложить на следующий релиз.
- «Убойное» требование
Вводная: На этапе оценки затрат разработчик говорит что это требование разрушит систему и чтобы его реализовать надо пару месяцев убить только на изменение архитектуры. А заказчик говорит: «Я, конечно, всё понимаю, но мне это нужно, по этому сделайте, вы же разработчики!»
Ожидаемые действия: Часто то что хочет заказчик — это лишь его личное видение ситуации и решения. За любым требованием лежит некая бизнес-потребность, задача её выявить и предложить более оптимальное решение, более дешевое в плане разработки.
- Интервью в слепую
Вводная: Аналитика отправляют опросить нового заказчика, однако о нем ничего не известно, даже не ясно еще, что за приложение ему нужно.
Какие главные вопросы задаст аналитик заказчику.
Следующие вопросы и их вариации я считаю правильными в такой ситуации:
Чем занимается заказчик и его сотрудники?
Зачем им понадобилось ПО? В чем вообще проблема?
Что он ожидает от этого ПО? Какой результат?
Как заказчик поймет что результат достигнут?
Какие ограничения есть у заказчика?
- Два директора
Вводная: Команда аналитика делает ПО для международной корпорации с офисами в Лондоне и Нью-Йорке. ПО будет использоваться клиентами этой корпорации. Директора этих офисов являются конечными заказчиками и для успешного релиза они оба должны подписаться. Однако, на одной из экранных форм один директор хочет чтобы была синяя кнопка и делала одно, а другой хочет чтобы была зеленая кнопка и делала совсем другое. Нужно найти аргументы, чтобы оба директора согласились на какое-то одно решение.
Ожидаемые действия: Через цепочку рассуждений прийти к выводу что раз директора управляют бизнесом, то и аргументы должны быть связаны с бизнесом компаний, а не «давайте сделаем две разные страницы» или «будем определять клиента по географическому положению». Идеальный вариант — соотношение выгоды, которую получит компания от разных функционалов с расходами на разработку и обслуживание этих функционалов.