Созвездие Луча
171 subscribers
3 photos
42 links
Проектирование в широком смысле + см. закреп : )
Download Telegram
#систематика /// Коммуникация: нарратив и объяснение

Коммуникация / описание может быть в виде нарратива и в виде объяснения.

Нарратив — это последовательный рассказ о чём-то, часто в виде истории (storytelling). То есть когда для сообщения выбираются / придумываются герои в каком-то контексте и рассказывается их история. И это действительно лучше запоминается.

Нарратив звучит убедительно, совпадает с картиной мира потребителя сообщения. И чем больше совпадение с картиной мира, тем убедительнее нарратив.

Нарратив позволяет запомнить историю — она логична и (при хорошем нарративе) создается впечатление, что так и должно быть.

При этом в нарративе:
- Нет требований к заземлению, системные уровни и уровни абстракции описываются в свободной форме.
- Нет требований к предсказанию, то есть не строятся модели и прогнозы.

Нарратив не передает вместе с историей новые знания об обработке картин мира, он не объясняет, а лишь сообщает наблюдение. Для коммуникации в совместной работе, когда целью является создание чего-то, нарратив работает хуже, чем объяснение, так как объяснение позволяет рассказать как есть / как устроено, вместо того, чтобы придумывать истории о том, как это выглядит в виде рассказа.

Объяснение позволяет компактно
- уложить в голове картину интересующей части мира; картина будет описывать часть мира и давать представление о подобных частях мира в последствии, следовательно, можно:
- вывести из этой картины предстказательную модель;
- передать это понимание устройства части мира из своей головы в другие головы.

Одному наблюдению может соответствовать насколько разных объяснений. Пример:
Наблюдение — на холоде вода превращается в лёд.
Объяснение 1 — там где холод, там духи льда, и они превращают воду в лёд.
Объяснение 2 — при 0ºC вода меняет агрегатное состояние на твёрдое, кристаллы воды меняют своё подведение.
Объяснение 3 — когда холодно, вода не течет, чтобы не тратить энергию, а замерзает в лёд и сохраняет энергию для поддержания внутреннего тепла.

Объяснение можно оценить без экспериментальной проверки — эпистемически. Проверка будет полу-формальной, но с такой проверкой можно работать.

Объяснение позволяет строить причинно-следственную связи и генерировать предсказания.

У объяснения есть требования к заземлению, то есть к понижению уровня абстракции.

___
#описание #нарратив #объяснение #заземление
#систематика /// Опровержение объяснения

Объяснения могут подвергаться опровержениям. И чем больше путей для опровержения объяснения, тем объяснение сильнее (при условии, что объяснение выдержало все эти опровержения, не было ими опровергнуто).

При рассмотрении опровержений удобно пользоваться моделью возможных и невозможных миров:
- возможные — которые не соответствуют объяснению
- невозможнные — которые противоречат объяснению
И чем больше невозможных миров отсекается объяснением, тем оно сильнее.

___
#описание #объяснение
#систематика /// Описание системы, разбиения

Описание — это то, как мы говорим о системе. Описание необходимо для обсуждения будущей системы, чтобы обсуждать модели-описания и договариваться для достижения непротиворечий.

Описание делается через рассмотрения, а их три основных:
- функциональное — по роли/функции: что части делают для реализации эмержентности / сервиса – это описание чёрного ящика – аналитиеская работа.
- модульное / конструктивное — по частям: из каких частей состоит система – это описание прозрачного ящика! – синтетическая работа.
- пространственное — по размещению в пространстве-времени: где-когда части физически находятся – тоже описание прозрачного ящика.
(вот эти три первых — это костяк архитектуры системы)
и множество дополнительных:
- финансы
- право
- этика
- етс

Важно: функциональное разбиения принято считать самым важным, и его можно назвать системным разбиением. Возникающий парадокс между системным разбиением по функциям и системным разбиением по часть-целое убирается с помощью трассировки функций к частям. Сделав такую трассировку вявляются уровни разбиения функционального и модульного, которые скорее всего не будут совпадать, и это нормально. Разбиения, как физические, так и функциональные, делаются вниманием.

