Системный аналитик vs бизнес-аналитик: найдите десять отличий (и готовьтесь к собеседованию)

За последние годы в IT все чаще появляются вакансии «аналитиков». Только вот каких именно? Бизнес-аналитиков, системных аналитиков… Многие путаются в этих названиях и должностных инструкциях. Попробуем разобраться, чем на самом деле отличаются эти две роли и как эти различия влияют на собеседования при найме.

Итак, представьте типичную ситуацию: стартапу нужен аналитик, и основатель понятия не имеет – какой именно. В описании вакансии намешано всего понемногу, и задачи бизнес-, и задачи системного аналитика (источник habr.com). Кандидаты тоже сбиты с толку: одним приходится общаться с заказчиками и оптимизировать бизнес-процессы, другим – копаться в технических деталях и писать спецификации для разработчиков. Вроде бы и те, и другие – аналитики, но роль у них разная. Давайте разберемся на живых примерах и мнениях экспертов, чтобы окончательно прояснить, кто есть кто.

Две роли – две области ответственности

Прежде всего, бизнес-аналитик и системный аналитик – это не конкуренты, а партнеры, работающие над общей целью. Но фокус у них действительно разный. Как метко заметила Индира Нам, аналитик с десятилетним опытом в Сбербанке, «разделение бизнес-аналитика и системного – это то, кто с кем общается и за какую часть отвечает». Бизнес-аналитик отвечает за бизнес-процессы и цели компании, а системный – за работу IT-системы и реализацию функций, необходимых для достижения этих бизнес-целей.

Проще говоря, бизнес-аналитик – это переводчик с языка бизнеса на язык требований. Он изучает, что нужно изменить в процессах компании, чтобы та работала эффективнее. Например, описывает текущие бизнес-процессы, находит «узкие места» и предлагает, что улучшить (источник skillbox.ru). Классический пример: аналитик видит, что какой-то отчет сотрудники до сих пор распечатывают на бумаге и несут руководителю.

Решение? Внедрить отправку этого отчета через CRM-систему, чтобы информация сразу доходила до всех заинтересованных лиц электронно. Но бизнес-аналитик, скорее всего, не будет сам писать техническое задание на доработку CRM – этим займется системный аналитик.

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

Для наглядности рассмотрим кейс. В интернет-магазине цветов руководитель жалуется: клиенты слишком долго оформляют заказ, многие бросают корзину. Бизнес-аналитик исследует текущий путь пользователя: рисует схему процесса покупки «as-is», находит проблемные места.

Выясняется, что покупателей заставляют заполнять кучу полей – например, адрес получателя, которого даритель может и не знать. Аналитик предлагает упростить форму: добавить опцию «узнать адрес у получателя автоматически» и убрать лишние графы. Он согласовывает новое решение с владельцем магазина и фиксирует требования в виде схемы и описания процесса «как должно быть» (to-be).

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

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

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

Важно понимать, что в реальных командах граница между ролями не всегда строгая. В небольших проектах один человек может совмещать обе роли – или компания может назвать позицию «бизнес-аналитик», ожидая от кандидата навыков системного анализа, и наоборот. Однако опыт показывает: попытка усидеть сразу на двух стульях несет риски. Эксперты по найму предупреждают, что объединение обеих ролей в одном человеке или взаимозамена их без корректировки ожиданий может привести к ошибкам, снижению эффективности и росту рисков (источник luckyhunter.io).

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

Кому ближе бизнес, а кому – системы?

Роли различаются не только задачами, но и требуемым складом ума. Считается, что бизнес-аналитика чаще привлекает людей, которым нравится общаться, договариваться, думать о продукте и пользователях. А системный анализ подходит интровертам, любящим копаться в деталях, схемах, API и базах данных. «Если крупными мазками – бизнес-анализ больше для экстравертов, а системный – для интровертов, но всё индивидуально», – отмечает та же Индира. Упрощенно можно сказать: одного больше драйвит улучшение клиентского опыта, а другого – техническая сторона реализации этих улучшений.

