Бизнес аналитик в банке кто это

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

Даниил Пронин
Руководитель группы системного анализа направления интеграции

Обязанности интеграционного системного аналитика

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

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

Зачем нужен бизнес-аналитик?

Чаще системный аналитик принимает требования от бизнес-аналитика. Наши системные аналитики изучают предоставленные документы (BRF, заключения бизнес-анализа), уточняют требования и согласуют их. Бывают случаи, когда требования даёт сразу заказчик, то есть бизнес. Тогда нужно в том числе провести небольшой бизнес-анализ.

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

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

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

Для части интеграций мы используем корпоративную шину (IBM ESB). В планах полностью отказаться от неё, однако этот процесс трудоёмкий и надо позаботиться о том, чтобы наши потребители не сильно страдали от перехода на новую архитектуру. Сейчас наше целевое решение в части интеграционных взаимодействий — это микросервисная архитектура с использованием REST API и брокеров сообщений (Kafka, IBM MQ, который потенциально будет заменён на ActiveMQ).

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

Во многих организациях подход code first. Аналитики объясняют, что должно приходить на вход и выход, и передают эту информацию разработке в виде оформленной спецификации, либо в виде ТЗ. Дальше разработчики реализуют модель данных на уровне кода, алгоритмов, и на её основе автоматически генерируется контракт сервиса. Это Swagger-контракт или API-спецификация.

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

Есть два способа описать Swagger-контракт: JSON-формат, либо YAML-разметка. Мы используем последнюю. В YAML-разметке мы описываем, что получится в ответ на обращение, все ограничения, и отдаём потребителям. Благодаря этому они понимают, как им работать с сервисом, и могут начать разработку. То есть им не надо ждать, пока мы напишем ТЗ и код, так как в code first контракта без кода не получится.

Слева — разметка YAML, справа — вёрстка Swagger. Это достаточно простой пример, зачастую встречаются многоуровневые конструкции в Swagger/ADOC и сложные диаграммы

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

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

Пример UML-диаграммы, спроектированной в PlantUML

Хард скилы интеграционного системного аналитика

Чтобы всё это делать, системный аналитик должен разбираться в соответствующем стеке. У соискателей, которые приходят на эту должность, мы спрашиваем такие знания.

Микросервисы

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

Наши микросервисы реализуются на Java Spring Boot, развёртываются в OpenShift и публикуются на платформе управления API под названием IBM API Connect.

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

Также важно уметь использовать средства просмотра логов. Мы используем Kibana, а также Zipkin для трассировки цепочки вызовов.

Zipkin. Можно видеть дерево вызовов сервисов с длительностью каждого из вызовов

ESB

Это промежуточное ПО, которое представляет собой большой транспортный пересадочный узел для входящих и исходящих потоков. То есть такой хаб, на котором публикуются различные сервисы. Обращение к ним происходит через SOAP, MQ, JMS и т. п. В SOAP-протоколе, например, описывается строго типизированный формат интеграции, то, как должны выглядеть входные и выходные сообщения. Они валидируются по XSD-схеме, при этом используется XML-разметка.

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

Схема шины. Фасады — входные точки, к которым обращаются потребители. Сервисы — внутренние модули, которые содержат в себе логику, адаптеры — выходные точки, через которые идёт обращение к конечным системам

Устройство шинного адаптера. Слева — входящие потоки, справа — коннекторы к конечным системам. У компонента к БД (верхний DB Component) нет коннектора, так как обращение БД внутри компонента происходит на уровне Java кода

Виды интеграций

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

— REST API. В чём отличие REST API от SOAP-сервисов. Как правило, все дают базовый ответ, что REST — это архитектурный стиль, а SOAP — это протокол.

Нужно знать, какие методы используются в REST-сервисе. Многие впадают в ступор, что подразумевается под ними. Это HTTP-глаголы, поскольку REST базируется на HTTP-протоколе. Многие ограничиваются двумя методами — GET и POST, но на деле их больше. Важно понимать, чем они отличаются, если не приходилось с ними работать.

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

