Карьера аналитика

Модель OSI (Open System Interconnection), часть 2

Продолжаем разговаривать про уровни модели OSI.

3️⃣ 3 уровень OSI - Сетевой уровень (Network Layer)

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

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

4️⃣ 4 уровень OSI - Транспортный уровень (Transport Layer)

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

Т.к. передача данных происходит по сети, то используются, как правило, два главных протокола TCP и UDP (о них еще поговорим).

5️⃣ 5 уровень OSI - Сеансовый уровень (Session Layer)

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

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

6️⃣ 6 уровень OSI - Уровень представления данных (presentation layer)

Уровень отвечает за преобразование данных в формат, подходящий для приложения или сети. Сюда же включаются задачи по шифрованию\дешифрованию, сжатию и преобразованию данных.

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

7️⃣ 7 уровень OSI - Прикладной (application layer)

Уровень обеспечивает доступ приложения к сетевым услугам. Реализует протоколы, которые поддерживают конечные пользовательские процессы и сетевые приложения.

Прикладной уровень похож на некий графический интерфейс для всей модели OSI - с его помощью пользователь взаимодействует с другими уровнями, причем даже не подозревая об этом. Этот интерфейс называется сетевым. Самые популярные из сетевых интерфейсов - это HTTP, HTTPS, FTP, SMTP.

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

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

Модель OSI (Open System Interconnection), часть 1

Сегодня мы опустимся на несколько уровней ниже классического системного анализа и рассмотрим модель OSI. Это эталонная модель взаимодействия открытых систем, которая описывает, как устройства в локальных и глобальных сетях обмениваются данными и что с этими самыми данными происходит. Ее предложили в 1984 году инженеры из Международной организации по стандартизации (небезызвестной нам ISO), которая в то время работала над единым стандартом передачи данных по интернету.

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

Так вот, сама по себе эталонная модель - это не стандарт интернета, как TCP/IP, скорее в рамках эдакой "коробки" OSI доступны различные веб-стандарты, такие как UDP, HTTP, FTP и другие (всего порядка сотни штук).
И наша модель разделяет процесс сетевого взаимодействия на семь взаимосвязанных слоев (уровней), каждый из которых выполняет свою четко определенную функцию и взаимодействует с уровнями, которые выше и ниже. Если упростить, то эти уровни работают с одними и теми же данными, но по-разному. Например, кабели передают информацию в виде нулей и единиц (самый нижний уровень), а сетевое оборудование (3 уровень) использует эти данные, чтобы передать их в другую точку страны или мира, чтобы компьютер конечного пользователя мог их получить и преобразовать в понятный для человека вид.

Рассмотрим каждый из слоев чуть более детально.

1️⃣1 уровень OSI - физический (physical layer)

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

Самый известный протокол на физическом уровне это Ethernet. Он описывает, как сигналы кодируются и передаются по проводам. Кроме этого есть Bluetooth, WI-FI, давно забытые ИК-порты, которые также содержат инструкции для передачи данных.

2️⃣ 2 уровень OSI - канальный (data link layer)

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

Если немного упростить, то на канальном уровне происходит передача информации в рамках одной локальной подсети.

P.S. О следующих уровнях поговорим во второй части. А пока поделитесь - задавали ли вам вопросы на собеседованиях на эту тему или вас эта участь обходила стороной?)

Профдеформация

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

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

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

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

А какие вы интересные вещи подмечали в жизни?

Последний рабочий день в этом году 🎉

Всё ты можешь

Раздражающие вещи в работе СА

Да, именно об этом хотелось бы сегодня поговорить, т.к. работа не только приносит удовлетворение и удовольствие - но и определенные негативные эмоции.
Хочу поделиться несколькими вещами, из-за которых они возникали у меня.

➖ Повторяющиеся, однообразные задачи

Я думаю с этим сталкивались все. Особенно опытные аналитики. И у каждого были такие задачи и свои примеры, когда из спринта в спринт приходилось заниматься одним и тем же. Например, написанием ТЗ на добавление очередных документов, которые система будет формировать в заявке на кредит. Когда тебе нужно из спринта в спринт заполнять один и тот же шаблон, немного меняя условия формирования документа.

➖Созвоны

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

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

➖Сроки

