Управление проектами *

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

В nanoCAD BIM Строительство (рис. 1) эта задача решается через инструменты табличных отчетов и специфицирования. Они позволяют извлекать информацию из помещений, проемов, конструктивных и архитектурных элементов, настраивать состав полей, группировку, сортировку, формат вывода и оформление таблиц по шаблону.

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

При миграции из одной корпоративной системы в другую часто встает задача репликации данных. Например, при поэтапной замене ERP по методологии Parallel Running во время опытной эксплуатации пользователи работают в двух системах, которые оперируют идентичным набором данных. Если модели данных сильно отличаются, а при репликации присутствует дополнительная логика, то команды чаще всего пытаются использовать шины данных (например Kafka). При таком подходе требуется самостоятельно реализовать механизмы копирования данных, обработки конфликтов, пересинхронизации, мониторинга и т. д. Все это увеличивает трудозатраты и потенциально может стать источником проблем. В этой статье разберем техническую реализацию репликации данных через шины, ее слабые места, а также альтернативные подходы.

Я немножко медиум. И меня часто посещают видения будущего. Их несколько. Я ясно вижу их во всех деталях и одно из них точно произойдет. Даже не сомневайтесь!

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

В современной строительной индустрии технологии информационного моделирования (BIM) становятся стандартом проектирования, позволяя автоматизировать рутинные процессы и повысить точность инженерных решений. Эффективным инструментом для реализации таких задач является программный комплекс nanoCAD BIM Строительство.

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

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

1. Подготовительный: настройка рабочей среды и импорт необходимых профилей и спецификаций. 

На этом этапе мы «учим» программу правилам оформления (как выглядит свая на плане, как нумеровать, какие параметры выводить в ведомость).

2. Моделирование: построение 3D-модели свайного поля с использованием Библиотеки объектов и заполнение параметров элементов.

Здесь мы насыщаем модель данными – это основа для всех последующих чертежей.

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

Финальная стадия, где программа «собирает» данные из модели и представляет их в виде нормативной документации.

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

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

Мы привыкли думать, что после хорошего созвона все участники понимают одно и то же: что решили, кто что делает и какие следующие шаги. На практике это почти никогда не так. В одном из исследований памяти разговоров участники через неделю после беседы смогли совпасть в воспоминаниях друг с другом лишь по 4,7% деталей разговора. То есть два человека, которые были на одном и том же созвоне, спустя время помнили практически разные версии событий. При этом люди, которые фиксировали информацию сразу после разговора, сохраняли значительно больше деталей (источник: Cognitive Science — Memory for conversations). Проще говоря, каждый уносит с встречи свою версию происходящего.

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

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

Представьте, вы работаете с почасовой оплатой. Как бы вы ответили на эти вопросы?

Вам пришла в голову идея, которая может улучшить финансовое состояние компании. Она пришла из ниоткуда, вы даже не думали над ней, а занимались своими повседневными делами. Компания не покупает отдельные идеи, она платит только по часам. За сколько часов она должна оплатить, если вы потратили на эту идею 0 часов?

Вам поставили задачу сделать какой-то функционал. Вы вспоминаете, что вы уже делали этот функционал раньше и на реализацию потратили 50 часов. Вы переносите это решение в текущий проект за 10 минут. Всё работает, задача сделана. Компания должна оплатить за 50 часов или за 10 минут?

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

Вы потратили 10 часов на решение, а потом поняли, что вы вообще всё делали неправильно, и кажется что вы в самом начале могли догадаться об этом и выбрать совсем другое решение. Должна ли компания оплачивать за это время?

В предыдущей статье мы рассмотрели общий процесс работы аналитиков. 

Здесь подробнее остановимся на ключевых этапах подготовки постановки.

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

За последние десятилетия у компаний появился внушительный набор управленческих инструментов. Waterfall, Scrum, Kanban, SAFe — каждый описан, стандартизирован, проверен на тысячах внедрений.

На практике эти подходы часто буксуют. Agile вместо ускорения добавляет встреч и согласований. Процессы становятся прозрачнее, а управляемость остаётся прежней. Спринты идут, доска заполнена, ретро проводятся, но скорость и предсказуемость стоят на месте. В таких случаях обычно говорят: «Методология не подходит». Но чаще дело в разрыве между логикой инструмента и средой, куда его пытаются встроить.

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

