Бизнес-аналитик изучает процессы и потребности компании, выявляет проблемы и помогает согласовать требования к изменениям. В IT-проектах он связывает бизнес и команду разработки: уточняет, что нужно пользователям, почему это важно и как проверить результат.
Этот материал предназначен для работодателей. Разберём, какой бизнес-аналитик нужен компании, где его искать, какие примеры работы изучить и как проверить компетенции на интервью.
Начните с задач, а не с перечня инструментов. Аналитик для описания складских процессов и аналитик для развития корпоративной системы могут иметь разный опыт. Чёткий профиль вакансии поможет найти специалиста, который соответствует вашему проекту.
Этот материал предназначен для работодателей. Разберём, какой бизнес-аналитик нужен компании, где его искать, какие примеры работы изучить и как проверить компетенции на интервью.
Начните с задач, а не с перечня инструментов. Аналитик для описания складских процессов и аналитик для развития корпоративной системы могут иметь разный опыт. Чёткий профиль вакансии поможет найти специалиста, который соответствует вашему проекту.
Какой бизнес-аналитик нужен
Название должности не всегда раскрывает содержание работы. В одних компаниях бизнес-аналитик занимается процессами и организационными изменениями, в других — преимущественно требованиями к программному продукту.
Эти профили могут пересекаться. Определите, какие задачи занимают основную часть времени и какой результат нужен от сотрудника.
Не путайте бизнес-аналитика с аналитиком данных. Если главное — SQL, исследование показателей и создание дашбордов, изучите, как найти аналитика данных. Бизнес-аналитик тоже может работать с данными, но это не всегда его основная функция.
Для бюджетирования, финансовых моделей и анализа денежных потоков полезен другой профиль. Его выбор разобран в статье как найти финансового аналитика.
Также разграничьте бизнес-анализ и системный анализ. Если сотруднику предстоит подробно проектировать интеграции, интерфейсы обмена и техническую структуру решения, укажите эти обязанности отдельно и проверьте соответствующий опыт.
В профиле вакансии зафиксируйте:
- проблему или направление, с которым предстоит работать;
- основные процессы и системы;
- участников проекта и порядок принятия решений;
- ожидаемые документы и другие результаты;
- уровень самостоятельности;
- требования к отраслевому опыту;
- границы ответственности.
Если нужна помощь с поиском, можно обсудить с CorpStaff подбор IT-специалистов. Подготовьте задачи и примеры ожидаемых результатов: это поможет определить профиль аналитика и критерии отбора.
Где искать
Используйте сайты вакансий, профессиональные сообщества, рекомендации и проектные контакты. Выбирайте каналы с учётом уровня специалиста и предметной области.
Сайты вакансий. Опишите работу конкретно: сбор требований к системе, анализ процессов, сопровождение внедрения или развитие продукта. Укажите, с кем будет взаимодействовать сотрудник и кто отвечает за технические решения.
Профессиональные сообщества. В тематических группах можно найти специалистов, которые обсуждают процессы, требования и практику внедрения. Смотрите на содержание ответов: умеет ли человек уточнять задачу, замечать ограничения и объяснять выбор подхода.
Рекомендации. Спросите коллег и партнёров, какие задачи аналитик выполнял лично и как работал с участниками проекта. Рекомендация особенно полезна, если проекты сопоставимы по сложности.
Проектные специалисты и подрядчики. Подходят для ограниченной задачи: обследования процесса, подготовки требований или сопровождения отдельного этапа. Согласуйте объём, доступ к сотрудникам, порядок проверки результатов и передачу материалов.
Для начинающего аналитика определите наставника и задачи, которые можно выполнять под руководством. Если сотрудник должен самостоятельно согласовывать сложные изменения между отделами, проверяйте такой опыт отдельно.
На первом разговоре уточните специализацию и разберите один проект. Не оценивайте кандидата только по названию должности: обязанности бизнес-аналитика в разных компаниях заметно различаются.
Что смотреть в опыте
Попросите кандидата подробно рассказать о двух проектах, похожих на ваши. Начните с исходной проблемы: что не устраивало заказчика, какие ограничения действовали и что требовалось изменить.
Затем выясните личный вклад. Кто проводил интервью, описывал процессы, готовил требования и принимал решения? Работа в успешном проекте не означает, что кандидат самостоятельно выполнил все аналитические задачи.
Проверяйте рабочие результаты — их часто называют артефактами. Это могут быть схемы, описания, таблицы и протоколы, которые помогают участникам одинаково понимать задачу.
Не требуйте весь перечень для любой вакансии. Состав документов зависит от проекта. Важно, чтобы кандидат мог объяснить, зачем использовал конкретный формат и кому он помогал.
Если требуется моделирование процессов, попросите разобрать схему в BPMN. Оценивайте не только знание обозначений, но и логику процесса: где начинается работа, кто выполняет действия и что происходит в нестандартной ситуации.
UML и SQL проверяйте, если они действительно нужны. Не превращайте интервью бизнес-аналитика в экзамен по разработке только потому, что проект связан с IT.
Для каждого кейса задайте вопросы:
- Как вы выяснили потребности участников?
- Какие источники использовали кроме интервью?
- Какие противоречия обнаружили?
- Как проверяли понимание требований?
- Кто согласовал результат?
- Что изменилось после реализации?
- Что вы сделали бы иначе?
Попросите пример ошибки или неудачного решения. Содержательный ответ показывает, как человек заметил проблему и изменил подход.
Рабочие материалы могут быть конфиденциальными. Принимайте обезличенные примеры или устный разбор. Не требуйте внутренние документы прежнего работодателя без разрешения.
Кейс на интервью
Кейс должен проверять сбор и уточнение требований, а не способность быстро составить длинный документ. Используйте учебную ситуацию, близкую к вашей работе.
Пример: согласование скидок в компании.
Руководитель продаж просит «автоматизировать скидки, чтобы менеджеры работали быстрее». Финансовый отдел хочет контролировать маржу. Менеджеры жалуются на ожидание согласований, а разработчики просят конкретные требования.
Попросите кандидата объяснить, как он начнёт работу, кого пригласит на обсуждение и какие результаты подготовит.
Первый этап — уточнение проблемы.
Хороший аналитик не начинает сразу проектировать экран. Он выясняет, как согласования проходят сейчас, где возникают задержки и почему требуется изменение.
Ожидаемые вопросы:
- Кто запрашивает и согласовывает скидку?
- В каких случаях согласование обязательно?
- Какие данные нужны для решения?
- Как часто возникают задержки?
- Есть ли разные правила для товаров и клиентов?
- Что происходит, если согласующий недоступен?
- Как компания поймёт, что процесс стал лучше?
Не требуйте угадать все правила. Кандидат должен обнаружить недостаток информации и предложить способ её получить.
Второй этап — участники и источники.
Попросите определить, с кем нужно поговорить. Кроме руководителей могут потребоваться менеджеры, сотрудники финансового отдела, администратор системы и разработчик.
Уточните, какие документы и данные помогут проверить ответы: действующие правила, примеры заявок, история согласований и обращения сотрудников. Аналитик должен отличать установленный порядок от реальной практики.
Третий этап — описание требований.
Предложите подготовить краткую структуру: цель, границы изменения, роли, основные шаги, правила и открытые вопросы.
Проверьте, разделяет ли кандидат потребность и вариант решения. «Сократить ожидание согласования» — цель, а «добавить кнопку» — возможная часть реализации. Кнопка сама по себе не подтверждает достижение цели.
Хороший ответ учитывает исключения: неполные данные, превышение полномочий, изменение заявки и отсутствие согласующего. Для системы могут понадобиться требования к доступам и истории действий.
Четвёртый этап — противоречие.
Добавьте условие: продажи предлагают разрешить скидки без согласования, а финансовый отдел требует проверять каждую заявку.
Оцените, как кандидат выяснит причины позиций, предложит варианты и организует решение. Он не должен молча выбрать сторону или обещать всем несовместимые результаты.
Возможные варианты обсуждения — разные маршруты по условиям заявки, ограничение полномочий или изменение сроков согласования. Это гипотезы для проверки, а не готовые правила компании.
Пятый этап — приёмка.
Попросите сформулировать несколько проверяемых критериев. Например: при отсутствии обязательных данных заявка не отправляется, а пользователь получает сообщение с указанием незаполненных полей.
Важно, чтобы критерий описывал наблюдаемое поведение и соответствовал согласованному правилу. Формулировка «система работает удобно» недостаточна.
Оценивайте кейс по общей карточке:
Для первичной проверки достаточно обсуждения и небольшого наброска. Не просите бесплатно обследовать действующий процесс компании и подготовить полноценную документацию. Если результат планируется использовать, согласуйте оплачиваемую работу.
Как проверить коммуникацию
Бизнес-аналитик работает со стейкхолдерами — людьми, которые влияют на проект или затронуты изменениями. Это руководители, пользователи, разработчики, тестировщики и другие участники.
Проверяйте способность слушать, уточнять и фиксировать договорённости. Красноречие само по себе не показывает, что человек сможет разобраться в противоречивом запросе.
Проведите короткую ролевую беседу. Пусть интервьюер выступит заказчиком и скажет: «Нам нужна новая CRM, старая неудобная». Посмотрите, выяснит ли кандидат конкретные проблемы, пользователей, ограничения и признаки успешного изменения.
После разговора попросите кратко пересказать понимание задачи. Сильный ответ разделяет подтверждённые сведения, предположения и вопросы, которые ещё нужно решить.
Для подготовки сценария можно использовать вопросы для интервью с ИИ. Проверяйте их связь с вакансией и оценивайте ответы по заранее определённым критериям.
Полезно задать вопросы о сложных ситуациях:
- Как вы действуете, если заказчик не может объяснить потребность?
- Что делаете, если участники по-разному понимают согласованный документ?
- Как сообщаете, что часть требований пока нельзя реализовать?
- Как работаете с изменением требований после начала разработки?
- Что фиксируете после встречи?
- Как проверяете, что участники одинаково поняли решение?
Ожидайте примеры действий: уточняющие вопросы, визуализацию, разбор конкретных ситуаций, фиксацию решений и подтверждение договорённостей.
Настораживают следующие признаки:
Сразу предлагает решение. Не выясняет проблему, пользователей и ограничения.
Только записывает пожелания. Не замечает противоречий и не уточняет неоднозначные формулировки.
Путает предположения с фактами. Включает неподтверждённые правила в требования без пометки и согласования.
Не обсуждает исключения. Описывает только идеальный сценарий.
Не может объяснить документ. Использует термины, но не показывает, какую задачу они решают.
Не фиксирует изменения. Не объясняет, как поддерживает актуальность требований и сообщает о новых решениях.
Обвиняет участников вместо разбора причин. Не показывает, как уточнял запрос и организовывал согласование.
Отдельный признак требует уточнения, а не автоматического отказа. Сопоставляйте ответы с кейсами и практической проверкой.
Перед выходом сотрудника определите приоритеты, доступ к участникам проекта и порядок принятия решений. В первые недели поручите ограниченную задачу: изучить процесс, собрать вопросы и согласовать небольшой набор требований.
Хороший бизнес-аналитик помогает команде одинаково понимать проблему, требования и результат. Выбирайте его по сопоставимому опыту, качеству рабочих материалов и способности вести обсуждение от общего пожелания к проверяемым договорённостям.
