⚠️ Не повторяйте этих ошибок

Люди склонны верить в лучшее. Как говорил классик: "Ах, обмануть меня не трудно!.. Я сам обманываться рад!"

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

Если говорить кратко: никогда не стоит доверять результатам встреч, на которых лично вы не были. Равно как и заверениям о "лёгкой задаче" от людей, которые сами не будут её пилить или отвечать за конечный результат 💩.

Держите три свежих примера из жизни.

1⃣ Подключение к стандартному платформенному сервису
Вы слышите: "Почти все уже подключились, подойди потом, расскажем". Или даже: "Да там дел на пару недель, ничего сложного!" ✨

📉 Реальность: советчики интегрировались год назад через REST со стандартным коннектором. А вам такая опция недоступна. Почему?
▫ У вашей системы другой стек, старый коннектор просто не подойдёт.
▫ Архитекторы недавно запретили прямое взаимодействие через REST — теперь только Kafka.
▫ Появилось обязательное требование о гарантированной доставке сообщений в ту самую Kafka 😱.

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

2⃣ Вывод функциональности на новую поверхность
Вы спокойно живёте в мобильном приложении. Вдруг прилетает новость: нужно вывести фичу на другую поверхность (веб-сайт, телевизор, умную колонку — не суть важно). Вы слышите: "Да мы вашу систему просто вызовем извне, всё будет работать" 📺.

📉 Реальность:
▫ На новой поверхности используются совершенно другие подходы к авторизации.
▫ Заказчику в действительности нужна несколько иная реализация, копировать логику один-в-один не выйдет.
▫ Сервисы, которые вы вызываете у себя, банально недоступны на новой поверхности, а их команда-владелец не собирается выводить аналог.
Кажется, кто-то забыл проговорить тонкости с архитекторами.

3⃣ Автоматическое наполнение базы знаний
В системе есть консультационный функционал: клиент спрашивает про продукт, вы делаете семантический поиск и отдаёте ответ. Базу сейчас наполняют вручную, но это некрасиво. На встрече льётся мёд 🍯 для ушей собравшихся: у базы знаний есть API, в мастер-системе лежат описания продуктов, давайте настроим выгрузку, а индексация подтянется сама 🤖.

📉 Реальность:
▫ В мастер-системе хранится описание в разы большего числа товаров.
▫ Формат — JSON, причём разные виды продуктов хранятся в разных реквизитах и по разным правилам.
▫ Выгрузить можно только всё сразу или ничего — отобрать нужные продукты нельзя.
▫ Принимающая сторона обнуляет качество поиска: объём одного JSON-файла кратно превосходит размер чанка при индексации 💥.

Страшно стало? 😬
И это я прошёлся только по верхам, намеренно не стал раскрывать все подводные камни.

Главное, что здесь стоит запомнить: простота бывает часто обманчива, и не стоит принимать всё на веру. Иначе рискуете взять на себя обязательства, которые будет невозможно выполнить.

#кейсы #интеграции #брокеры #архитектура #юмор