Бизнес-аналитика может заинтересовать тех, кто любит видеть общую картину: как устроен бизнес, где находятся точки роста, как пользователи взаимодействуют с продуктом. Им важнее результат для клиента и выгода для компании. Системный анализ же манит тех, кому любопытно, как работает все под капотом: как системы обмениваются данными, как спроектировать надежную архитектуру, как оптимизировать работу приложения на уровне кода. То есть либо вас больше вдохновляют жизненные, прикладные вопросы бизнеса, либо технические задачи – от этого и стоит отталкиваться при выборе специализации.

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

Как говорят в Skillbox, для профессионального роста обоим аналитикам важно развиваться и в области бизнес-, и системного анализа. Универсальный аналитик, знающий и BPMN и UML, и умеющий поговорить с гендиректором о стратегии, и с тимлидом о microservice-архитектуре, на вес золота. Но такие «универсалы» обычно приходят с опытом – начинать карьеру все же лучше, определившись, какой трек вам ближе.

Собеседование: испытание для аналитика

Если вы определились с ролью и подались на вакансию, будьте готовы к серьезному собеседованию. Практика показывает, что интервью на аналитиков нередко сложнее, чем сама повседневная работа – многие кандидаты сравнивают их с экзаменом. Проверяют не только знания, но и умение рассуждать, общаться, находить решения на лету. И для бизнес-, и для системного аналитика важны и технические навыки, и soft skills – поэтому обычно интервью включает вопросы разного плана (источник ifellow.ru).

Во-первых, теория и профессиональные методики. Почти наверняка спросят, как вы собираете и документируете требования. Например: «Какие типы требований бывают? В чем разница между функциональными и нефункциональными?». Кстати, правильный ответ: функциональные описывают, что должна делать система (например, формировать отчет), а нефункциональные – как она должна работать (например, отчет генерируется не дольше 5 секунд при нагрузке в 1000 пользователей). Системному аналитику практически гарантированы вопросы по технике: что такое UML и BPMN, когда и как их применять?

Как построить ER-диаграмму для базы данных? Что такое клиент-серверная архитектура? Могут проверить понимание интеграций: «Что будете делать, если внешнее API недоступно, а система должна обмениваться данными?» – ожидают, что кандидат продумает обработку ошибок, очереди или ретраи. Бизнес-аналитику скорее зададут вопросы про работу с бизнес-процессами: «Что такое диаграммы As-Is/To-Be?», «Как проводить GAP-анализ?». Например, надо уметь объяснить, что As-Is/To-Be – это описание процесса до изменений и после, своего рода «снимки» текущего и целевого состояний, а GAP-анализ ищет разрывы между ними и пути их устранения.

Во-вторых, практический опыт и кейсы. Часто интервьюер попросит рассказать о вашем реальном проекте: какие задачи вы решали, какую методологию использовали, с какими трудностями столкнулись. Для бизнес-аналитика могут дать ситуационный вопрос: «Вы выходите на проект, где бардак в требованиях – с чего начнете наводить порядок?» Или: «Как поступите, если заказчик требует очень сложную доработку «еще вчера»?» – здесь проверяется умение управлять ожиданиями, приоритизировать и договариваться.

Системному аналитику нередко предлагают решить мини-кейс по архитектуре или SQL: например, написать простой запрос или набросать структуру базы данных под описанный функционал. Недаром даже в статьях по подготовке советуют системным аналитикам освежить навыки SQL перед интервью (источник selecty.ru). Если в вакансии указаны конкретные технологии (SOAP/REST, Kafka, Oracle и т.д.), стоит повторить хотя бы основные концепции, потому что могут спросить про ваш опыт с ними.

