Продолжаем разбираться в вопросе знакомства «нового» аналитика (системный и бизнес) со «старым» ПО (продукт/система/сервис). Добрались до ключевого вопроса - Как на собеседовании оценить опыт кандидата в данной области?

Можно задать вопрос напрямую, и получить развернутый ответ, который будет шаблонным и соответствовать идеальным условиям работы, или который будет содержать «преувеличение» опыта соискателя. Я считаю этот подход малоэффективным. Предлагаю использовать альтернативный путь - делать выводы на основе ответов на другие вопросы об опыте работы.

Вариант 1: Попросить рассказать на примере одной из последних задач, как он взаимодействует с заказчиком? Или, рассказать приходилось ли ему согласовывать с заказчиком приемочные испытания для задачи и как это выглядело? С одной стороны мы обсудим работу с требованиями. С другой поймем насколько кандидат пытается разобраться в имеющемся ПО и как он использует ресурс коллег от Бизнеса (основной заказчик) или Сопровождения (это могут быть DevOps или Support). Если соискатель работал у вендора, то он сможет рассказать про взаимодействие с представителями компании-заказчика (это будут примерно те же роли).

Вариант 2: Спросить про процесс работы над типичной задачей на последнем (-их) месте работы. В каком виде получает задачу от заказчика? Она хорошо описана или приходится уточнять детали? При проектировании изменений мнение каких заинтересованных лиц приходится учитывать? Далее фиксируем, что расскажет кандидат. Фиксирует ли он у Бизнес заказчика изменившееся описание задачи. Спрашивает ли у Сопровождения особенности текущей работы ПО. Обсуждает ли с Разработкой предварительные варианты решения в процессе работы над задачей аналитики.

Вариант 3: Смоделировать ситуацию, когда он в команде останется один. Например, «Ты выходишь на работу в новую компанию и получил задачу от Бизнес заказчика. В это же время у тебя из технической команды один коллега ушел в отпуск, второй уволился, третий уехал на конференцию, а Сопровождение занимается своими сверх срочными задачами. Как спланируешь работу над задачей?». Чтобы не пугать кандидата, можно добавить, что это вымышленная ситуация и мы у себя не допускаем подобных ситуаций, но его ответ нам интересен. Правильным в данном случае было бы предупредить о рисках линейного руководителя и Бизнес заказчика. Далее можно изучать документацию, всю которая найдется по нашему вопросу. Пробуем «пощупать» имеющуюся функциональность на тестовом стенде, и «проверяем» результаты в БД и в логах. Общаемся с Бизнес заказчиком и стараемся получить от него максимум информации, даже технические детали, если он знает. После такого изучения ПО аналитик сможет предложить решение и закрыть свою задачу. Когда коллеги будут доступны, можно будет с ними обсудить решение и при необходимости доделать задачу.В качестве заключения: Навык разбираться в работе имеющегося ПО важен не меньше, чем навыки проектирования нового ПО. Высокий уровень данного навыка поможет кандидату быстрее освоиться на новом месте работы и/или в новой технической и предметной области. Также это повысит качество решаемых задач. Поэтому при оценке кандидата следует обращать внимание на этот навык совместно с другими.