— SOAP-сервисы. У нас они остались на шине, но иногда приходится обращаться в мастер-системы по SOAP-протоколу. Важно понимать, из каких артефактов состоит сервис, например, XSD, WSDL.

Очереди и брокеры сообщений

У нас это IBM MQ и Kafka, но важен опыт работы с любым брокером сообщений, так как их концепции похожи. Если соискатель работал с этими инструментами, то спрашиваем, какая разница в построении очередей. Нужно описать, как выглядит взаимодействие — кто подписчик, кто поставщик сообщений.

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

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

Инструменты системного аналитика

• Спецификации. YAML-разметка, Swagger и OpenAPI.
• Для документации мы используем не стандартные страницы в Confluence или документы Word, а разметку AsciiDoc. Она лежит рядом с кодом, и в Confluence мы её подтягиваем через плагин.

Пример ADOC с превью

• Мы работаем в инструменте PlantUML, он позволяет текстом описывать UML-диаграммы, которые затем верстаются в картинку. Всю документацию мы кодим в различных разметках и храним рядом с кодом. В принципе, работа с документацией для интеграционного аналитика в Ренессансе — это скорее кодинг, чем работа в графических и текстовых редакторах.
• Gitlab и Jira.
• Средства для отладки тестирования: Postman, SoapUI для отладки сервисов или автоматизации вызовов. Иногда аналитику необходимо сымитировать вызов. Так он самостоятельно и быстро поймёт логику работы сервиса, входные и выходные параметры и сможет решить, нужны ли доработки. Если бы он лазил в документацию (которая не всегда может быть корректно составлена), то на это бы ушло больше времени, чем предметно что-то вызвать и смотреть на результат.
• Базы данных. Как правило, системный аналитик редко ходит в БД. Но, тем не менее нужно уметь составлять базовый SQL-запрос с выборкой.
• СМЭВ — это контурное взаимодействие с различными государственными ведомствами. С его помощью можно получить актуальную информацию, соответствующую законодательству, не спрашивая клиента.

Софт скилы системного аналитика

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

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

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

• Уметь собирать требования различными способами. Можно использовать различные приёмы для того, чтобы снижать степень неопределённости: брейншторминг или опросы. Участвовать также не только в опросе бизнес-аналитики, но и напрямую с бизнесом.
• Быть инициативным. В команде всегда ценны те люди, которые готовы помогать коллегам, включаться, чтобы причесать общий бэклог, забрать оттуда для себя задачу.
• Не стесняться границ, зон ответственности. Бывают случаи, когда участники команды разработки коммуницируют с коллегами только через лидов. Это порочная практика, поскольку тратится время на эту лишнюю цепочку.
• Оставаться ответственным. Не только за свои задачи, но и перед командой.

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

Советы при подготовке к собеседованиям

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

Освежите в памяти базовые понятия. Часто соискатели не готовятся, когда идут на собеседование. Это выглядит логично, потому что человек идёт показать свои знания и опыт. Но чем шире у человека кругозор, тем креативнее решения он придумывает.

Источник: tproger.ru

Бизнес-аналитик Операционного департамента в банке

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

Он проводит исследования оптимальности введения новых бизнес-технологий в существующий процесс и следит, чтобы они соответствовали всем нормативным документам Центрального Банка РФ. Для качественного исполнения обязанностей, сотрудник должен понимать принцип работы всего банковского дела и операционного департамента, в частности. Бизнес-аналитик принимает участие в тестировании программного обеспечения, на котором будет работать операционно-кассовый отдел.

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

Заработная плата Бизнес-аналитика Операционного департамента в банке.

Средний доход может составлять 40 000 – 60 000 рублей, в зависимости от регионального места работы и объема выполняемой работы. Он состоит из:

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

Требования к Бизнес-аналитику Операционного департамента в банке:

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

Обязанности Бизнес-аналитика Операционного департамента в банке:

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

Источник: hcpeople.ru