Анализ и проектирование систем *

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

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

Потом проходит месяц, иногда два, и выясняется, что компания по-прежнему принимает решения примерно так же, как и раньше. Руководители снова уточняют цифры в чате, менеджеры продолжают выгружать Excel “для себя”, финансовая команда сверяется со своими файлами, коммерческий блок опирается на свои расчёты, а дашборд открывают перед встречей или в тот момент, когда нужно быстро найти подтверждение уже сложившейся версии.

Формально BI появился. Но способ управления почти не изменился.

Я не пишу это как претензию к бизнесу или к конкретным BI-инструментам. Обычно причина не в одном неудачном решении, а в том, что техническая часть проекта и управленческая часть проекта существуют отдельно друг от друга. DataLens, Power BI, Tableau, Metabase или самописный фронт могут быть вообще ни при чём. Отчёт может быть быстрым, аккуратным и полезным для просмотра, но при этом так и не стать частью процесса, в котором принимаются решения.

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

Всем привет! На связи снова Никита Таскин и Анастасия Ильина. Продолжаем тему о контроле доступа применительно к системным интерфейсам, и на этот раз речь пойдёт об API. Напомним, что первая часть была про авторизацию UI, и ознакомиться с ней можно здесь. У нас всё так же разбор контекста ABAC-авторизации для управления задачами команд разработки в Сфера.Задачи. В этот раз мы глубже окунёмся в архитектуру и спроектируем решения для разных по сложности вариантов атрибутного контроля. Также посмотрим на другой вариант применения нашего экспериментального подхода «постанализ юзкейсов».

Привет, Хабр!

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

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

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

Производственник, который пришёл в IT. О том, почему до кода надо идти в цех.

Несколько лет назад наблюдал проект на одном производственном предприятии. Небольшое производство, человек 200. До нашего проекта руководство уже наняло специалистов 1С и начало автоматизировать учёт движения сырья и управленческую отчётность по сменам.

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

К концу внедрения 1С дошло: эти 30% операций никуда не делись.

Просто переехали из бумаги в 1С. Только теперь в красивом интерфейсе.

Всем привет! Меня зовут Вардан Манучарян, я аналитик в команде Монетизации Авито, и мы отвечаем за механику алгоритмов продвижения, то есть управляем порядком, в котором пользователи видят объявления. Для этого нам нужно отслеживать, как изменения в ранжировании влияют на бизнес и покупателей. В этой статье расскажу про интерливинг, — метод, который помогает корректно проводить A/B-тесты с изменением ранжирования. Статья будет интересна аналитикам, которые проводят много A/B-тестов.

Всем привет, меня зовут Катя, я развиваю Gramax. Уже несколько месяцев мы делаем ИИ-агента для работы с текстом и документацией, поэтому много смотрим на реальные кейсы в разных компаниях. Один из самых сильных принесли друзья из SellOut+. Они делают аналитические системы для фармы и FMCG, быстро пробуют новые подходы и в какой-то момент взяли первую версию функции агентов в Gramax.

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

DLQ — это просто топик. Сложное — всё, что вокруг него.

Эта статья — про практическую архитектуру обработки событий из Kafka с отправкой данных во внешний REST API.

Главная проблема такого сценария — нестабильность внешнего API. Он периодически деградирует по latency или начинает отвечать с ошибками, и это напрямую влияет на пропускную способность всего консьюмера.

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Два года я изучаю российский рынок шин данных. За это время удалось связаться с более 40 вендорами, с половиной из них мы встретились, чтобы написать обзор. Каждый такой материал — это вопросы разработчикам, демонстрация решения, изучение документации. Недавно я объединил все обзоры в один большой, чтобы было удобнее знакомиться с разными продуктами. Рассказываю, в чем идея и что у меня получилось сделать за 2 года.

Anti-corruption layer в учебниках выглядит как одна аккуратная коробка между чужой системой и вашей: всё чужое остаётся снаружи, внутрь проходит только то, что уже переведено на язык вашего домена. Граница ровная, как по линейке. Почти за год, что мы вытесняли 10-летний Rails-монолит на .NET, такой ровной границы я не увидел ни разу – ни у себя, ни, кажется, у кого-то ещё на живом проекте.

Понятно это стало в первую же неделю. Мы открыли таблицу exercises и нашли в одной JSONB-колонке 14 разных форм одного типа задания, слепленных за 10 лет. Смаппить это в новые DTO как есть – и новая модель отрастит ровно ту же форму, что у Rails. “Нужен ACL”, подумали мы. Только, как выяснилось на практике, не один.

Перезалив. Хабр в очередной раз посчитал две ссылки на рабочий прототип рекламным объявлением - спасибо! Удалены все ссылки на продукт, за исключением исходников на githubе. Приятного чтения.