Раздражает срок "Нужно еще вчера". Особенно когда задача была не приоритетной и ты смело занимался другим, а потом всё резко поменялось и приходится на пол пути бросать одно и браться за другое.

➖ Спонтанные изменения

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

С заказчиками аналогично, когда задача уже на условном ПМИ - и тут вдруг захотелось все переделать потому что потому. А то что согласовано ТЗ, прошло множество обсуждений - это уже все, не котируется.

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

➖Люди

См. предыдущий пункт. Но в основном все лапушки, конечно.

➖Доступы

Да, да. Те самые доступы, которые ты можешь получать по месяцу, каждый (!). Привет банки, особенно.
Я только один раз видел в онбординге таблицу, в которой были перечислены все доступы, которые нужно запросить и которые понадобятся в работе аналитика. Часто бывает так, что ты спустя пол года работы на что-то натыкаешь в первый раз и идешь получать доступы, которые долго выдают.

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

А также поделитесь в комментариях своими вариантами того, что вас раздражает\огорчает\демотивирует в работе - интересно будет почитать и подумать, откликается ли это мне или другим.

Хореография

Паттерн "Оркестрация" был рассмотрен в предыдущем посте, теперь поговорим про хореографию.

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

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

Особенности архитектуры:

➖ Децентрализованное управление: система распределяет управление между участвующими компонентами. Каждый из них самостоятельно решает, как реагировать на события или сообщения, которые он получает;
➖ Автономность: компоненты в отлаженной системе должны работать автономно и не полагаться на внешние команды. Они отвечают за анализ входящих сообщений и запуск необходимых действий на основе своей собственной внутренней логики;
➖ Слабая связь: Данный подход способствует слабой связи между компонентами, позволяя им взаимодействовать без сильной зависимости друг от друга, что повышает гибкость системы (в отличие от оркестрации, в которой все жестко завязано на центральное звено);
➖ Асинхронная связь: связь между компонентами в системах с хореографией как правило асинхронная. Это позволяет компонентам обмениваться между собой сообщений или событиями, на которые не нужно немедленно и синхронно отвечать, что обеспечивает намного более лучшую отказоустойчивость (и масштабируемость);
➖ Управляемые события: компоненты реагируют на события или изменения состояния системы. События запускают действия внутри отдельных компонентов, те на них реагируют, создавая новые события, на которые триггерятся другие компоненты - и получается, что таким "Коллективным разумом" определяется поведение всей системы целиком.

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

P.S. И на самом деле сейчас такой подход на практике я встречаю чаще. А у вас на проектах как?

Хореография и оркестрация

Уже достаточно много постов в канале написано на темы, связанные с проектированием сервисов/микросервисов. В частности о том, как проектировать их методы, описывать документацию и примеры различных best-practices, которые я почерпнул из собственного (и не только) опыта.

Настало время подняться на уровень, а то и на два, выше и поговорить про архитектуру. А именно про различные популярные подходы к проектированию систем, которые используют микросервисную архитектуру.

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

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

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

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

Особенности архитектуры:
➖ Централизованное управление. Оркестратор определяет порядок выполнения задач и управляет их распределением между участниками системы;
➖ Жестко заданные процессы. Порядок выполнения задач заранее определяется и настраивается в рамках оркестрируемого процесса.
➖ Управление состоянием. Оркестратор может отслеживать состояние выполнения процесса и реагировать на изменения, из-за которых он перераспределить задачи и принимать решение на основе обновленного контекста.
➖ Управление ресурсами. Оркестрация может включать в себя управление любыми ресурсами, которые необходимы для выполнения процесса. От бизнесовых сущностей, до распределения вычислительных мощностей.

Из минусов:
➖Самый очевидный минус в том, что когда у тебя весь процесс завязан на одно управляющее звено - он становится более уязвим примерно ко всему.

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

P.S. В комментарии вложу абстрактный пример концепции оркестрации.

Особенно про аналитику и документацию.

Нельзя так просто взять и перестать шутить про ее отсутствие.

Подход "API First"

Частично про этот подход я уже рассказал в прошлом посте, сейчас сформулирую более подробно.

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

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

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

Как процесс выглядит на практике со стороны аналитика, проектирующего сервис, у которого будут какие-либо внешние потребители:

