Кто есть кто: системный и бизнес-аналитик

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

Александр Чунаев

Head профессии по системному анализу в розничном блоке

Если вы откроете список вакансий на hh.ru, зайдёте на YouTube или любой другой ресурс, то увидите информацию про множество разных аналитиков: бизнес-аналитик, системный аналитик и так далее. И на каждой странице будет своя информация о том, в чём суть их работы.

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

Из чего состоит работа аналитика

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

Более подробно про профессию лучше рассказать по книге «Разработка требований к программному обеспечению», которую написал достаточно известный на Западе айтишник Карл Вигерс. Итак, аналитика состоит из нескольких составляющих:

Цель

Это то, ради чего работаем. Чтобы правильно её определить, лучше всего многократно уточнить, к чему мы хотим прийти. Один из любимых способов — задать «пять почему» или «А зачем ты это делаешь?/Что хочешь получить в результате?». Только точно понимая цель можно сформулировать оптимальное решение и отбросить всё лишнее.

Требования

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

Полнота и корректность — требование должно полностью отражать, что заинтересованное лицо хочет получить (корректность), быть грамотно сформулированным и не иметь смысловых пробелов (полнота).
Осуществимость — требование должно быть возможно выполнить. Это подтверждается разработчиками.
Необходимость — требование должно согласовываться с целью задачи, ожиданиями заинтересованных лиц и возможными ограничениями/правилами.
Проверяемость — выполнение требования должно быть возможно проверить. Это свойство для тестировщиков.

и другие.

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

Требования делятся на несколько слоёв:

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

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

Работа с требованиями протекает постепенно:

Аналитик собирает и изучает информацию.
Структурирует и осмысляет её.
Фиксирует и утверждает требования.
Передаёт требования разработчикам и тестировщикам .

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

Интеграции

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

В чём разница между бизнес- и системным аналитиком

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

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

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

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

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

Что в итоге?

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