Разработка плагинов для BIM-команд
У BIM специалиста есть задачи, которые не требуют квалификации, но требуют абсолютной точности при каждом повторении: перенести правки по инженерному разделу в модель после того, как архитекторы обновили планировку, свести спецификацию из трех разделов в единую таблицу, вручную сверить параметры оборудования после того, как в модель внесли изменения. Именно на такие задачи незаметно уходит больше всего времени. А однообразие повышает риск пропустить ошибку. По отдельности каждая такая задача выглядит мелочью, которую проще сделать руками, чем налаживать автоматизацию. За месяц, за проект, за год эти часы складываются в привычную, из года в год повторяющуюся рутину.
Кто-то в такой ситуации просто мирится: работа есть работа, а на автоматизацию в BIM никогда не находится время. Кто-то открывает поиск, вбивает «автоматизация BIM» или «разработка плагина для Revit», и почти сразу упирается в десяток предложений заказать разработку под ключ, даже не успев понять, нужна ли разработка именно для его задачи.
Здесь BIM-координатору стоит остановиться на шаг раньше, до того как переходить сразу к разговору о разработке. Не каждая повторяющаяся операция требует программиста, технического задания и бюджета на разработку. У части таких задач уже есть готовое, бесплатное и проверенное сообществом решение. У другой части есть путь проще и быстрее, чем разработка с нуля. И только у части задач, которые действительно завязаны на сложную логику или становятся постоянной частью процесса команды, альтернативы полноценному плагину нет.
Вопрос не в том, автоматизировать или нет — вопрос в том, каким именно инструментом решать конкретно вашу задачу: для разных по своей природе задач нужны разные инструменты.
Три уровня решения
Прежде чем разбирать конкретные инструменты, стоит увидеть саму рамку выбора. Любая задача автоматизации в BIM решается на одном из трех уровней, и они выстроены не по случайности, а по возрастанию сложности и стоимости: готовое решение, визуальный no-code инструмент, разработка плагина.
Первый уровень: готовое решение. Кто-то уже сталкивался с точно такой же задачей и выложил бесплатный плагин или надстройку в открытый доступ: не нужно ничего разрабатывать, достаточно найти и установить. Второй уровень: визуальный no-code инструмент. Если готового решения нет, но задача поддается описанию через последовательность действий с моделью, ее можно собрать самостоятельно или силами инженера с базовыми навыками, без программиста и без бюджета на разработку. Какой именно это инструмент, зависит от платформы: подробнее об этом чуть позже. Третий уровень: разработка специализированного плагина под конкретную задачу — полноценная программа с собственным интерфейсом и доступом ко всем возможностям API платформы, которую поддерживают и дорабатывают так же, как любой другой рабочий инструмент команды.
Ошибку легко совершить в обе стороны: решить, что раз задача повторяется каждую неделю, значит хватит скрипта, или наоборот, что раз задача важная, сразу нужен полноценный плагин. Правильный уровень зависит не от бюджета, который готова выделить компания, и не от того, что сейчас модно обсуждать на профильных форумах, а от природы самой задачи: как часто она повторяется, меняются ли исходные данные, сколько человек ей пользуется, и что произойдет, если решение сломается в середине проекта.
Дальше, по порядку, начиная с того уровня, с которого стоит начинать всегда: с проверки, а не решена ли задача уже кем-то другим.
Сначала проверь готовое решение
Начать стоит с самого дешевого варианта: узнать, не занимался ли этой же задачей кто-то другой раньше. Это работает не только в экосистеме Revit: разработчики давно закрывают часть типовых задач координации готовыми бесплатными решениями на разных платформах, и часть из них закрывает именно то, с чем чаще всего возятся вручную. Для Revit таких решений особенно много.
Перенос параметров между элементами и семействами, пожалуй, одна из самых частых причин обращения к разработке, хотя для этой задачи уже есть готовая надстройка Transfer Family Parameters, которая пакетно копирует параметры из одного семейства в другое прямо в проекте. Пакетное переименование семейств, видов и листов при смене шаблона проекта, перенумерация элементов произвольных категорий с собственной логикой, экспорт и импорт спецификаций в Excel без обходных путей. Под все эти задачи в открытом доступе уже есть готовые бесплатные инструменты.
К отдельной категории относятся готовые скрипты для Dynamo, визуального no-code инструмента внутри Revit (о нем подробнее в следующем разделе), в виде пакетов нодов, которые тоже устанавливаются без единой строчки кода: Clockwork с несколькими сотнями нодов для массовых операций с элементами, archi-lab с продвинутыми геометрическими вычислениями, Rhythm для массового получения и изменения параметров. Все они ставятся через встроенный в Dynamo Package Manager, где хранится больше двух тысяч пакетов от сообщества. По сути, та же экономия усилий, что и с готовым решением, только внутри самого Dynamo.
Похожая картина складывается и на других платформах, и это стоит сказать явно тем, кто работает не в Revit. Для AutoCAD и nanoCAD существует ModPlus: набор из нескольких десятков готовых плагинов, часть которых распространяется бесплатно. Среди них: получение сведений и расчетов по сортаментам арматуры, подбор и расчет массы арматурных сеток по нормативным документам, формирование и заполнение общестроительных спецификаций, то есть именно то, с чем постоянно сталкивается КМ и КЖ раздел. Насколько это не просто описание на сайте, а реально работающий инструмент, показывает пример проектной компании «СибТехПроект»: там 63 проектировщика в повседневной работе используют 26 разных инструментов ModPlus.
Здесь стоит сказать честно: не для каждой задачи есть готовое решение. Для полноценной проверки модели на коллизии бесплатных инструментов уровня Navisworks или Solibri в открытом доступе нет: серьезные инструменты для этой задачи платные, и притворяться, что бесплатная альтернатива где-то спрятана, не стоит. Но прежде чем писать скрипт или тем более заказывать разработку, минута на поиск готового решения экономит куда больше времени, чем кажется.
Когда достаточно Dynamo
Если готового решения нет, но задача не выглядит слишком сложной, следующий шаг: Dynamo. Это визуальный инструмент, встроенный прямо в Revit: вместо кода вы собираете последовательность блоков, каждый из которых выполняет отдельное действие с моделью, и это доступно инженеру без опыта программирования.
Dynamo хорошо справляется с автоматизацией рутинных задач в Revit, если они разовые или тестовые: посчитать что-то по модели один раз, проверить гипотезу, собрать быстрый прототип автоматизации, прежде чем вкладываться в более серьезное решение. Здесь и проявляется MVP-логика в миниатюре: минимальный рабочий скрипт, который показывает, работает ли сама идея, еще до того, как речь зайдет о полноценной разработке.
Но у Dynamo есть предел, и он не в возможностях языка, а в том, что происходит, когда скрипт перестает быть разовым экспериментом. Скрипты плохо переживают обновления Revit: интерфейс и ноды меняются от версии к версии, и то, что работало вчера, может сломаться после обновления. Скрипт, написанный одним инженером, тяжело передать другому: без интерфейса и документации разобраться в чужой логике непросто, особенно если автор уже сменил проект или компанию.
Вопрос «Dynamo или плагин, что выбрать» мы уже разбирали отдельно, в статье «Dynamo или плагины», и туда стоит заглянуть за более подробным сравнением плюсов и минусов. А если вы работаете не в Revit, справедливый вопрос: есть ли у вас вообще инструмент такого уровня. Короткий, честный ответ есть в следующем разделе.
Не у всех платформ есть свой Dynamo
Короткий ответ на вопрос из предыдущего раздела: нет, не у всех платформ есть свой Dynamo.
У AutoCAD исторически есть AutoLISP, но это язык программирования, а не визуальный конструктор: чтобы что-то сделать, нужно писать код, а не собирать блоки мышью. Похожая история с Tekla Structures: официальный Tekla Open API позволяет разрабатывать полноценные приложения, плагины и макросы, но тоже требует кода на C#, а не визуальной сборки логики. Если разработка плагина для Tekla все же понадобится, готовиться стоит именно к программированию, а не к настройке готовых блоков. Открытый API nanoCAD устроен так же: это инструмент для разработчика, а не для инженера без опыта программирования, и у автоматизации nanoCAD расклад ровно тот же.
Практически это означает, что для автоматизации AutoCAD, Tekla и nanoCAD второй уровень рамки заметно тоньше, чем для Revit, а иногда его будто и нет вовсе: либо задачу закрывает готовое решение первого уровня (тот же ModPlus из предыдущего раздела), либо приходится сразу переходить к программированию, минуя средний уровень.
Есть два частичных исключения, о которых стоит знать. Для Tekla есть связка Tekla Open API с Grasshopper, визуальной средой параметрического программирования, изначально созданной для Rhino: через нее можно собирать логику для элементов модели на визуальном языке, но это сторонний инструмент, а не встроенная возможность самой Tekla. Для тех, кто работает с IFC-файлами напрямую, есть связка IfcOpenShell с BlenderBIM: бесплатная надстройка для Blender дает графический интерфейс поверх библиотеки IfcOpenShell и позволяет выполнять базовые операции с IFC-моделью без единой строчки кода.
Это не значит, что для AutoCAD, Tekla и nanoCAD после готовых решений остается только разработка плагина. Значит лишь, что путь туда короче, чем в Revit, и это лучше знать заранее, а не выяснять в середине проекта. У Tiver Group есть подтвержденный опыт разработки именно на такой, не-Revit платформе: плагин для nanoCAD, который автоматически считывает данные с чертежей и сверяет планировочные решения с нормативами, снизил количество ошибок на 85% и ускорил анализ в 3 раза. Ни Revit, ни Dynamo здесь ни при чем — ровно тот случай, когда визуального инструмента среднего уровня нет и задачу решает напрямую специализированный плагин.
Когда нужна разработка плагина на заказ
Из какой бы точки вы ни пришли, исчерпали возможности Dynamo в Revit или с самого начала работали на платформе, где подобного no-code инструмента попросту нет, дальше стоит один и тот же вопрос: как отличить задачу, которая действительно требует полноценной разработки, от той, что можно и дальше решать вручную или скриптом. Разработка плагинов на заказ, что для Revit, что для любой другой платформы, оправдана не потому, что задача кажется важной, а потому что она проходит хотя бы через один из четырех проверяемых критериев.
Первый критерий: задача завязана на постоянно меняющихся данных модели, а не на разовом снимке состояния. Если результат работы скрипта устаревает при каждом изменении проекта и его приходится пересчитывать вручную, разовый скрипт превращается в постоянную обузу, а не в решение. Именно в такой ситуации Tiver Group разрабатывала плагин для автоматизации проектирования кабельных трасс в Revit: он сам перестраивает трассы кабельных лотков, расставляет крепления и спецификации и пересчитывает нагрузки при каждом изменении проекта — и это ускорило проектирование на 60%.
Второй критерий: задача повторяется на разных проектах с разными исходными данными. Если логику приходится каждый раз частично переписывать под новый проект, вместо точечного решения нужен инструмент, который принимает разные вводные без пересборки кода.
Третий критерий: решением должны пользоваться нетехнические участники команды. Скрипт, который понимает и запускает только его автор, не масштабируется на всю команду: здесь нужен интерфейс, кнопки и понятные шаги, а не консоль и параметры командной строки.
Четвертый критерий: решение стало критичной частью рабочего процесса, а не разовым удобством. Если без него команда уже не может работать в срок, оно должно быть таким же надежным, поддерживаемым и переживающим обновления платформы, как любой другой рабочий инструмент, а не хрупкой самодельной автоматизацией, которая может сломаться в середине проекта.
Чем больше из этих четырех критериев совпадает с вашей задачей, тем меньше смысла искать более простую альтернативу. Дальше разумный вопрос: во сколько обойдется заказная разработка BIM-плагина и с чего начать, не рискуя всем бюджетом сразу. Здесь и пригождается подход MVP: о нем следующий раздел.
Как снизить риск разработки плагина
У разработки плагина, как и у любой инвестиции, есть риск: что, если решение не оправдает вложенных денег и времени, а гипотеза окажется неверной уже после того, как бюджет потрачен на полную версию? Здесь и работает подход MVP: минимальная рабочая версия плагина.
Идея простая: вместо того чтобы сразу заказывать полноценное решение со всеми функциями, интерфейсом и обработкой всех крайних случаев, сначала разрабатывается минимальная версия. Она закрывает только основной сценарий задачи, без дополнительных удобств, но уже позволяет проверить главное: работает ли сама идея на реальных данных проекта и действительно ли она экономит время и снижает число ошибок, как предполагалось.
Порог входа при таком подходе ниже, чем при заказе полной версии сразу: меньше объем работы, ниже стоимость, короче срок разработки, а значит, меньше и цена ошибки, если гипотеза не подтвердится. Если минимальная версия показывает результат, дальше можно инвестировать в полноценное решение, с интерфейсом для всей команды, обработкой особых случаев и долгосрочной поддержкой. Если результат не оправдывает ожиданий, потери ограничены стоимостью прототипа, а не полного цикла разработки.
Это меняет сам вопрос, с которого стоит начинать разговор о разработке плагина на заказ. Стоимость на этом первом шаге разумно обсуждать применительно не к финальному продукту, а именно к минимальной версии. Уже по ее результатам можно решать, стоит ли продолжать. Такой подход — не способ сэкономить на разработке в целом, а способ не платить за окончательное решение до того, как станет ясно, что оно действительно нужно именно в таком виде.
Окупаемость: считать, а не верить на слово
Даже если минимальная версия подтвердила гипотезу и решение технически работает, это еще не значит, что вложения в разработку окупятся. Работающий плагин не всегда означает выгодный: экономия времени может оказаться меньше, чем стоимость разработки и поддержки, и тогда автоматизация становится вложением без отдачи, а не выгодой.
Окупаемость бывает заметной. У Tiver Group есть плагин для разверток фасадных панелей под ЧПУ-обработку в Revit: он автоматически строит развертки и экспортирует их в форматы для ЧПУ, гибко подстраиваясь под изменение эскизов без переписывания логики — и это сократило время подготовки чертежей в 5 раз. Но такой результат не гарантирован для любой задачи: он получен там, где операция повторялась достаточно часто и на достаточно большом объеме проектов, чтобы разница окупила стоимость разработки плагина для Revit в разумный срок.
Именно поэтому перед тем, как заказывать разработку, стоит не поверить на слово, а посчитать: сколько времени сейчас уходит на задачу вручную, сколько будет стоить разработка и поддержка плагина, и через сколько проектов или месяцев экономия перекроет эти затраты. Иногда расчет показывает, что автоматизация не окупается вовсе, и это тоже честный результат расчета, а не повод стесняться отказа от разработки.
Подробный, пошаговый расчет окупаемости разобран в отдельной статье «Как не потратить месяцы на автоматизацию, которая не окупится»: если вы уже прошли предыдущие уровни рамки и оказались перед вопросом, окупится ли заказ плагина именно для вашей платформы, эта статья поможет посчитать это точнее, прежде чем подписывать техническое задание.
Что делать дальше
Расчет окупаемости из предыдущего раздела служит последним практическим фильтром перед решением. Если он сошелся, самое время вернуться от частностей к общей картине, с которой начался этот разговор. Автоматизация BIM не сводится к вопросу «делать или не делать». Это выбор одного из трех уровней: готовое бесплатное решение, визуальный no-code инструмент там, где он есть, или разработка специализированного плагина. Этот выбор работает для любой платформы, будь то Revit, AutoCAD, Tekla или nanoCAD, но, как честно показали разделы выше, не одинаково: у Revit есть Dynamo и десятки готовых решений, у остальных платформ второй уровень тоньше или отсутствует вовсе, и путь к разработке плагина там короче.
Если ваша задача прошла все уровни: готового решения нет, визуального инструмента либо не хватает, либо на вашей платформе его попросту нет, а критерии перехода к разработке совпадают и расчет окупаемости сходится, дальше разумный шаг: обратиться за разработкой плагина к тем, для кого это направление профильное.
Услуга Tiver Group «Разработка плагинов» охватывает Revit, Tekla, Civil 3D, Navisworks, Pilot, Tangl, Renga и nanoCAD, с подходом MVP там, где задача сложная и хочется сначала проверить гипотезу с низким порогом входа. Показанные в этой статье примеры относятся к Revit и nanoCAD: именно там у нас есть готовые, посчитанные результаты. Для остальных платформ из списка отдельного кейса в этой статье нет, но охват услуги распространяется и на них тоже.
Если вы дочитали до этого места и все еще думаете, что задача решается проще, вернитесь к разделу про готовые решения или к разделу про визуальные инструменты. Торопиться некуда. Но если разработка плагина на заказ, для Revit или для любой другой платформы из списка, уже не гипотеза, а понятный следующий шаг — напишите нам: обсудим задачу и решим, с чего начинать, с MVP или сразу с полной версии.
