Почему я занимаюсь FPF: потому что это уникальное конкурентное преимущество
Я продолжаю заниматься First Principles Framework (FPF) с бригадой нежити, практически full time. Зачем это? Хобби? Нет, это реализация стратегии, шанс сохранить рабочее место в быстроменяющемся мире. Что даёт FPF по сравнению с “конкурентами” - текущими стандартами онтологий вроде той же BORO или даже CCO, процессными agile фреймворками вроде SAFe и LeSS, всяческими SWEBoK и SEBoK? Тут я понимаю, что кто не знает этих страшных слов, те даже не задумываются над тем, какие есть потенциальные конкуренты у FPF, это означает, что в значительное число проблем оставлено “на совесть команды”, а там уж “хотели как лучше, получилось как всегда”. Да, можно “спросить у AI” – но ответ вы получите чаще всего самый популярный, то есть предыдущего поколения инженерии и менеджмента. А новинки? Они не проверены, там “слова-слова-слова”. Для понимания сути слов-слов-слов надо откатываться к первым принципам, самым элементарным мыслительным операциям, которые нужны ещё до того момента, как мы поняли предметную область. Вот именно этим я и занимаюсь.
Любой сложный проект – это иллюстрация библейской истории про Вавилонскую башню:
– Data Scientist говорит о “надежности модели”, имея в виду точность на тестовой выборке.
– Инженер по безопасности слышит “надежность” и думает о формальной верификации кода.
– Менеджер проекта видит “надежность” как отсутствие срывов сроков.
– Архитектора интересует “надёжность”, но у него это – “наработка на отказ”.
Они используют одни и те же слова, но говорят о разном, языки их разные и полны “ложных друзей переводчкика”. Специалисты спорят в итоге долго и бесплодно, договариваются трудно и с ошибками, а “рабочего/нейтрального английского” для того, чтобы они заговорили понятно друг другу – его нет! Всё это понятийное месиво будет как на русском, так и на английском, так и на суахили.
First Principles Framework (FPF) — это не просто еще одна онтология, ещё один (даже не международный) стандарт или “процессная agile системная методология”. Это фреймворк, который даёт не только универсальный/нейтральный для разных прикладных предметных областей язык, “рабочий/нейтральный/унифицированный/общий язык первых принципов мышления”, но и указывает на то, о чём вообще стоит говорить.
FPF не заменяет текущие лучшие знаниевые фреймворки (онтологии, Agile, стандарты), а надстраивается над ними. Своды знаний (SEBoK, PMBoK) каталогизируют какие-то “лучшие практики”. FPF предоставляет трансдисциплинарный клей, который позволяет этим практикам из самых разных стандартов и из самых разных голов (не всё берётся из стандартов или постов в блогах замечательных людей, что-то люди в проекте придумывают сами!) работать вместе без противоречий, особенно на стыках архитектуры, организации и методологии. Поэтому “конкуренты” остаются на другом уровне, FPF тут трансдисциплинарен, “по ту сторону”:
– если вы опираетесь на онтологии, то они “описывают мир”, а FPF описывает, как мыслить о мире. FPF задаёт первичные принципы мышления о мире, предписывает искать какие-то объекты в мире, а не просто сообщает, какие объекты бывают и как их получше описать.
– если вы опираетесь на процессные инженерные стандарты, то забудьте про предметную суть вашей системы, там лишь общие слова (даже движение agile начинало с равной роли инженерного и менеджерского знания, а затем свалилось в “процессы” и чистый менеджмент, инженерия оказалась “за бортом”). FPF увязывает мышление и действие системы-создателя и поведение создаваемой системы (у которой мышление может и быть, например, мышление AI, но может и не быть – даже если это космический корабль).
– если речь идёт об архитектурных стандартах, то у вас не будет ни онтологий, ни общего хода инженерного процесса. FPF отлично справляется с архитектурой, которая по определению вынуждена работать на стыках с самыми разными инженерными специализациями, а в силу закона Конвея ещё и стыкуется с организационной архитектурой. И ещё FPF поддерживает нарождающуюся роль прикладного методолога, которой пока никто не озабочен. А ведь “прикладность” в крупном проекте тоже междисциплинарна!
– если речь идёт об общем интеллекте, то вас научат физике-математике - а с тем, как работать, будет опущено. FPF вполне дружит с физикой и математикой, но не останавливается на этом. С ним можно и в исследования (например, в эволюционную биологию eco-evo-devo), и в работу и даже в личное развитие.
– что делать с AI, который крайне мультидисциплинарен, не говорится вообще нигде. FPF тут поддерживает вот эту мультидисциплинарность: вы можете подгрузить FPF искусственному интеллекту, и вы обсудите сложные вопросы “на стыке дисциплин” на одном с ним языке. К мультидисциплинарной команде это тоже относится: вы подгрузите в головы членам команды FPF (сейчас ближайшее к нему приближение – это руководства по программе рабочего развития), и дальше сможете с командой обсуждать проблемы “на стыках” на одном общем языке. И, конечно, это “минимальный язык”: первые принципы, которых не так много.
Метафор для FPF можно придумать много: это и “мышление оркестратора мультидисциплинарных проектов”, и “операционная система мышления для совместной работы множества прикладных процессов мышления и деятельности”. FPF задаёт “чек-лист мышления”, поэтому проект не теряет цель, обоснования, ресурсы, конфликтов системных уровней, и всё это даже на стыке дисциплин — там, где классические онтологии, процессные и архитектурные стандарты, инженерные корпуса знаний молчат о «почему» и «кому доверять». Первые принципы - это ab initio, “до опыта” (погуглите или спросите у AI-агента), то есть “до входа в проект”: зная первые принципы из фреймворка, вы будете уже знать о проекте и о том, как действовать в проекте ещё до момента первого с ним знакомства. И это позволит сориентироваться в проекте раньше других, вы будете конкурентоспособны даже внутри команды проекта! FPF не выполняет работу за вас, но усиливает вашу способность управлять неминуемой проектной сложностью, задавать правильные вопросы (чек-листы!) и принимать быстрые, обоснованные и проверяемые решения. В мире, где цена ошибки из-за недопонимания между командами может стоить недель, месяцев или даже лет работы, FPF предлагает страховку в виде ясности мышления и общего языка, общей для команды картины мира.
Почему плохо понятно то, что я делаю
Разговор о приготовлении борща, картины приготовления борща – всё это не напоминает разговоры о поедании борща и картины поедания борща. Разговор о создании ракеты с космическим кораблём, картины их изготовления – всё это не напоминают разговоры космонавтов и картины полёта ракеты и космического корабля. Разговор о создании FPF, картины разразботки FPF – всё это не напоминает разговоры об использовании FPF конкретными людьми в конкретных проектов, не напоминает картин проектного окружения, в котором уместно использовать FPF.
То, что я сейчас делаю, пока интересно только:
– онтологам, а их на планете очень немного. Вы даже фамилии нынешних знаменитых онтологов назвать не сможете, так ведь? Ну, разве Аристотеля вспомните, но он же помер давно. Это всё “работники производственной закулисы”.
– эпистемологам, а их на планете даже меньше, чем онтологов. Тут вы можете вспомнить Поппера и Куна, но они тоже умерли. Опять же, предмет онтологии хоть как-то понятен, а предмет эпистемологии (и инженерии знаний) мало кому понятен и интересен (хотя со знаниями вроде все работают).
– методологам, ибо речь идёт о методах мышления. Но кто себя осознаёт профессиональным методологом? Из современных методологов кого знаете? А ведь прикладная методология - ей многие занимаются профессионально, процессы-то многих интересуют, принципиальные схемы многих интересуют. Но нет, FPF трансдисциплинарен, поэтому он “по ту сторону” (транс-) от прикладной методологии.
– … я мог бы продолжать и продолжать, ситуация везде одна и та же. Мой проект в его текущем состоянии (“создать FPF”) интересен немногим.
Но вот в ситуации использования всё волшебным образом меняется. Это мы видим с предыдущим поколением методов фундаментального мышления, которые документированы в руководствах МИМ по рабочему (Памятка по программе рабочего развития инженеров-менеджеров МИМ: ailev — ЖЖ) и исследовательскому (Памятка по программе исследовательского развития инженеров-менеджеров МИМ: ailev — ЖЖ) развитию инженеров-менеджеров.
Поэтому я продолжу с разработкой, буду писать “на птичьем”. Но довольно скоро буду говорить “на понятном”: обсуждать ситуации использования. Хотя тут немного лукавлю: FPF всё-таки останется “для себя” или “для своих в команде”, а вовне будет звучать “обычный язык, как везде”. Но “внутри себя” или “внутри команды” (в случае использования в команде) будет звучать более точный язык, направляющий внимание к важному и отвлекающий от неважного.
Что я сделал за последние три дня, где подглядеть результаты
Так, я сделал десяток ADR по довольно-таки радикальным решениям (Набор ADR для улучшения FPF до draft 20jul25.md — Яндекс Диск):
++ ADR-0 Architecture Decision Record: “Architheories” and the Three-Class Taxonomy
++ ADR-1: Интеграция семантического треугольника в определение Episteme
– ADR-2: Расширение мереологии знания композиционными отношениями
– ADR-3: Группировка эпистемических осей KDF в подпространства (введение субшкал надёжности)
– ADR-4: Рекурсивная самооценка спецификации FPF как эпистемы
– ADR-5: Введение понятия пространства характеристик (Characteristic Space)
++ ADR-6: Переименование U.Dimension в U.Characteristic и унификация терминологии осей
++ ADR-7: Введение Lexical Framework (LexF) для управления лексикой и терминами
– ADR-8: Адаптация всех модульных спецификаций FPF к новым понятиям Characteristic и LexF
– ADR-9: Возможность специализированных пространств характеристик и новых фреймворков на их основе
Плюсиками там обозначены ADR, которые более-менее реализованы (хотя не все полностью), при этом терминология исходного файла полностью поплыла, и после реализации трёх ADR мне пришлось сделать переименования в текстах оставшихся семи (переделанные ADR вот тут: Вторая волна ADR для улучшения FPF до draft 20jul25.md — Яндекс Диск).
Получившийся файл спецификации FPF (FPF specification (full draft 20jul25).md — Яндекс Диск) имеет следующие отличия по сравнению с версией трёхдневной давности:
– в нём уже не ядро-модули-фреймворки-фасеты, ибо это “конструктивы” с намёком на разное назначение, а содержательные наименования эпистем: ядро (куда ж без этого, kernel) и архитеории (архи- и от архитектуры, и от архетипов, и от архиважности). Архитеории – это по факту транс-теории. Трансдисциплины - это очень широко, у нас сильно поуже, а просто теории - это ведь прикладные, а нам надо именно трансдисциплинарные теории, но транс-теории как-то плохо звучат. Быть поближе к “архитектурности” – хорошо, у нас там ещё и архитектурные характеристики потом будут, так что сделали шаг к этому. Архитеории бывают исчислениями (которые безмасштабные, с оператором агрегации и композициями) и не-исчислениями (которые работают на одном масштабе, у них нет оператора агрегации для их объектов). Не-исчисления бываю (пока, а там посмотрим) логиками (скажем, логика аргументирования: там где делаются какие-то выводы) и характеризациями (скажем, характеризация измерений и метрик: там, где вводятся какие-то специализированные свойства и характеристики).
– добавлена новая архитеория: лексическая характеризация
– все Dimensions заменены на Characteristics (для физиков и геометров Dimension осталось как синоним, но основное слово - характеристика, и там ещё надо будет помучиться с нюансами, а также группированием характеристик в пространства, они ж будут ещё осями в пространстве, измерениями/Dimensions. Заодно в лексической характеризации правило: если вводится какой-то термин, то из всех синонимов основным делается тот, который использует максимальное число пользователей (и специально оговорено, что формалисты будут довольствоваться синонимами, а не рулить основными значениями: их мало, и надо с них тельняшки снять. Они делают полезную работу, но пускать их к людям с их птичьим языком надо аккуратно, контролировать). В любом случае, для лексической характеризации явно оговаривается, что терминология будет меняться (возможно, меняться часто).
– эпистема теперь представляется как семантический треугольник (треугольник Фреге). Там вышла сложная история (ибо вводить отдельный U.Type - это была забастовка всей нежити против “лишних понятий”, требование ввести атрибуты эпистемы было заблокировано мной - ибо когда-то EPISTLE заметил, что “что в одном проекте атрибут - в другом полноценный объект, и наоборот”, а победила странная конструкция с объявлением трёх ролей (object, concept, symbol) по отношению ComponentOf. Примером там набор разных теорий относительности с разными их изложениями. Всё это моделируется триплами и очень громоздко, но уж как получилось. Дальше будут композиционные отношения (пара отношений RepresentationOf и UsageOf), потом введётся пространство характеристик для каждого из углов треугольника.
Дальше надо будет разобраться с характеристиками, шкалами, метриками, осями и всем получившимся немаленьким хозяйством (переписывать придётся огромными кусками), а дальше разобраться с архитектурной архитеорией (и там будет функциональность-конструктивность) и унификационной теорией (там будет оркестровка задействования фреймворков). Какие-то предварительные заделы на эти темы уже есть. Но там ещё много и другой работы.
Пока у меня главная задача – собрать всё важное в один файл, заведомо криво и с ошибками, зато очень быстро. После этого будет хорошо понятно, что именно я сделал и как это использовать. Без такого файла я могу сколько угодно рассказывать про великие замыслы, они будут банально непонятны.
Как пользоваться? Подгрузить в LLM файл спецификации FPF, дальше задавать вопросы про ваши проекты, но просить отвечать “с учётом FPF”. А если там будут отвечать непонятно, то просить объяснить на простом языке “как менеджеру”. Никаких специальных промптов не надо.
На картинке зарисовка алхимика, изготавливающего FPF, а кто дочитал до этого места – бонус. Вот статья, показывающая, что в термоядерном реакторе можно из ртути делать золото в промышленных количествах, что существенно меняет экономику проектов с термоядом. Электричество дёшево, а вот золото – нет. С другой стороны, если золото будут не “добывать”, а “изготавливать”, оно тоже станет дешёвым. По Tony Seba подрыв под всем миром наступает не столько из-за отдельных технологий, сколько из-за их “конвергенции”. AI помогает удерживать плазму в термоядерных реакторах, которые будут и добывать золото, и генерировать электричество, которое будет потреблять тот же AI. По предварительным расчётам прибыльность термоядерных реакторов за счёт этой алхимии поднимется вдвое. Вот, “Scalable Chrysopoeia via (n, 2n) Reactions Driven by Deuterium-Tritium Fusion Neutrons” – [2507.13461] Scalable Chrysopoeia via $(n, 2n)$ Reactions Driven by Deuterium-Tritium Fusion Neutrons (сайт разработчика: https://www.marathonfusion.com/).
