Салют! ВАЖНОЕ СООБЩЕНИЕ!

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

В связи с последними событиями и техническими нюансами мы приняли решение дублировать (а местами и эксклюзивно публиковать) часть контента на другой площадке — 💬 Business | System analyst

НО ЭТО НЕ ПРОЩАНИЕ С TELEGRAM! 🤝

Мы остаемся здесь и будем вести канал до самого конца, пока у нас есть возможность до вас достучаться. В Telegram по-прежнему будет выходить контент, общение и обратная связь, также как и в 💬 Business | System analyst

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

Подписывайтесь на нас на дополнительной площадке 💬 Business | System analyst, а мы продолжаем работать для вас здесь! ❤️

Так же есть сообщество в ВК - 💙 Business | System analyst

Где будем дублировать посты

Оставайтесь всегда с нами 😉

SQL: 3 задачи по анализу торгового пространства для ритейла

⏳ 8 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Мифы про REST API

- Миф 1. PUT и PATCH — одно и то же, можно использовать любой метод
- Миф 2. REST stateless (не имеет состояния), значит, нельзя использовать сессии
- Миф 3. «GraphQL/gRPC — это 'новый REST' или его прямая замена»

⏳ 11 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

Прошлая часть: часть 1

💙 BA|SA | 💬 BA|SA

Тренажёр по BPMN: дистанционное банковское обслуживание

⏳ 30 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Как мы нашли своё решение для миграции и репликации данных в РСХБ

⏳ 9 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Architecture As Code (AaC): от рисунка на салфетке к инструменту анализа

⏳ 9 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Разработка DWH для начинающих

⏳ 7 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Эволюция подходов к работе со спецификациями: от бумажного ТЗ к  Everything as Code

⏳ 8 мин | 🟡⚪️⚪️

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

💙 Analyst IT | 💬 Analyst IT

Как изменилась работа системного аналитика с приходом ИИ

Салют! Я работаю в аналитике с 2013 года. Начинала с позиции младшего бизнес-аналитика в производственной компании со своим заводом, сейчас занимаюсь системным анализом в ИТ. За последние два года с распространением больших языковых моделей мой рабочий процесс изменился кардинально.

👋 Что исчезло из рутины

1️⃣ Ручная обработка неструктурированных данных.

Раньше сбор требований состоял из нескольких Word и PDF, и занимал несколько часов.
Сейчас я загружаю исходники в LLM и получаю структурированный список противоречий и расхождений за 20–30 минут.

2️⃣ Форматирование документации.

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

3️⃣ Генерация типовых тестовых сценариев.

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

__________________

😱 Что стало сложнее

1️⃣ Иллюзия готового решения у заказчика.

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

2️⃣ Риск потери глубины погружения.

ИИ ускоряет написание SQL и скриптов, но модель может упустить детали вроде специфики типов данных или кодировок. Ментальная нагрузка сместилась: раньше я тратила усилия на написание, теперь — на верификацию.

3️⃣ Фрагментация инструментов.

Раньше стек ограничивался Word, Excel, Draw.io и Jira. Сейчас я работаю с тремя-четырьмя LLM-сервисами одновременно. Количество инструментов выросло, время на переключение контекста — тоже.

______________

‼️ Как изменилась роль

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

Распределение времени изменилось.
Если раньше 60% уходило на оформление и синхронизацию артефактов, то сейчас 80% времени я трачу на:

1. Аналитическое мышление — оценку долгосрочных последствий, выявление скрытых ограничений.

2. Коммуникацию — количество итераций согласования выросло, так как ускорилась генерация артефактов.

3. Валидацию — выявление галлюцинаций и неточностей в сгенерированных материалах.

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

Главное изменение — смещение фокуса с оформления и написания на архитектурное проектирование и валидацию. Скорость ожидания результата выросла, ответственность за решения осталась прежней.

В след раз я приведу кейс из рабочей жизни, и покажу прям на примере, как я сдружились с ИИ))

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

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

Пример: Интеграция с внешним 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

Салют! Сегодня предлагаю подвести итоги по теме ИИ + аналитик и обсудить - уйдет ли профессия аналитика с рынка?

‼️Мое личное мнение - Нет, не уйдет.

Но уйдет роль «исполнителя», который тратил 60% времени на оформление, перепечатывание полей из PDF в Excel и написание типовых сценариев.

Останется роль «архитектора», который:

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

__________

‼️ Что изменится в ближайший год

