Это был очень крутой вебинар! 🦊 Практика! По шагам разбирали работу с Postman!

Пропустили или не удалось досмотреть до конца? Зарегистрируйтесь здесь и пришлем информацию про повтор в почту ✉️

До встречи ☀️
Про путешествия лисы и тюленя - подписывайтесь на Instagram.com/katherine__aa 🦊 🦭

В книге Release IT Майкла Нейгарда по проектированию архитектуры, в главе 16, есть крутая история про ЧЕРНУЮ ПЯТНИЦУ. Он описывает во всех подробностях, как в этот день покупатели создают пиковую нагрузку и убивают Интернет-магазин.

Прекрасные цитаты:

Черная пятница. Число покупателей в магазинах за сутки может увеличиться в 4 раза. Трафик в интернет-магазинах может возрасти на 1000 %. И это настоящее нагрузочное тестирование, единственное тестирование, которое имеет реальное значение.

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

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

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

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

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

Так что у кого-то в ЧЕРНУЮ ПЯТНИЦУ радость, а у команды разработки и аналитиков торговых систем рука на пульсе 🙂

Сегодня, 11.11.22, как раз ЧЕРНАЯ ПЯТНИЦА! И в честь этого события я дарю вам
‼️ СКИДКУ 30% на любой практический курс GetAnalyst в продаже
🟢 ПРОМОКОД: 111122
⏰ до 12 ноября 23:59 (Мск)

Сегодня самая лучшая возможность получить знания в GetAnalyst!

Интеграция — что это такое?

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

Агрегатор выдаёт все возможные варианты, вы выбираете приемлемую цену и совершаете заказ. Согласитесь, это очень удобно!

Аналогично работают приложения Госуслуги, банки, сервисы по доставке еды и многие другие. Все возможности через единое окно!

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

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

Как итог, пользователю не приходится обращаться к множеству ресурсов - всё в одном месте ✅

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

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 недель передать максимум знаний для самостоятельной работы. И двигаться дальше, в команду с другим проектом.

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

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

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