ИИ-шки, как и среднестатистический человек:
1. Точно так же несут бред
2. Точно так же экономят ресурсы (токены, точнее, вычислительные мощности датацентров)
3. Точно так же не запоминают, если им не скажешь 5+ раз
4. Точно так же фокусируются на неважном, если их не прерывать (особенно если собираете внутри ИИ-шки экспертную панель)
5. Точно так же [эксперты в рамках экспертной панели/команды внутри ИИ] ссорятся между собой и никак не могут определиться, что говорить
6. Точно так же забывают инструкции (и надо напоминать/контролировать их соблюдение), точно так же надо проверять
7. Точно так же дают не самый плохой результат (не самую плохую версию ответа) не с первого раза
8. Точно так же надо просить прокритиковать свое же рассуждение и предложить способы его улучшения
9. Точно так же сдаются, когда просишь их в десятый раз перегенерировать ответ (и точно так же надо подбодрить, когда они сдаются, чтобы попытались ещё)
10. Точно так же нужна модель собеседника, чтобы общаться.

Главное отличие при общении в другом. Когда ты имеешь дело с человеком, тебе надо открыть/discover этого человека, чтобы составить правильную модель собеседника в своей голове (мы общаемся через модели в головах). Ты изначально не знаешь, какой этот человек на самом деле, поэтому требуется постоянно открывать/discover его, чтобы осуществить delivery – собственно коммуникацию.

А когда имеешь дело с ИИ, тебе надо смоделировать себе собеседника (иначе тебе будет отвечать собеседник-пересказчик первых 10 страниц гугла, который говорит на языке, понятном среднему пользователю).
Последние сетки вполне себе могут сносно сделать аватар какого-нибудь специалиста в предметной области (можно прямо сразу моделировать конкретного человека, а можно просто задавать портрет, например, врач-терапевт с 20+ годами стажа, входящий в топ 1% в предметной области), смоделировать его коммуникационный стиль, установить ограничения на выдумывание (в частности, выдумывание списков источников информации). Тогда можно получить не совсем плохое описание, которое уже пригодно для человеческой критики (нормальными специалистами, разумеется), и затем проверять "в бою" отредактированное описание.

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

Почему я приветствую развитие ИИ

Во-первых, если вы хорошо разбираетесь в своей предметной области, вы получаете ускорение в своей предметной области примерно в 10 раз: https://t.me/theworldasaneuralnetworkchat/1364

Во-вторых, вся эта история про ИИ/LLM – это история про экономию ресурсов. Первую версию описания дешевле собрать вместе с командой нежити под кураторством человека, чем бегать за всеми белковыми экспертами и собирать их в одном месте, уговаривать сотрудничать и тп.
Сейчас едва ли не основные траты ресурсов во время работ приходятся именно на координационные акты. "Как сделать" ("как применить метод" и даже "как сформулировать метод") постепенно перестают представлять настоящую проблему. "Как собрать команду и как её уговорить сотрудничать" – куда более весёлый квест.

В-третьих, чем больше распространяется ИИ, чем больше людей его используют, тем больше BS окажется нагенерировано и тем ярче проявится это в работе. Тем больше будет стимулов заниматься развитием личного интеллекта (а не только искусственного) 😉
Умные люди будут ужасаться происходящему и будут стараться спастись от глупости – и спасти окружающих. В общем, нам будет чем заниматься)

