Привет, Хабр! Меня зовут Николай, я аналитик компании SimbirSoft. Мне довелось участвовать во многих проектах, и на каждом из них заказчики понимали задачи и роль аналитика по-своему. Поэтому вопрос ролей аналитика на проекте — мои личные кровь и пот боли: часто в одном лице хотят видеть и разработчика, и продвинутого тестировщика с пониманием процессов автотестирования, и многое-многое другое. Тем не менее, многие требования находят отражение в навыках и интересах аналитика, но их ещё нужно правильно сформулировать при поиске.
В этой статье я расскажу, какие роли выполняют специалисты, как меняются их задачи, с кем могут путать разных аналитиков в IT, как их отличить, и чем каждая роль полезна для разных типов проектов. Потому что правильно выбранный аналитик может заменить 2-3 специалистов разного профиля, а неправильно — не сделать ничего.
Этот гайд поможет и заказчикам, и исполнителям. Первым — четко сформулировать желания и потребности. Вторым — разобраться в требованиях первых и лучше понять себя как специалиста.
Иными словами, типология ролей аналитиков призвана предотвратить расхождение интересов специалиста и клиента. Я нередко наблюдал ситуации, когда запросы клиентов не отражали полный список требований, ожидаемых от специалиста на самом деле. Например, при обсуждении выяснялось, что вместо системного аналитика для разработки ТЗ требовался аналитик 1С. Или от аналитика-джуниора по умолчанию ожидались навыки по разработке взаимодействия конкретных систем, довольно редких в отрасли. При этом я не беру в расчет обычные проблемы обычного системного аналитика, когда приходится погружаться в незнакомую предметную область или принимать дела в самом разгаре проекта.
Аналитиков в IT можно условно разделить на две группы:
Собственно аналитики, которые занимаются бизнес- и системной аналитикой. Сюда входят бизнес-аналитики и системные аналитики, а также их разнообразные роли, которые различаются в зависимости от выполняемых задач на проектах. О разнице между бизнес- и системным анализом можно послушать в выпуске подкаста «Чистый код».
Те, кто занимаются аналитикой как методом исследования чего бы то ни было. Эта группа, напротив, включает в себя совершенно разноплановые специальности, поэтому данный блок в статье мы спрячем под спойлер. Все эти специалисты занимаются разнообразными видами анализа, преимущественно выражаемого в аналитических отчетах.
Содержание
I. Бизнес-аналитик, системный аналитик, и их подвиды
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 специалиста.
В следующем разделе мы поговорим о специалистах, которые применяют анализ для решения своих задач. Однако кто-то из них не относится к самой аналитике и является специалистом иной области, иногда даже не касающейся IT. Тем не менее, их всех часто записывают в аналитики. А это не всегда верно и может вызывать недопонимание между заказчиком и специалистом.
Аналитика как метод
Как ни странно, бо́льшая часть описанных в данном разделе специальностей — именно роли, если мы говорим об аналитике как науке или разделе знания. Системный аналитик может выполнять нижеописанные роли при наличии специфических знаний, но чаще для этих задач ищут отдельных людей. И это правильно: даже простое хранилище данных будет спроектировано значительно быстрее профильным специалистом, чем это сделает аналитик-универсал.
Аналитики хранилищ, данных и прочего
DWH-аналитик / SQL-аналитик / Аналитик баз данных
Очень условная категория специалистов с самым разнообразным бэкграундом. Работа с базами данных ожидается как навык от системного аналитика. Отдельная роль аналитика по работе с БД нужна тогда, когда требуется нечто больше, чем просто выполнять обычные запросы. Например, разработка функций, реструктуризация или перенос данных.
А вот проектирование хранилищ, которым занимается DWH-аналитик, раньше отдавалась очень продвинутым SQL-разработчикам или системным администраторам. Сейчас ввиду наличия колоссальных хранилищ таким специалистам требуется гораздо больший набор аналитических знаний, чтобы эффективно выполнять свои задачи.
Стоит разделять две роли — один человек проектирует требования, второй их реализует. Все вместе это DWH, но в таком случае это временная роль для разработки проекта или реализации значительных доработок (если вы не Amazon, конечно).
Data-аналитик / Data-инженер
Споров о разделении этих специализаций в интернете уйма. Пожалуй, все сводится к выполняемым задачам: один специалист умеет разобраться в потоках данных и описать, как с ними работать; второй способен создать математическую модель обработки. Соответственно, и тем и другим может заниматься аналитик, но только при наличии соответствующих навыков (а в ряде задач — и узкоспециализированного образования).
Впрочем, и тот и другой к бизнес- или системному анализу не имеют отношения: набор навыков «правильного» data-аналитика включает в себя дисциплины этих наук только факультативно. Со своей стороны data-аналитики могут уметь работать с озерами данных и создавать предварительные модели данных, писать технические концепции, но это дополнительный и очень редкий навык.
BI-аналитик
Это ещё один вид аналитиков. В том, кто и откуда они — есть расхождения. Некоторые считают, что это подвид маркетологов, которые занимаются визуализацией полученных аналитических данных и собственноручным созданием систем визуализации (разработкой требований или настройкой специализированных решений из коробки для работы в конкретных условиях). Кто-то считает, что эти специалисты — бизнес- и системные аналитики, способные разрабатывать корректные метрики для оценки бизнес-процессов и ставить задачи на разработку систем, которые будут однозначно представлять эти данные.
В любом случае, для них предполагается самостоятельная работа по определению необходимых метрик, внедрению сбора данных о них и обработке — причем чаще всего с использованием конкретных систем. Все это очень далеко от обычного бизнес-анализа и требует дополнительных знаний, что заставляет искать BI-аналитиков среди маркетинговых и продуктовых аналитиков. Но это уже совсем другая история — о «зверях» незнакомых, редких и полезных.
Выводы
Уже на основе выделенных ролей можно создавать огромную матрицу — когда какой специалист нужен. И все равно ошибиться: слишком многое зависит от коллектива, от личности специалиста и конкретных предпочтений/настроений в команде. Узкая специализация гарантирует качество выполнения определенной работы, но при появлении новых вводных возникают отклонения.
Поэтому заказчик должен точно осознавать возможные изменения в ходе работы, а аналитик — постоянно расширять свои компетенции и корректировать узкие места своих знаний. Но поскольку каждая роль бизнес- и системного аналитика включает в себя и личные качества, и личный опыт — нужно учитывать, что перепрыгнуть наработанные годами привычки за полгода не получится. Не нужно ждать от специалиста по интеграциям, который несколько лет разрабатывал API в подходе API Fist в сторонке от команды, сможет с ходу управлять большой командой аналитиков. И наоборот.
Формируйте свои желания и требования к аналитикам качественно, господа!
Спасибо за внимание!
Больше авторских материалов для аналитиков читайте в соцсетях SimbirSoft – ВКонтакте и Telegram.
