Привет, Хабр! На связи руководитель отдела внедрения по технологиям информационного моделирования в ПИК Полина Павлова.
Сегодня я расскажу о том, как появились наши цифровые продукты и как они связаны между собой.
Начало работы и создание первых инструментов
ПИК начал формировать продуктовую модель в Дирекции автоматизации проектного блока в 2018 году. В тот период времени компания основательно занялась переходом в BIM-проектирование (о том, что такое BIM можно узнать в ранее выпущенной статье «House Flipper в реальной архитектуре: как специалисты проектируют что угодно в цифровом симуляторе»).
В то время лидером рынка ПО для проектирования был производитель Autodesk. В начале 2000-х Autodesk приобрел программное обеспечение Revit, которым до сих пор пользуются проектировщики из самых разных компаний для быстрого и удобного моделирования своих разделов с последующим оформлением и формированием комплектов согласно ГОСТам, применяемым в проектировании.
Если смотреть со стороны автоматизации — Revit использовался неслучайно. За счет достаточно проработанной инфраструктуры, качественного открытого API, а также постоянного обновления со стороны разработчиков инструмент давал большой потенциал к автоматизации процессов проектирования.
У ПИК был и остаётся свой большой штат проектировщиков, дополненный огромной командой подрядчиков и аутстафферов. Для дальнейшего упрощения работы с большим количеством потребителей команда дирекции провела реструктуризацию, выделив при этом отдельных специалистов, которые занимались бы задачами развития новых технологий в проектном блоке (о том, какие могут быть сценарии формирования структур в BIM-командах, можно почитать в нашей статье «Правила построения BIM-команды»).
Создание новых инструментов: Family Manager, BIM Inspector и PikTools
В начале 2020-х в ПИК начала формироваться отдельная команда единомышленников. На самом старте работ с цифровыми моделями команда сформировала для себя стратегическую цель — обеспечить машиночитаемые требования для возможности дальнейшей их обработки различными потребителями.
Первым шагом к реализации стала задача — сделать базу данных для централизации решений по компонентам цифровой модели. Наличие такой базы давало толчок к управляемости процессов: контроль входных элементов в базу, возможность систематизации и структуризации этих элементов и, конечно же, банальное удобство работы пользователей.
Решением такой задачи стало формирование инструмента с забавным названием Family Manager. При чем тут семья? Да, всё просто: компоненты цифровой модели в Revit называются «Семейства». Изначально сам инструмент был интегрирован в Revit как надстройка, но спустя пару лет Family Manager (далее по тексту FM) преобразовался в целый самостоятельный продукт, который по задумке сформированной цели и стал являться ядром нашей платформы.
Чуть позже, почти параллельно с разработкой FM, другая команда ПИК стала работать над следующей задачей. Помимо наличия стандартизированной библиотеки элементов нам был необходим инструмент, позволяющий контролировать и анализировать состояние моделей, разрабатываемых проектировщиками. Таким образом, у нас появился цифровой продукт под названием BIM Inspector. Название также появилось достаточно просто: BIM — основа нашей цифровой среды, Inspector — понятно без комментариев. В свое время у руководителя данного продукта даже появилась шуточная шляпа полицейского.
Изначально BIM Inspector по аналогии с FM представлял из себя простую надстройку в Revit, где на её основе пользователь мог проверить корректность наименования файла, координаты моделей или же принять во внимание информацию, что нормативное количество элементов не совпадает с фактическим количеством, расположенным в модели. Со временем росло количество инспекций, повышались требования к скорости и качеству проверок. Сейчас инструмент вырос в самостоятельный продукт с отдельными расчётными серверами (фермами), позволяющими проверить огромное количество моделей, предоставить по ним отчёт и сделать всё это без вовлечения специалиста.
Казалось бы, описанные выше продукты закрывали два достаточно важных блока: подать на вход корректные данные, а после проверить на выходе, чтобы применение этих данных не было искажено в модели. Но без внимания не могла остаться ещё одна важная часть проектирования. Проектировщику, на самом деле, важнее всего скорость проектирования. Да, качество не должно хромать и снижаться, но при всех раскладах проектировщику всегда проще в начале быстро закрыть задачу, а потом уже проверять результат.
Поэтому на протяжении всего времени часть коллектива трудилась над созданием инструментов автоматизации. Это те самые чудесные кнопки в панели Revit, которые помогают пользователю сделать рутинную операцию за пару кликов. В первое время структура всех этих инструментов готовилась и формировалась разрозненно (всю «подкапотную» информацию лучше почитать подробнее в статье «Через тернии к ReactiveBim»).
Так ребята делали чудесные кнопки, каждый программист со своей «изюминкой». Команда росла, росло количество разработчиков, инструментов. В один прекрасный момент поняли, что такой подход уже нецелесообразен. Перешли к формированию собственного фреймворка ReactiveBIM, в котором появилась понятная и чёткая структура, общие правила, а также единый подход, позволяющий любому специалисту быстро погрузиться в разработку плагинов для автоматизации BIM-моделирования. Это и стало началом формирования продукта PikTools (в пер. с англ. «инструменты ПИК»).
В процессе роста инструмента всегда появляется потребность интеграции его с другими продуктами. Таким образом, PikTools начал забирать из FM информацию для отработки алгоритма (например, в код добавили правило, что инструмент сам забирает элементы из FM для их дальнейшей расстановки в модели). При взаимодействии с BIM Inspector стало понятно, что необходимо формировать общие алгоритмы, а также проверять пользователя на верную последовательность использования кнопок.
Подведём первичные итоги. В структуре ПИК практически параллельно разрабатывались три продукта: Family Manager, BIM Inspector и PikTools. Первый даёт базу с нужными компонентами для цифрового проектирования, второй проверяет модели на «чистописание», а третий помогает пользователю совершать рутинные операции быстрее. Кажется, основные зоны закрыты. Но, как говорится, нет предела совершенству.
Другие инструменты: «Робот», BIM Data Service и PIK СheckUP
Ещё один из продуктов, достойных внимания — «Робот», или R2, как мы ещё его называем. Всё, как и с другими инструментами, зародилось с проблемы, которая стояла перед командой. Где-то в 2017 году активисты команды анализировали и смотрели решения на рынке, которые позволяли бы комплексно роботизировать процессы, начиная с этапа «Предпроект» и заканчивая выпуском рабочей документации. Поняв, что пока эта ниша не занята, стали формировать команду под идею.
Первым делом команда сконцентрировала внимание на работе с мастер-планом и уже на этом этапе немного снизила планку, решив, что не весь процесс работы нужно убирать в алгоритм. Что нужны реперные точки, где человек будет смотреть и оценивать результат. Начали с расчета инсоляции, и дело пошло достаточно плодотворно. О всей истории развития «Робота» обязательно расскажем в отдельных статьях.
Здесь же хочется отметить, что продукт «Робот» включает в себя комплексный набор инструментов, таких, как:
генерация функционального зонирования и массинга;
генерация колористики фасадов;
градостроительный робот;
колористика;
видобот (схемы видов из окна) и многое другое.
«Робот» со временем подружился с другими нашими продуктами. Например, сейчас «Робот» может брать из базы FM типовые секции и башни для стадии предпроекта и проекта. Также «Робот» может конвертировать данные из своей базы в Autocad Civil, из Revit обратно в «Робот» и наоборот через функции продукта PikTools.
Также хотелось бы поделиться рассказом ещё об одном инструменте, перешедшем в стадию зрелого продукта — BIM Data Service. Идея хранения «BIM данных» заключалась в том, что на стороне заказчика есть большое количество подразделений, готовых использовать данные из модели. Но основная их часть — это разработчики, которые совершенно не знакомы с особенностями программы Revit. Конечно же, первым делом мы задумались о поиске подходящих специалистов на рынке, но очень узкий профиль таких специалистов просто не позволил бы закрыть потребность в кадрах.
Так и была сформирована внутренняя база данных BIM Data Service, которая открыла возможность работы с информацией из моделей аналитикам, разработчикам и любым другим специалистам.
Если кратко, то текущий продукт состоит из двух крупных частей: структура объекта и контент. Контент зашит в MongoDB, а для структуры используется PostgreSQL. Изначально планировалось, что сервисом будут пользоваться в основном разработчики, которые знают, как обращаться с базой. Но со временем команда продукта поняла, что зона потребления данными расширяется, в результате чего возник запрос на формирование интерфейса пользователя, с которым команда также справилась.
И последний продукт, о котором хотелось бы рассказать в текущей обзорной статье — это PIK СheckUP. Этот инструмент был разработан для того, чтобы получить нулевую толерантность коллизий (пространственных пересечений между элементами модели).
Специалисты понимали, что невозможно слишком часто привлекать проектировщиков в процесс работы и в связи с этим стали развивать облачные сервисы конвертации моделей. Основным инструментом для проверки коллизий стала программа Autodesk Navisworks. В ней было всё необходимое, оставалось только подготовить модели и настроить поверки.
На текущий момент PIK CheckUP является продуктом, который включает в себя:
инструмент облачной конвертации моделей из формата .rvt в .nwc;
настройки для Navisworks, которые упрощают процедуру настроек проверок;
интерфейс для BIM-специалиста, где можно узнать о статусе и результатах проверки в более развернутом формате.
Название продукта выбрано не просто так. В медицине термин Check-up относится к регулярной проверке здоровья малыми усилиями, но заранее для преодотвращения больших последствий. Таким образом, и в нашем продукте была заложена идеология предотвращения больших проблем на стройке путем предоставления инструмента проектировщику, позволяющего следить за состоянием здоровья своей модели.
Итоги
Надо сказать, что в компании ПИК за последние 6 лет действительно образовалась собственная экосистема из разработанных продуктов. Все продукты изначально были созданы под свои точечные нужды, но со временем их коллаборация стала давать большую эффективность для работы проектировщиков. Ниже приведена схема, где можно ознакомиться с тем, как наши продукты связаны друг с другом. Об особенностях каждого из них обязательно расскажем в следующих наших статьях.
Какие выводы мы сделали, работая над нашей экосистемой:
Понимание стратегии. При выборе подхода все члены команды должны знать о конечной цели и, разрабатывая свои продукты, постоянно ориентироваться на неё. Таким образом, интеграция инструментов в экосистему будет максимально лёгкой.
Приоритет на эффективность. Важно проанализировать, какие этапы работ могут быть оптимизированы, чтобы облегчить процесс работы и выдать результат с минимальными трудозатратами. Также важно не только смотреть на конечную цифру получаемого эффекта, но и оценивать свои трудозатраты, которые требуются для разработки продукта и последующего его поддержания.
Обратная связь от пользователей. Нужно регулярно собирать и анализировать обратную связь от конечных пользователей. Это помогает выявлять новые потребности и улучшает существующий функционал как одного инструмента, так и системы в целом.
Обучение и поддержка. Огромное значение имеет обеспечение пользователей доступом к образовательным ресурсам и технической поддержке. Это необходимо для более эффективного использования инструментов и повышения квалификации пользователей в работе с разработанными продуктами, так как при разработке целой экосистемы продукты наполняются порой сложными на первый взгляд функциями.
Оценка рынка. Стоит следить за тенденциями в области разрабатываемого продукта. Это поможет адаптировать продукты к меняющимся требованиям рынка и оставаться конкурентоспособными. Никому не нужен дорогой инструмент, не дающий эффекта конечному покупателю.
Разработка интерфейсов. Важно развивать удобные интерфейсы для всех продуктов, чтобы упростить работу с ними для пользователей, не обладающих техническими навыками. Развитие интерфейса должно быть общим для всех продуктов системы. Таким образом легко можно будет перейти с продукта на продукт.
Гибкость и адаптивность. Целая экосистема требует большого количества ресурсов для её поддержания, так как в ней заложено огромное количество связей. Необходимо стараться выстраивать систему таким образом, чтобы быть открытыми к изменениям в продуктовой линейке и быстро реагировать на новые вызовы и возможности в отрасли.
Углубление интеграции продуктов. Постоянное развитие интеграции между инструментами даст максимальную производительность от использования данных и функционала каждого продукта. Но стоит помнить, что укрепление связей может ограничивать продукт как самостоятельное звено.
Возможно, эти советы помогут кому-то более грамотно выстроить следующие шаги в построении своей экосистема. Мы, в свою очередь, обязательно будем делиться с вами теми вызовами, которые встречали наши продукты на этапе своего развития.
Будем на связи. До скорых встреч!