1️⃣ Скорость. То, что раньше делалось за 4–5 дней, будет делаться за 1–2 дня. Но количество итераций согласования вырастет — потому что генерировать стали быстрее, а думать — нет.

2️⃣ Инструменты. Вместо набора разрозненных LLM-сервисов появятся агенты, которые сами делают несколько итераций проверки, держат контекст и выполняют цепочки действий. Аналитик будет управлять ими, а не писать промпты вручную.

3️⃣ Навыки. Ключевыми станут не умение красиво оформить документ или написать SQL, а:
· системное мышление;
· умение формулировать задачи для ИИ (промпт-инжиниринг на уровне архитектуры);
· навык валидации и критической оценки;
· коммуникация — потому что решения все равно согласовываются с людьми.

4️⃣ Входной порог. Младшим специалистам станет сложнее входить в профессию через рутину — ту самую, которую ИИ уже забрал. Теперь «набивать шишки» придется на более сложных задачах, где цена ошибки выше.

__

✅ Что не изменится

1️⃣ Ответственность. За проваленный проект, неправильно спроектированную интеграцию или потерянные деньги отвечает человек, а не нейросеть.

2️⃣ Необходимость понимать бизнес. ИИ не знает, почему поле full нельзя использовать из-за legacy-ограничений или почему заказчик на самом деле хочет не то, что написал в промпте. Это знание остается в головах команды и в процессе коммуникации.

3️⃣ Ценность опыта. Сеньор, который прошел через десятки проектов и знает, где обычно возникают проблемы, будет использовать ИИ эффективнее джуниора, потому что знает, что проверять и на что обращать внимание.

Вместо итога

Профессия не исчезнет, но изменится так же, как изменилась профессия бухгалтера с приходом Excel, или верстальщика с приходом CMS.

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

Через год мы будем работать не с промптами, а с агентами. Но сидеть на созвонах, согласовывать противоречивые требования и объяснять разработчикам, почему нельзя сделать «как ChatGPT сказал», будем все так же мы.

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Зачем нужны нефункциональные требования к ПО и откуда их взять

⏳ 6 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

«Let well alone»: почему в больших проектах мы перестали удалять код

⏳ 6 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Гайд системного аналитика по корректировкам витрин

⏳ 7 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Салют! Сегодня хочу поделиться случаем из практики и назвать его - «Два берега одной реки»

Крупный завод (нефть) — проект описания производственных процессов

Пятый год в профессии БА. За плечами — несколько волн внедрения SAP, пара аудитов и навык разговаривать с технологами на их языке, а не только на языке диаграмм.

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

‼️Два заказчика — два мира

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

Его позиция:
«Описывайте как есть. Завод — не офис, здесь всегда будут отклонения, и это нормально»

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

Её позиция:
«Нам нужна целевая модель. Как должно быть — со стандартами, точками контроля, ответственными. Не описывайте хаос»

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

👩‍💻 Как я работала в этих условиях

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

✅ Мое решение

Предложила двухслойную модель процессов:

1️⃣ Нормативный слой — как процесс должен выглядеть в эталонных условиях. Чёткий BPMN, роли, точки контроля, KPI — территория руководителя из корпцентра

2️⃣ Операционный слой — типовые отклонения и развилки, которые реально возникают на производстве — территория начальника ПТО, где фиксировалась живая экспертиза завода
Каждый получил своё. Конфликт не исчез — он получил законное место в архитектуре.

‼️ Момент, который запомнился

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

Начальник ПТО настаивал: в реальности остановка установки всегда согласовывается неформально с диспетчером за сутки — и только потом идёт официальная заявка.

Руководитель из корпцентра: неформальных согласований в регламенте быть не может.
Я предложила ввести в нормативный слой официальный шаг — «предварительное уведомление диспетчерской службы». Без слова «неформально», но по сути — именно то, что всегда происходило. Легализовали практику, не назвав её хаосом.
Начальник ПТО: «Ну вот, наконец-то по-человечески»

Руководитель из корпцентра: «Это корректно с точки зрения методологии»

Итог
За полтора года — 47 сквозных процессов от приёмки сырья до отгрузки готовой продукции. Модель легла в основу тиражирования на два других завода холдинга.
На финальной презентации начальник ПТО сказал, что впервые видит документацию, которую не стыдно показать оператору пятого разряда. Для меня это была лучшая оценка — лучше любой премии.
На производстве знание живёт не в документах — оно живёт в людях. Задача аналитика — построить мост между этим живым знанием и системой, которая его сохранит.

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA