В чём сложность работы аналитика с интеграциями?

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

2️⃣ Данные беспорядочны и не структурированы
Форматы условий бывают разные, а порой и несовместимые. Аналитик решает эту задачу.

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

4️⃣ Требования могут меняться прямо в процессе работы
Особенно если надо интегрироваться с государственными системами (выходят поправки в действующее законодательство, меняются бизнес-процессы)

5️⃣ Работа с повышенной защитой информации
Информация — один из важнейших активов бизнеса. При передаче персональных и финансовых данных нужно решать вопросы с её безопасностью.

В каждом интеграционном кейсе будут свои подводные камни. Будьте готовы, что придётся максимально точно поработать с документацией (ТЗ, ЧТЗ, СТП, API). Важно, как можно подробно, описать то, что требуется сделать разработчикам. От этого будет зависеть конечный результат👌

Тема интересная и не такая сложная, если разобраться что за ней стоит 😉 Делитесь в комментариях, что еще вам хочется узнать про интеграции!

В предыдущем посте в качестве примера интеграций я уже затронула тему покупки билетов в онлайн через агрегатор ✈️🚌🚞

Какие ещё бывают интеграции, с которыми мы можем встретиться в жизни?

◾️ Терминал для покупки билетов на поезд / автобус
Есть терминал на вокзале. Человеку нужно купить билет: ввести пункты отправления и прибытия, найти рейсы, указать дополнительные данные, оплатить, получить распечатанный билет. Оплата может выполняться с подключением к оборудованию работы с картами и банком - это интеграция. Поиск билетов может быть не только в системе одного вокзала, но и в других источниках данных - тоже интеграция.

◾️ Системы аналитики
Для того, чтобы отслеживать действия пользователя на сайте или в приложении могут подключать Яндекс.Метрику и Google Analytics. Это нужно для построения отчетов по активности пользователей. По нажатию на определенные кнопки, либо при получении определенных данных пользователем, действия из нашей системы могут передаваться в эти системы аналитики. Процесс передачи данных о них - интеграция.

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

Согласитесь, всё это напоминает простое общение между людьми.
Системы общаются между собой, как и люди коммуницируют друг с другом. В каждом случае, чтобы договориться о чём-либо, нужен индивидуальный подход:
✅ Задаем правильные вопросы - запросы к системе, из которой хотим получить данные
✅ Получаем ответы - система, у которой мы попросили данные, "думает", а затем возвращает ответ. Успешный, удовлетворяющий наши ожидания, или не очень - ошибка 😅

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

Привет!

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

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

Для меня получать новые задачи всегда сравнимо с увлекательным приключением. Предвкушение новых знаний! Разбираться и погружаться в детали проектирования. Честно, могу зависнуть в работе на десятки часов, и даже этого не заметить. Это как игра: получится или нет?!

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

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

Я смотрела на задачу, понимала логически что должно получиться, и пыталась состыковать как это сделать. Интерес разгорелся 😏

Самой главной преградой было: с чего начать-то?

В итоге я начала с того, что посмотрела на функции пользователей в нашей системе. Взяла для старта поиск пунктов отправления / прибытия и поиск рейсов. Затем посмотрела на содержание API-документации автовокзала. И дала разработчикам задачи формате:
📝 Поддержите загрузку пунктов отправления / прибытия из системы вокзала. Метод загрузки данных возьмите из раздела документации автовокзала, пункт такой-то.
📝 Поддержите загрузку рейсов из системы вокзала. Метод загрузки данных возьмите из раздела документации автовокзала, пункт такой-то.
Ничего умнее я не придумала. Мне показалось, что этого достаточно.

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

Во что обернулись первые постановки задач?
Я скопировала методы из этой API-документации в наши постановки задач как есть, потому что даже толком не понимала, как её читать. Структуру примерно улавливала, но как с этим работать до конца не осознавала. Задачи ушли в разработку.

После этого на меня обрушились уточняющие вопросы от разработчиков 🤦‍♀️ А как? А куда? Какие данные брать? Как состыковать время по часовым поясам в нашей системе, что делать, если дубликаты остановочных пунктов?

