Целеполагание
Ответная статья, ведь не всегда не прав только Проектировщик, но и к Заказчику есть вопросы:)
Пишу, как на основе своих ошибок в роли Заказчика, общего кругозора, так и ваших комментариев, спасибо всем за обратную связь!
Давайте проговорим про:
- Требования Заказчика и их обоснованность;
- Про то, что должен предоставить BIM-отдел Заказчика Проектировщику и должен ли;
- Про выгрузки и проверки модели;
- Про самого Заказчика, ведь это тоже человек, значит, в его поступках есть или полностью отсутствует логика (не исключено).
Самое главное в любых взаимоотношениях (как деловых, так и личных) — это налаживание коммуникации Заказчик-Подрядчик
На мой взгляд, согласовывать допущения на старте проекта Проектировщику в зависимости от текущих условий — нормально и нужно, чтобы реализовать по принципу СКР "Сроки—Качество—Ресурсы".
Представим, что :
- Мы- ответственные Проектировщики, которые прочитали весь EIR, уточнили, нет ли к нему Приложений, и ознакомились с библиотекой Заказчика (при наличии);
- Все вопросы поднимаются своевременно, до начала реализации того или иного, а не постфактум;
С какими же проблемами может столкнуться Проектировщик, и как выйти из ситуации с наименьшими потерями (и можно ли быть в плюсе)?
1. Слишком консервативный Заказчик
Ситуация, когда Заказчик уперся и не согласовывает методологии формирования проектной документации, потому что сподвигают (да, да от слова "ПОДВИГ") его изменить подход к выгрузкам объемов.
Заказчик должен быть гибким, если цель оправдывает средства: избежание срыва сроков, сохранение партнерских отношений, экономия ресурсов, увеличение производительности...
Например, Проектировщик хотел согласовать использование несистемных инструментов для моделирования гипрочных зашивок (горизонтальные стены и вертикальные "крышки"). Т.е. по EIR это должны были быть стена + перекрытие. У него же 1 параметрическое семейство с кучей плюшек, повышающих скорость проектирования. В данном случае мой ответ был положительным, поскольку Проектировщик учёл требования по выгрузкам: доделал семейство так, чтобы все показатели рассчитывались корректно.
Мне кажется, почти в любой ситуации можно найти компромисс, если потратить чуть больше времени вначале, заранее все обсудить (когда ещё не всё горит, а лишь часть) и предложить несколько вариантов Заказчику. Он, со своей стороны, рассчитывает каждый вариант, в случае, если все будут неподходящими, даёт рекомендацию, какие инструменты, неописанные в EIR, также могут подойти для этой цели без проблем обработки информации. Если Проектировщик может использовать данное решение, редактируются/дополняются требования, если нет-итерация повторяется.
Мой взгляд на процесс согласования методологий отражен на рис. 1-2.
2. Когда LOD 200 (ст. ПД) у Заказчика подразумевает наличие всех отверстий
Или: «Хочу вот это, вот это и ещё это здесь и сейчас.»
Чтобы разговаривать на одном языке с Заказчиком нужны численные показатели. Сделать-то всё можно, вопрос в целесообразности, наличия ресурсов:
- Покажите, насколько увеличатся сроки и стоимость договора, например, если вы в модели реализуете отверстия на стадии ПД (LOD 200) и увяжитесь со смежниками;
- Обозначьте, какие трудозатраты/квалификация персонала нужны для расчета кабеля в Revit;
- Расскажите про целесообразность армирования в 3д, опираясь на факт, что она не участвует в выгрузках объемов, а также в проверках на пересечения.
и т.д...
Если Заказчика устраивают ваши предложения на старте проекта, все остаются в плюсе. Если нет, то хотя бы Заказчик понимает, чего ожидать, чего- нет; а Проектировщику ясен фронт работ.
3. Когда Заказчик направил замечания по модели, а ты уже произвел 10 итераций обмена заданиями
Как Проектировщик обязан направить документацию в срок, так и Заказчик должен соблюдать обязательства: выдавать ТЗ на старте проекта, замечания в установленный срок после получения документации/модели. Наверное, это сложнее всего регулируется, но по второму вопросу я прописываю в Регламенте 3-7 рабочих дней в зависимости от отклонений от графика проектирования и строительства.
Более неприятная ситуация, когда документация согласована, а модель - в подвешенном состоянии. Что тут сделать- я не знаю.
4. Когда у вас первая промежуточная выгрузка, а в замечаниях: "Не заполнены параметры по EIR"
Зачастую Заказчик требует направлять рабочие модели, к примеру, 1р./2нед. При этом он выборочно осуществляет промежуточную проверку на соблюдение EIR. И это, скажу я вам, довольно сильно пугает Проектировщиков, ведь модель рабочая, и это нормально, что часть параметров по EIR не заполнена, к примеру, да даже затесавшиеся непроектные элементы...)
Цель промежуточной проверки: убедиться, что все друг друга поняли, нет несогласованных отступлений от EIR, пока не поздно.
Лично я, чтобы снять напряжение, ввела статусы замечаний, которые показывают их значимость и определяют последовательность отработки. Подробнее в статье "Реестр Замечаний".
5. Вечер пятницы и рассылка от Заказчика: "Новая версия EIR 11111"
Поскольку у Заказчика только начинают формироваться BIM-отделы, происходит анализ текущих бизнес-процессов, что ведет к корректировке существующих методологий по отдельным задачам, или вовсе меняется специфика всего отдела.
Например, в моей компании, ЛенРусСтой, идёт разработка пилотного проекта в Revit, а также справочника видов работ, меняется подход к формированию бюджетов, а за этим следуют проблемы из-за изменения EIR в середине/конце проекта:
- Пересмотр категорий моделирования;
- Изменение/появление кодов по классификатору в конце проекта.
В данном моменте Проектировщик также играет ключевую роль, помогая Заказчику, делая запросы на новые коды по классификатору, к примеру.
6. Утро понедельника и рассылка от Заказчика: по всем вопросам проекта обращаться к новому сотруднику Х
Это про то, когда сменились ответственные лица на проекте, и Проектировщик получил новый список замечаний, или, ещё хуже, новый EIR с другой логикой.
Почему так происходит? В компании нет четкого регламента по проверкам модели от А до Я. Мне кажется, это обязательный документ, позволяющий:
- Систематизировать работу отдела;
- Повысить квалификацию коллег;
- Быть независимым от изменений в коллективе.
Что делать Проектировщику?
Смириться или самостоятельно предусмотреть подробные автоматические проверки по EIR и собственному опыту проектированию (из серии: чтобы не придраться). И стремиться, опять же, свести к тому, чтобы делать минимум телодвижений, получая отчет чуть ли не каждый день (в условиях плотной работы). Иначе это затея слабо реализуема, ведь Заказчик в первую очередь смотрит на сроки.
Сейчас всё больше специалистов начинают использовать визуальные средства для аналитики процессов. Много полезной информации можно найти на ТГ канале BIM-лидера Геннадия Дрягина. Ещё рекомендую статьи Евгения Тесёлкина (мне без опыта работы с дашбордами и базами данных сложно даётся материал, но разобраться можно).
7.1 Когда исправил все коллизии, но Заказчик каким-то образом нашёл ещё
Моя политика такова: в идеальном мире Заказчик разрабатывает библиотеку семейств, скриптов по заполнению параметров согласно EIR, а также настройки для проверок:
- и т.д. при использовании других инструментов.
Проверил на коллизии, убедился, что всё исправлено, выгрузил модели и направил Заказчику.
7.2 Когда у Заказчика и Проектировщика разные наборы проверок в Navisworks
Пожалуй, выделю в отдельный пункт, очень часто сталкиваюсь с данной проблемой. Почему же она возникает? Всё просто, у всех разные интересны.
Проектировщику при реализации проверок важны читабельность отчета о пересечениях и уверенность в том, что, отработав коллизии, Заказчик примет модель с первой итерации.
Проверки должны быть максимально детализированными, чтобы потом вручную не группировать конфликты. И чтобы гарантировать положительное решение Заказчика по приёмке модели, Проектировщики хотят унифицировать матрицы, предлагая свои наборы проверок.
А Заказчику, опять же, важны цифры: сколько коллизии, какой объем погрешности они дают при выгрузке объемов?
Получается, детализация проверок для него избыточна. Второй момент, кстати говоря, удобно отследить в Larix (модуль проверки на пересечения).
Пример:
- Заказчику достаточна проверка АР-АР;
- Проектировщик же хочет сразу увидеть перечень пересечений стена-стена, стена-пол и т.д. по отдельности для удобства отработки. И вот одна проверка АР-АР разбивается ещё на несколько.
Однажды мне прислали матрицу на 50 +- строк. А порядок моей матрицы был где-то около 15 :)
Да, впоследствии, она была расширена, но не более чем до 20)
А сколько у вас строк в матрице?)
8. Когда Заказчику нужно всё в Revit, а он даже объемы из модели не выгружает
Здесь, я, пожалуй, тоже не знаю, чем помочь, кроме как устроить конструктивные переговоры (работает не всегда):
- Обсудить цели Заказчика;
- Помочь с написанием Требований под эти цели.
9. Когда Заказчик предоставил скрипты, а инструкций нет
Звучит классно, да? Заказчик предоставляет скрипты. Но это лишь означает, что у него очень много требований, и он заинтересован упростить задачу, чтобы не увеличивать стоимость договора/сроки и т.д.
Так вот, получаете вы скрипт, например, по заполнению параметров ТЭП. Делаете зоны, моделируете формы, заполняете минимально необходимые параметры, запускает скрипт, и начинается процесс завершён, "но с предупреждениями"...И далее начинаются танцы с бубнами.
А оказывается: проблема, к примеру, была в том, что формы нужно было моделировать в сборке, а зоны в моделях АР. Есть и свои плюсы того, что Проектировщик сам разбирался: нашёл недочеты скрипта, которые не влияли на его отработку, но тем не менее требовали исправления.
Практика показывает, что только каждый 10-ый Генпроектировщик заинтересован в совместной работе с Заказчиком, позволяющей достичь бОльшего.
10. Когда Заказчик регламентирует наименование видов
Тут важен больше скорее не сам факт регламентации видов, а отсутствие подосновы в тех или иных требованиях.
Например, очень часто бодаются за наименование уровней. А ведь по сути, наименование уровня никак не влияет на постобработку информации Заказчиком, главное, чтобы у уровня был заполнен параметр "Этаж" -остальное вторично. А вот, если Заказчик предоставляет скрипт по заполнению данного параметра, и для его отработки важно однозначное наименование, сразу появляется смысл в требованиях.
Ну и насчёт видов, разве это страшно, что будет черновой вид с постфиксом дублирования"01", "02"- ей Богу, ну и ладно.
Знаете, я, пожалуй, ещё кое-что вспомнила.
11. Когда выгружаешь модели нескольких кварталов Заказчику через файлообменник
Очень больно и бесполезно.
Повторюсь, Заказчик должен быть гибким и это в его же интересах.
СОД должна быть функциональна. Вполне реалистичный и простой способ: сервера Заказчика позволяет осуществлять автоматические выгрузки моделей без участия BIM-специалиста. Да, даже просто взять и настроить планировщик с периодичностью каждый понедельник раз в две недели- и минус головная боль.
Что делать, если у вас закрытое предприятие, нет доступа к личным облаках, есть централизованный файлообменник, с которым разрешено работать только одному человеку из отдела? Забыть про него, и внедрять современную среду общих данных, средства электронного документооборота. Например, Pilot BIM :) Что бы вы посоветовали?)
Заключение
Как-то много слов получилось, похоже мне действительно нравится писать статьи..и на минутку сейчас 0:17, второй день моего отпуска, и один из моих планов- это выпуск статьи в понедельник утром) ну ладно, вечером)
Подытожу так:
Давайте жить дружно, взаимодействовать, обсуждать, договариваться и упрощать там, где это возможно!)
