Как нанять бизнес-аналитика: требования к уровням, собеседование и практическая проверка

Как нанять бизнес-аналитика: требования к уровням, собеседование и практическая проверка

Когда я впервые начала подбирать сотрудников уже в роли руководителя, у меня не было понятного ответа даже на самый первый вопрос: с чего начинать поиск бизнес-аналитика?

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

Я открывала похожие вакансии, смотрела, что требуют другие компании, и постепенно собирала собственный список. В нем быстро оказались знание нотации BPMN, работа с интеграциями, проведение интервью, описание требований, знание нескольких конфигураций 1С и еще десяток пожеланий.

Получался универсальный аналитик, который должен был уметь почти всё. При этом оставался главный вопрос: какие из этих требований действительно нужны для нашей работы?

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

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

Постепенно у меня появился собственный рабочий подход к подбору аналитиков. Я стала разделять обязательные и осваиваемые навыки, по-разному оценивать специалистов разных уровней и использовать на собеседовании небольшие практические ситуации.

В этой статье хочу поделиться наработками, которыми сама пользуюсь, когда нужно подобрать бизнес-аналитика. Это не универсальный стандарт для любой компании, а практическая схема, которую можно адаптировать под состав команды, уровень вакансии и задачи конкретного проекта.

Сначала нужно определить, кого именно ищет компания

Под названием «бизнес-аналитик» в разных компаниях скрывается разная работа.

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

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

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

Обе роли нужны, но требования к ним будут разными.

Перед публикацией вакансии нужно ответить себе на несколько вопросов:

• аналитик будет изучать процессы или в основном уточнять отдельные запросы;
• кто принимает итоговые решения по требованиям;
• нужно ли самостоятельно проводить встречи с руководителями;
• должен ли специалист знать конкретные конфигурации 1С;
• будет ли он участвовать в приемке и обучении;
• какая часть работы связана с документацией;
• есть ли в команде старший аналитик, который сможет проверять первые результаты.

После такого разбора часть требований к кандидату обычно исчезает.

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

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

Не смешивать обязательные требования и навыки, которым можно научить

В вакансиях часто одинаково звучат требования разного уровня:

• умение проводить интервью;
• знание BPMN;
• опыт работы с 1С:ERP;
• понимание интеграций;
• умение писать понятные требования;
• знание конкретной системы управления задачами.

Но часть из них определяет способность человека работать аналитиком, а часть можно освоить уже после выхода.

Гораздо сложнее быстро научить человека:

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

Поэтому требования полезно делить на три группы.

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

Что проверять у начинающего, среднего и ведущего аналитика

Одна и та же формулировка «сбор и анализ требований» может относиться к разному уровню самостоятельности.

Начинающий аналитик

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

Полезно проверить, может ли кандидат:

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

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

Если компания не готова выделить время на такую поддержку, нанимать стажера только из-за более низкой стоимости рискованно. В результате часть работы все равно придется выполнять более опытным сотрудникам, но уже параллельно с исправлением ошибок новичка.

Аналитик среднего уровня

Специалист этого уровня обычно может самостоятельно вести ограниченный функциональный блок.

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

На собеседовании я проверяю:

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

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

Ведущий аналитик

Для ведущего аналитика недостаточно хорошо описывать отдельные функции.

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

Полезно обсуждать не только подготовленные документы, но и ситуации, где:

• заказчик и проектная команда по-разному понимали цель;
• пришлось отказаться от первоначального решения;
• требования нескольких подразделений противоречили друг другу;
• объем проекта начал расширяться;
• младший аналитик подготовил слабый результат;
• решение влияло на несколько систем.

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

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

Почему обычного разговора о прошлом опыте недостаточно

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

Фраза «мы описали процессы компании» может означать, что специалист самостоятельно проводил интервью и готовил модель. А может — что он присутствовал на встречах и оформлял материалы ведущего аналитика.

Я обычно уточняю конкретное действие:

Какой участок находился именно в вашей ответственности?

Кто определял список участников встречи?

Как выглядел результат вашей работы?

Какие замечания вы получили?

Что пришлось переделать?

Такие вопросы помогают перейти от общего рассказа о проекте к реальной зоне ответственности кандидата.

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

Важно не само наличие ошибки. Намного полезнее понять, как кандидат ее обнаружил, что сделал после этого и изменил ли собственный подход к работе.

