Хорошие нотации тут как иероглифические системы, они не соответствуют текстам на естественном языке – японец и испанец прочтут 2+2=4 абсолютно по-разному, а выполнят – одинаково. Но особенность хороших нотаций не в том, что они именно «иероглифичны». Иероглифы могут быть использованы или как знаки для описания чего-то другого, или они сами могут быть объектами, с которыми ведутся манипуляции по известному уже алгоритму, без шага стратегирования (придумывания алгоритма) и планирования (уточнения того, когда что с чем надо сделать, чтобы получить результат эффективно) – нас интересует «непосредственное манипулирование». В методологии всё то же самое, но нотации будут не только для абстрактных понятий, как в математике, но и для предметов метода. Скажем, нотация чеклистов с контрольными вопросами оказывается удобной для контроля достижения состояний предмета метода: это не просто какое-то длинное текстовое описание, но буквально чеклист, в нём есть место, куда поставить птичку «выполнено». Это тоже нотация.

Дальше по этой линии идёт DDD (domain driven design, где объекты реального мира сопоставляются объектам программы, как минимум – моделируются структурами данных), и дальше вычислитель с этими данными сам по себе становится объектом реального мира, а не просто работает с описанием объекта – это линия как «станка с ЧПУ», так и линия реестров и регистров. Если что-то поменялось в регистре, то это означает изменение в реальном мире, например, будет или не будет работать турникет допуска в помещение. Это всё важно для обсуждения тех методов, которые описываются в том числе и теорией речевых актов⁶⁷, то есть методы, включающие высказывание каких-то утверждений, которые по сути являются действиями (перформативы⁶⁸ – поручения, обещания, акцепты и прочие коммуникационные акты, которые меняют ситуацию, то есть являются поступками, а не «просто словами»). Например, работы по инженерии предприятия⁶⁹ Jan Dietz с коллегами как раз основаны на теории речевых актов.

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

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

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

Но можно применять и идеи автоматного программирования⁷⁰ (задействование «автомата» как машины состояний), использовав понимание, что предмет метода проводится через какие-то состояния в графе его состояний. Основная мысль тут: при любой попытке поднять формальность описания способа работы вы упрётесь в хорошее понимание программирования, хорошее понимание алгоритмики в плане парадигм программирования (выражение алгоритмов) и определение сложности «созидательных программ» (обобщение компьютерных программ на программы для создателей), чтобы оценить потребные ресурсы и оценить время выполнения работ по методу.

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

А пока подчеркнём, что при попытках записи каких-то методов надо бы обращать внимание на алгоритмику и её опыт.

Автор этих строк в качестве первого рабочего задания после университета (1980 год) получил задание создать язык для описания строительства здания – и не знал, что он попал в отдел, который как раз занимается проблемами AI на базе класса систем, известных как «фреймовые»⁷¹ (кодирование методов в структурах данных для «стереотипных ситуаций»). Постановка проблемы была примерно такой: «давай опишем алгоритм строительства дома на каком-то языке. Но мы знаем продолжительность каждой операции и требуемые ресурсы – для этого у нас есть СНиПы, строительные нормы и правила. Затем мы просто посчитаем длительность стройки в компьютере. Так что дай нам соответствующий язык описания». Конечно, в головах у всех в 1980 году был именно императивный подход к таким описаниям – который доблестно провалился, поэтому и обратились к фреймовому подходу в AI. Но как описывать эти «фреймы» и как находить их в жизни? Попытки сначала сделать язык для чего-то маленького (конечно, автор через пару недель попытки описания стройки понял, что проблема пока никому не по зубам, хотя за неё брались многие – но был молод и не отчаивался, поэтому просто решил пойти через решение более простых проблем), например, сделать язык формального описания для книг кулинарных рецептов, тоже ни к чему не привели. И только после многих лет автору стало понятным, почему всё было так плохо и почему идеи методологии трудно показать в их формализме на уровне, достаточном для автоматической/машинной реализации метода (а ведь вся цифровая трансформация – она про это!):

• Начальная путаница с методами происходит от типовых онтологических ошибок. Скажем, метод завязывания шнурков – это метод работы по завязыванию шнурков агентом, причём это само завязывание шнурков (паттерн действий в реальном мире) в его содержательной части. А описание метода – это алгоритм, оно же теория, оно же объяснение. Ввиду массовой путаницы между описаниями и реальной жизнью у методологов-аналитиков, а также часто у программистов (они работают с «данными», а не с «жизнью») обсуждения реальности не происходит, рабочий процесс вдруг оказывается «описанием», а не тем, что происходит в жизни, алгоритм путается с мастерством (программой на каком-то компьютере, то есть путаница с вычислителем, выполняющим алгоритм), статус алгоритма как описания/объяснения/теории исчезает.

• Метод описывается алгоритмом, а алгоритм – это одновременно и теория, для объяснения надо разбираться в конструктивной математике, соответствии Curry-Howard и прочих основаниях математики и computer science.

