вторник, 14 сентября 2010 г.

UserNONfriendly process - боремся с bim'ами-pt.2

Теперь об участниках проекта - тех, кто непосредственно выполняет проект. Пост будет не очень красочным - просто сообщу о некоторых своих наблюдениях - о том, как UserNONfriendly process в среде bim-приложения сделать Userfriendly.
На мое практике набор команды с нуля под проект случался редко, если не сказать, что вообще не случался. Одним словом, планирование и технологический процесс проектирования в bim-приложении пока у меня не отработаны.
Пост, конечно, получается нудноватым - но что делать.



Ниже представлю схему - в данном случае простейшего майндмэпа, которой я пользуюсь при начале нового проекта с использованием bim'а.
Определение навыков - важный этап планирования. Тут обычно я пытаюсь определить существующие навыки участника и потенциальные, которые можно развить в ходе проекта. Так, если участник хорошо моделирует сложные объекты и есть навыки скриптинга - в ArchiCAD это можно использовать при создании библиотек объектов. Специалист с широким профилем может быть направлен на организацию информационной модели и создание основных элементов здания, а также создание шаблона работы с моделью; также он может выполнять функции лидера. Узкопрофильного спеца можно "посадить" разрабатывать узлы или формировать ведомости элементов. 
Роль в команде - выношу в отдельный пункт. Хорошо, когда все полноценные игроки и каждый - мастер на все руки. Но не в этом случае. Мое видение - небольшая субординация и распределение обязанностей не помешают. Выявляем лидера - пусть он будет ответственным за результат, проверяет саму архитектуру, конструкции и тп. Исполнители делают то, что лучше всего умеют. Поддержка - это может быть и тот самый специалист широкого профиля, а может быть приглашенный консультант по техническим вопросам. Технически неясных моментов много при использовании bim-приложения и все они зачастую не связаны с результатом - архитектурой. Пример поддержки -  создание GDL-объекта в ArchiCAD требует некоторые навыки программирования; для конкретных требований (создание символов электрики или элементов меблировки) необходим опыт решения таких задач(иначе закопаться в скриптинге можно надолго). Приглашается консультант - и такой нашелся - ставится задача, предоставляется решение, консультант получает деньги. Все довольны.
Заинтересованность в проекте - этот пункт может вызвать сомнение у некоторых, но для себя считаю его крайне важным. Именно здесь кроется успех проекта, его сроки, наработка опыта. При высокой заинтересованности (таковая должна быть у лидера команды) человек лишь нуждается в небольшой поддержке, "обратной связи" - совещания, комментарии, оценка и т.п. При низкой заинтересованности - понятно, что здесь надо прилагать усилия для ее повышения. Вы скажете - увольняем такого сотрудника. А если в других проектах он проявляет себя очень активно(например, в "выкашивании" чертежей в AutoCAD или быстром моделировании в SketchUp). В таком случае я стараюсь найти тот аспект bim-приложения, который может заинтересовать участника и тем самым превратить интерес в полезный для команды навык. Пример - оформление альбома в AutoCAD несравнимо многодельнее, чем в ArchiCAD. Здесь показываем участнику преимущество, заостряем на нем внимание и стараемся показать участнику его возросшую ценность в команде.
PS.
Безусловно, внедрение более сложного приложения, да еще со своими особенностями, вызывает стресс у участников проекта. Bim-приложения, на мой взгляд, не достаточно оптимизированы для сложных интерьерных проектов. И несмотря на это я использую ArchiCAD(а кто-то - Revit или Vectorworks) в своих проектах, пытаясь найти те плюсы и минусы, которые предлагает нам эпоха иноформационного моделирования. Посмотрим, что получится.


Комментариев нет:

Отправить комментарий