Идеальная история, где заказчик сразу сформулировал потребность, команда всё поняла и разработка прошла без уточнений, скорее вызывает дополнительные вопросы.

Практический пример лучше абстрактного теста

Большое практическое задание на несколько часов часто проверяет не только компетенции, но и готовность кандидата бесплатно потратить вечер (если такой готовности нет, то это не означает еще, что специалист плохой).

Для первичной оценки достаточно небольшого рабочего примера, который можно разобрать прямо на встрече.

Например:

Руководитель отдела говорит: «Нужно запретить менеджерам менять дату сделки. Они постоянно переносят сроки, и прогноз становится недостоверным».

Можно попросить кандидата объяснить:

• какие вопросы он задаст;
• какую проблему видит в запросе;
• кто должен участвовать в обсуждении;
• какие варианты решения рассмотрит;
• что зафиксирует после встречи.

Слабый ответ обычно сразу переходит к реализации: добавить запрет, роль или проверку перед записью.

Более сильный кандидат сначала уточнит, кто меняет дату, по каким причинам, должна ли она иногда корректироваться, какую дату используют в прогнозе и нужна ли руководителю история переносов.

Может выясниться, что полный запрет создаст новую проблему. Например, менеджеры не смогут обновить дату после изменения договоренностей с клиентом и начнут вести реальные сроки вне системы.

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

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

Что проверить в письменной работе

Для аналитика письменная коммуникация не менее важна, чем проведение встреч.

Даже сильное устное обсуждение теряет ценность, если после него остается текст, который каждый участник понимает по-своему.

Кандидату можно дать короткое описание разговора и попросить за 15–20 минут подготовить результат встречи.

Здесь не столь важно оформление, сколько содержание:

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

Особенно показательно, как кандидат работает с отсутствующей информацией.

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

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

Сложные обороты и большое количество терминов не делают материал качественнее. Хороший результат помогает участникам продолжить работу без дополнительного устного перевода.

Красные сигналы на собеседовании

Отдельная фраза редко говорит о кандидате всё. Но некоторые ответы стоит проверить глубже.

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

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

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

«Главное — максимально подробно всё описать». Подробность полезна не сама по себе. Документ может быть большим и при этом не отвечать на ключевые вопросы.

«На моих проектах противоречий не было». Возможно, кандидат работал с очень узким участком или не замечал конфликтов интересов.

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

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

Но, конечно, принимать решение по одной неудачной формулировке неправильно. Полезнее попросить привести конкретный пример и разобраться, что конкретно кандидат вкладывает в свой ответ.

Не принимать решение только по отраслевому опыту

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

Но отраслевой опыт не заменяет аналитические навыки.

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

Я смотрю на сочетание нескольких факторов:

• насколько критично знание предметной области с первого дня;
• есть ли в компании эксперты, которые смогут объяснить процесс;
• как быстро кандидат раньше осваивал новые направления;
• умеет ли он признавать границы своих знаний;
• способен ли переносить аналитический подход между разными предметными областями.

Для проекта с жесткими сроками и сложным регулируемым учетом готовый отраслевой опыт может быть обязательным.

Например, если сотруднику сразу нужно самостоятельно обсуждать сложные процессы бухгалтерского или налогового учета, времени на длительное погружение может не быть.

Для долгосрочной команды иногда выгоднее взять сильного аналитика и дать ему время на изучение предметной области.

Здесь важно заранее понимать, кто поможет сотруднику получить необходимые знания и как будет проверяться корректность решений на первых задачах.

Что должно быть понятно к моменту выбора кандидата

По итогам собеседования руководителю стоит определить не только то, подходит ли человек команде.

Нужно понимать, какой участок ему можно будет передать, где потребуется участие наставника и какого уровня самостоятельности мы ожидаем через несколько месяцев.

Мне помогает ответить на несколько вопросов:

• какие задачи кандидат сможет выполнять сразу;
• какие навыки нужно будет развивать после выхода;
• кто сможет проверять его первые результаты;
• какие ошибки на старте будут допустимы;
• какой уровень самостоятельности должен появиться к завершению испытательного срока.

Эти ответы нужны не только для принятия решения о найме. Они помогают не создавать завышенных ожиданий ни у руководителя, ни у самого кандидата.

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

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

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

После принятия кандидатом предложения начинается следующий этап — адаптация. Нужно подготовить первую задачу, определить роль наставника, познакомить сотрудника с рабочим контекстом и постепенно увеличивать самостоятельность.

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