IT АНАЛитика | Вильд Виктор

Чей офис коллеги?

IT АНАЛитика | Подписаться

Прибейте меня, я делаю интеграцию. Часть 1 🍑

Вы - аналитик.
И вам говорят:
«Нужно интегрироваться с другой системой».

А можно я в очередной раз опишу задачу на покраску кнопочки?🥺

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

Но одними фичами сыт не будешь, и работа с интеграциями - неотъемлемая часть жизни аналитика.

В прошлом году я уже делал серию постов про ведение проектов с нуля:

Как вести проекты с нуля?
Как вести проекты с нуля? 2
Как вести проекты с нуля? 3
Как вести проекты с нуля? 4
Как вести проект с нуля? 5
Как вести проект с нуля? 6
Как вести проект с нуля? 7

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

Ща всё будет «hold my beer», или чай, если вы не пьёте, как я ☕️

Что вообще такое интеграция?
Интеграция - это когда две или больше системы обмениваются данными или событиями, чтобы бизнес-процесс работал целиком.

По-простому:
✅ одна система что-то создает;
✅ другая это принимает;
✅ и между ними есть договорённости, формат, правила и ответственность.

Пример

Допустим, у нас есть новая система, которая отвечает за работу с клиентами.
Пока что она умеет только одно - создавать клиента.

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

А потом приходит бизнес и говорит:
— клиенту нужно создать счет (это делает другая система);
— клиента нужно проверять в системе проверок;
— часть данных нужно отправлять в систему отчётности.

И вот тут внезапно появляется сразу несколько интеграций.
Если хоть одно звено отвалиться, то бизнес-процесс ломается.

Вот это и есть интеграция.

Поставщик и потребитель
В любой интеграции всегда есть минимум две роли.

Поставщик (provider) - это система, которая:
➡️ владеет данными;
➡️ их создаёт или обновляет;
➡️ отвечает за их корректность.

Потребитель (consumer) - это система, которая:
➡️ получает эти данные;
➡️ использует их в своих процессах;
➡️ живёт с последствиями, если данные приехали криво.

Очень частая ошибка не договориться на старте:
🧐кто владелец данных;
🧐кто имеет право их менять;
🧐кто вообще отвечает, если всё сломалось.

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

Зачем тут вообще аналитик?
Потому что именно он:
👍видит бизнес-процесс целиком;
👍 понимает, зачем вообще нужна эта интеграция;
👍 переводит хотелки бизнеса на человеческий язык для команды;
👍 фиксирует договорённости между системами.

В следующей части поговорим про виды интеграций.

А пока расскажите в комментариях:
с какой самой странной или болезненной интеграцией вам приходилось сталкиваться?👇

IT АНАЛитика | Подписаться

🧐 Внедряем AI: ваша компания готова?

Искусственный интеллект уже не будущее — это настоящее. Хотели бы внедрить AI, но не знаете, с чего начать?

🎙22 января в 12:00 (Мск) GreenData приглашает на вебинар «Low-Code и AI: новый этап автоматизации бизнеса», где разберем реальные кейсы в прямом эфире.

👏 GreenData — российский разработчик low-code платформы, помогаем автоматизировать процессы, снижать издержки и быстрее внедрять изменения.

😉 Бонусом делимся практическим гайдом, какие 5 популярных бизнес-задач легко поддаются автоматизации с помощью AI.

Внутри:

✅ Что происходит сейчас — текущие проблемы и риски
✅ Как это автоматизировать — конкретные решения и инструменты
✅ Какой получите результат — экономия времени и бюджета

➡️ Регистрируйтесь по ссылке, получайте гайд и приходите на вебинар GreenData
#реклама
О рекламодателе

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

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

Читать📚

IT АНАЛитика | Подписаться

Айтишники, аналитики - газ отмечать Новый год⛄️

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

Год для IT был неспокойный. Много неопределённости, тревоги и вопросов. Но мы как-то справились и продолжаем двигаться дальше.

От себя хочу пожелать:
🌟 работы, которая приносит кайф, а не только деньги
💫 интересных задач и новых офферов
🌟 почаще отдыхать и ходить в отпуск (я проверял, это реально работает).

Спасибо, что вы здесь и остаетесь на канале.
С наступающим 🎄

IT АНАЛитика | Подписаться

За деньги ДА!

В прошлом году и немного в этом я проводил консультации.

Я специально это не пушу.
Свободного времени немного, и после работы хочется либо заняться своими делами, либо просто почилить.
Да и консультировать «всех подряд» не самая интересная для меня история.

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

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

👉Ссылка

IT АНАЛитика | Подписаться

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

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

В статье разбирают доменную структуру, зоны ответственности команд и то, как бизнес и IT взаимодействуют на масштабе большой компании.

Читать 📚

IT АНАЛитика | Подписаться

Ты почему время в задачу не списал?

Один из вечных бичей всего IT - списывание времени и трекинг активности по задачам.

Весной у меня было собеседование в один аутсорс.
И там сразу говорят:

«У нас есть программа, которую надо поставить. С утра включаешь, вечером выключаешь, в обед ставишь на паузу, чтобы мы трекали время. Ты не подумай, это чисто формальность» 🥴

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

И это сразу напомнило мне первые годы в IT.

Когда работал в саппорте, задачи прилетали в Service Desk, и ты их просто разгребаешь.
Твоя главная метрика - SLA и сколько времени задача висит в работе.
Если задач от пользователей нет, сидишь спокойно, чилишь, занимаешься своими делами.

Потом я перешёл в бизнес-анализ.

Там уже нужно было списывать время в Jira и обязательно писать комментарий, что именно ты делал.
А у нас при этом было два разработчика на шесть аналитиков.
И бывали дни, когда за день ты объективно особо ничего не сделал, максимум пара встреч.
А время в задачу всё равно списывать надо🙂

В итоге начинаешь сам себе придумывать активности и пытаться это всё красиво упаковать в комментарий.
Чтобы если вдруг кто-то посмотрит, не было стыдно.
Хотя давайте честно, я почти уверен, что это никто никогда не проверял.

Сейчас и уже довольно давно я просто списываю время в задачу.
И всё.

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

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

Даже если человек будет п*здеть на созвонах и рассказывать про «активную работу», которой по факту нет, это всё равно вскрывается очень быстро.

А вы как считаете?
Нужен ли трекинг времени и активности или это просто иллюзия контроля?

IT АНАЛитика | Подписаться