В моей работе ввиду должности (директор организации) внутри организации коммуникация в виде инструкций чаще исходит от меня, и я стараюсь как раз максимально подробно давать коллегам контекст при постановке задач, уточнять как их интерпретировать, и часто прошу после постановки задачи уточнить их перед выполнением - что и как они планируют делать. Также я стараюсь всегда обозначать конечную цель действия, зачем нужно выполнение той или иной задачи - так как это может влиять и на внутреннюю приоретизацию среди нескольких задач, и на выбор подходящих методов, и возможно даже на конечный результат - если моё описание его всё же окажется недостаточно точным.
Отмечу здесь, что такая практика мной используется давно, и когда я был в роли руководителя проектов (в должности ГИПа), а не только на текущие роли операционного менеджера или менеджера по оргразвитию. Также давно я практикую постановку задач письменно, в связи с чем мои описания задач всегда были довольно обширными. К сожалению во многих случаях агенты-люди, читавшие эти описания, не имели достаточно собранности для прочтения и корректной интерпретации всей информации из описания задачи, всего контекста. Это иногда приводило к ситуациям когда задача всё же выполнялась неверно, так как “ну там было очень много текста, я прочитал только то что посчитал важным, а остальное увидел только сейчас, когда вы указали что это было упомянуто, и не учёл эти факторы при выполнении задачи”.
В этом смысле выполнение задач ИИ-агентами имеет огромный плюс для меня - привычка давать максимальный контекст у меня уже имеется, а ИИ-агент оказывается куда более собранным чем человек, и учитывает весь заданный контекст. Я замечаю что это приводит к получению мной более качественных, более кастомизированных ответов от LLM.
Однако, в данном задании речь об интерпретации мной сообщений извне. Для меня внешние коммуникации - это в основном переговоры с нашими заказчиками. Там действительно есть довольно много сложностей.
Часть из них связаны с тем, что коммуникацию от лица заказчика с нами осуществляют специалисты различных отраслей, и не у всех из них есть познания в строительстве - поэтому приходится уточнять что имеют в виду например представители IT-сферы, ставящие нам задачи по проектированию компьютерных сетей в новых зданиях, или например специалисты в области медицины, знающие в совершенстве технологию проведения обследований пациентов, но с трудом интерпретирующие терминологию в области архитектуры или пожарной безопасности. Осложняется коммуникация с ними тем что сроки на неё всегда сжатые, и многие по умолчанию считают что мы их должны понимать с полуслова, так как “вы же профессионалы”. Упускается из виду тот факт что они профессионалы в медицине, а мы - в строительстве, и онтологии у нас действительно разные. Тратить время на синхронизацию в начале переговоров многие считают лишним, поэтому неизбежно приходится тратить это время позднее, когда выявляется различное трактование нами и ими задач и приходится переделывать часть работы.
Вообще это частое явление - недооценка того как важно затратить некие дополнительные ресурсы в начале проекта, чтобы этим минимизировать риски необходимости куда больших затрат (и времени и денег) на корректировку его промежуточных результатов в середине или даже ближе к концу (а чем позднее выявляется ошибка тем дороже и дольше её приходится устранять). Это касается не только синхронизации онтологии, но и например ценности BIM-моделирования зданий на этапе проектирования: это стоит чуть дороже и выполняется чуть дольше, чем традиционная разработка плоских чертежей в CAD, но на позволяет получить описание будущего здания более точным и таким образом снизить число бросовых работ на этапе строительства. Однако доказать это заказчикам бывает весьма затруднительно, и в итоге каждый заказчик проходит этот путь сам, получая этот опыт на практике. Если заказчик занимается строительством зданий регулярно - он учтёт этот опыт на следующем проекте, но многие заказчики строят здания редко, лишь по производственной необходимости, и с ними получается что к следующему своему проекту через несколько лет они забывают этот опыт и идут заново по тем же граблям. Аналогичная ситуация имеет место и с синхронизацией онтологий на старте совместного проекта.
Кроме этого есть сложности в трактовке терминов и между специалистами в строительстве. Например слово “проект” употребляется часто, но не всегда из контекста одинаково очевидно обеим сторонам коммуникации, идёт ли речь про project или про design. Также термин “проектная документация” одними трактуется как совокупность описаний проектных решений, а другими - как гораздо более узкоспециалиированная сущность, конкретный набор документов на определённой стадии проектирования “проектная документация” определённой Градкодексом РФ. Такие разногласия всегда требуют разъяснения, что мы стараемся делать на уровне формальных документов - договоров и технических заданий, но не на 100% удаётся избежать недопонимания даже несмотря на эти усилия.
Эту проблему могло бы решить создание общепринятой (т.е. разделяемой всеми) онтологии предметной области (в идеале - строительства, ну или хотя бы в области строительного проектирования для начала). И попыток создания таких онтологий предпринималось немало, однако пока ни одна онтология не заняла это место - в силу бюрократических сложностей и недостаточного профессионального “веса” разработчиков каждой её версии в профсообществе. Можно сказать, в терминах данного руководства, что эпистемиологический статус всех этих онтологий в глазах большинства специалистов отрасли недостаточно высок для всеобщего их признания.
Примеры этих онтологий:
-
термины из Градкодекса и Постановления Правительства РФ № 87 (их там крайне мало и связи между ними описаны недостаточно, поэтому такую онтологию нельзя признать полной),
-
ГОСТ Р ИСО 6707-1-2020 “Здания и сооружения. Общие термины” (количество терминов здесь больше, но вопрос их взаимосвязи также решён недостаточно полно, часть определений отличается от Градкодекса который имеет более высоки нормативный статус - поэтому данный ГОСТ применяется лишь справочно)
-
Классификатор строительной информации, который ведёт подведомственное Минстрою РФ учреждение и объединяющий в себе 21 таблицу, часть из которых связаны друг с другом а часть - нет. В этом классификаторе есть хорошая схема, показывающая верхнеуровневые взаимосвязи между типами (и определены эти типы). Это попытка объединить в одном документе несколько различных классификаций, чтобы создать исчерпывающее количество классов для строительных элементов. К сожалению большая часть позиций этого классификатора пустая так как не имеет физического смысла (в силу принятой разработчиками организации), а часть позиций имеют физический смысл но не имеют практического приложения (как например “предметы приводимые в движение рукой” или “предметы нагреваемые жидкостью”). В итоге классификатор пока сложно применим практически, ну и как онтологию его использовать тоже не получается
-
Industrial Foudation Classes, разарабатываемые международным консорциумом BuildingSmart - как следует из названия, это тоже в первую очередь классификатор, а не онтология, хотя и имеются статьи о потенциале этого классификатора в онтологическом смысле, но для онтологии он тоже недостаточен (как и ряд других классификаторов - COBiE, Omniclass, Uniclass, Coclass и т.п.). Обилие таких устоявшихся для применения в разных странах и отраслях промышленного строительства классификаторов - ещё одна причина, по которой профсообществу трудно создать общепризнанную онтологию: она в любом случае будет не соответствовать какому-то из традиционных классификаторов, поэтому, как например в ситуации с единым стандартом на электрические розетки, понимание его полезности есть у всех, но договориться какой выбрать - не получается.
-
также попытки разработки ведут специалисты из компаний NSR Specification (Nanosoft, Россия), Института системного программирования РАН и ряда других. Хочется верить что рано или поздно договориться всё же удастся.
Возвращаясь к теме задания, кроме онтологических проблем в нашей коммуникации с заказчиками и например государственными институциями есть сложности и эпистемологического, и прагматического характера. Например, подавая уже в третий раз комплект документов для оформления разрешения на строительство, мы получаем уже третий комплект чисто формальных замечаний к документации - здесь не хватает справки, здесь справку исключить, здесь округлить до сотых, а здесь до десятых, или и вовсе текст вида “документация не соответствует постановлению Комитета по градостроительству и архитектуре Санкт-Петербурга №545” без указания в чём именно выражено несоответствие. Эпистемологический статус этого сообщения, с учётом того что замечания уже все отработаны и это третья подряд подача, мы можем принять как довольно низкий, и прагматически это сообщение означает совсем не то что в нём написано. Прагматика его звучит так: “Пока вы не поручите разработать архитектурно-градостроительное обоснование вашего объекта архитектурной мастерской из списка “одобренных” для таких работ организаций, мы будем писать вам формальные отказы, и вы с вашим заказчиком будете терять время и деньги. Заплатите один раз нужным людям и стройте свой склад спокойно”.
Также спорные эпистемологические статусы могут иметь сообщения от агентов, которые формально находятся в проектных ролях руководителей проекта или иных специалистов со стороны заказчика, а практически играют другие, более важные для них роли карьеристов, и соответственно их предметы интереса или по крайней мере предпочтения в этих других ролях отличаются от предпочтений проектных ролей. Например в интересах проектной роли может быть скорейшее согласование документации по проекту для начала строительства, а для роли карьериста агент может посчитать более важным найти силами подрядчика (то есть нашими) способ построить то же здание дешевле, чтобы потом показать экономию как своё достижение и получить продвижение по службе - и такие поиски могут затягиваться и в итоге вся прибыль от экономии будет съедена убытком от смещения сроков. Но такой убыток прячется (тем более “сроки сорвал подрядчик”), а копеечная экономия на проектных решениях подаётся как достижение РП и выпячивается. Действия контрагентов в таких неявных ролях требуют их выявления и привлечения к коммуникации большего числа агентов со стороны заказчика, что не всегда возможно - поэтому иногда приходится действовать и для удовлетворения таких ролевых интересов. Соответственно прагматика коммуникаций с таким руководителем проекта требует более длительного её выявления, так как он будет говорить одно, а иметь в виду другое - и это нужно уметь распознать.
В общем, затронутые в данном разделе руководства проблемы действительно имеют место в моей работе и работе моих коллег. Уточнение языка для их описания - полезно, так что этот раздел был мной изучен не зря, и знания будут обязательно применены в дальнейшей работе.