Вообще, я — ПМ с опытом в коде. А еще мы с мужем делаем сами ремонт в новой квартире, и в процессе я случайно обнаружила «золотую жилу» неэффективности.

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

Короче, с B2B-продажами в этой нише всё, мягко говоря, не очень.

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

В общем, вот во что это вылилось...

Функционал САПР/ТИМ-платформ охватывает широкий спектр типовых инженерных задач, однако в деятельности каждой проектной организации возникают специфические сценарии, требующие индивидуальной доработки инструментов. Построение перекрытий по сложному рельефу, массовое создание отверстий в конструкциях или расчет инсоляции ограждающих конструкций – при выполнении вручную такие операции занимают значительное время и сопряжены с высоким риском ошибок.

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

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

Меня зовут Темченко Сергей, и за последние два года я в разных ролях участвовал во множестве LLM-проектов. Недавно я заметил, что на полях моей тетради накопились значительное количество заметок. Ими я хочу с вами поделиться.

Сейчас каждая компания запускает LLM-проекты, но далеко не все понимают, во что на самом деле ввязываются. По моим наблюдениям, команды на старте систематически недооценивают, насколько сложен путь от прототипа до работающего решения. Под катом условный чек-лист действий, которые нужно сделать (или не сделать) перед тем, как приступать к LLM-проектам в крупных организациях.

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

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

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

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

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

Как мигрировать с Jira и Confluence на российское ПО за одни выходные?

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

В первой части статьи мы пришли к выводу, что само использование ИИ не ускоряет инженерную систему. Можно вырастить MAU LLM, потом MAU API, раздать людям кодинг-агентов и всё равно не увидеть изменений в Lead Time, Throughput и Defect Rate.

Проблема в том, что локальное ускорение быстро упирается в остальной процесс. Один человек или одна роль могут начать делать свою часть быстрее, но задача всё равно ждёт требований, проверки, тестирования, согласований, соседних команд или бизнес-эксперта. Поэтому дальше мы пошли в Agentic Engineering.

Девелопмент — это динамичная и меняющаяся среда, несмотря на довольно строгий внешний образ.

Со 2 апреля 2026 года при подаче на согласование архитектурно-градостроительных решений (АГР) объектов капитального строительства в Московскую городскую экспертизу (МГЭ) обязательно предоставление цифровой информационной модели (ЦИМ АГР) в формате IFC, соответствующем машиночитаемым требованиям в формате IDS.

Во многих компаниях строительной отрасли в этом году обсуждают, что BIMы (сотрудники BIM-команд) стали тратить часы на итерации: нужно было выгрузить модель, проверить, исправить и снова выгрузить. В этой статье расскажем, как в ПИК сократили время подготовки и научили систему проверять соответствие требованиям IDS еще на этапе проектирования — без единой выгрузки в IFC. Опытом поделятся Максим Курбатов, руководитель продукта BIM Inspector в ПИК Digital, и Авенир Барышев, координатор по технологиям цифрового моделирования в ПИК.

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

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

Я главный режиссёр и руковожу внутренним продакшеном одного из центральных каналов. Каждый месяц моя команда производит около 400 видеозадач. Это проморолики, фирменные заставки, партнёрский маркетинг и контент для соцсетей канала.

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

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

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

Привет! Ну что, мы продолжаем зажигать ваши сердца и совсем недавно снова собрали корпоративных авторов и редакторов уже на четвертую творческую встречу. Она состоялась 24 июня в нашем офисе в Москве, а уже в эту пятницу, 10 июля, в 13.00 проведем сокращенный формат в режиме онлайн по многочисленным просьбам тех, кто находится не в столице или не смог добраться до офиса. 

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

Зачем мы это делаем? Кому всё это нужно? Как можно попасть на такую встречу в качестве гостя или спикера? Вопросов к нам стало прилетать немало, и я решила ответить на них, так сказать, оптом. Если ты  корпоративный автор и тебе не хватает опыта, знаний о Хабре, мотивации, поддержки и вдохновения – велкам под кат! Я поведаю историю этого проекта, а также расскажу про наше авторское сообщество, которое появилось как логичное продолжение одной из таких творческих встреч и частью которого ты тоже можешь стать.

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

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

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

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

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

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

Enterprise Architecture помогает связывать бизнес‑цели, технологии и изменения в компании. Но без правильного подхода она легко превращается в набор диаграмм и бюрократию. Разбираем 10 типовых ошибок внедрения EA и способы их избежать.