Понятийное наведение внимания: контроль типов
Когда вы нашли информацию и у вас появились идеи, вы начнёте их описывать. Первые версии описаний будут отличаться от последующих: вы будете использовать ассоциативное наведение внимания и выписывать идеи, которые пришли в голову, «выгружать из головы». И это правильно: если вы сразу будете пытаться сделать идеально, то вы никогда не придумаете решение.
Вы будете как-нибудь выделять объекты внимания и пытаться как-то связать их между собой. Никакого чёткого контроля типов, то есть, онтологической проверки правильности присвоения типа, здесь обычно нет (если только вы не обладаете хорошим онтологическим мастерством). Более того, если вы попытаетесь включить его сразу, то скорость появления первой версии модели резко упадёт: контроль типов выполняется с задействованием медленного мышления S2. Вы рискуете надолго задержаться.
Поэтому обычно делается так: выдаётся первая версия модели. Она описывается (лучше всего – при помощи мышления письмом/моделированием), затем её критикуют: сначала сам создатель описания, а потом – заказчики, адресаты и другие потенциальные интересанты. В ходе критики уместно включить контроль типов и проверить, нет ли в модели (представленной текстом, таблицей, диаграммой или ещё как-нибудь) явных ошибок. Например, если вы смотрите на схему, нарисованную вашими сотрудниками, вы можете сказать, объекты какого класса указаны на ней? Допустим, на схеме коммуникации в команде вы перечисляете роли, исполняемые сотрудниками. И вот внезапно вместо одной из ролей у вас появляется имя сотрудника (Phillipe в правом нижнем углу) – это явная ошибка в контроле типов:
Кроме того, можно покритиковать и другие выборы названий, например, Integration (название функции) вместо Integrators (название роли). Но такая критика часто имеет смысл после того, как собрана первая версия модели, например, получена схема как на картинке выше.
Онтологическая критика вашей модели подскажет вам, объекты каких типов пропущены или указаны неправильно. Далее надо будет не пропустить этот сигнал: если у вас где-то провален контроль типов, то именно в этом месте чаще всего не удерживается внимание, нет нормального языка описания, всё мутно и непонятно. Поиск и моделирование вот таких мутных мест даст вам идеи по поводу того, куда двигаться. Далее вы можете проводить всё более детальное моделирование (приближать камеры вашего внимания), сужая область ваших поисков. Примерно так же сужают область поисков, когда ищут потерпевший бедствие корабль или упавший в воду самолет.
При включении понятийного внимания и контроля типов могут возникать проблемы – по самым разным причинам. Одна из них – вы и/или ваши сотрудники вообще не проводят контроль типов. Контроль типов, в свою очередь, тоже может отсутствовать по разным причинам: например, потому что ваши сотрудники не знают, что это такое, и не владеют мастерством моделирования. В ходе сессий рабочего развития вы ликвидируете этот пробел. Менее очевидная, но не менее частая причина провалов в контроле типов (и дальнейших проблем с использованием описаний) в том, что вы не понимаете, каким языком или языком какого класса описываете модель «из головы».
Языки, как вы уже знаете, бывают разные. Нас во время стажировки интересуют языки профессиональные – языки общения разных предметных областей, на которых общаются исполнители разных ролей. Например, язык разработчика, бухгалтера, менеджера/управленца, маркетолога, врача и так далее. Такие языки по шкале формальности языков сдвинуты в сторону бОльшей формальности, хотя и не являются очень строгими:
Тем не менее, в жизни вы столкнётесь с тремя другими классами языков. В первую очередь это художественный язык, с которым вы в детстве знакомились на уроках русского языка и литературы. Некоторые из понятий, которыми мы пользуемся сейчас, например, понятия омонимов и синонимов, вы изучали именно на примерах из художественной литературы, написанной художественным языком. Такой язык красочен, образен, очень хорошо воздействует на эмоции. Описания, написанные или переданные таким языком (не важно, текстом или в другой форме), часто надо толковать не прямо, а косвенно. Например, если вы увидите картинку женской фигуры с повязкой на глазах и весами в руках, вы на автомате расшифруете её как отсылку к справедливости или справедливому суду[1]. В художественных текстах зачастую не один смысл, а несколько, и до них надо добраться, попытаться вычислить, что имел в виду автор. Причём разные читатели могут найти для себя в тексте разный смысл!
На другом конце шкалы – строгие, формальные языки вроде математического. При использовании такого языка у вас плотное концептуальное пространство и, соответственно, мало возможностей для двойных толкований: 2 + 3 = 5. Знаки «плюс» и «равно» и цифры одинаково толкуются всеми, кто пользуется математическим языком. В этом смысле они противоположны художественному языку.
Однако чаще всего мы употребляем слова/знаки не художественного и не строго формального языков, а других, находящихся ближе к середине шкалы: бытового и профессионального языков. Бытовой язык чуть менее иносказательный и красочный, его легче истолковать, чем художественный – но в то же время в нём сплошь и рядом будут встречаться провалы с контролем типов, поэтому на шкале он ближе к классу «художественных» языков. Профессиональный язык же ближе к «строго формальным»: онтология профессионального языка обычно не определена строго, однако она существует, и в ней меньше ошибок. Профессиональный язык не столь красочен, но ему это не нужно: в случае использования профессионального языка волнует в первую очередь точность передачи значения, поэтому у него более плотное (по сравнению с бытовым и тем более художественным) концептуальное пространство. Тем не менее, такое пространство не будет формализовано до конца: в рамках одной предметной области, например, операционного менеджмента, может одновременно существовать несколько разных значений слова «проект». Одни сообщества операционных/проектных менеджеров будут пользоваться понятием «проекта», предложенного институтом проектного управления Project Management Institute (PMI), PRINCE2 и так далее, для которых проектом считается совокупность действий, приводящих к конечному заранее определенному и не меняющемуся после завершения результату, с четкими сроками начала и конца. Однако в настоящее время понятие проекта размылось, стало менее плотным, и теперь проектом могут назвать и набор спринтов, по итогам которого программисты выдали минимальный продукт, который затем пошли дорабатывать (в классическом понятии после закрытия проекта выпущенная в нем вещь не дорабатывается и не поддерживается). Поэтому, когда вы имеете дело с профессиональным языком, придётся все равно договариваться, что вы имеете в виду, когда употребляете какие-то термины.
Владению художественным языком нас учат явно на уроках русского языка и литературы, владению одним из строго формальных языков – математическим – на уроках математики. Бытовым мы учимся пользоваться, чтобы общаться с окружающими в быту (и этого вполне хватает). А вот пользоваться профессиональными языками нас не учат явно: в университете вы осваиваете специфичные для предметной области дисциплины, например, материаловедение, учитесь пользоваться этим языком – но это происходит неявно. Никто не указывает, что вы изучаете язык предметной области. То же самое происходит на работе: вы учитесь общаться по ролям, но обычно никто так не формулирует и не подчёркивает, что вы исполняете разные роли, имеете в этих ролях разные картины мира и описываете мир с определённых точек зрения/viewpoints, для которых характерны свои языки. Поэтому вы зачастую не можете различить, на каком языке вы общаетесь: на языке профессиональном, то есть, языке предметной области, или на бытовом.
В профессиональных языках более-менее четко определяются типы из базовой/core и верхнеуровневой/upper ontology онтологий, а также ключевые понятия, которые обозначаются разными словами. Например, в онтологии работ (то есть, на языке операционного менеджмента) будут определены понятия метода и работы. Более того, будет дан целый перечень слов-синонимов, по которым можно опознать понятие «метода» (метод/способ/практика/функция/культура/стиль/деятельность/труд) и «работы» (работы/операции/operations). Точно так же будет упоминаться создатель/часть конвейера/часть более крупного создателя/рабочая станция, обязательно будет обсуждаться, какие объекты создаются в ходе выполнения работ и как они путешествуют от создателя к создателю. При этом в конкретной прикладной онтологии появятся обязательно дополнительные, не заданные языком понятия, например, «судебный кейс» как объект, путешествующий по конвейеру юридической компании.
Недостающие понятия в прикладной онтологии должны, по идее, браться с опорой на имеющиеся понятия профессионального языка и смежных с ним языков других предметных областей. Однако часто при создании порождающей модели вы будете использовать профессиональный язык лишь частично: возьмёте оттуда несколько понятий, а остальные будут привычными бытовыми, что будет приводить к провалам в контроле типов. Например, сотрудник будет рассматриваться не как создатель/рабочая станция/часть конвейера, а как «ресурс», хотя точнее говорить не о сотруднике как о ресурсе, а о его предельной загрузке/capacity как о ресурсе. Более того, когда вы только начинаете тренироваться проводить онтологическую работу, вы будете толковать прочитанные вами учебники неправильно: присваивать словам/знакам из учебника бытовые, а не профессиональные значения, не отличать понятие/идею/концепт «работы» из бытового языка от языка физики или операционного менеджмента. Если разложить эту ситуацию при помощи треугольника Фреге (см картинку ниже), то получается, что «слово/знак», которое прочитали в учебнике вы и «идея/концепт/понятие/значение», с которым вы его сопоставили (то есть, объект, к которому вы отсылаете), не такой же, как у автора учебника.
Треугольник Фреге
Соответственно, вы реально/на самом деле неправильно прочитали учебник! А авторы, в свою очередь, не учли, что при чтении вы будете пользоваться привычным языком и привычными картинами мира, которые могут отличаться от тех, которые представлял себе автор. Точно такая же ситуация будет происходить в вашем ежедневном общении внутри компании. Понимаете ли вы, что на самом деле имел в виду сотрудник, который произнёс, например, слово «процесс» – метод или работу? Может ли он сам сформулировать, что именно имеет в виду? Если нет, то ваш разговор будет напоминать разговор слепого с глухим.
К счастью, разобраться с этим просто: вы уже владеете нужными знаниями. Если вы хотите договориться, вам нужно позадавать вопросы, которые подсказывает модель Фреге. А именно: если нужно понять, что собеседник имеет в виду, попросите его заземлиться или выполните заземление за него, то есть, приведите пример (экземпляр класса). Например, если собеседник предлагает обсудить процесс испытания оборудования, то можно поспрашивать, что именно будет обсуждаться: распределение работ между сотрудниками Васей и Петей (и тогда собеседник под словом «процесс» имеет в виду «работа», и с ним нужно говорить на языке операционного менеджмента, упоминая слова оттуда) или набор испытаний и контрольных состояний оборудования (тогда собеседник говорит как инженер и с ним надо говорить на языке инженера, а ещё точнее – инженера конкретной области, например, холодильных установок). Слова/знаки приходят из языка, являются минимальными составляющими/морфологическими/конструктивными единицами языка, поэтому слово/знак в треугольнике Фреге можно воспринимать как отсылку к словарю языка и интерпретировать модель так: нам надо уточнить язык, откуда берем слова, которые используем для передачи значения/смысла/идеи об объекте. Соответственно, действие по заземлению позволяет пройтись по треугольнику Фреге: при помощи заземления показать на индивида/индивидуальный физический объект (или группу таких объектов), то есть, сначала показать на левый нижний угол треугольника. Затем, глядя на приведённые примеры и обращая внимание на употребляемый язык (слова языка), вы сможете вычислить разницу в значениях/понятиях между вами и вашим собеседником или адресатом описания (то есть, обратиться к правому нижнему углу). Затем можно будет подобрать слова, которые лучше отражают смысл и точнее называют объект. Например, вы задали вопрос, что именно будет обсуждаться на встрече по «процессу испытания оборудования», и узнали, что собеседника интересует «набор контрольных состояний оборудования». По употребляемым словам вы понимаете, что речь идёт о методе, а не о работе: ничего не говорится о том, кто будет выполнять работу, не упоминаются сроки и так далее. Зато интересно, как именно объект «оборудование на испытании» будет менять свои состояния. Это язык обсуждения методов. Соответственно, слово «процесс» надо толковать как имеющее значение/понятие «метода» и обсуждать «методы» с использованием соответствующего профессионального языка.
Если вы или ваши сотрудники создают описания из класса описаний, которые регулярно переиспользуются для принятия важных решений, то лучше всего будет собрать данные о часто встречающихся ошибках при присваивании типов и учить их выполнять проверку типов в описании самостоятельно. Чтобы такая проверка была оправданной, нужно установить правила, по которым она проводится. Например, проверка точно должна проводиться, если цена ошибки при составлении описания велика: вы описываете модель сложного решения,к примеру, решения о реорганизации компании, или проектируете важный кусочек системы/вещи/объекта, к примеру, клиентский путь. Работы по созданию описания и контролю типов в описании нужно разделить. Выполнять их может один и тот же создатель/рабочая станция, например, вы, но не одновременно в один присест: сначала надо составить/нагенерировать/набредить «более-менее похожую на правду» порождающую модель, а затем критиковать и проверять типы.
Если вы начнёте тщательно контролировать типы (например, возьмёте ваши описания и распарсите текст, присвоив тип буквально каждому слову, кроме служебных), то вы обнаружите, что не так часто созданные вами или вашими сотрудниками описания будут проходить строгую проверку. Хороший контроль типов обнажает недостаток понимания предметной области и/или квалификации в её описании. Быстрое мышление S1 позволяет за счёт быстрого генерирования неточных идей (иногда – неточных до степени бреда) замаскировать недостаток понимания. Чем больше художественных описаний, написанных художественным языком в нехудожественном/профессиональном тексте, тем больше причин проверить типы: почти наверняка вы обнаружите в таком тексте много дребезга.