Привет, Хабр! Меня зовут Николай, я аналитик компании SimbirSoft. Мне довелось участвовать во многих проектах, и на каждом из них заказчики понимали задачи и роль аналитика по-своему. Поэтому вопрос ролей аналитика на проекте —  мои личные кровь и пот боли: часто в одном лице хотят видеть и разработчика, и продвинутого тестировщика с пониманием процессов автотестирования, и многое-многое другое. Тем не менее, многие требования находят отражение в навыках и интересах аналитика, но их ещё нужно правильно сформулировать при поиске.

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

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

Иными словами, типология ролей аналитиков призвана предотвратить расхождение интересов специалиста и клиента. Я нередко наблюдал ситуации, когда запросы клиентов не отражали полный список требований, ожидаемых от специалиста на самом деле. Например, при обсуждении выяснялось, что вместо системного аналитика для разработки ТЗ требовался аналитик 1С. Или от аналитика-джуниора по умолчанию ожидались навыки по разработке взаимодействия конкретных систем, довольно редких в отрасли. При этом я не беру в расчет обычные проблемы обычного системного аналитика, когда приходится погружаться в незнакомую предметную область или принимать дела в самом разгаре проекта. 

Аналитиков в IT можно условно разделить на две группы: 

1. Собственно аналитики, которые занимаются бизнес- и системной аналитикой. Сюда входят бизнес-аналитики и системные аналитики, а также их разнообразные роли, которые различаются в зависимости от выполняемых задач на проектах. О разнице между бизнес- и системным анализом можно послушать в выпуске подкаста «Чистый код». 

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

Содержание

I. Бизнес-аналитик, системный аналитик, и их подвиды

1. Бизнес-аналитик (BA) и его роли

• Каноничный бизнес-аналитик

• Ведущий аналитик команды

• Операционный/процессный аналитик

• Аудитор (процессов)

• Специалист по оптимизации процессов

• Бизнес-аналитик как проджект-менеджер

2. Системный аналитик и его роли

• Инженер по требованиям

• Системный аналитик 

• Системный инженер

• Интеграционный аналитик

II. Аналитика как метод

• DWH-аналитик / SQL-аналитик / Аналитик баз данных

• Data-аналитик / Дата-инженер

• BI-аналитик

III. Выводы

Бизнес-аналитик, системный аналитик, и их подвиды

Бизнес-аналитик (BA) и его роли

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

Каноничный бизнес-аналитик

Анализ процессов + менеджмент = решение проблем бизнеса в общем виде

Это специалист, который способен понять и выявить потребности владельцев бизнеса на некоторое улучшение, провести последующий анализ существующих процессов и предложить изменение в соответствии с потребностями заказчика. Именно к нему идут, чтобы, например, «повысить на 10% прибыль за счет снижения общих издержек производства». Причем действует этот специалист очень часто со стороны менеджмента, а не со стороны команды, что приводит к определенному сопротивлению его деятельности у разработчиков. Если же такой специалист находится в команде разработки, то бывает так, что он единственный, кто может продуктивно разговаривать с менеджментом и владельцем бизнеса — потому что видит целью не собрать продукт, а дать возможность пользователю реализовать бизнес-задачу. 

Бизнес-аналитик — переводчик с языка бизнеса на язык программистов, составляющий бизнес-требования (а иногда и предварительное ТЗ — о распространенных ошибках при его создании писали здесь). Кроме того, он должен формулировать запросы на доработку в терминах проекта. В зависимости от структуры проекта, это могут быть общие требования в духе «необходимо улучшить скорость работы пользователя с системой», а могут быть и вполне конкретные, с конечной целью доработок в определенном модуле и способами её достижения.

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

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

Анализ процессов команды + менеджмент = решение проблем бизнеса и команды аналитиков

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

Операционный/процессный аналитик

Анализ процессов + менеджмент = решение проблем бизнеса за счет оптимизации процессов

На первый взгляд, он ничем не отличается от каноничного бизнес-аналитика, описанного выше, который анализирует процессы AS IS и предлагает искомый TO BE для озвученного заказчиком запроса. То есть так должно быть в идеале. При этом определение операционного или процессного аналитика чаще всего используют вне IT, хотя на самом деле подразумевают ту самую работу по BABOK.

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

Аудитор (процессов)

Анализ процессов = определение проблем бизнеса

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

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

Специалист по оптимизации процессов

Подбор решений + продвижение решений = решение проблем бизнеса

Он же канбан-мастер, эксперт ТРИЗ и главный рационализатор. Вроде бы и не аналитик совсем, и к IT-системам относится постольку-поскольку. Эта роль раньше была очень распространена, и сейчас крупные предприятия возвращаются к системе бережливого производства, внедряя те или иные подходы (в том числе Канбан) — так кто сказал, что это не нужно при выпуске IT-систем?

Найти соответствующего специалиста, который может провести анализ ситуации на месте (в том числе в IT-системе) и обладать подходящим бэкграундом — тяжело. Но иногда нужен именно он, а не бизнес-аналитик,  обладающий обширным, но несколько оторванным от производства объемом знаний. Рационализаторы — люди, увлекающиеся ТРИЗ и Канбан, чаще всего имеют опыт практической работы (даже руками) и управления коллективами в производстве материальной продукции. Их взгляд ох как может пригодиться.

Бизнес-аналитик как проджект-менеджер

Анализ текущих действий на основе процессов + менеджмент (контроль процессов) = решение задач бизнеса

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

Выделять отдельного специалиста на роль менеджера проекта целесообразно, когда предполагается, что он будет выполнять большой объём работы — например, в новом проекте, при многочисленных декомпозированных задачах. То есть всегда, когда процессы не отлажены, неравномерны. Однако зачастую на проектах не так много задач для ПМ как отдельного сотрудника, поэтому эту роль берёт на себя по совместительству бизнес-аналитик (а иногда системный, но о нем расскажем в следующей главе). 

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

Системный аналитик (SA) и его роли

Инженер по требованиям

Сбор и анализ требований + анализ IT-системы = техническое задание

Это роль в классическом понимании системного анализа как раздела науки об описании систем (существует она куда дольше, чем современные IT-корпорации) на языке математики предполагает наличие массы стандартов, подобных IREB.

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

Системный аналитик, он же full-stack аналитик

Сбор требований бизнеса + анализ IT-системы = поставленные задачи

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

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

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

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

Системный инженер

Анализ окружения (системы) + анализ IT-системы + выбор решений = техническое задание + передаваемая система

Осторожно: иногда так называют продвинутого системного администратора.

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

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

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

Интеграционный аналитик

Анализ взаимодействий + анализ IT-системы = описание взаимодействий

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

На практике его роль выполняет full-stack системный аналитик. Но когда интеграционная работа начинает съедать большую часть времени, а опыт сужается до нескольких систем, волей-неволей стоит выделить эту роль как отдельную. Конечно, речь не идет об умении проектировать REST API — интеграционные аналитики специализируются на разработке комплекса взаимодействий под ключ. Например, интеграции брокеров сообщений, подключения к ЕАИС или специфическим производственным системам. 

Почему стоит выделить эту роль? Дело в том, что в ряде ситуаций интеграционному аналитику не требуется знание других разделов знаний системного анализа — по крайней мере, в том объеме, что требуется от full-stack специалиста.

Выводы

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

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

Формируйте свои желания и требования к аналитикам качественно, господа!

Спасибо за внимание!

Больше авторских материалов для аналитиков читайте в соцсетях SimbirSoft – ВКонтакте и Telegram.