Системы описываются частично в будущем — когда они воплощены / run-time. То есть описываются воплощения систем, всё остальное по сути и есть описание / design-time: от идеи - через описание - к воплощению. Поэтому в описаниях часто что-то отсутствует, так как это ещё не случилось, это в будущем, это ещё не выявлено.
Описываются требования и архитектура; они всегда есть, но могут быть еще не описаны и/или не выявлены.

Описание проявляется только в виде документации, то есть записанное, задокументированное на каком-то физическом носителе.

Каждая проектная роль делает своё описание системы — ролевое описание системы (viewpoint).

Система, пока она не воплощена, имеет лишь описание. Как только система выделена вниманием, то есть кто-то о ней думает, то эта система (она может ещё только появиться в будущем) имеет описание, то есть образ того, как она работает в виде воплощения. То есть описание системы возникает до воплощения. Чтобы работать над системаой, воплощать её, необходимо задокументировать описание. Исключение — когда система создаётся НЕ коллективно, и описание системы достаточно для одного человека, который мыслит и воплощает систему.

____
#описание #функция #модуль #размещение #трассировка #эмерджентность
#систематика /// Описание и требования к нему

К описанию бывают требования двух видов

- Требования к формату описания
- содержанию — запрос на описание части физического мира, ограниченного чем-то
- языку — как выделяются объекты из фона и какими словами обозначаются
- нотации

- Требования к цели — запрос на описание, чтобы агент А по описанию сделал действие N
в этом случае надо догадываться:
- сколько на самом деле нужно описаний, так как "чтобы агент А сделал действие N" может наступить только при участии других агентов, для которых тоже потребуется описание.
- на каком языке и нотации требуется описание
- что должно являться содержанием описания, то есть к какой части мира описание реферирует

Эти виды требований могут и комбинироваться, а также скорее всего каждый из нас тяготеет к одному из видов как более комфортным и понятным или привычным требованиям.

Важно уметь выявлять одно из другого — на основе запроса по формату надо уметь выявить или предположить цель применения этого описания, а на основе запрос по цели надо уметь выявить требования по формату: содержание-язык-нотация.

Часто требования к описанию на бытовом уровне выдвигаются только как требования к содержанию.
И тогда надо догадаться:
- на каком языке описывать? — язык уже где-то закреплен или его надо выявить / снять с речи и применить?
- насколько детально описывать — насколько мелкий самый мелкий наш объект внимания в этом описнаии? Это системные уровни в системном разбиении часть-целое — здесь речь про масштаб рассмотрения, позиция в спектер zoom in - zoom out рассмотрения.
- насколько конкретно описывать — вот тут надо предполагать, что получаетнль описания будет с описанием делать — выявлять общие законы или рассматривать конкретную описываемую часть мира; это про выбор предмета описания — класс или экземпляр.

Раз к описанию есть требования, то есть и потребности, из которых эти требования проистекают, а значит у описания обязательно должна быть цель — соответствующая цели того, кто запрашивает описание. Запрашиваемое описание — это про предпочтение в интересе той роли, которая запрашивает это описание.

___
#описание #часть_целое #системное_разбиение #требования #нотация #роли #интерес
#инфоарх /// Таблица

Таблица это текст со связями объектов.

Если простой линейный текст это одномерная структура, то таблица двумерная, что позволяет просматривать связи между описываемыми объектами.

Таблица — нотация для передачи связей объектов.

Связи также можно представить в виде схемоидов, схем, диаграмм, майнд-карт, etc, но такие представления могут не передавать полностью модель отношений, вырывая из контекста только те отношения и только те объекты, которые показаны на схеме.

___
#описание #таблица #нотация #схема #диаграмма
#систематика /// Системная инженерия

Системная инженерия есть трансдисциплинарный подход и метод создания успешных систем. Успешная система есть функционирующая система, в которой удовлетворены интересы всех проектных ролей.
Системная инженерия рассматривается только как гибрид анализа и последующего синтеза, понимания-для-созидания, где конечной целью является воплощение успешной системы, то есть результат в физическом мире
© "По карте не ходят, меню не едят, на чертежах не летают, код не хранит значения переменных"

Компьютерная программа — описание системы, воплощением же будет состояние программы в ходе её выполнения на компьютере.
UI — описание того, что видит пользователь, воплощение — состояние системы в момент когда пользователь видит UI и работает с ним.
UX — описание действий пользователя и их последствий, воплощение — массив всех конкретных действий каждого пользователя и последствия действий для него.

В случае разработки софта можно представить весь процесс цепочки: все программы, связанные друг с другом (и часто взвимодействующие также с людьми в оргпроцесссах) меняют описание в их базах данных, и все для того, чтобы в конце, как итоговое изменение физического мира, пользователю доставили материальную коробку с товаром из интернет магазина или пустили в зал кинотеатра или на борт самолёта.

Также полезно при проектировании и разработке системы держать в уме само воплощение, то есть представлять систему как будето она уже существует. И если что-то мешает это представить, то там и надо работать, туда направлять фокус.

___
#воплощение #описание
#систематика /// Конфигурация

Конфигурация есть текущее воплощение системы, её части на данный момент плюс их описание.
Конфигурация должна быть обязательно описана и задокументирована; обычно это выражается в описании релизов, версий, состояний milestone, етс.
Несоответствия реальности и описаний конфигурации — конфигурационные коллизии; это плохо, это много лишней работы.
Поэтому необходимо отслеживать соответствие воплощения системы и её описания, осуществлять управление конфигурацией.

____
#конфигурация #воплощение #описание
#систематика /// Коммуникация и описание

Описание всегда есть коммуникация. Даже если мы делаем описание для самих себя, то коммуницируем сами с собой из одной точки времени в другую.

___
#коммуникация #описание
#систематика /// Абстракция и размытость

Абстрагирование — упразднение какого-то признака класса.
Абстрагирование — переход в над-класс, избавление от какого-то признака более узкого класса для перевода рассмотрения в в более широкий класс. Пример — переход в рассмотрении от синих панамок к панамкам вообще; мы убрали из рассмотрения признак цвета и теперь рассматриваем все панамки вообще, перешли в над-класс "все панамки".
Цепочка абстрагирований: моя конкретная синяя панамка — абстрагировались до синих панамок в целом (а могли до "моих панамок" всех цветов) — затем абстрагировались до панамок вообще — затем до головных уборов — до одежды — ...

Размытость — рассмотрение в широком классе, но с невыделенными или неизвестными признаками. При размытости необходимо думать какие признаки надо выделить, на какие узкие классы приземлить рассматриваемые объекты.

Поиск нужного уровня абстракции, а также выведение из размытости на уровни абстракции необходимы для выявления требований к описанию, предполагая итогового получателя описания и цель применения описания.

___
#абстрактность #размытость #описание #класс #надкласс #подкласс
#систематика /// Коммуникация; нарратив и объяснение

Коммуникация / описание может быть в виде нарратива и в виде объяснения.

Нарратив — это последовательный рассказ о чём-то, часто в виде истории (storytelling). То есть когда для сообщения выбираются / придумываются герои в каком-то контексте и рассказывается их история. И это действительно запоминается лучше, чем просто какой-то набор фактов.

Нарратив звучит убедительно, он совпадает с картиной мира потребителя сообщения. И чем больше совпадение с картиной мира, тем убедительнее нарратив.

Нарратив позволяет запомнить историю — она логична и (при хорошем нарративе) создается впечатление, что так и должно быть.

При этом в нарративе:
- Нет требований к заземлению, системные уровни и уровни абстракции описываются в свободной форме.
- Нет требований к предсказанию, то есть не строятся модели и прогнозы.
- Нарратив не передает вместе с историей новые знания об обработке картин мира, он не объясняет, а лишь сообщает наблюдение.

