Система vs описание и design-run time separation

Болтал с кодексом о FPF, и неожиданно обнаружил, что самая скучная часть руководств (разделение системы и ее описания) одновременно является и чуть ли не самой важной.

Это становится наглядным если провести параллель между Work - Method - MethodDescription и треугольником Фреге.

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

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

Так вот, триаду Work - Method - MethodDescription можно представить в виде подобной же связки. Конкретные выполненные действия с результатами (Work) никак напрямую не связаны с инструкцией (MethodDescription) как и нет связи между “знаком” и “материальным объектом” в треугольнике Фреге, и эта связь есть только через агента который и выполняет метод. Я сейчас в огрубленном и менее точном виде повторил то, что постоянно говорится в руководствах — ценность не в этом, а в том как это можно применять.

Если вы практически понимаете значение треугольника Фреге и используете его в деятельности, попробуйте эти же практические приемы (рабочие, мыслительные, коммуникативные и т.д.) применить для связки Work - Method - MethodDescription.
Кажется должно очень хорошо сработать.

Общее рассуждение про важность strict distinction (A.7 отделяет EntityOfConcern от его описания – говорит, что это не одно и то же) правильное. Но треугольника Фреге (школьной семиотики) в FPF уже довольно давно нет, там более сложная онтика эпистемы – даётся слотовая структура, и там не “три угла”, а добрый десяток слотов, а уже всякие “носители информации” вообще намеренно выведены из состава эпистемы.

В руководствах где-то треугольник Фреге может ещё оставаться, но FPF чуть более современен.

1 лайк

У меня посыл немного в другом.

А именно, когда мы говорим землекопу “кидай землю вон туда” или говорим сотруднику “исправь вот эту ошибку” у нас в этот момент по сути происходят как минимум два акта:

  • Коммуникативный акт по треугольнику Фреге: “вон туда” или “ошибка” превращается в некий концепт, указывающий на материальный объект. Не факт что для говорящего и слушающего это один и тот же концепт и один и тот же объект
  • Методологический акт по design time-run time separation: сама эта фраза может превратиться в очень разные методы исправления (то, как себя ведет агент) – землекоп это может воспринять “если не можешь докинуть подойди”, либо как “кидай в том направлении”, с исправлением ошибки вариаций еще больше.

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

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

А для меня это

  1. Тема “треугольника Фреге” (что сильное старинное упрощение, сейчас преодолённое) – ну, типа как про тепло говорят в терминах теорий теплорода и флогистона, игнорируя достижения термодинамики.
  2. Тема отсутствия коммуникации по поводу метода, невидимость метода, полный пропуск методологии в работе – это да, это мы знаем, это мы отдельно каждый раз на наших резидентурах тренируем, это тяжко обычно. Но потом забавные эффекты: идёт крупный руководитель-владелец по своему предприятию и страдает: вдруг он видит не просто, что его работники работают, но что они работают по методам, которые не осознают, поэтому не могут поменять! А он вдруг это увидел, и понимает, что это полный ужас, “фирма работает как во сне, не осознавая в буквальном смысле, как же именно она работает – никто не задумывался, просто “брали и делали””. И метанойя методолога – сильные эмоции.
1 лайк