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

В этой статье я хочу поделиться практическим опытом создания архитектурной BIM-модели многоквартирного жилого дома в nanoCAD BIM Строительство на основе уже существующего проекта, выполненного в Archicad.

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

Исходные данные проекта

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

В рамках обучения заказчик использовал программу преимущественно для разработки конструктивной части здания. Поскольку объект представлял собой кирпичный жилой дом, средствами nanoCAD BIM Строительства в рамках раздела КР были выполнены: раскладка пустотных плит перекрытий, лестничных маршей и площадок, фундаментных блоков, перемычек над проемами и деревянная стропильная система крыши.

Пять лет назад завершилась моя работа в одном из самых амбициозных, но не завершившихся IT-проектов в истории пассажирских перевозок. Проект для РЖД, который по масштабу и связности экосистемы должен был встать в один ряд со Сбером и обогнать всё, что существовало у мировых перевозчиков. Его убила не кривая архитектура, а пандемия и тектонические сдвиги подковерной борьбы.

Более 15 лет в b2b-разработке приучили меня держать подобные кейсы за контуром публичности. Но сегодня юридические ограничения сняты, и я готов сорвать покровы.

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

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

Серия вторая: Продуктовое мясо и хроники интеграционного ада. Детальный разбор самого цифрового космолета, погружение под капот легаси-экосистемы, курьезные истории из жизни нашего «прода» в жанре «пиу-пиу». И в завершение 10 наших железных правил выживания с госами.

Добро пожаловать на борт. Физика процесса изменена, но внешне мы стоим на ногах.

Привет! Хочу рассказать вам о том, как мы применили продуктовый подход к исследованию опыта разработчиков при работе с Figma, чтобы создать единый стандарт оформления макетов в компании.

На Хабре уже есть несколько отличных разборов того, как разные команды наводят порядок в Figma: аннотации, стрелки, сценарии, раскладки макетов и так далее. Я видел материалы Ozon Tech, t2, Иннотех — это классные справочники правил, можно брать и пользоваться. Но, когда в 2024 году я взялся за задачу подготовки стандарта для нашей компании, то столкнулся с вопросами, о которых нигде ничего не нашел. Как разработать единый подход? Что считать правильным и почему? Как упаковать эту идею и «продать» остальным членам команды, а главное: что делать дальше?

В этой статье поделюсь нашим методом поиска ответов на эти вопросы.

Redis долго был понятным выбором: BSD-лицензия, можно использовать почти где угодно. После смены лицензии в 2024 году всё стало сложнее: RSAL, SSPL, AGPLv3, Valkey, форки и вопросы к юристам.

В статье рассматриваю этот вопрос со стороны обычных продуктовых команд, а не облачных провайдеров. Если Redis у вас внутри как кеш, очередь или для сессий, что реально меняется, где начинаются риски и что сегодня разумнее выбрать - Redis 8, Valkey или другой Redis-compatible вариант.

Всем привет! Мы — команда Облака Mail: редакторка Наташа, дизайнер Саша и исследовательница Лена.

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

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

«Освоить профессию с нуля» — популярный запрос, но не всегда корректный. А что, если абсолютного нуля не бывает? Ведь у каждого из нас есть свой опыт, знания и преимущества в чём-то своём.

Хабр, привет! Меня зовут Альберт Болотнов, я главный системный аналитик продукта в бигтех-компании. Я отучился на инженера в МГТУ им. Баумана, но через два года работы сменил сферу на IT, а ещё спустя год — добрал необходимые знания в курсе «Системный аналитик» в Яндекс Практикуме. В этом тексте расскажу про свой путь и дам несколько советов тем, кто ищет себя или делает первые шаги в профессии.

Эта идея появилась у меня давно.

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

А вот люди, которые каждый день работали с данными, не всегда были в таком же восторге.

BI хорошо показывает, что что-то изменилось: появилась аномалия, просел показатель, выросло значение, изменилась динамика. Но после этого почти всегда возникает следующий вопрос: почему так произошло?

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

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

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

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

Так появилась первая версия программы: она формировала отчёты в Excel и хранила на сервере историю выгрузок.

9 мая пост «I’m going back to writing code by hand» набрал на Hacker News 1038 баллов и 617 комментариев. Автор семь месяцев вайб-кодил Kubernetes-дашборд с Claude, дошёл до god object на 1690 строк и бросил AI-кодинг. Я узнал в этом свою историю полугодовой давности, но вывод сделал другой.

Меня зовут Андрей Шантарин, я ИТ-директор на машиностроительном предприятии.

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

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

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

Это бонусный материл в серии о внедрении LLM в клиентские сервисы. Если в прошлых трех статьях я подробно разбирал удачные моменты, архитектуру и правильные шаги, то этот текст решил целиком посвятить разбору наших ошибок и факапов. Сейчас – менее красивая часть и реальный опыт PM: что происходит после демо, когда AI-пилот пытаются превратить в промышленную систему и команда сталкивается со скрытыми техническими проблемами.

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

