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

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

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

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

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

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

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

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

Цель

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

Требования

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

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

и другие.

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

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

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

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

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

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

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

Интеграции

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

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

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

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

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

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

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

Что в итоге?

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