В-третьих, “поведенческие” вопросы и коммуникация. Поскольку аналитик – это коммуникатор и посредник, на собеседовании обязательно оценят ваши soft skills. Например, для бизнес-аналитика популярный вопрос: «Как вы проводите интервью с заказчиком?» – хороший кандидат расскажет, что готовится заранее, изучает информацию о бизнесе клиента, формирует список гипотез и вопросов, на встрече начинает с открытых вопросов о целях, проблемах, потом уточняет детали, фиксирует результаты, различает хотелки и реальные потребности. Другой пример: «Как вы презентуете результаты проекта стейкхолдерам?» – здесь важно показать умение говорить на языке аудитории, будь то топ-менеджмент (для них – фокус на выгодах, минимум технического жаргона) или техническая команда (больше деталей реализации).

Системного аналитика могут спросить: «Как действуете, если требования бизнеса противоречат техническим ограничениям?» – ждетесь ответ про поиск компромисса. Или: «Приведите пример конфликта между бизнес-заказчиком и разработчиками и как вы его решили». Например, бизнес хотел запустить 10 новых полей формы “еще вчера”, разработка физически не успевала – решение: предложить приоритизацию, сделать сначала самые важные 3 поля, остальные в следующий релиз, согласовать с бизнесом. Главное – показать, что вы умеете находить баланс между интересами сторон, не встаете ни на чью сторону и говорите с каждым на понятном ему языке.

Многие отмечают, что интервьюеры бывают двух типов: «теоретики» и «практики». Первые будут гонять вас по определениям, терминологии, стандартам (“что такое нормализация БД?”, “перечислите критерии качества требований” и т.п.). Вторые – скорее поинтересуются, с чем вы реально работали и как решали задачи на прошлых проектах (“какой самый сложный баг находили в требованиях?”, “как сокращали время согласования документов?”). Невозможно заранее угадать, кто вам попадется, поэтому готовиться стоит ко всему понемногу. Полезно заранее выписать свой личный опыт – вспомнить проекты, кейсы, успехи и неудачи, чтобы на интервью не потеряться и подкреплять ответы реальными историями.

Кстати, пройти собеседование с первого раза удается не всем, и это нормально. Во-первых, каждый новый опыт – это урок: вы узнаете, на какие вопросы не смогли уверенно ответить, и подготовитесь лучше к следующему интервью. Во-вторых, собеседование – вещь во многом субъективная: всё зависит от того, как сложится общение с конкретным интервьюером. Иногда отказ – не показатель вашей некомпетентности, а просто отсутствие “химии” или несовпадение ожиданий. Опытный аналитик Виктор Дмитриев, получивший более 20 офферов, прямо говорит: не расстраивайтесь из-за отказов, относитесь к интервью как к возможности прокачаться и найти именно свою команду.

***

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

В небольших компаниях роль может выполнять один человек, в крупных – целые отделы аналитиков каждого профиля. Но суть остается: бизнес-аналитик формулирует правильный вопрос («что нужно бизнесу?»), а системный аналитик – находит правильный ответ на него в терминах IT-систем («как это реализовать?»). И те и другие сегодня очень востребованы в самых разных отраслях – от банков до геймдева.

Если вы собираетесь строить карьеру в аналитике, попробуйте оценить свои склонности и интересы – что откликается сильнее: разговоры с людьми о стратегии бизнеса или разработка технических решений «под капотом»? Впрочем, выбор не навсегда: многие со временем переходят из одной роли в другую, расширяя компетенции. Например, устав от бесконечных митапов с заказчиками, бизнес-аналитик может углубиться в системы, а системный аналитик, напротив, пойти ближе к продукту и пользователям. Обе профессии предлагают богатый вертикальный рост (до руководителя, архитектора, продакт-оунера), а также горизонтальные возможности обучения и менторства (сейчас огромный спрос на опытных аналитиков как наставников новичков).

И самое главное – независимо от выбранной специализации, будьте готовы постоянно учиться. Читайте книги и статьи по бизнес-анализу и системному анализу, следите за трендами. Тогда на собеседовании любой сложности вы сможете уверенно показать, что разбираетесь и в потребностях бизнеса, и в языке технологий. А именно этого и ждут от хорошего аналитика. Удачи!