➖ Задача поступает тебе в работу, собраны предварительные требования (или даже написано БТ);
➖ Тебе необходимо спроектировать какой-нибудь core-сервис со сложной внутренней логикой, который будет рассчитывать данные для потребителей. У тебя уже есть верхнеуровневое понимание того, какие данные этот сервис будет потреблять и какие данные он будет отдавать на выход;
➖ Вместо того, чтобы начать анализировать саму логику, по которой эти сложные вычисления будут производиться, ты первым делом идешь и накидываешь контракт сервиса в формате черновика, который отдаешь тем командам, которые от тебя зависят на согласование;
➖ Пока контракт выравнивается и происходит обработка замечаний\комментариев ты уже приступаешь к описанию основной логики. При этом ты освободил руки для СА смежных команд, которые уже могут приступать к анализу со своей стороны.
➖ К концу анализа у тебя есть описанный и согласованный контракт, все команды находятся в одинаковом понимании и ожиданиях.

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

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

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

А на ваших проектах как принято - кто является источником правды с точки зрения проектирования сервисов: аналитик или разработчик?

Swagger. Что это и как с ним работать

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

Swagger — набор инструментов для создания, документирования и тестирования RESTful API. Основой Swagger является формат OpenAPI, который позволяет описывать API на уровне спецификаций (ссылки без vpn не работают).

Для чего он вообще нужен и почему применяется на проектах?

➖Автоматическая генерация документации, понятной для людей и машин;
➖Обратный процесс - автоматическая генерация кода на основе документации с помощью Swagger Codegen;
➖Тестирование API. Предоставляет функционал аналогичный Postman, т.е. возможность вручную "подергать" методы;
➖Единый стандарт (OpenAPI) для совместимости между системами и командам.

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

Кроме того, что на проекте в принципе появляется документация, что само по себе уже отлично - становятся доступны различные подходы к разработке, которые позволяют оптимизировать процессы в командах и даже межкомандное взаимодействие. Например, если использовать подход Swagger First (Contract\API First, называется по-разному). Об это расскажу в следующем посте.

Также, те аналитики (и не только), кто работали на проектах, где есть и FE и BE - наверняка сталкивались с такой проблемой, что фронтендеры не могли приступать к своей части разработки, до тех пор, пока бэкенд не предоставит им контракт какого-нибудь, например, фронтального адаптера, с которым FE нужно интегрироваться в рамках доработки.
А это может быть долгая история, т.к. пока опишешь API, пока опишешь всю бизнесовую логику работы, пока пройдешь ревью и т.д. - фронтендеры устанут ждать. С помощью swagger'а же бэкенд-разработчики могут сначала описать API, опубликовать его и дальше продолжать описывать всю остальную часть, но при этом фронты уже могут приступать к работе и работать параллельно, что ускоряет процесс.

Ну и вообще нагрузить системных аналитиков, чтобы они сами написали спецификацию (и я считаю, что это правильно), выложили ее в репозитарий аналитики в гите и уже потом приступать к разработке сервиса, имея на руках ТЗ и спецификацию.
Единственное, что стоит отметить - спецификация != документация. Т.е. вы с помощью спецификации можете описать сервис, можете описать все его эндпоинты и методы - но вы должны отдельно описать еще в документации то, а как эти методы будут работать, т.е. их бизнес-логику. Потому что в рамках сваггера это хоть и реализуемо, но весьма сложно и не красиво.
Поэтому для каждого сервиса идеально иметь две части документации - одну, с описанием самого сервиса, всей его бизнес-логики и логики работы его методов; и вторую - спецификацию.

Рекомендую ознакомиться с этим инструментом, посмотреть на pet-проект и попытаться реализовать парочку "ручек" для понимания того, как это происходит с помощью EditorSwagger. Тем более, что он подсвечивает все ошибки и валидирует ваши контракты, пусть и не всегда очевидным образом.

Приходилось ли вам описать контракты и использовать их на своих проектах?

Уточка, кстати, топ.

Честно украдено из рабочего чатика.

Было?

MDM - Master Data Managment (система управления мастер-данными)

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

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

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

❔Но зачем нам вообще нужны эти мастер-данные и тем более системы по управлению ими?

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

