Системный и бизнес-анализ

Мы работаем на крупном проекте, где присутствует десятки интеграций, сотни бизнес-сценариев, документация в Confluence, а теперь ещё и описания бизнес-сценариев с помощью ИИ прямо в репозиториях. Это здорово выручает для погружения в проект, но всё равно не покрывает всю картину при работе над конкретной доработкой. Поэтому в команде аналитиков мы начали заводить собственных ИИ-агентов: собираем в папку нужные репозитории из Git, БФТ от заказчика, заметки со встреч, и вместе с агентом проектируем и анализируем.

Дальше в статье мы разберём полный конвейер: как готовим данные для ИИ-агента, передаём ему контекст и затем превращаем результат анализа в готовое ЧТЗ. Без нормальной подготовки на входе даже самый умный агент выдаст ерунду, а Markdown-результат на выходе ещё нужно оформить в корпоративный .docx.

С 1 января 2027 года вступает в силу Постановление Правительства РФ №874, существенно уточняющее правила учёта затрат и калькулирования себестоимости продукции, поставляемой по государственному оборонному заказу.

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

Именно вокруг этой задачи я собрал книгу «ГОЗ: как прожить контракт от подписи до исполнения» - 82 страницы, 42 схемы, 12 глав. Ознакомиться, скачать и прочитать книгу можно бесплатно.

https://litnet.com/ru/book/goz-kak-prozhit-kontrakt-ot-podpisi-do-ispolneniya-b633273

Книга построена как сквозной практикум: один контракт и один шкаф железнодорожной автоматики и телемеханики проходят двенадцать глав — от регистрации обязательства до производства, закупок, труда, НЗП, отчётности, проверки, приёмки, расчётов и перехода через 1 января 2027 года.

Вместо введения

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

В распределённой системе всё меняется.

Один пользовательский запрос может пройти через API Gateway, несколько микросервисов, очередь сообщений, базу данных и внешний API. При этом каждый компонент может находиться на отдельном сервере или контейнере.

Если такой запрос выполняется 4 секунды, возникает вполне практический вопрос:

Где именно были потрачены эти 4 секунды?

На сети? На базе данных? На блокировке потока? На выполнении конкретного метода? На внешнем сервисе?

Именно для ответа на этот вопрос в APM используются трассировка (distributed tracing) и инструментация приложений.

Один из наиболее интересных подходов — автоматическая инструментация, при которой разработчику не требуется вручную добавлять tracing‑код в каждый сервис.

Разберём, как это работает на уровне архитектуры и что происходит внутри приложения.

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

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

Привет! Я — Анна Ноябрьская, работаю в отделе аналитики «Синтеки». Мы создаем софт для снабжения и закупок в строительстве и помогаем клиентам анализировать данные по многим бизнес-процессам.

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

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

«Нужен простенький дашборд: продажи, популярные товары, фильтр по категориям. Всё в Excel, работы на пару часов».

Меня зовут Антон Богун, я старший разработчик ПО в Axenix. В прошлой статье мы говорили о Doc as Code как об инженерной практике: документация живет в Git, проходит review, проверяется автоматически и становится частью процесса разработки. Это важная база, но сегодня у нее появляется следующий уровень применения.

Разработчик подключает ИИ-агента уже не к абстрактной документации, а к собственному проекту: к кодовой базе, OpenAPI спецификациям, Markdown страницам, release notes, задачам в трекере и интеграционным схемам. От агента ждут не пересказа документации, а понимания текущего поведения системы.

Именно здесь возникает новая проблема. Метод API может называться так же, путь может остаться прежним, request body может почти не измениться, но поведение системы уже стало другим. Например, заказ больше не создается сразу в финальном статусе, часть заказов уходит на дополнительную проверку, после создания публикуется событие, а обработка продолжается в другом сервисе через брокер сообщений.

Для человека такие изменения часто понятны из задачи, pull request, обсуждения или кода. Для ИИ-агента это неочевидно, если код, спецификация, документация и задачи не связаны между собой.

Doc as Code отвечает на вопрос: как хранить и проверять документацию. Но для ИИ-агента важнее следующий вопрос: как понять, что изменилось в поведении системы и где это отражено.

ИИ-агенту нужен контекст проекта, а не просто набор файлов

Когда мы говорим «дадим ИИ-документацию», часто подразумевается, что достаточно открыть агенту доступ к репозиторию, где лежат openapi.yaml, README и несколько Markdown страниц. Но в реальном проекте этого мало.

Представьте, что у вас одновременно запущено несколько десятков экспериментов. В каждом миллионы пользователей и несколько метрик с ежедневным пересчётом. У нас как раз такой кейс, поэтому ещё при проектировании платформы мы подумали, что считать метрики на уровне пользователей будет слишком дорого и медленно…