Обсуждали недавно в чате нового потока "Рациональной работы" (https://system-school.ru/programs/orgdev – кто не знает, что это такое) "вещь/систему, которую создаёт предприятие". И речь зашла, конечно, о предприятиях, которые продают "воздух", не участвуют толком в создании никакой вещи.

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

Есть и коммерческие (на первый взгляд) организации, которые проводят исследования безопасности использования ИИ для политиков: https://systemsworld.club/t/veshh-v-sozdanii-kotoroj-uchastvuet-predpriyatie-zadanie-9-3-iz-kursa-1-1-raczionalnaya-rabota/24031.
Но если результаты работ такой компании используются, чтобы та или иная политическая группировка получила побольше политического (и экономического, и силового) ресурса под крик "ИИ небезопасно, давайте запретим!", то по сути, о существовании какой-то вменяемой/адекватной вещи говорить не приходится. Компания если и участвует в создании, то в создании политической группировки в состоянии "получила власть (прибавку к власти)". О воплощении в жизнь адекватных экономических решений в области ИИ тут говорить не приходится.

Точно так же можно продавать "косметику" (какую-то определённую), а можно – пустые обещания что-то изменить во внешности человека.

Все эти ситуации объединяет одно – создатели, не участвующие в создании какой-то вещи, меняющей мир (и желательно – к лучшему), фактически участвуют в создании очередного "МММ", которое нужно исключительно для обеспечения благосостояния его основателей.

Участвовать ли в очередном изводе МММ – личный выбор каждого. К нам в МИМ/ШСМ обычно приходят люди, которым не интересно создавать МММ, а интересно менять мир к лучшему. Очень приятно работать с такими людьми ❤️

Как вы, возможно, уже знаете, большая стажировка по "Рациональной работе" будет распилена на 4 стажировки поменьше:

1. Распожаризация: как не "тушить пожары" на работе, а избегать их появления.
2. Моделирование как основа коммуникации и лидерства.
3. Рабочее моделирование в инженерии и менеджменте.
4. Причинность, интервенции и контрфактичность в инженерии и менеджменте.

Руководства в интерфейсе AIsystant тоже будут распилены на 4 отдельных руководства. И материал в них будет обновлён!

Я уже начала переписку раздела 1 – и перепилила половину подразделов. Подразделы стали покороче и, надеюсь, попонятней, там добавлены алгоритмы, например, алгоритм проверки, не спутали ли вы вещь и действие. Дальше в раздел будет добавлен материал по различению моделей и описаний (чего сейчас не хватает).

Иии разделы по моделированию, которые будут в "Распожаризации", тоже изменятся. Текущий раздел 2 "Что такое онтологическая работа" будет переназван (рабочее название – "Отслеживать трату ресурсов") и начинаться будет с описания точки зрения операционного менеджера. Как думает (или должен думать) операционный менеджер, как связаны трата ресурсов и проход, и так далее.
После чего собственно расскажем, что такое "роль", "viewpoint", "индивид", "категория/класс", "отношения" и тп.

Надеюсь, нашим инженерам-менеджерам понравится такой подход и станет легче применять материал руководств в жизни! ❤️

Хочу показать, как можно моделировать граф создателей (производственные цепочки) на примере цветочного салона.

Моделирование цветочного салона, часть 1

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

Ситуация эксплуатации (на примере): муж дарит жене на День Рождения букет её любимых цветов. Курьер должен привезти букет вовремя (к моменту дарения), букет должен быть красивым и выглядеть свежим, должна быть возможность сделать красивую фотографию с ним и поставить в вазу. Можно рассмотреть и другие ситуации, например, коллеги-мужчины дарят женщинам на 8 марта по цветку / небольшому букету.

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

Сначала отмоделируем воплощение целевой системы – букета. Составляет букет флорист: он должен знать правила сочетания цветов, уметь составить композицию (желательно в стиле салона). Затем есть следующая рабочая станция – упаковщик, который должен упаковать букет, например, в крафтовую бумагу, повесить ленточки и подготовить букет к отправке. Затем (в случае онлайн-доставки) есть курьер/доставщик, который доставляет букет по нужному адресу к нужному времени. Производственная цепочка по воплощению букета довольно простая, в целом. Но дальше начинаются наши любимые нюансы 😃

Во-первых, выше названы только роли:: функциональные объекты, которые должны продемонстрировать некоторое поведение. Но не сказано, какие именно конструктивные/физические объекты будут его реализовывать. Тут возможны варианты: когда вы только-только открываете салон, роль флориста и роль упаковщика будет совмещать один и тот же человек.
При этом, хотя функции выполняет один и тот же человек, это разные рабочие станции. Банально у флориста и у упаковщика разные рабочие места: флористический стол обычно мокрый (над ним работают с цветами, вытащенными из воды) и грязный (на него летят обрезки стеблей, листьев и так далее), упаковывать букет за ним нельзя – можно испачкать его. Поэтому у упаковщика либо отдельный от флористического столик для упаковки, либо под упаковку приспосабливают выдвижную столешницу в столе флориста. Кроме того, конкретно рабочее место упаковщика должно быть рядом с розетками, чтобы можно было, к примеру, проклеить уголки упаковки термоклеем при помощи клеевого пистолета.

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

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

Итак, с производственной линией по воплощению букета закончили. Ноо не всё так просто! В следующий раз поговорим о том, как составляются описания букета:: вещь/целевая система. Там тоже можно выделить свою “производственную линию”, и ресурсы для неё нужны будут во многом те же, что и для воплощения букета.

Альтернативный способ отмоделировать альфу "воплощение букета"

При помощи ChatGPT, усиленной FPF, составила более подробное описание производственной линии по составлению букета.


Получилось так:
1. Отборщик стеблей. Когда салон получает заказ, отборщик по карточке заказа выбирает стебли нужных SKU и количества из холодильника, переводит их из запаса в буфер подготовки (приносит к столу флориста). В более крупных салонах эту роль будет выполнять помощник флориста.

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

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

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

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

6. Курьер/доставщик. Курьер должен доставить букет и подтвердить его получение, например, фотографией клиента с цветами. После чего заказ будет считаться исполненным, а букет – перешедшим в ситуацию/контекст эксплуатации.

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

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

Чтобы получить такое описание, я загрузила последнюю версию спецификации FPF, дала команду ChatGPT "Отвечай далее в этом чате с опорой на новую версию FPF в приложении".
После чего подгрузила книжки по Factory Physics, TameFlow, а также несколько книжек о прикладной предметной области (например, Buying and Running the Florist Shop).

Потом составила вот такой запрос:

Опиши мне альфу описания букета как производственную линию в Factory Physics & TameFlow.

Учти, что рабочие станции в производственной линии – это функциональные физические объекты, а не процессы. Например, правильное название рабочей станции – это "флорист", а не "сборка букета". Это пример, а не название рабочей станции, которое нужно использовать, название ты должен придумать сам.
Называй рабочие станции по названию роли, которую должен исполнить оператор на данном рабочем месте.
Не называй рабочие станции по названию места. Например, нельзя называть рабочей станцией "Флористическая сборочная стойка", надо называть рабочую станцию "флорист".

Сделай таблицу, в которой будут перечислены:
– функциональный объект (название роли, которая исполняет работу) – физический объект (конкретный агент-исполнитель работы)
– место, где исполняется работа (физически)
– метод, который применяет рабочая станция
– тип буфера рабочей станции
– расчет пропускной способности станции

Имена объектов давай по паттерну F.18.

Запрос корректировался несколько раз. Я читала выданный ответ и дальше добавляла замечания:

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

2. название рабочей станции – название роли, исполнитель которой будет выполнять работу. После первого замечания LLM попыталась мне называть рабочие станции именами рабочих мест, например, выдала мне в качестве рабочей станции "флористический стол". В принципе, я даже понимаю, откуда это взялось: в операционном менеджменте рабочей станцией могут назвать "станок ЧПУ" (физический/конструктивный объект). Но всё же мы хотим разнести "роль:: функциональный объект" и "исполнителя роли:: физический объект". Это важно, когда мы перестраиваем производственную линию, например, добавляем ресурс: нанимаем сотрудников и делегируем им функции.

Очень помогла ссылка на паттерн F.18 в FPF, который задает правила именования объектов. Очень рекомендую им пользоваться 😃

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

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

Несколько выводов по использованию ИИ

Тестировала в течение месяца Thinking-версию ChatGPT, перешла теперь на Pro.

1. ChatGPT Pro СИЛЬНО умнее ChatGPT Thinking. Для меня прямо ощутима разница в качестве ответов. В ответах Thinking мне порой приходилось править-выбрасывать 50-70% текста. Pro выдает сразу более качественное описание, пока не более 30% информации отфильтровываю. С бесплатными моделями, даже усиленными FPF, разговаривать вообще бессмысленно, ерунду городят. В общем, умность модели таки имеет значение.

2. ChatGPT Pro в режиме Extended Thinking думает в 5-10 раз медленнее (4 минуты на проверку моего текста vs 40 минут). Но качество ответа лично для меня бьёт все остальное. С ответами Thinking-модели мне потом приходилось возиться ещё несколько часов, чтобы что-то приличное из этого сделать. С Pro я этого времени не трачу, так что с Pro у меня получается результат быстрее ("скорость до результата" выше; на "скорость в процессе" не стоит обращать большое внимание в таком случае).

Наши инженеры-менеджеры говорят, что для большинства задач им хватает Thinking-модели. Она удобнее, потому что меньше теряет контекст и быстрее думает (в дихотомии "скорость vs точность" выбирают скорость). Думаю, всё зависит от ситуации применения LLM.

➡️ Если вам нужно выполнить сложную онтологическую работу, то Pro модель фактически незаменима (лучше всех рассуждает). Например, такую работу выполняет Анатолий, когда составляет FPF. Такую работу придётся проводить тем, кто захочет разработать хороший Second или Third Principles Framework. Но также такую работу придётся проводить тем, кто запускает оргизменения и должен быстро отмоделировать обновлённый кусочек предприятия во время его эксплуатации.

➡️ Если требуется создать прототип какого-то софта, то я бы тоже выбрала Pro модель. Код вам напишет LLM на достаточно неплохом уровне; а вам нужно аккуратно составить онтологию предметной области, для которой создаётся софт. Онтологию вы будете составлять с LLM совместно, и Pro-модель справится лучше.

➡️ Если вы используете LLM для мелких текущих задач вроде "составить план интервью", "пофиксить баг", "написать письмо или отчёт", то Thinking-модели действительно достаточно. Это очень типовые и шаблонные задачи, серьезные рассуждения здесь не нужны, скорость ответа важнее его точности.

➡️ Вам также может быть важнее скорость ответа модели, если вы проводите много мелких тестов в течение дня. Но тут я бы чередовала Thinking и Pro модели: в течение дня выполняла мелкие тесты, а поразмышлять над стратегией тестирования, над ошибками в методе тестирования и подходах я бы отправляла Pro-модель под конец рабочего дня (пусть себе размышляет).

Сама я на подписку Plus не вернусь. Свои $200 Pro-шка у меня отрабатывает на полную катушку 😉

P.S. Чтобы (любая) модель не теряла контекст, напоминайте ей постоянно об этом. Людям требуется 5+ (а лучше 7-9) напоминаний, чтобы они что-то сделали; почему вы считаете, что с LLM-ками всё иначе?

Не могу нарадоваться на ChatGPT Pro (простите)

Онтологические проблемы, коих в дисциплине операционного менеджмента больше, чем собственно операционно-менеджерских расчетов, решать с ним куда удобнее

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

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


Первый класс проблем – это проблемы с выбором точки зрения/viewpoint: требуется явно управлять выбором точки зрения, из которой вы (и ваши собеседники) будете смотреть на ситуацию.

Как это выглядит в реальной жизни? Например, вы и ваше начальство постоянно обсуждаете сроки выполнения работ, необходимые ресурсы, загрузку команды – потому что вы привыкли это обсуждать. Тем не менее, проект застопорился и двигается неохотно, даже если команду постоянно принуждают "включать режим форсажа" (работать сверхурочно для выполнения работ в срок). Потому что вы и ваши руководители постоянно выступаете в роли операционных менеджеров – именно их интересуют сроки, бюджеты, ресурсы, а также периодически играете роль (авторитарного) лидера, который поторапливает команду и мотивирует её работать больше. Но проблема может быть вовсе не в области операционного менеджмента и лидерства! Настоящая проблема, мешающая проекту продвигаться дальше, в том, что никто толком не обсуждает с инженерами метод выполнения проекта. Метод в итоге выбирается интуитивно и как попало, не подходит под контекст проекта и тормозит всё (реальный случай!). Чтобы решить эту проблему, потребовалось восстановить разговор о методе в команде – только тогда всё сдвинулось с мёртвой точки.

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

Точку зрения на предприятие и на конкретную ситуацию в вашем проекте (те в конкретном контексте) надо выбирать явно. На английском эта практика называется viewpoint governance. Если вы пользуетесь LLM, усиленной First Principles Framework (FPF), вы можете задать LLM-ке вопрос, как наладить viewpoint governance в вашей команде (компании, подразделении – нужное подчеркнуть). Только попросите её отвечать с опорой на FPF, но как инженеру-менеджеру, не знакомому с языком FPF (тогда LLM не будет отвечать вам на "птичьем языке" фреймворка).

Типовые проблемы с viewpoint governance на предприятии обычно следующие:

– в принципе не понимаем, с каких точек зрения нам нужно рассматривать ситуацию, и не понимаем, что нужно начинать с явного выбора роли(ей). А далее необходимо понять, какие описания ситуации нужны для каждой роли. Например, не понимаем, что требуется обсуждать явно метод реализации проекта. Все руководители обсуждают сроки, ресурсы, загрузку, незавершёнку, бюджеты – а инженеров никто не слышит. Когда с инженерами наконец-то начинают говорить о методе, они плачут от счастья (зачёркнуто), и начинают определяться реальные проблемы в проекте, приходит понимание реальных сроков реализации проекта. Это реальный кейс одного из наших инженеров-менеджеров в телеком-компании.

– не можем явно выбрать, интересы/concerns какой роли в данной ситуации важнее, те какая точка зрения на ситуацию приоритетнее, и о чём думать в первую очередь. Например, как операционные менеджеры стоим на своём и отказываемся брать новый проект в работу, пока не закрыли один из старых, потому что это увеличит незавершёнку. С точки зрения операционного менеджера это правильно; но *только* с точки зрения операционного менеджера. А если у компании (например, веб-студии) кассовый разрыв, и ей требуется взять новый проект, чтобы покрыть авансом этот разрыв? Что в данном случае важнее – растягивание сроков выполнения проектов или выживание компании?
Ещё один пример, который я люблю приводить – это посадка самолёта на пшеничное поле в сентябре 2023 года. После отказа одной из гидравлических систем самолёта (не самой важной) пилоты прекратили заход на посадку в Омске, аэропорте назначения, и решили полететь в Новосибирск. Как выяснило расследование, это решение они принимали не как пилоты, которые должны думать о безопасности полёта, а скорее как финансисты, которые беспокоились о стоимости ремонта гидравлики (в Новосибирске ремонт должен был обойтись дешевле). Результат – неправильные расчёты расхода топлива и посадка на пшеничное поле вместо почти штатной посадки в Омске.

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

Проблемы с выбором точек зрения помогает исправлять применение паттернов FPF, в частности:
– A.1.1 U.BoundedContext — помогает понять, _в какой рамке смысла_ мы вообще обсуждаем ситуацию;
– C.2.1 U.EpistemeSlotGraph — заставляет указать DescribedEntity, GroundingHolon, ClaimGraph, Viewpoint, View, ReferenceScheme;
– E.17.0 U.MultiViewDescribing — помогает организовать несколько описаний одной и той же сущности под разными точками зрения;
– E.17.1 U.ViewpointBundleLibrary — помогает заранее иметь библиотеку типовых bundles точек зрения;
– E.17.2 TEVB — даёт типовые инженерные viewpoints для описания холонов/систем.
– A.6.3 U.EpistemicViewing — помогает построить view как срез описания под выбранным viewpoint, не меняя объект разговора;
– A.6.5 U.RelationSlotDiscipline — помогает не смешивать slot, value, reference, viewpoint, view и surface;
– A.7 / E.10.D2 Strict Distinction / I-D-S discipline — помогает не перепутать объект, описание, носитель, план и факт;
– A.19 Selector / comparison patterns — помогают выбирать между competing viewpoints/criteria без скрытого “ну и так понятно”.


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

Следующие несколько классов опишу вместе одним постом.
Вывод, который, я надеюсь, сделаете вы после чтения поста: нужно попытаться описать проблему, которую вы решаете, а потом попробовать определить точки зрения, со стороны которых сейчас рассматривают ситуацию реальные люди в реальном проекте – и какие точки зрения упущены вовсе. Вы можете провести такую работу совместно с LLM, усиленной FPF: описать ситуацию, описать точки зрения (или хотя бы перечислить роли, исполнителей которых вы обнаружили) и спросить, каких точек зрения не хватает, чтобы разобраться с ситуацией – с опорой на C.2.1, E.17.1 и все остальные релевантные паттерны FPF.