Классический пример - клиентская база. Это то, что есть в каждой компании, которая продает какие-либо услуги и как правило это различные ФЛ\ИП\ЮЛ. Представим, что внутри компании было несколько направлений, каждое из которых генерило определенное количество тех самых клиентов (на примере банков - потребительские кредиты (целевые, нецелевые), кредитные карты, гарантии, аккредитивы и прочая-прочая. И каждый из этих маленьких кусочков бизнеса с кем-то работал). И в результате развития отдельных направлений у них сложились свои, внутренние, потребности по хранению клиентских данных и они отличны друг от друга.

Например, для одного из направлений по нормативке необходимо сохранять минимальный набор персональных данных, а для другого еще различные ИНН, КПП, ОКАТМО, ОКВЭД и прочие сложные аббревиатуры.
И вот у нас в таком разрозненном порядке хранятся данные в разных системах одной компании, хотя фактически это одна и та же бизнес-сущность.

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

И примеров такой боли можно придумать много.

❔Как решать?

Для недопущения таких проблем и превентивного их решения используются MDM-системы. Как правило во всех крупных компаниях на каждую ключевую бизнес-сущность (клиенты, внутреннии пользователи и пр.) приходится ровно одна система, которая полностью этими данными управляет. И ни одна другая система, в обход MDM не может эти данные менять.

Поэтому очень часто перед системными аналитиками стоит задача по интеграции с подобными системами в рамках своих внутренних задач. Например, если тебе в рамках бизнес-процесса необходимо запрашивать информацию о существующих клиентах или обновлять\создавать информацию о них в MDM, в случае, если ты проектируешь систему, которая является точкой входа новых клиентов.
К счастью, как правило эти системы очень хорошо задокументированы, как минимум потому что у них очень много потребителей и поэтому интеграция с ними - это достаточно прозрачный процесс (но, естественно, не всегда).

Приходилось ли вам интегрироваться с подобными системами (или может быть проектировать их)?

Про текущую ситуацию на рынке

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

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

Отдельный лайк рекрутерам\HR (не всем) и их скорости реакции. Мне написали спустя 53 минуты с момента обновления резюме, но и количество реакций в целом за первые 2-3 часа было большим - люди правда стараются найти хоть кого-нибудь к себе на проекты. А вот факапы с рекрутерами заслуживают отдельного поста))

Это было лирическое отступление. Теперь мои выводы:
1️⃣ Рынок живее всех живых. Нехватка миддлов - аналитиков просто зашкаливает, они нужны вообще всем. Поэтому если у вас хотя бы год опыта (крепкого такого опыта) то найти работу вообще ноль проблем, выбирай из 'дцати компаний. Если у вас не так, проблема в подготовке.
2️⃣ Рынок все также принадлежит соискателю и он диктует свои условия.
С учетом того, что сейчас такой недостаток специалистов, любой опытный человек заработает себе как минимум несколько офферов и уже из них будет выбирать лучшее для него по финансам\условиям на проекте;
3️⃣ Когда ты выбираешься за рамки сеньора и внутри компании тебе некуда расти - ты грустишь.
Потому что прям ОЧЕНЬ интересных предложений на рынке мало и ты такой их перебираешь: ага, ну опять сеньор на финтех, скука; и вот тут предлагают сеньора на финтех - эх, тоже скука; может хоть тут? А нет, вообще какая-то ерунда типа gambling, хоть и с очень большими деньгами. Но об этом чуть позже, тут мне есть что рассказать;
4️⃣ В плане финансов тоже особо ничего не изменилось в среднем, вилка как была год назад, так и осталась, тут никаких неожиданностей. Хотя ряд предложений на обычные сеньорские позиции меня очень приятно обрадовал и даже немного удивил.
5️⃣ Для рядовых позиций тоже не очень изменилась ситуация, но (субъективно, исходя из наблюдений за своими менти), мне показалось что количество конкурентов среди людей без опыта стало меньше. То ли поток обучающихся на массовых курсах стал меньше, то ли количество компаний ищущих себе джунов стало больше, то ли мне просто так показалось - но вот делюсь.

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

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

P.S. Спасибо большое тем людям, которые продолжали пересылать мои посты даже несмотря на мое inactive состояние - you're breathtaking (с). Я выжил и планирую вернуться с контентом, как вы?

