Как проектировать интеграции с Kafka

⏳ 7 мин | 🟡⚪️⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Observability в финтехе: связываем клик пользователя с падением интеграции

⏳ 10 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Салют! На днях писала пост про то, как ИИ повлиял на нашу работу. Сегодня привожу пример с моей рабочей жизни)

Пример: Интеграция с внешним API поставщика

Был проект по автоматизации закупок. Нужно было интегрироваться с API крупного поставщика, у которого документация была… как бы помягче… «исторической». Swagger-спеки не было, был PDF на 200 страниц, где описание полей шло вперемешку с юридическими оговорками и примерами на устаревшем XML.

Задача: спроектировать систему обмена данными (заказы, статусы, отгрузки), описать маппинги полей и написать ТЗ для разработки адаптера.

👩‍💻 Как я использовала ИИ

1. Структурирование «мусора»

Я скормила ИИ (через API, с соблюдением всех NDA и анонимизацией данных) выдержки из PDF — только описания методов и схемы объектов.

Промпт был такой:

У меня есть описание REST API (фрагменты). Документация неструктурированная. Выдели все эндпоинты, методы, обязательные и опциональные параметры. Приведи в виде таблицы: эндпоинт, метод, описание, входные параметры (с типами), выходные параметры. Если есть зависимости между вызовами — отметь. Не додумывай, только то, что явно написано

ИИ вытащил структуру за 15 мин, которую я вручную собирала бы 2–3 дня. Да, были неточности — нейросеть иногда путала description поля с примером значения. Но база была готова.

2. Генерация маппингов

Дальше нужно было сопоставить поля поставщика с нашей внутренней моделью данных.

Я подготовила таблицу с нашей схемой (поля, типы, ограничения) и дала задание:

Вот поля поставщика (колонка A), вот наши поля (колонка B). Предложи маппинг. Где нет прямого соответствия — отметь как “требует преобразования” и предложи вариант логики. Где данных не хватает — отметь как “требует уточнения у бизнеса”

ИИ выдал черновик маппинга с 40+ полями. Из них около 30 я приняла без изменений, в 7 добавила свои правки, а 3 действительно пошли на уточнение к заказчику (и оказалось, что эти поля реально не используются — я бы сама копалась полдня).

3. Написание ТЗ для разработчиков

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

Я использовала ИИ так:

У меня есть описание интеграции. Напиши раздел ТЗ “Логика обработки ошибок” для следующих сценариев: таймаут, 4xx, 5xx, невалидный JSON. Для каждого укажи: что логируем, нужен ли ретрай (с какой задержкой), переходим ли в ручной режим. Стиль — технически точный, без воды

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

Аналогично я накидала:

- описание аутентификации
- примеры запросов/ответов (которые ИИ сгенерировал на основе структуры полей)
- чек-лист для приемки интеграции (разработчик сказал потом: «О, тут даже кейс с пустым массивом учтен — спасибо, я б забыл»)

4. Валидация (ключевой момент!)

И вот тут — самое важное. Я не просто скопировала результат.

Когда ИИ сгенерировал маппинг, я заметила странность: поле delivery_address.line2 он замаппил на наше address_extra, а поле delivery_address.full — на наше address_full. Но в документации поставщика было написано, что line2 используется только если full не заполнен. Это бизнес-логика, которую нейросеть упустила (или она была на другой странице PDF, которую я не скормила).

Я докрутила: добавила условие «если full не пуст — берем его, иначе формируем из line1 + line2».

‼️ Без моей экспертизы это уехало бы в разработку, а потом — баг на тестировании и лишняя итерация.

Что по итогу

Итого: вместо 4–5 рабочих дней я уложилась в 1,5 дня. При этом качество выросло — потому что время освободилось на сложную логику и валидацию, а не на перепечатывание полей из PDF в Excel.

‼️В комментариях оставила небольшой вывод👇

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

ИИ-агенты защищают друг друга от отключения: анализ уязвимостей в передовых моделях

⏳ 11 мин | 🟡⚪️⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

MoneyDev: как заработать на макулатуре

⏳ 21 мин | 🟡⚪️⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

От ТЗ до сертификата: как интегрировать оценку соответствия в жизненный цикл продукта

⏳ 7 мин | 🟡⚪️⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

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

Часть 1
Часть 2

В сумме вышло 50 вопросов, с их разбором, также собрала все вопросы в pdf формате, можно скачать, будет полезно))

Готовится вторая часть таких вопросов уже с уклоном на ИИ, покажу, что изменилось и какие сейчас дополнительные вопросы задают на собесах 🧐

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?»

⏳ 8 мин | 🟡⚪️⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

System Design: проектируем сервис заказа такси

⏳ 21 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

«Невидимые требования» — главная причина провала проектов