Для коммуникации в совместной работе, когда целью является создание чего-то, нарратив работает хуже, чем объяснение, так как объяснение позволяет рассказать как есть / как устроено, вместо того, чтобы придумывать истории о том, как это выглядит в виде рассказа.

Объяснение позволяет компактно уложить в голове картину интересующей части мира; картина будет описывать часть мира и давать представление о подобных частях мира в последствии, следовательно, можно:
- вывести из этой картины предстказательную модель;
- передать это понимание устройства части мира из своей головы в другие головы.

Одному наблюдению может соответствовать насколько разных объяснений. Пример:
Наблюдение — на холоде вода превращается в лёд.
Объяснение 1 — там где холод, там духи льда, и они превращают воду в лёд.
Объяснение 2 — при 0ºC вода меняет агрегатное состояние на твёрдое, кристаллы воды меняют своё подведение.
Объяснение 3 — когда холодно, вода не течет, чтобы не тратить энергию, а замерзает в лёд и сохраняет энергию для поддержания внутреннего тепла.

Объяснения можно сравнивать, их можно оценить без экспериментальной проверки — эпистемически. Проверка будет полу-формальной, но с такой проверкой можно работать.

Объяснение позволяет строить причинно-следственную связи и генерировать предсказания.

У объяснения есть требования к заземлению, то есть к понижению уровня абстракции.

___
#описание #нарратив #объяснение #заземление #коммуникация
#систематика /// Эволюция объяснения

Объяснение не может быть идеальным, а лишь лучше предыдущей версии объяснения или лучше предыдущего другого объяснения.

Объяснение можно оценить по следующим параметрам:
- Заземление — чем больше зазамлено / чем менее абстрактно, тем лучше.
- Детализация — чем более подробно объяснение, тем оно лучше.
- Количество путей опровержения — чем их больше, тем лучше; то есть если объяснение по большему числу путей опровержения выстояло, тем оно лучше, крепче, solid.
- Количество (новых) допущений — чем их меньше, тем лучше; то есть не приходится искать / придумывать (новые) условия, в которых бы объяснение работало.
- Отношение к старому объяснению — чем больше аргументации, критики, залатывания дыр в прошлом объяснении / прошлой версии объяснения, тем лучше.

Новая версия объяснения должна выигрывать у прежней версии хотя бы по одному из пунктов:
- решает хотя бы одно из несоответствий в прежней теории
- позволяет вывести новое для лучшего предсказания
- содержит меньше допущений

___
#объяснение #заземление #детализация #описание
#систематика /// Опровержение объяснения

Объяснения могут (и должны) подвергаться опровержениям. И чем больше путей для опровержения объяснения, тем объяснение сильнее (при условии, что объяснение выдержало все эти опровержения, не было ими опровергнуто).

При рассмотрении опровержений удобно пользоваться моделью возможных и невозможных миров:
- возможные — которые соответствуют объяснению
- невозможнные — которые противоречат объяснению
И чем больше невозможных миров отсекается объяснением, тем оно сильнее.

___
#описание #объяснение
#систематика /// Уровни целеполагания в коммуникации

Помимо основного принципа кооперации про то, что у агентов должна быть минимум одна общая цель, могут быть также различия в стоящих рядом целях или в отношениях агента к общей цели.
Что это может быть:

Текущая или позиционная цель
Текущая цель подразумевает результат коммуникации прямо сейчас, как результат текущей коммуникации, например, получить ответ на вопрос, побудить к действию.
Позиционная цель подразумевает изменение или удержание позиции агента в будущем. То есть, сейчас коммуникация не будет иметь целевого результата, но в последствии будет, и текущая коммуникация есть один из шагов к целевой позиции.

Содержание или форма коммуникации
Коммуникация о содержании ставит целью изменить / развить / улучшить картину мира агента/агентов, объяснить наблюдение или дать инструкции.
Пример 1: обсуждение с бригадиром как класть плитку при ремонте, какого цвета выбрать затирку для плитки, кто будет это всё закупать и привозить.
Пример 2: обсуждение с проектной командой какой именно софт будет отвечать за печать документов — своей разработки или закупленный на стороне.
Коммуникации об установлении языка ставит целью договориться о форме коммуникации, выбрать понятый и удобный агентам мета-язык / метод описания / интерпретатор / способ моделирования.
Пример 1: обсуждение с бригадиром как передать требования к ремонту — в виде устного описания пожеланий по телефону / в виде распечатанного дизайн-проекта / в виде 3D-модели помещения с наложенными текстурами в виде файла, доступного для просмотра на планшете.
Пример 2: обсуждение с проектной командой в каком видео описывать и согласовывать процесс — UML, BPMN, естественный язык со схемоидами в Confluence.

___
#коммуникация #цель #содержание #форма #метод_описания #описание #интерпретатор
#систематика /// Онтологический дребезг

Это ощущение, что в описании, речи, коммуникации что-то не так. Ощущение, что допущены ошибки при работе с типами объектов, отношениями объектов.

Это чувство / ощущение важно тренировать, чтобы вылавивать места, где скрыты ошибки, где надо распутать клубок объяснений, пониманий, связей. В противной случае ошибки рассуждения / описания будут пропущены и проявятся позже, уже на этапах проектирования и моделирования, что значительно дороже исправлять.

Чувство онтологического дребезга тренируется и калибруется, чтобы через призму этого восприятия также рассматривать описания, коммуникации, объяснения.

Онтологический радар, ловящий это чувство дребезга, лучше всего не выключать вообще (чем включать при необходимости проверки), так как ситуаций — когда ошибки есть и их надо отловить — происходят чаще, чем мы сможем заметить и успеть включить радар.

___
#описание #коммуникация #объяснение #иерархия #класс #тип #объект
#систематика /// Модель, метамодель, мегамодель

При воплощении чего-либо нам нужно описание этого, того, что будет воплощено. Обсуждать надо описания, обсуждать до воплощения. Одна из частей описания — модель.

Модель необходима для обсуждения интересов, предпочтений и намерений.
Кол-во моделей для обсуждения пропорционально кол-ву интересов в системе.

Модель — абстракция от реальности и конкретики; "правильное упрощение" в смысле отсечения лишнего, упрощения до лишь самых важных нюансов.

Модель — это описание, прогнозирующее как будет работать воплощение системы. Для каждой системы есть НЕ одна модель, модели зависят от интересов проектных ролей.
Пример модели: при проектировании здания создается его чертёж, это его модель. Но чертежей будет несколько — один для электриков, один для безопасников, один для инженеров по станадартам. Чертёж как модель должен быть задокументирован, и документ может включать все перечисленные чертежи-описания сразу, но для каждой роли важем будет лишь одна из моделей, представленных в документе. Еще один пример — карта с легендой этой карты. Карта это модель местности, а легенда карты есть метамодель.

Для создания моделей используются метамодели — описания моделей, по которым участникам проекта становится понятно, что за модель рассматривается, в каком аспекте.
Пример метамодели: для изготовления панамы делаются выкройки, это модель, но есть и легенда — заштрихованные области на выкройке означают, допустим, вельвет, а пустые контуры означают, скажем, войлок; кружочки, закрашенные сеткой — декоративные пуговицы. Вот эта штриховка и символы пуговиц и есть метамодель.

Ошибки необходимо выявлять на стадии моделирования. Именно для этого создаются модели, по одной для каждого интереса, совокупность моделей есть мультимодель. Модели обсуждаются для достижения непротиворечий, для этого модели обязательно документируются с помощью метода описания. Предоставляя на обсуждение описание (модель), обязательно указывается метод описания.
Пример: показывая функциональную схему мы обязательно сообщаем, оформлена ли она формально, напимер, в UML, или же это вольный схемоид для вернеуровневого обсуждения;
ещё пример: предоставляя значения цветов мы обязательно указываем, в какой нотации они записаны: HEX / RGB / SMYK / HSB / Pantone (Обычно это следует из формата или префикса, но обязательно наличие индикатора, нельзя просто написать, что цвет равен 006011, это может оказаться как # 006011, так и HSL H00 S60 L11 ).

При обучении моделированию обучаются метамоделям, а не моделям. Модель каждый раз будет своя для каждого уникального проекта. А вот метамодели часто совпадают (пример: .XML и .JSON есть метамодель для описания метаданных).

Метамодель также называется интерпретатором описания. "Язык для описания языка" — например, легенда карты или список сокращений в документе техзадания.

Самый понятный интерпретатор это естественный язык.

Важно держать в уме вопросы, которые мы хотим/можем задать описанию и какие ответы хотим/можем получить — это влияет на выбор интерпретатора нами и на восприятие интерпретатора потребителем описания.

Повторим: интерпретатор = метамодель = описание описания = мета-язык.

При рассмотрении отношений модели и метамодели будем использовать термины описание и его интерпретатор.

___
#роль #модель #метамодель #мегамодель #описание #мета_язык
#систематика /// Описание и его интерпретатор

Интерпретатор = описание описания. То есть метамодель. Язык, описывающий язык описания, мета-язык.

При работе с описанием важно различать само описание и его интерпретатор.

Если описание принять за язык объектного уровня (то есть описание рассказывает про рассматриваемые объекты), например, это будет естественный язык, то при попытке этим же языком описать понятия из интерпретатора будут возникать парадоксы. Чтобы этого избежать, стоит разделять термины, применяемые в описании и в интерпретаторе, и использовать для описания и интерпретатора разные наборы слов/терминов.

Пример на уровне кавычек во фразе: «я верю, что высказывание «снег белый» верно в том случае если снег белый» — внутренние кавычки есть описание / модель / язык объектного уровня, а внешние кавычки есть интерпретатор / метамодель / метаязык. Так как внутри и снаружи внутренних кавычек есть "снег белый", то это сообщение ничего не объясняет из-за описанного парадокса.

Часто интерпретатор не даётся потребителю описания в явном виде. Например, в устной речи так случается почти всегда: интерпретатора явно нет. В таких случаях потребитель интерпретирует, опираясь на:
- опыт верных / полезных / успешных интерпретаций подобных описаний / выражений
- контекст и исторчник получения описания

Чаще всего, когда интерпретатор не задан явно, потребитель не осознает выбор и/или распознавание интерпретатора, это происходит фоном.

Этим можно пользоваться при шифровании, когда потребитель даже не подозревает, что у выражения есть интерпретатор, позволяющий получить целевое прочтение выражения / описания.
Также интерпретатор может быть дан явно и намеренно ложно, чтобы не допустить нежелательного прочтения выражения (допустить только желательное прочтение тем потребителем, кто имеет также верный / целевой вариант интерпретатора).

Если же интерпретатор дан явно (и не является ложным), то всё просто — интерпретируем согласно интерпретатору. Например, читаем схему, поглядывая в условные обозначения, или смотрим инфографику, сверяясь с легендой.

При выборе позиции "верить или не верить" описанию (часто этот выбор не осознанный) этот вопрос веры применим как к самому описанию, так и к интерпретатору, который также является описанием. То есть, при оценке достоверности рассматривается вся мегамодель. Это рассмотрение мегамодели — для принятия решения верить описанию или нет — основано на:
- контекст потребления описания;
- прагматическая цель коммуникации, то есть не только в соответствии с роль агента-интерес-предпочтение-намерение, но и цель текущей коммуникации агента (цель часто тоже выводится из контекста: опыта прежней коммуникации с агентом);
- эпистемический статус агентов, о нём подробнее завтра.

___
#интерпретатор #описание #метод_описания #метамодель #мегамодель #эпистемический_статус #мета_язык
#систематика /// Эпистемический статус агента

Если взять высказывание / описание какой-то части мира, то у вас будет мнение относительно этого высказывания, допустим, вы согласны с описанием и считаете, что часть мира именно такая как описано, а пусть и с сомнениями, если описание выражено множеством высказываний и с частью из них вы не согласны. Это эпистемический статус высказывания на вашей стороне (в вашей голове).
У других агентов (часто это люди) может быть другое мнение о том же высказывании. И вот набор мнений относительно высказывания на стороне агента есть эпистемический статус агента.

Пример: вы считаете, что "Архаров бегает хорошо" и при этом думаете, что ваш коллега Барханов считает про Архарова так же. Поговорив с Бархановым про бег Архарова, вы меняете ваше представление о том, как считает Барханов относительно бега Архарова. При этом сами вы можете и не менять своё мнение о беге Архарова.

То есть:
любая коммуникация, любой акт обмена информацией, меняет представление об эпистемическом статусе агента.
В примере:
Барханов — агент
ваше знание о том, каково мнение Барханова о беге Архарова — эпистемический статус агента.

Отстутствие информации при коммуникации тоже меняет представление об эпистемическим статусе агента (на вопрос "Как тебе бег Архарова?" Барханов молчит).

Язык многоуровневый — описания и их интерпетаторы при этом рекурсивны в обе стороны.
Множество агентов в мире, каждый агент имеет представление о представлениях других агентов. Это представление о представлениях агентов изменяется в ходе коммуникации, когда агенты отдают и получают информацию. И эту информацию можно интерпретировать на разных уровнях — на уровне описания / объектном уровне языка или на уровне интерпретатора / мета-языка.

___
#интерпретатор #описание #метод_описания #метамодель #мегамодель #эпистемический_статус #мета_язык
#систематика /// Целеориентированное описание

Описание обязательно создается для совершения дейстия в реальном мире. У описания обязательно есть цель — чтобы целевое действие совершилось.
Описать N, чтобы агент A выполнил действие X.

Хорошее, работающее описание можно создать по простым шагам:
1) Выявить, узнать целевое действие для описания. Без этого описание обречено на провал. Целевое действие запрашивается у заказчика описания, если в самом запросе описания цель не ясна. О цели лучше всего спросить прямо — "в результате потребления описания что должно произойти, с кем и как"; с кем и как важны, чтобы не скатываться в размытые и общие запросы вроде "чтобы стало лучше, чтобы доход рос, чтобы сотрудники не ругались". Если нет возможности спросить прямо, то узнать косвенно: собираем/выявляем максимум контекстной информации о заказчике, прямо спрашиваем про его роль/роли ("вы как кто спрашиваете?") или понимаем их из контекста. На основе этой информации строит гипотезы о целях описания и проверяем эти гипотезы, лучше всего явно — "я верно понимаю, что вы хотите … ?".
2) Провести исследование — чего не хватает, чтобы подобрать язык для описания. На выходе — список недостающей информации. Кроме языка здесь важны эпистемический статус агента (адресата описания), понятийное расстояние. По шагам:
- Кто адресат описания — это максимально важно, так как не зная адресата мы составим описание для никого, потратим время впустую, шанс, что описание сработает, минимальный.
- Какие объекты надо описать? в какой части реального мира эти объекты находятся? в разрезе каких понятий / в какой нарезке* их надо описать? насколько детально и насколько конкретно?
Пример про нарезку: описать панамку в разрезе материалов и техники сшивания или в разрезе фасона, цвета или в разрезе себестоимости и цены?
- На каком языке описывать? какие термины будут понятны адресату? надо ли приложить интерпретатор?
- В каком формате описываем (картинка, схема, текст, видео-инструкция, канбан-карточка, устное объяснение) и в какой нотации?
- Какая цель агента-потребителя описания? Он будет использовать описание для работы, для каких-то других дел / целей?
- Каков эпистемический статус агента? Что он уже знает о той предметной области, про которую мы собираемся ему сообщать? Выполнял ли он подобные действия раньше?
- Какое должно быть содержание описания, чтобы привести агента-потребителя в необходимый нам статус?
4) Собрать недостающую информацию — в идеале собирать информацию у прямых адресатов, у тех, кто будет читать описание и что-то делать по нему. По шагам:
- Прямо спросить у адресатов всё, что нам непонятно.
- В случае если спросить нельзя, то построить гипотезы и проверить их:
- предположили нарезку и язык — пообщались этим языком по этой нарезке — при необходимости скорректировали язык и нарезку
- предположили уровень подробности и уровень абстракции — проговорили самые мелкие и самые крупные объекты интереса, проговорили максимально конкертные и наиболее абстрактные объекты / понятия — скорректировали при необходимости.
6) Спроектировать описание — подобрать язык, настроить максимы кооперации. По шагам:
- Чтобы подобрать язык стоит также понять на каком участке спектра точности удобно / привычно / комфортно общаться потребителю описания.
- Также важно предположить понятийное расстояние, чтобы понимать шаг, который может делать агент, то есть как быстро он будет усваивать новые для него картины мира из нашего описания.
8) Создать описание — по шагам:
- Явно (текстом/таблицей) изложить (для себя!) все мета-данные для описания: целевое действие, роль заказчика, кто адресат, его статусы, язык и нарезка, понятийное расстояние и удобный уасток спектра, etc.
- Создать полный текст, соблюдая правила:
- Один абзац — одна мысль в формате тезис—аргумент—вывод.
- В начале обозначить, о чем будет описание и зачем оно нужно агенту-потребителю
___
#описание #коммуникация #цель #надсистема
#систематика /// ОиК-задание-1

Выберите какую-либо из своих деятельностей/ролей и опишите её.
Для слов, использованных в описании, укажите типы:
1) Физический объект (для проверки: он имеет представление в пространстве и времени).
2) Класс (подробнее про классы).
Для полноты описания и самопроверки рекомендуется для класса указать подкласс, надкласс, экземпляр этого класса).
3) Признак класса.
Стоит также указать какие классы выделены на основе этого признака.
4) Описание.
Укажите также, что им описывается и на каком языке. Подробнее про описание: “воплощение и описание + все посты по тегу #описание.
5) Роль.
Укажите интерес, предпочтение и намерение для роли.
__
Варианты решений пишите в комментарии к этому посту.
Во вторник опубликую свои варианты.
__
Это 1-е задание/упражнение из цикла повторных решений кейсов на курсе Онтологика и коммуникация.
__
Упражнение тренирует так называемую машинку типов; позволяет лучше разобраться в деятельности — своей и окружающих агентов (коллег, родных, друзей, партнеров, etc);
__
#задания_ОиК
#систематика /// Эстетика, красота, изящность, элегентность

Дисциплина эстетики обсуждает критерий изящности/красоты у решения. Причем как решения задач по созданию систем, так и для художественных задач.

Само решение по созданию и/или описанию системы может и должно быть элегантным, красивым.

Для художественных задач (а лучше сказать устремлений) эстетика может проявляться на нескольких уровнях — на уровне самой идеи, на уровне формы выражения, на уровне обсуждения художественного акта и т.д.:

- что сотворено? — концепт, понятие
- в каком виде выражено — знак, язык, формат, модель
- как представлено и воспринято — коммуникация, агентное восприятие

Все эти уровни могут быть по-своему красивы. Но могут и не быть, что оказывается весьма трагично.
Взаимное влияние эстетики этих уровней — то, что стоит продумать.
В рациональном (не художественном) рассмотрении также можно мыслить красотой самого решения, красотой описания и красотой обсуждений по решению; однако здесь вступает чистый прагматизм и целеполагание, весомо влияющие на уровень эстетики в совокупном решении (мега-модели).

---
#эстетика #модель #описание #концепт