По выходным делаю для вас контент в новом, для себя и канала, формате.

После большого зимнего перерыва снова нашел в себе мотивацию и силы для творчества, чего мне не хватало последнее время.

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

Считайте это анонсом >3

А вот про этот пост я говорил, после которого и захотел это всё написать.

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

Чем в более крупную компанию стучаться, тем больше вероятность вот такого.

❗️Завышение стажа в резюме: работает или нет?

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

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

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

Как это работает?

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

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

Поэтому данный способ достаточно часто срабатывает в плюс и ты начинаешь получать офферы.

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

❕Однако, лично мое мнение в том, что не нужно перебарщивать. Я имею ввиду то, что если у вас совсем нет опыта - не нужно сразу устраиваться на миддла или сеньора, накручивая слишком большой опыт (такое, судя по некоторым историям, тоже реально).
Одно дело без опыта начать работать джуном - от тебя многого ждать не будут, вполне может прокатить и тебя не "раскроют". Но если ты пройдешь на того же миддла и даже не сможешь разговаривать с командой на одном языке - то в чем смысл? Не говоря уже о том, что ты не сможешь выполнять свои задачи самостоятельно, чего ждут от специалиста этого уровня. Испытательный вы вряд ли пройдете, да еще и информация о вас может распространиться в разнообразных чатиках.

Поэтому единственный совет - подходите ко всему разумно.

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

❕ Схемка для задачи, которую описывал выше

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

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

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

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

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

P.S.: Не сжал картинку, потому что иначе телеграм ее сильно шакалит.
P.P.S.: Напишите в комментариях, были ли у вас на практике проблемы с кросс-командными задачами или вам попадались только лапушки, которые всегда шли на встречу.

❕Немного о событиях последних двух месяцев (и не только)

Как обычно, перед новым годом и своим днем рождениям у меня случилась пауза в ведении канала и любых других активностей, кроме работы.
1️⃣Во-первых потому что этой самой работы было достаточно много (как всегда под конец года);
2️⃣Во-вторых потому что перед свои днем рождения у меня силы обычно на полном нуле и особо нет возможности их распылять на что-то еще.
Правда сейчас эта пауза уже достаточно затянулась, поэтому пытаюсь вернуться в своё продуктивное русло.

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

Например, одна из интересных задач, которая была у меня на практике - это интеграция нашего кредитного конвейера с ДБО для того, чтобы клиент мог удаленно подписывать свой КОД (кредитно-обеспечительную документацию) удаленно, в своём мобильном приложении, без необходимости личного присутствия в офисе.
Сейчас это не новость и в принципе это реализовано уже много где, да и в целом мы все с большой силой стремимся в цифровизацию, безбумажность и вот это всё новое, удобное и красивое.
А всё для того, чтобы людям было удобно и просто пользоваться любыми ресурсами (круто же иметь Госуслуги, личные кабинеты во всех сервисах\банках, которые предоставляют огромное количество функций и возможностей решить почти любые вопросы удаленно? А это всё мы, команды разработки. Ну и наши любимые заказчики, которые все эти идеи круто накидывают на вентилятор). По-моему я только из-за этого до сих пор держусь и не выгораю.

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

С технической точки зрения всё было несколько сложнее. Начнем с того, что у нас разные файловые хранилища (что плохо, но уж как есть) и соответственно нам надо было брать документы из нашего ФХ, сохранять их в ФХ ДБО и только после этого отправлять определенный список документов в ДБО для подписания. Первая часть интеграции, по получению\сохранению документов, должна была идти синхронно, вторая уже асинхронно, потому чтоэто надежно, ну и с бизнесовой точки зрения у клиента было время на подумать, хочет он вообще это подписывать или не особо. Поэтому ответ нам приходил уже также асинхронно.

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

P.S.
Кстати, результаты опроса, который я закидывал позавчера достаточно ожидаемы почти во всем, но я таки удивлен, что аж 40% людей нравится рисовать диаграммы, а 42% нравится консультировать команду. Я думал тут будет значительно меньше голосов, но это интересно, в любом случае. Спасибо, что вы остаетесь активными, даже спустя такой перерыв в постинге ❤️