• Более того, это не просто алгоритм действий с данными, а алгоритм действий в реальном мире, и это тоже трудно понимается. Речь идёт об идее 4E (extended, embedded, embodied, enactive) cognition⁷², и это алгоритмы роботов с датчиками и актуаторами (станка с ЧПУ в простейшем случае), а не алгоритмы классического компьютера. Иногда это алгоритмы, реализуемые вычислителями на мокрой нейронной сетке (у людей) и задействующие сложные инструменты (станки), и ещё и многоуровневые (скажем, ваш заказ пиццы по каким-то методам в пиццерии обрабатывает довольно много людей и компьютеров, а также довольно много разного кухонного оборудования). Об этом трудно думать как-то в общем виде. Но именно такие размышления «в общем виде» позволяют переносить найденные в одних предметных областях методологические решения в другие предметные области. В частности, в ходе цифровой трансформации надо как-то сдвигать выполнение работ с физических двойников на цифровые двойники (например, подстройку режимов работы), а с людей на роботов. Это требует единообразного описания методов работы софта, людей, станков и даже AI-агентов.

• Трудность ещё и в том, что разложение алгоритма представляется как код – и понимание разных парадигм этого разложения алгоритма трудно, с мультипарадигмальным программированием с трудом справляются и профессиональные программисты. Автор этих строк знает огромное число программистов, которые в начале своей работы буквально страдали, пытаясь писать объект-ориентированно, но выдавая императивный код, а когда речь шла о переходе на функциональное программирование, например программирование на Haskell, имели вообще непреодолимые трудности. Даже если прорваться через типизацию объектов (что тоже проблема для многих людей – поэтому-то и нужно использовать трюки типа «онтологического дребезга» и всякие другие альтернативные интерфейсы к мокрой нейросетке новоявленного методолога), то прорваться через функциональную парадигму будет очень трудно. Та же печальная судьба трудностей в изучении постигла средства логического программирования (прежде всего Prolog, но дальше и Agda⁷³, и Coq⁷⁴ – они считаются ещё более трудными в изучении, чем средства функционального программирования, ибо могут рассматриваться и как функциональные языки, и как логические языки с зависимыми типами⁷⁵). Радикальное решение тут – сразу учить конструктивизму, конструктивной математике, теории категорий, гомотопической теории типов. Но это оказывается ещё труднее, чем учить распространённым функциональным и логическим языкам программирования. В любом случае, пошаговые представления метода хорошо применимы в мизерном количестве случаев, сама методологическая/функциональная действительность требует функциональных/декларативных представлений, а не императивных/процедурных. Рабочий процесс какого-то завода нельзя разложить на более мелкие рабочие процессы – и так довести это разложение до рабочих процессов, выполняемых отдельными людьми, если использовать идею «пошагового выполнения процесса», ничего не получится.

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

Например, по данным Американской ассоциации психологии с 1993 года было опубликовано около 39000 новых конструктов и 43000 новых методов⁷⁶. Более половины этих методов никогда не использовались за пределами своей первоначальной статьи, в которой они были представлены. Можно поглядеть, как выглядит картинка «методов в психологии» – интерактивная карта со ссылками на оригинальные описания предложенных методов психологической работы⁷⁷.

Это дополнительная сложность для прикладных методологов: если вы хотите как-то связно рассуждать про «методы в психологии», то вам надо понять, как вообще этому многообразию методов учить, как понять, что там важно, а что не очень. Распространённость методов тут не очень поможет. Так, теория флогистона и теория эфира когда-то были в физике тоже чрезвычайно распространены вместе с базирующимися на них методами описаний мира, а термодинамика едва-едва появилась, и была крайне контринтуитивна в понимании. Впрочем, и сейчас можно утверждать, что термодинамика контринтуитивна, идеи флогистона и эфира много легче в понимании, но термодинамические расчёты работают, а расчёты по теориям флогистона и эфира – нет. В случае теорий менеджмента или теорий психологии так однозначно сказать о работающих или не работающих методах – нельзя.

То же самое разнообразие методов наблюдается сегодня во всех предметных областях, например, методах создания систем AI, и даже в самих методах физики, и даже в методах самой методологии, да и в кулинарии – число рецептов как методов готовки конкретных блюд огромно, различать их трудно. Похоже, с таким многообразием должны работать не люди, а какие-то системы AI – и даже в случае AI нет впечатления, что можно эффективно участвовать в этой эволюции методов, ведь каждый день надо будет отслеживать появление сотен новых методов, придуманных как людьми, так и AI – и тут же запатентованных как smart mutations по отношению к предыдущему методу. Патенты ведь – это тоже описание методов работы, «как работает» (и сложность их текста показывает, что методы крайне сложно описывать формально). Но как определить, каким патентом стоит воспользоваться, а какие патенты уже устарели?

В этом месте любой человек, разбирающийся с методологией вообще и методологией прикладной предметной области говорит «Ааааа!» и хватается за голову. Много легче жить, когда просто не знаешь о всех этих трудностях. Как обычному человеку совладать с таким объёмом знаний в каждой предметной области, как стать методологом какой-то прикладной предметной области? Этот вопрос остаётся открытым.

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