Есть такое выражение: оказался в нужное время в нужном месте 🙌

Но согласитесь, важно не только оказаться в нужном месте, но и ещё и постараться взять максимум от этого.

Всю мою жизнь, когда я понимала, что сейчас в НУЖНОМ месте, старалась пользоваться шансом и получить от этой возможности максимум пользы.

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

В работе всегда “донимаю” более опытных коллег, потому что мне важно дойти до сути и разобраться. Я не выношу “пробелы” в понимании. И да, я дотошная 😅

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

👉 Боюсь ли я показаться тупой?
Перед клиентами, которые излагают суть их бизнеса, о котором я ничего не знаю.
Или на конференции с сотнями человек в зале, когда задаю вопрос в микрофон, который может оказаться простым?
Уже нет.

Но эта уверенность стоила мне долгих лет:
Лучше вовремя спросить и получить информацию за 5 минут, чем потом часами безуспешно разбираться самой.

Поэтому предлагаю и вам во время встреч GetAnalyst побыть немного занудами 😎

В хорошем смысле!

✔️ Задавайте вопросы мне и спикерам команды
✔️ Дискутируйте в комментариях
✔️ Сомневайтесь и опровергайте
✔️ Подтверждайте своими примерами
✔️ Учитесь уверенно себя вести на публике

Это путь к успеху!

Пользуйтесь тем, что вы оказались в нужном месте, в безопасной обстановке единомышленников, которые так же как и вы, хотят разобраться во всём до мелочей.

Мы здесь, чтобы помочь. Все ваши вопросы важны! Вообще все! ❤️

Всегда можно идти длинным путём "я сам разберусь". Упускать возможности даже в нужном месте и в нужное время.

А можно воспользоваться шансом и сделать простой шаг: задать вопрос и показать себя. И помните, ответ на ваш вопрос может помочь не только вам, но и сотням других людей 🙌

💥 UML-Sequence: основная диаграмма для Cистемных аналитиков 💥

Интеграционный сценарий написан. Но иногда в нем много текста. Слишком много текста 😁

А разработчики много читать не любят. И вообще, для быстрого понимания “о чем тут вообще” помогают картинки и схемы. Особенно, когда речь идет о сложных интеграционных сценариях.

➡️ Прекрасным дополнением к интеграционному Use Case служит UML диаграмма последовательности. Она же UML-Sequence.

UML-Sequence

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

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

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

Основные инструменты для построения UML-диаграммы:
🔸 Draw.io (diagrams.net)
🔸 PlantUML
🔸 Microsoft Visio (аналог Draw.io)
🔸 Lucidchart (аналог Draw.io)
🔸 Enterprise Architect


🖼 На картинке к посту UML-Sequence диаграмма процесса регистрации пользователя.

Попробуйте прочитать её и обратить внимание на следующие моменты:

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

👉 2. Не хватает технических деталей.
В какие таблицы БД записывать данные, как именно проверяется формат имени, email и телефона, по каким правилам генерируется ссылка на подтверждение УЗ (учетной записи клиента).

👉 3. Стрелки вправо всегда действия (глаголы), а пунктирные стрелки влево - данные или сообщения о результатах.
Это правило построения UML Sequence.

Диаграмма создана в Draw.io.

#ИнтеграцииGA

💎 5 диаграмм, которые сейчас используют аналитики + как их сделать через ИИ 🤖

По итогам опроса получили более 600 голосов и следующие результаты:

1. UML Sequence (78%)

Для описания обычных и интеграционных сценариев.
🤖 Можно делать через ИИ + PlantUML

2. BPMN (76%)

Для описания бизнес-процессов.
🤖 Проблемно делать через ИИ.
Можно получить подсказку как строить, но рисовать придётся вручную.
В целом есть вариант описать через код в Camunda, но несколько попыток у меня не дали нормальные результаты.

3. ER-диаграмма (61%)

Для проектирования БД.
🤖 Можно делать через ИИ + DBdiagram.io

4. C4 (28%)

Для проектирования архитектуры.
🤖 Можно делать через ИИ + Structurizr.com

5. Диаграмма состояний / UML State Diagram (27%)

🤖 Можно делать через ИИ + PlantUML



Из результатов можно сделать выводы:

🔸 Описание сложных сценариев требует использования диаграмм BPMN или UML, что подтвердило более 75% опрошенных.
Большинство работодателей будут спрашивать вас знание как минимум одной из этих нотаций.

🔸 Проектированием БД или её анализом занимается более 60% опрошенных участников.
Поэтому задачи, связанные с “покажи как развязать связь многие-ко-многим” продолжают оставаться актуальными на собеседованиях и в работе аналитиков.

🔸 Более 25% опрошенных так или иначе работают с архитектурой систем.
Это навык старших системных аналитиков. Для проектирования используют нотацию C4. Archimate, как альтернативу, тоже используют, но очень мало.



Итого:

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

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



Друзья, спасибо вам за помощь в исследовании 🤝

🤖 Проекты с Generative AI: что нужно знать аналитикам (выступаю 11-12 октября) 🤖

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

На внешних конференциях для СА и БА я почти перестала появляться. Каждый месяц вы видите меня на открытых уроках в GetAnalyst. Это огромная работа по подготовке материала. Плюс я веду блог. И работаю работу. Времени нет.

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

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



Но... нетворкинг - вещь мощная 😁
Коллеги, которые записывались у меня в подкасте, свели нас с организаторами конференции Devan в Перми про лидерство в ИТ.

Пригласили стать спикером на оффлайн-конференции. Хотела отказываться. Английский в приоритете.

Но потом увидела несколько интересных тем, в их числе:

👍 Аналитики не нужны? (Александра Камзеева)
Далеко не все компании за пределами РФ имеют позицию СА и БА, то эта тема всегда актуальна. У меня есть статья Нужны ли аналитики зарубежом, которая показывает, почему я хочу посмотреть доклад.

👍 Личный бренд с нуля и без стресса: Linkedin для (не)технических специалистов (Мария Махт)
Если вы ищите работу зарубежом, то профиль LinkedIn должен быть идеален. Да и компании РФ в запрещенную сеть активно ходят за сотрудниками. Хочу посмотреть на еще одну точку зрения про то, как оформить LinkedIn.

👍 ТОП-25 ошибок в BPMN (Денис Котов, основатель StormBPMN)
Важная тема, судя по моим предыдущим постам 😁 Крутой спикер. Актуально для коллег, с которыми делюсь опытом.


Нетворкинг решает.
Так что мое выступление можно будет увидеть в Перми:
🤖 Проекты с Generative AI: что нужно знать аналитикам

Для сообщества GetAnalyst есть промокод на скидку 10%: GETANALYST10.

Кому актуальны темы о лидерстве в ИТ, рекомендую глянуть программу 👀

🧩 Маппинг данных - что это и зачем? 🧩

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

Этот процесс необходим в задачах на интеграции.

Маппинг описывают в виде таблицы. Допустимо делать и в виде структурированного списка, но по опыту скажу - таблицы удобнее.

➡️ В таблице с маппингом делают несколько основных колонок:

- название параметра на разговорном языке;
- описание, требования к валидации, ФЛК (форматно-логический контроль) и преобразованиям, если это необходимо;
- типы данных в каждой системе;
- названия параметра в API каждой системы (например, поле из JSON, поле из xml или другого формата сообщения, query из URL и др);
- название параметра в БД системы, которая отвечает за работу интеграции, если в процессе работы метода надо сохранить данные в БД.

Допустима вариативность с колонками. Их может быть больше, а может быть и меньше.


Если говорить про задачу интеграцию системы #ShipEasyGA с DaData для структурирования адресов, то маппинг будет содержать несколько колонок:

- название поля на русском
- название поля в REST API Backend ShipEasyGA
- название параметра в API системы DaData, чтобы установить соответствие с её полями в интеграции
- название поля в БД ShipEasyGA, т.к. есть поиск пунктов курьерской службы в радиусе 5км
- описание поля, требования к его обработке и проверкам
- типы данных в API ShipEasyGA, API DaData и БД. Я бы добавила только отдельную колонку “Тип данных в API ShipEasyGA”. Все остальные типы данных не так важны или очевидны.


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

#ИнтеграцииGA

📦 Как интеграции влияют на БД проекта 📦

Одним из ключевых шагов в работе с задачами на интеграции является работа с базой данных (БД).

Реляционная БД — это место, где обычно хранятся все данные системы, организованные в виде таблиц и полей.

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


👉 Интеграции могут влиять на структуру БД проекта следующим образом:


1. Данных во внешней системе больше, чем нужно (получение из внешней системы)

Бывает, что от внешней системы приходит больше данных, чем нужно для нашей. В этом случае аналитикам нужно описать маппинг данных — сопоставление полей, — и оставить только то, что реально важно для наших API и БД.

Пример:
При интеграции с системой DaData мы получаем много полей, связанных с адресами, но для нас важны только структурированные данные о местоположении, такие как улица, город и почтовый индекс. Остальные можно игнорировать.

В таких случаях доработка БД не нужна.


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

Если на нашей стороне не хватает каких-то данных в БД, которые обязательны для отправки в API внешней системы, то мы должны:

2.1. Продумать алгоритм создания этих значений из имеющихся данных или подставлять значения по умолчанию.

2.2. Если данные не обязательны для отправки, хотя есть в API внешней системы, но в нашей БД их нет, то доработки в БД не требуются.

2.3. Добавлять новые таблицы и поля в нашу БД, а также функциональность по их наполнению нашими пользователями.



3. Во внешней системе меньше данных (получение)
...


Продолжение следует 👇

#ИнтеграцииGA

📦 Как интеграции влияют на БД проекта 📦

3. Во внешней системе меньше данных (получение)

Иногда внешняя система предоставляет меньше данных, чем требуется для сохранения в нашей БД.

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

Пример:
При получении документов из внешней системы мы не получаем их статусы. В этом случае мы можем по умолчанию делать статус “Новый” для таких документов.

4. Сохранение данных в БД не требуется

Есть случаи, когда сохранять данные в нашу БД при интеграции вообще не нужно. Информация обрабатывается на уровне API, где все лишние поля могут быть проигнорированы, а недостающие значения заменяются прямо в сообщениях JSON/XML/др


5. При получении и сохранении данных из внешней системы нужно делать отметку “is_external”

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

В этом случае новое поле в БД is_external=true/false отлично в этом помогает. Его надо добавить

Пример:
В интернет-магазине есть свои и чужие товары, которые загружены из каталога внешней системы. Это надо показывать пользователям. Для таблицы “товары” в БД надо будет добавить новое поле is_external.

👉 Необходимые доработки перед интеграцией

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

Если структура БД не позволяет корректно сохранять новые данные, потребуется доработка.

Например, в проекте #ShipEasyGA сейчас адреса отправления и получения посылки хранятся в одной строке. Для сохранения структурированного адреса отдельных полей нет.

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

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

#ИнтеграцииGA

📝 Изменения в БД в связи подключением внешней системы 📝

Прежде чем показать пример маппинга данных, я детальнее проработала часть модели БД для #ShipEasyGA.

Показала ER-диаграммы ДО -> ПОСЛЕ на прикрепленной картинке 🖼


Ключевые решения:

1. Создана таблица address для хранения структурированных адресов.

Каждый адрес (отправления и получения) привязывается к клиенту-отправителю.

При следующем заказе можно предлагать клиенту выбрать адрес из истории: при нажатии на строку с полным адресом, без ввода символов, сразу показывать подсказки со структурированными адресами из предыдущих заказов.

Это сэкономит запросы во внешнюю систему.

1.1. Один адрес может быть использован для нескольких заказов одного клиента.

1.2. Если два разных клиента введут одинаковые адреса, то структурированный адрес будет сохранен в БД дважды, для двух разных клиентов.

Это поведение системы считаем нормальным. При желании можно усложнять и оптимизировать 🙂

2. В таблице order добавила ссылки для адресов отправления pickup_address_id (UUID) и получения delivery_address_id (UUID).

Не обязательные, Так как для старых заказов, которые были созданы до обновлений, не будет структурированных адресов.

3. В таблице order для старых заказов останутся поля с полными адресами pickup_address (varchar(512), NOT NULL) и delivery_address (varchar(512), NOT NULL), их нельзя удалять.

Это нужно, чтобы сохранить обратную совместимость в БД - то есть не “сломать” старые заказы, которые ориентируются на это поле.

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

* Для каждого заказа хранится копия данных об отправителе и получателе.

Если клиент, как пользователь системы, сменит фамилию, почту или телефон, то мы не будем "ломать" старые заказы и сохраним исторические данные.



Теперь, когда мы понимаем и структуру БД проекта, можно переходить к маппингу для нашей интеграционной задачи 🙌

#ИнтеграцииGA #БДGA

📖 Пример маппинга данных для #ShipEasyGA 📖

В предыдущих постах:
+ Рассказала про маппинг,
+ Влияние интеграций на БД,
+ Показала БД проекта (предыдущий пост)


Чтобы показать пример маппинга, нужно определиться, для какой постановки задачи мы его делаем:

👉 Если на Frontend, то показываем соответствие данных между:
- UI,
- API ShipEasyGA.
Frontend вообще не надо знать какие интеграции есть “под капотом” и лишние детали для Frontend-разработчиков в постановке задачи не показываем.

👉 Если на Backend, для реализации API-метода ShipEasyGA, то показываем соответствие данных между:
- API ShipEasyGA,
- API внешней системы DaData,
- БД, если для работы API нужно читать данные из БД или сохранять их в неё.


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

GET /address?text=’строка адреса’&type='pickup/delivery'

Это интеграционный API-метод.

Также, чтобы оптимизировать работу метода, если его вызвали без передачи строки text или она пустая, то предлагается показывать клиенту ShopEasyGA 5 последних адресов из БД (таблица address), которые он использовал для других заказов, если они есть в БД.

Файл с примером маппинга прикреплен к посту 📖
Это часть постановки задачи на интеграционный API-метод.

#ИнтеграцииGA