Зачем предприятия ведут учёт? Отчётность перед ФНС? Или может воронка клиентов? Сотни ответов российского рынка учётных систем на этот простой вопрос.

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

Год назад я невольно стал заложником терзающих мой разум раздумий о смысле учётных систем. Так был написан первый, второй… пятый модуль мультитенантной ERP-подобной системы для малого бизнеса (Go + pgx | Next.js + TS), вопреки рынку ставящей именно модуль финансов в центр системы.

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

Мы в Beeline Cloud решили обсудить, насколько серьезны опасения и что обо всем этом думают профильные специалисты.

Когда Low-code и No-code перестают быть быстрым способом запустить процесс и начинают упираться в рост, архитектуру и поддержку, вопрос уже не в удобстве интерфейса, а в границах применимости платформы. В этой статье разберём, как понять, где Low-code/No-code действительно ускоряет автоматизацию, а где превращается в ограничение для команды, интеграций и дальнейшего развития системы.

На примере бизнес-приложения IDM (Identity Management) мы покажем, как меняется подход к разработке, если использовать No-code, Low-code или Pro-code инструменты. Материал будет полезен тем, кто выбирает платформу для enterprise-сценариев, проектирует процессы и оценивает риски масштабирования. 

Как на собеседовании отличить системного аналитика, который учил REST по учебнику, от того, кто реально проектировал API?

В статье — три живых кейса из практики в FinTech и e‑commerce. Вы сможете проверить себя, увидите разбор популярных ошибок и узнаете, почему даже опытные инженеры спорят про PATCH и 409.

мы продолжаем изучать моделирование спутниковой связи. В предыдущей статье мы узнали 3 способа организации дерева папок нашего проекта в NS-3. Данная статья цикла посвящена знакомству с устройством и возможностями модуля Satellite и как его установить в NS-3.

В начале 2024 года я устроилась Senior Software Test Automation Engineer в финтех-стартап. После работы в большой стабильной корпорации это был настоящий вызов ― попасть в живой дышащий мир молодой продуктовой  компании, пытающейся занять своё место на рынке. Мне понравился продукт и привлекала возможность влиять на процессы, даже устанавливать новые.

Сперва я изучала как всё работало на тот момент, особенно меня интересовал вопрос обеспечения качества. В жизни я стремлюсь к эффективности: получать больше, а тратить меньше. В бизнесе такой подход приветствуется, особенно в стартапе. Причем стартап банально не выживет если он неэффективен. Я чувствовала себя на месте.

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

Однако не всё было идеально, проблем тоже хватало, даже при том, что скорости релизов мы достигли прямо таки нереальной, обеспечивая при этом отличное качество. В этой компании существовала доселе не встречавшаяся мне структура ― инженерное комьюнити. В каждой дисциплине было своё. У инженеров по качеству ― QA Community. Польза его для процветания компании неочевидна при первом взгляде. Как человеку, который любит докопаться до причин всего на свете, мне было любопытно как это работает и почему. В том числе влекомая этом любопытством я спустя некоторое время выдвинула свою кандидатуру на должность очередного QA Community Lead. Да, должность выборная, как президенство, срок правления ― год, потом смена власти. Немного ранее выборов у нас сменился СТО и объявил, что теперь теперь избранный кандидат должен получить также апрув от него, а также он может оставаться на должности дольше, если нет возражений от комьюнити и/или СТО. Или пока не настанет импичмент, а такое тоже было в истории компании. 

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

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

Нейросети пока не могут работать с большими проектами. Даже лучшие их образцы начинают тупить, если кода больше 40-100 кб, и галлюцинировать после 10-60 итераций одного и того же проекта (1000 циклов - это пока что грубый маркетинг). Шестьдесят итераций - это много? Если речь об автономной ИИ-разработке, то очень мало. Если о man-in-the-loop, то более-менее уже потянет.

Я выбрал такие условия:

Claude Code — лучший кодинг-агент в мире. На наших задачах сливается систематически: знает запреты, нарушает в следующем PR.

В прошлых статьях мы разобрали, что такое цифровой двойник предприятия, а также механизм управления изменениями. Определили, как выстроить процесс изменения, чтобы изменения не привели к хаосу в ЦДП (Цифровом двойнике предприятия). Разобрали, что такое Задание на разработку, Релизный контейнер, Проект, и определили процессы для этих документов. Теперь приступим к рассмотрению того, каким образом необходимо реализовывать изменения в ЦДП.

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

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

Каждый новый этап развития экономики порождал новые системы учёта.

Рассказываем, как лазерное сканирование в связке с nanoCAD Облака точек помогает выявлять отклонения в несущих конструкциях (крановые пути, башенные сооружения, монолитные ЖБ-конструкции) — от автоматического анализа кренов до интерполяции плоскостей и цилиндров при отсутствии проектной модели.