Однажды, ничего не предвещало беды.
Как вдруг, мой начальник озадачил меня: «А вот нам на смежный проект нужен новый аналитик, давай ты будешь собеседовать кандидатов?»
Я, конечно, согласился.
А потом подумал и понял, что я понятия не имею как собеседовать аналитиков, а главное, как понять, хороши они или нет. Но отступать было уже поздно!

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

Образовалась целая орда якобы важных параметров, которые часто противоречили друг другу.
Пораскинув мозгами и посоветовавшись с мудрыми людьми я приступил к плану собеседования.
Вместо поиска абстрактных «золотых» качеств и навыков аналитика, которые надо бы проверять на собеседовании я начал отсекать бесполезные.

В итоге, бесполезным оказалось всё связанное с технологиями и приложениями. Проект на который я искал человека был про бизнес-приложения для клиентов, так что проверять знание, например, SQL или JSON не было никакого резона, а научить рисовать картинки в Sparx можно и обезьяну за неделю. Знание же всяких UML и BPMN требовалось лишь в контексте понимания процесса работы, а не «как правильно рисовать кружочки и стрелочки».

Казалось бы, о чем спрашивать то тогда? Но в итоге образовался отличный план, через который прошли 17 соискателей.

План состоял из трех частей.
  • Общие вступительные вопросы.
    Какие требования бывают и какими свойствами обладают хорошие требования.
    Они нужны чтобы понять, а аналитик ли передо мной?
    Как выяснилось в процессе, за красивыми резюме скрывались и тестировщики и разработчики и даже люди не имеющие отношения к IT.
    Вдобавок, эти простые вопросы дали еще один неожиданный эффект. Некоторые соискатели начинали психовать, когда им, обладателям таких шикарных резюме, задают такие простые вопросы. Ну, с такими разговор короткий, психованным в аналитиках не место.
  • Вопросы о процессе разработки и роли аналитика в команде.
    Что должен делать аналитик, а что не должен. Какие у него отношения с девелоперами и QA, как он понимает методологии разработки в которых участовал и т.д. Практика показала, что далеко не все представляют себе весь цикл разработки приложения, свою роль в команде и зачем вообще бизнес заказывает софт у разработчиков.
  • Ситуационные вопросы.
    Здесь мы моделировали как реальные ситуации в работе аналитика, так и выдуманные мной, чтобы проследить за ходом мысли соискателя. Рассматривали обычные проблемы аналитика: конфликт приоритетов или требований между несколькими заказчиками, конфликт внутри команды, нечеткое подчинение, интервьюирование заказчика, конфликт бизнес-интересов и т.п.
    Самый полезный блок, т.к. проверял не только внимательность и сообразительность, но и способность уточнять неизвестные данные. В некоторых ситуациях я специально умалчивал некоторые вводные, однако только три(!) из семнадцати кандидатов хоть что-то уточняли у меня. Что, по моему мнению, печально.


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

Так что если вы с такой стороны еще не смотрели на найм аналитиков, посмотрите!

UPD: Привожу примеры задаваемых вопросов и ожидаемых ответов.

Из вступительных вопросов:
  • Какой, по вашему, главный инструмент аналитика?
    Самый первый вопрос. Я свято уверен что это голова. Но как оказалось, некоторые соискатели путают понятия «инструмент», «навык» и «компетенция»
  • Какие требования бывают?
    Здесь достаточно ответа что функциональные и нефункциональные. Что, нефункциональные можно разделить на бизнес-правила, ограничения и атрибуты качества. Что требования к отказоустойчивости — это атрибут качества, а требования к интеграции — это ограничения.
  • Какими свойствами обладают хорошие требования?
    Здесь ожидал услышать что-нибудь из этого списка: полные, однозначные, непротиворечивые, проверяемые и понимаемые. Можно еще, конечно, называть, но мне подойдет и так.


Из вопросов о роли аналитика в команде:
  • Кто оценивает трудоемкость задач?
    Команда разработки
  • Кто пишет тест план и тест кейсы ?
    QA. Несмотря на простоту ответа, некоторые соискатели удивили меня тут, сказав что все это делает аналитик. Для таких у меня был заготовлен вопрос: «Так что, по вашему QA — это такая бездумная обезьяна которая только и может что кнопки жать по готовым сценариям?» Но не смотря на подсказку, пара человек всё равно гордо ответила «Да!» на этот наводящий вопрос.
  • Кто показывает демо клиенту (в случае scrum команды)?
    Кто угодно из команды разработки, но не аналитик.

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