Привет!

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

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

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

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

Мои ТОП-кейсы по интеграциям, которые прокачали мои скилы и позволили глубже погрузиться в проектирование:

🟡 Подключение платежных систем - онлайн-оплата (Интернет-эквайринг)
🟡 Обмен документами с системами ЭДО (электронный документооборот)
🟡 Сбор аналитики во внешние системы для анализа данных и маркетинга
🟡 CRM-системы
🟡 Агрегатор билетов на перевозки - объединяли в одной системе всех перевозчиков
🟡 Терминал самообслуживания - собирали в одну программу принтер, считыватели карт, купюроприемник, сканеры, фронтенд и бэкенд
🟡 Кассовое ПО для Android, Win, Linux, MacOS, где нужно было делать интеграции со встроенными и внешними считывателями банковских и бонусных карт с чипами, сканеры штрихкодов/QR, фискальные накопители для чеков налоговой РФ, принерами

Делитесь в комментариях, какие задачи на работе сейчас развивают ваши скилы?

Хочу поделиться с вами своей историей: как системный анализ и работа в IT повлияли на мою жизнь.

Я всегда мечтала путешествовать. Когда мне было 19, в копилке было целых три полета на самолете в Калининград, Грецию и Турцию. Мне тогда казалось, что отпуск 1-2 раза в год за границей - предел мечтаний! И я откладывала по чуть-чуть из ЗП на это редкое удовольствие. Ревела, когда уезжала из следующего отпуска в Италии. Тогда я уже работала младшим системным аналитиком и очно учлась в ВУЗе.

Сразу после возвращения из Италии я увидела фотографии подруги, которая побывала в США. Еще до этого мне про Route 66 рассказывали. И мысли были "Ну лет в 30 я точно накоплю и отправлюсь туда в отпуск!". Не отпустила меня эта мысль после фото. И через пару месяцев я все же решила проверить сколько стоит это удовольствие. Оказалось, что нескольких зарплат будет достаточно 🤔 Так появилась цель получить заветное путешествие в США.

Уже через 6 месяцев после появления этой идеи о США я впервые оказалась во Флориде и Калифорнии!

А потом через 2 месяца после возвращения была на выходных в Вене. А еще через 2 выходные в Сочи. Потом выходные в Испании. Да и ЗП росла, что выходные где-то за границей уже были стабильно раз в 4-8 недель. И отпуск в США раз в пол года без отрыва от производства - еще до пандемии я начинала работать удаленно.

Позже я придумала новую цель и накопила на учебу в США. После завершения магистратуры в РФ сразу отправилась туда с удаленной работой старшим системным аналитиком в Москве. Опять же, до пандемии, когда это еще не стало обычным делом))

А сегодняшний день я просто не могла представить. Мне меньше 30, я живу в Калифорнии и у меня бизнес, который работает по всему миру, и команды в разных часовых поясах: Россия, Франция, Казахстан... Много бывших коллег и друзей из IT сейчас живет не в России.

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

А еще исполнить детскую мечту - путешествовать! 🙌

P.S. Нашего Тюленя в Лас Вегас по вашей просьбе свозила 😏

Ситуация: надо испечь торт! Увидели в интернете красивый медовик и поняли: это он. Красивый, яркий, вкусный. Нужен такой.
Ожидаем, что по рецепту всё быстро и легко получится. Готовим, и в итоге получается какое-то жалкое подобие. Вроде и торт, но до оригинала с картинки недотягивает.

Так и при проектировании. Ожидание: заказчик поставил задачу, получил приложение и ура - релиз готов. Согласитесь - идеальный сценарий. Но… что-то пошло не так. Заказчик начинает требовать доработки, надены баги, от пользователя прилетают жалобы. Вроде и работает, но не так гладко.

Чтобы избежать таких багов и спроектировать рабочую систему дам вам несколько лайфхаков 😉

1️⃣ Конкретизируйте требования
Согласитесь, если в рецепте к торту будет написано - добавьте соль по вкусу, мы зададимся вопросом: это сколько? Щепотка, 2 щепотки, ложка чайная?

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

2️⃣ Упрощайте алгоритмы
Не нужно превращать алгоритмы в огромных монстров. Разделяйте сложное на простое, как огромный контструкор на кубики.
Пропишите и посмотрите на всё сверху вниз и выделите крупные шаги. И дальше уже с верхнего уровня, проваливайтесь по ступенькам и прописывайте по элементам.

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

Продолжаем разбирать лайфхаки на тортах? Ставим ❤️

Лайфхаки для аналитиков. Часть 2

3️⃣ Систематизируйте требования
Представьте, вы зашли на сайт и увидели рецепт торта, который напоминает сплошной набор символов, без единой картинки. Вы закроете страницу и пойдёте искать информацию дальше.

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

Что делать?
+ Делите на части, так проще воспринимается.
+ Добавляйте картинки и схемы.
+ Используйте простые слова и формулировки.
+ Разделяйте требования и примеры.
+ Требования пишите отдельно от документации.

4️⃣ Продумывайте альтернативные сценарии
Можно вносить все шаги алгоритмов в таблицу. После того как сценарий прописан, пофантазируйте и задайте себе вопрос, с точки зрения пользователя: а что я могу сделать дальше?

С тортом аналогично: что делать, если у меня нет стевии? Предлагаем решение!

5️⃣ Подготовьте чек-лист аналитики
Проверьте себя, все ли компоненты и функциональность учли при проектировании. Все ли доработки описаны?

6️⃣ Делайте ревью требований
Подключайте к ревью аналитиков, разработчиков или тестировщиков, чтобы они посмотрели на ваши требования и подсказали, как можно улучшить ваш торт 🍰

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