В какой-то момент команда уже всерьёз обсуждала замену модели. Казалось, что проблема в качестве генерации: ответы были уверенные, но иногда неверные. После разбора логов оказалось, что в части диалогов LLM вообще не должна была отвечать. Routing отправлял пользователя в ветку answer, хотя API возвращал partial, а сценарий должен был уходить в handoff.

Самые дорогие ошибки жили не в LLM. Они жили в routing, API, handoff, базе знаний, метриках и compliance-слое. Модель просто красиво озвучивала проблемы, которые система создала раньше.

Перелом случился, когда мы перестали спрашивать: «Почему LLM ответила неправильно?» – и начали спрашивать иначе: «Почему система вообще поставила модель в ситуацию, где правильного ответа у неё быть не могло?»

Вывод неприятный, но полезный: сильная LLM не компенсирует слабую архитектуру. Если у системы нет нормального routing, владельца knowledge base и понятного handoff, сравнение моделей часто становится дорогим отвлекающим манёвром.

Я работаю более 6 лет системным аналитиком и порядка трёх лет на продуктах по внедрению LLM в бизнес. И меня категорически не устраивает AI-зрелость большинства моих коллег в этих ИИ-проектах!

Есть мысль, что часть проблемы в отсутствии у системных аналитиков общепризнанного подхода к AI‑усилению, подобного тому, что уже сформировался у разработчиков. Но при этом я часто встречаю в вакансиях требования «опыт написания документации AI‑native», «AI‑центричная аналитика». И я согласен с таким запросом рынка — давайте уже подстраивать пайплайн под эксперта! А эксперты в процессе написания кода — это наш разработчик + AI. Очевидным и логичным решением будет писать аналитику сразу в текстовом формате, постепенно уходя от Miro и Draw.io.

Первое время я даже считал, что придумал новый фреймворк, и даже придумал ему красивое название — Analysis‑as‑Code, но оказалось, что существует Spec‑Driven Development — подход, в котором «спецификация» становится центральным документом, а ИИ использует её в реализации задачи.

В этой статье я хочу разобрать Spec‑Driven Development (SDD) с оглядкой на роль системных аналитиков в России и СНГ и понять, как их меняется их роль при таком подходе.

Всем привет! Меня зовут Андрей Беляев, я бизнес-архитектор в компании «Инфосистемы Джет».

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

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

Специалисты института «Уралгипротранс» рассказали об опыте использования программы nanoCAD BIM Электро на примере разработки разделов силового электрооборудования и электроосвещения при проектировании учебного корпуса и общежития политехнического техникума в городе Березники Пермского края. В статье отмечены особенности применения программного продукта, а также основные результаты его внедрения.

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

За годы работы «Уралгипротранс» реализовал множество проектов как в России, так и за рубежом...

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

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

Представьте себе высоконагруженный сервис, который решает, с какого из множества складов нужно отправить товар покупателю. В пике через него проходит около 600 000 RPS, а строгий SLA требует ответа в пределах 50 мс. Для расчёта нужно за минимальное время выбрать оптимальный склад с учётом остатков, доступности и других данных, которые хранятся в разных микросервисах и их базах данных.

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

Недавно CrewAI представила экспериментальную возможность Conversational Flows как способ найти баланс между детерминированной логикой и рассуждением на основе ИИ в агентных системах. Это действительно важная архитектурная задача. Хочу поделиться тем, чему мы научились, создавая и эксплуатируя именно такие системы в промышленной среде — для корпоративных заказчиков из банковского сектора, телекома и других строго регулируемых отраслей.

Каждое лето сотни тысяч абитуриентов пытаются понять одну простую вещь:

Поступлю я или нет?

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

Но на практике ответить на этот вопрос гораздо сложнее, чем кажется.

Именно из этой проблемы вырос проект AbitList.

Сайт: https://abitlist.ru

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

Внедрение ERP? Интеграцию ERP с MES? Замену импортной PLM? Подготовку регламентов? BI-панель? Электронный документооборот? Производственную аналитику? Новые рабочие места в системе? Всё это может быть полезно, а иногда и совершенно необходимо. Проблема начинается в тот момент, когда обычная автоматизация, внедрение или интеграция начинают называться цифровой трансформацией предприятия.

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

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

Привет, Хабр! Меня зовут Александр, я работаю в IT с 2006 года, последние годы занимаюсь системным анализом и управлением командами аналитики.

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

Для кого-то T-Shaped — это специалист, который понимает систему шире своей основной области и умеет эффективно взаимодействовать со смежными ролями. Для кого-то — тот, кто должен «уметь всё понемногу». А иногда под этим термином вообще начинают подразумевать сотрудника, который фактически совмещает несколько ролей одновременно. Короче говоря, с T-Shaped все далеко не так однозначно.