Решили попробовать через бакетирование. Все пользователи в рамках одного эксперимента разбиваются на 256 бакетов, поэтому статистика считается уже по бакетам. В результате вычислительная сложность и объём хранимых данных сокращаются на порядки. Вместо миллионов строк мы работаем всего с 512, поскольку для двух групп нужно обработать по 256 бакетов.

Но сразу возникает вопрос: а не теряется ли при этом статистическая корректность? Ведь нам важно оценивать эффект именно на пользователя, а не на бакет, работать со всеми типами метрик, включая ratio, и поддерживать всевозможные сплиты. Кроме того, мы хотим применять CUPED, который снижает дисперсию через исторические данные, но ещё сильнее усложняет расчёты.

Привет! Меня зовут Диана Анфёрова, я лид аналитиков и системный аналитик в Контур.Толке. В статье делюсь своими критериями качества работы аналитика и на реальных задачах показываю, как проносить не только постановки функциональности, но и результаты. И быть ценнее для компании.

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

Привет! На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Я достаточно много занимаюсь интеграциями, хранилищами данных и BI, поэтому, когда ребята из «Денвик Аналитика» предложили познакомиться с новым инструментом DVT, не стал отказываться.

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

Пример, конечно, условный: оператор контактного центра должен отправить клиенту СМС со ссылкой, не переключаясь в другую систему.

Меня всегда смущала фраза «системный аналитик — мост между бизнесом и разработкой». Для первого знакомства с профессией она годится. Но что делать, если готового ответа нет, а на входе только просьба «добавьте кнопку»? Здесь, по моему мнению, и начинается наша работа, которую словом «мост» уже трудно описать.

Хотел разобраться с одним, казалось бы, простым вопросом: за что мы заплатили подрядчику? Платёж был в 1С, заявка была в Bitrix24, а договор и акты приходилось искать среди вложений. С поиска этой связи начался финансовый сервис, а вокруг него постепенно появились ещё четыре продукта. Расскажу, как они складываются в ERP‑контур для стройки, что уже работает и где автоматизация пока может уверенно ошибиться.

Самые интересные новости финансов и технологий в России и мире за две недели: Флорида пытается через суд притормозить OpenAI, из РФ запретили вывозить много налички, Китай включил экспортный контроль за своими AI-спецами, Anthropic подали заявку на IPO, OpenAI запустил агентов-точечек, но отложил новую GPT-6.1 Astra из-за проблем с безопасностью, а Google тоже не спешит выпускать Gemini 4 Argon.

1 октября в России заработал реестр цифровых платформ. Это седьмой новый государственный реестр только за 2026 год, и год ещё не закончился. Я подумал, что в такой ситуации стране срочно не хватает одного: реестра реестров. Собрал 100 государственных реестров в одну таблицу, проверил каждый по тексту закона и посмотрел, что из этого получается. Рассказываю, что узнал по дороге.

Вам в наследство досталось руководство пользователя МИС на 1160 страниц в формате .docx, тысячи повторяющихся скриншотов, процесс обновления вызывает глубокую грусть. Что с этим «добром» делать?

В этой статье я расскажу о своём проекте по переводу такой документации на рельсы docs-as-code: переосмысление структуры, укрощение размера скриншотов, борьба с кириллицей в Asciidoctor, настройка автоматической сборки HTML и PDF через GitLab CI/CD.

Я собрал больше 32 тысяч объявлений с Krisha и данные БНС по зарплатам, ценам, тарифам и переездам. Потом посчитал, сколько остаётся от зарплаты после аренды, еды и коммуналки, и сравнил это с тем, куда на самом деле переезжают люди.

Когда ИТ-директор в 2019 году выбирал промышленную систему, у него был короткий путь: открыть отчёт Gartner, Forrester или IDC, посмотреть, кто в правом верхнем углу, и вести переговоры с тремя вендорами, а не с тридцатью. Квадрант не заменял пробное внедрение, но экономил месяцы на составлении длинного списка. В 2022 году западные агентства ушли, а российские продукты в их отчётах и раньше встречались единично.

Потребность никуда не делась. За четыре года её начали закрывать десятки локальных рейтингов: отраслевые, редакционные, вендорские, от СМИ и от ассоциаций. У каждого своя методика, свой набор категорий, свой способ попасть в список. Сравнить два рейтинга между собой нельзя, а понять, почему продукт в одном списке первый, а в другом отсутствует, нельзя тем более. Рынку нужна не ещё одна таблица, а понятный способ считать.

Мы в АНО «Цифровые платформы» в сентябре в тестовом режиме запустили Призму: квадрант российского ПО по каждой из 441 категории каталога, 9842 позиции, пересчёт раз в квартал. Эта статья не отчёт о продукте. Это попытка разобрать задачу «как построить квадрант в условиях, когда ни вендоры, ни заказчики пока не умеют описывать внедрения» и предложить рынку подход, который можно критиковать, дополнять и забирать себе.