Шаг за шагом со всем разбилась. Гуляла по граблям от вопроса к вопросу, не понимала, что делать, и только уточняла-уточняла-уточняла.

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

Я потратила массу времени, пока разбиралась со всеми вопросами от разработчиков по моим постановкам задач. Моя работа в тот период могла быть гораздо быстрее и эффективнее. А мне пришлось параллельно работать над несколькими задачами по непонятным для меня интеграциям, и переключать мысли с одной на другую. А еще при этом додумывать а что у нас поменяется в приложениях и на сайте. Ведь это были только постановки задач на Backend 😱

Это был длинный путь, на котором я научилась:
✅ четко делить Backend и Frontend,
✅ осознала интеграции и их влияние на системы,
✅ научилась работать с API документацией,
✅ освоила инструмент тестирования API - Postman

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

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

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

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

Поделитесь в комментариях, а как вы относитесь к новым задачам? С интересом или со стрессом?

Любой опыт ценен. Особенно тот, который позволяет закрепить теоретические знания.

Освоение инструмента Postman помогло разложить в моей голове по полочкам:
✔️ Что такое REST API и как он работает
✔️ Зачем делают API и для чего он
✔️ Разница в задачах на Backend и Frontend
✔️ Задачи на интеграции - с чего начинать и куда двигаться
✔️ Как разбираться, что скрывается "под капотом" внешней системы, с которой интегрируемся, и писать правильные вопросы на почту внешним разработчикам
✔️Что писать в постановках задач для Backend-разработчиков, если мы делаем свой API
✔️Как разрабатывать и сопровождать системы, с которыми интегрируются, и делать крутую API-документацию

Вот так Postman повлиял на развитие моих навыков проектирования. Это познание прошло на реальном проекте и повысило мою ценность как специалиста в области системного анализа. А сейчас я делюсь своим опытом с вами! 😉

Продолжим осваивать Postman вместе уже завтра!
🚀 Postman для аналитиков: осваиваем тестирование REST API на практике
🗓 23 ноября (ср), 19:30-21:00 (Мск)
🔗 Регистрация здесь

До встречи! 🔥

Уже через 3 часа! Вебинар Екатерины Ананьевой
📹 Postman для аналитиков: осваиваем на практике в прямом эфире
⏰ 19:30 - 21:00 Мск

Ссылку на трансляцию пришлем в канал за 15 минут до начала.

Привет!

Спасибо за огненный вебинар, на котором мы разбирали как интегрироваться с CRM-системой и тестировали шаг за шагом REST API через Postman 🚀 Очень круто, когда мы вместе шаг за шагом получаем новые знания!

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

Поэтому, как и обещала, делюсь с вами полезными ресурсами с API-документацией, которую вы можете использовать для самостоятельной практики Postman быстро, и без квестов с "работает/не работает" и "понятная документация/что они имели ввиду":

🔗 https://dadata.ru/api/
🔗 https://api.moyklass.com/
🔗 https://dev.vk.com/
🔗 https://yandex.ru/dev/
🔗 https://dev.moysklad.ru/
🔗 https://freshofficeapi.docs.apiary.io/#introduction

До 6 декабря можно присоединиться к группе и сделать проект на интеграции вместе! Подробности тут 😉

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

🚀 Postman для аналитиков: осваиваем тестирование REST API на практике
🗓 26 ноября (сб), 15:00-17:00 (Мск)
🔗 Регистрация здесь

Познакомитесь с подходом к задачам на интеграции и освоите инструмент тестирования API - Postman!
До встречи! 😉

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

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

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

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

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

Про программно-аппаратные интеграции я рассказывала на одном из открытых эфиров. Предлагаю погрузиться в эту крутую тему. Ссылка здесь. Продуктивного просмотра 😉

Разберем разные типы интеграций на примерах

Сервер ↔️ Сервер
Интеграции с платёжными системами, системами электронного документооборота, и другие интеграции для обмена данными. Например, агрегатор Aviasales собирает данные о рейсах от авиакомпаний и из других источников, чтобы мы могли купить самый дешёвый билет.