Салют! Сегодня хочу поговорить о проблеме, с которой может столкнуться каждый аналитик — вне зависимости от домена, компании и стека. Про требования, которые никто не записал. Не потому что забыли. А потому что считали: это и так понятно. Я сама сталкивалась с такой ситуацией и не раз 🥲

Большинство проектных провалов связаны не с техническими проблемами, а с плохо собранными или неполными требованиями. Но когда начинаешь разбираться в таком проекте — почти никогда не находишь явной халтуры.
Люди работали. Митинги проводились. Документы писались. Вроде все гуд, все работали!

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

✔️ Заказчик не договаривает детали — он уверен, что они очевидны.
✔️ Аналитик не уточняет — боится выглядеть некомпетентно.
✔️ Разработчик молчит — думает, что аналитик разберётся.

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

Я называю такие требования - «невидимыми».

Они не злонамеренные и не случайные — они системные. И появляются по трём предсказуемым причинам:

1️⃣ Разрыв контекстов. Заказчик живёт внутри своего процесса годами — для него многое фоновое знание, которое он физически не умеет передать словами. Он не скрывает, он просто не видит, что скрывает.

2️⃣ Разница уровней абстракции. Бизнес думает результатами и процессами. Аналитик — сущностями и логикой. Разработчик — данными и структурами. Одно и то же слово на каждом уровне означает разное.

3️⃣ Социальная динамика. Задавать уточняющие вопросы неловко — кажется, что ставишь под сомнение компетентность собеседника или собственную. Молчание воспринимается как понимание, хотя на самом деле это просто вежливость.

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

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

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Как разрабатывать интеграционные решения в крупных компаниях: методология и артефакты

⏳ 7 мин | 🟡⚪️⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Почему я перестала доверять «очевидным» требованиям

Есть одна фраза, от которой у меня теперь непроизвольно сжимается желудок🤨. Звучит она так: «Ну это же понятно, зачем это писать».

За несколько лет в аналитике я слышала её десятки раз — от бизнеса, от заказчиков, от коллег. И почти каждый раз за этой фразой прятался баг. Не в коде. В голове у людей, которые были уверены, что думают об одном и том же.

Расскажу один конкретный случай из своей практики в финтехе.

Мы работали над внутренним порталом для операционного отдела. На установочном митинге руководитель направления сказал:

«Нам нужна кнопка выгрузки отчёта по клиентам»

Коротко. Чётко. Все кивнули — и я в том числе. Требование ушло в бэклог.

Через пять недель разработчики показали готовую выгрузку: все поля на месте, данные корректные, формат .xlsx, скачивается за секунду.

Я проверила — полное соответствие тому, что обсуждали. Передаю на приёмку. Через час приходит сообщение:

«Это не тот отчёт. Нам нужна выгрузка строго по форме № ОП-7 из нашего внутреннего регламента — с группировкой по менеджерам, подитогами по продуктам и отдельной вкладкой для просроченных клиентов».

Про форму № ОП-7 на митинге не было сказано ни слова. Потому что «это же очевидно» 🤯

Две недели переделок. Недовольный заказчик. Разбор полётов с тимлидом. И главное — ощущение, что я подвела команду, хотя сделала ровно то, о чём договорились.

После этого случая я изменила подход к сбору требований. Теперь любое упоминание слов «отчёт», «выгрузка», «уведомление», «форма», «статус» — это для меня стоп-сигнал. Я не иду дальше, пока не получу ответ на три вопроса:

1️⃣ Как это выглядит прямо сейчас? Покажи файл, скриншот, распечатку — что угодно реальное.
2️⃣ Кто это использует и когда? Конкретный человек, конкретная ситуация.
3️⃣ Что произойдёт, если этого не будет? Это помогает понять реальный приоритет и критичность.

Эти три вопроса кажутся простыми — но именно они вскрывают всё скрытое. Форму № ОП-7. Макросы. Регламенты безопасности. Согласования со смежниками. То, что заказчик считает само собой разумеющимся и поэтому не говорит вслух.

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

Вывод: Документируй не то, что кажется сложным, — а то, что кажется очевидным. Именно там живут самые дорогие ошибки. Один уточняющий вопрос на старте стоит дешевле двух недель переделок на финише. Я убедилась в этом на собственном опыте — и теперь не киваю молча никогда!

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Проектируем сервис HTTP-запросов: Kafka, PostgreSQL, Redis-очередь и миллионы логических партиций

⏳ 11 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Agile systems engineering по ISO/IEC/IEEE 24748-10:2026: как быть гибким и не потерять жизненный цикл

⏳ 10 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Безопасность ИИ: как перестать бежать анализировать каждое новое ПО и перейти к системному подходу

⏳ 9 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT