Где встречаются дисциплины: история одного продукта

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

В нашем портфеле шесть продуктов: Family Manager, BIM Inspector, PikTools, Робот R2, BIM Data Service и PikCheckUp. Все они интегрированы между собой, но также могут использоваться по отдельности. Чтобы раскрыть суть междисциплинарного продукта, сначала стоит коротко пояснить, что такое PikTools и BIM Inspector — так как МД-продукт с ними связан.

PikTools — это инструменты для оптимизации работы в Revit, Civil 3D и AutoCAD. Они автоматизируют проектирование и оформление документации.

BIM Inspector — сервис, который автоматически проверяет модели на соответствие стандартам и BIM-требованиям, выявляет ошибки.

МД-продукт — это универсальный набор плагинов PikTools Общее, предназначенных не для какой-то одной специализации, а для всех участников проектирования в Revit. В нем собраны вспомогательные функции, которые нужны любому специалисту: пакетная печать листов в PDF, автоматическое заполнение параметров по заданным правилам, изменение уровня элементов без смещения, копирование листов, видов и многое другое. Это позволяет уменьшить количество рутинных задач, ускорить работу и снизить риск ошибок.

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

Если перейти к BIM Inspector, то в нем реализованы междисциплинарные проверки. Например:

• Проверка соответствия площадки и общих координат между текущим файлом и координационным.
• Проверка соответствия семейств Family Manager

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

• Проверка соответствия уровней и осей координационному файлу
• Выявление дублирующихся элементов
• Контроль корректности заполнения параметров с помощью плагина “Склеить параметры” и другие проверки.

Плагин “Склеить параметры” входит в состав PikTools Общее и позволяет автоматически заполнять значения на основе заранее заданных правил в Excel-таблице — это может быть конкретное значение, расчетная формула, объединение значений нескольких параметров с использованием префиксов/суффиксов и не только. Один раз правильно настроив таблицу, можно применять ее в разных проектах, быстро и без ошибок заполняя параметры всех элементов. Проверка в BIM Inspector сравнивает значения из модели с теми, которые должны быть получены с помощью плагина, чтобы убедиться в правильности заполнения. Получить более подробную информацию про плагин можно в статье “Склейка как помощник в проектировании”.

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

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

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

Раньше сложные, узкоспециализированные плагины по дисциплинам получали больше внимания в отличие от массовых плагинов. Хотя если взглянуть на статистику нашей компании, то аудитория этих плагинов довольно широкая, количество пользователей за 2025 год около 2000, а ежемесячно — около 1300 человек. Без должного внимания эти инструменты могли быть в чем-то неудобными, либо работать с отклонениями, пользователи чаще сталкивались с багами и были вынуждены привыкнуть к этому.

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

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

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

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

Для поддержания баланса не требуется большая команда. Появление междисциплинарного трэка и команды помогает сохранить фокус на данных вопросах. Такой подход позволяет сохранять приоритет общих задач и инструментов без дисбаланса. Специалист, не привязанный к одной дисциплине, способен анализировать задачи шире, рассматривать различные точки зрения и находить универсальные решения. Это обеспечивает объективность и рациональность при принятии решений.

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

Внедрив это у себя, мы рекомендуем попробовать и другим. Создание отдельного МД-продукта и команды дало нам:

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

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