Клиент ↔️ Сервер
Это могут быть сайты, мобильные и десктопные приложения, которые взаимодействуют с сервером через API для получения данных из БД и отображения их на экране пользователю, и для сохранения данных в БД.

Клиент ↔️ Клиент
Обмен данными между смартфонами по Bluetooth или NFC.

Клиент ↔️ Оборудование
(Программно-аппаратная)
Сканирование QR-кодов приложением камеры в телефоне. Терминал самообслуживания с возможностью приёма платежей наличными и картой через подключенное оборудование.


Есть ещё деление интеграций по окружениям: на внешние и внутренние.
✔️ Внутренняя — это когда между собой взаимодействуют компоненты системы, разработанные внутри одного проекта/продукта. Протокол разработан внутри компании и дополнительно подключать третьи стороны не нужно.
✔️ Внешняя — это когда есть взаимодействия с чужими системами, созданными другими разработчиками (например, системы партнеров).

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

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

Уже через 3 часа! Вебинар Екатерины Ананьевой
📹 Postman для аналитиков: осваиваем на практике
⏰ 15:00 - 17:00 Мск

Ссылку на трансляцию пришлем в канал за 15 минут до начала.

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

Вопрос доверия в моей карьере проявился в двух направлениях:
1️⃣ Делегирование - другим аналитикам, разработчикам, тестировщикам
2️⃣ Найм и передача управления - я строила отдел и готовила команды к высадке новых аналитиков

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

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

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

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

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

Я отправилась к руководителю и попросила разрешить мне эксперимент: переучу тестировщика с гуманитарным образованием в системного аналитика. Просила 2 месяца на обучение для работы над текущими задачами проекта. Пообещала, что когда закончим "аналитический фундамент" вместе с ней, переберусь в другую команду, а за своим экспериментом буду приглядывать и доучивать. Добро дали, но с сомнениями.

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

Как превратить тестировщика в middle системного аналитика? 🤔

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

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

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

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

Через 6 месяцев регулярных занятий и работы с ДЗ по выходным, неуверенный голос резко преобразился. Она уже без моей помощи работала в команде. А от разработчиков сыпались благодарности "Какой у нас крутой аналитик! Катя, спасибо тебе за нее!".

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

Доверие - важное качество для будущих руководителей. Сейчас я много доверяю людям и это дает результаты. Я верю в то, что каждый из нас способен на многое. И сейчас я с вами, чтобы делать из вас крутых системных аналитиков ❤️

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

Первый, кто делает запрос на обработку данных, обычно называется клиент. А второй, который отвечает ему и обрабатывает запрос — сервер. Это компоненты одной или разных программных систем.

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

Итак, вас просят заполнить анкету. Далее возможны ситуации:
1. Вас просят сидеть безотрывно рядом с кассиром и ждать, пока процедура открытия счета будет завершена. Уйдете хоть на секунду - надо сначала. Это СИНХРОННОЕ взаимодействие.
2. Вас просят погулять где-нибудь пару часов, позанимться своими делами, пока все будет готово. Это АСИНХРОННОЕ взаимодействие.

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

Примеры:

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

◾Пользователь хочет получить список товаров интернет-магазина. Он ожидает увидеть товары сразу, поэтому здесь также подойдёт синхронный запрос на получение каталога товаров.

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

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

Примеры:

◾Загружаем файл на Google Drive. При этом, когда пойдёт загрузка, мы увидим внизу окошко с индикатором, что процесс пошёл: какое-то количество Кбайт на диск уже загружено. Файл публикуется: он сохраняется на диск с устройства. Это происходит фоново, остальная работа с Google Drive и другими программами не блокируются. Для остановки фоновой загрузки есть отдельная кнопка.

◾Ещё один пример с Запретграм. Мы выкладываем контент. Пока пост или reels загружаются, пользователь может продолжить смотреть чужие посты и видео. Публикация нашего контента происходит асинхронно.

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

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

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