💫 ПРОБЛЕМЫ В РАБОТЕ С ЗАДАЧАМИ НА ИНТЕГРАЦИИ 💫

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

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

1:18 - Что такое интеграции?
4:25 - Роль системного аналитика в процессе работы с задачами на интеграции.
11:41 - Как изменилась работа с задачами на интеграции за последние годы?
16:49 - Написал требования в соответствии с API-документацией внешней системы, а потом оказалось, что работает не так.
19:40 - Интеграция работала в продакшн и всё было хорошо, а потом всё внезапно сломалось.
22:57 - Что делать если предстоит интегрироваться с системой у которой еще нет API, а сроки горят?
26:18 - Разработчик системы, с которой предстоит интегрироваться, не предоставляет API и доступы, а задачу нужно реализовать, потому что сроки (P.S. Влиять через заказчика на внешнюю команду при возможности).
28:07 - Что, если вы тот самый разработчик, у которого просят API, но вам пока не до этого?
29:21 - Платные подписки и использование внешних систем. Примеры: DaData.ru, сервисы SMS-рассылок с поштучной оплатой со счета заказчика и другие.
31:58 - Разные структуры данных в разных системах: как собрать всё в нашей системе воедино? Про агрегаторы.
36:07 - Высокие нагрузки и длительное ожидание ответов. Асинхронные запросы и вебхуки.
39:37 - Не работал с видом API, по которому предстоит интеграция (REST API, GraphQL, gRPC, SOAP API и WebSocket - основные, посмотрите на них).
42:02 - Заключение и рекомендации


Эпизод доступен в:

⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Apple Podcast
⏯ Castbox
⏯ Spotify
⏯ Amazon Music


Подписывайтесь на подкаст и делитесь с коллегами, начинающими и опытными системными аналитиками!

Когда ты уже не джун 😀

Всем отличного начала рабочей недели, друзья! Давайте сделаем 💪🏼

#GAhahaha

1️⃣ ПРО ПРОДУКТОВУЮ РАЗРАБОТКУ

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


Продуктовую разработку можно разделить на два вида:

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

🥷: Известный пример коробочного продукта — пакет Microsoft Office. Вне зависимости от компании, в которой используется, он содержит одни и те же функциональные возможности.


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

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

🥷: Так изначальное решение остается масштабируемым и гибким для последующих доработок внутри одного бизнеса и прекрасно адаптируется для другого.

2️⃣ ПРО КАСТОМНУЮ РАЗРАБОТКУ

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

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

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

3️⃣ ПРО СМЕШАННУЮ РАЗРАБОТКУ

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

🥷: Плюс такого подхода — сжатые сроки, поскольку ядро системы уже есть, просто его надо "нарастить" кастомными фичами.

Чаще всего к смешанной разработке прибегают при внедрении CRM-систем, порталов и при создании сайтов.


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

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

Всем привет, друзья! 👋

На этой неделе мы с вами разбирали тему видов разработки ПО и их особенностей.

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

Сегодня хотим предложить вам закрепить полученную теорию КВИЗом. Вы как, непротив? 😀
Знаем, что КВИЗы вы любите. Мы тоже! 🤓
Поэтому предлагаем вернуться к началу недели и освежить знания.

Как будете готовы – ставьте 🔥 и мы запустим КВИЗ.

#quizGetAnalyst