Представление метода работы как алгоритма: методология как алгоритмика-на-стероидах

Материал этого раздела весьма сложен, может оказаться, что вам нужно освежить азы алгоритмики. Как минимум, вы проходили алгоритмику в школе, возможно, сдавали по ней ЕГЭ, но методология требует, конечно, не школьного понимания алгоритмики. Увы, даже азам алгоритмики мало где учат. Мы можем указать на руководство по интеллект-стеку и там на дополнительные материалы^[1]. Посмотрите там, чем же занимается алгоритмика. Конечно, программистам материал этого раздела будет понимать легче, но наш опыт показывает, что и это не всегда так: материал отсылает не к «программистскому опыту», а к теоретическому знанию — объяснениям азов алгоритмики в её связи с математикой и физикой. Увы, этому даже в вузах учат отнюдь не всех «программистов с высшим образованием».

Мастерство выполнения метода — программа, которая описана алгоритмом. Мы пока опустим тот нюанс, что алгоритма совершенно недостаточно для описания программы, ибо программа — это алгоритм плюс структуры данных^[2], да ещё и реализованные каким-то вычислителем (подробней это обсуждалось в руководстве по системному мышлению). В случае методов мы говорим, что создатели — это обобщение «вычислителя» до «создателя» (то есть не только работаем с данными на входе и получаем данные на выходе, но берём какие-то предметы метода на входе и получаем предметы метода на выходе — делаем физические преобразования). Так что «программа метода» понимается не просто как «вычислительная программа», а как «преобразовывающая мир», «программа для станка с ЧПУ» в простейшем случае. А если создатель умный и эта программа — алгоритм в мокрой нейросети, или даже гибридной нейросети предприятия, то мы назовём её «мастерство». Это неважно, что гибридная нейросеть предприятия состоит из мокрых нейросетей множества людей и компьютерных сухих нейросетей плюс множества баз данных и классических компьютерных программ, а ещё станков в поддержку как вычислений, так и преобразований физического мира. Всё равно можно говорить о мастерстве предприятия, например, о мастерстве разработки ракет компанией SpaceX («мастерстве в выполнении работ по методу разработки ракет»).

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

С подробным описанием метода плохо справится даже граф (визуально это будет «диаграмма», «принципиальная схема» и небольшое количество типов узлов графа и типов рёбер графа), но хорошо справится алгоритмическое представление в виде:

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

И тут важная особенность: разложение метода очень плохо прописывать императивно (как пошаговое выполнение каких-то отдельных операций), но хорошо прописывать функционально или в какой-то другой парадигме вычислений (в нашем случае — обобщённых вычислений, с выходом в изменения физического мира и получением информации замерами состояний предметов метода в физическом мире). В программной инженерии есть огромное число обсуждений того, чем лучше и чем хуже декларативное программирование по сравнению с императивным. Первый же аргумент против декларативного программирования, из вариантов которого наиболее проработано функциональное программирование — оно слишком сложное. Вот пример декларативного и императивного подхода к разложению методов «варка борща» и «нахождение клада» из текста, который так и озаглавлен «Почему функциональное программирование такое сложное»^[3]:


Решаем задачу	императивно	декларативно
Найти клад	Если на улице дождь, надень куртку, выйди из дома, пройти 100 шагов на север, 200 на восток, возьми лопату, копай пока не наткнешься на клад	Достань подходящим инструментом из земли клад, прибыв на координаты (Lat, Lon) в подходящей одежде.
Сварить борщ	Помой морковь, почисти лук. Обжарь их на сковороде в подсолнечном масле. Свари бульон на мясе, вынь мясо, положи туда обжаренные лук и морковь. Порежь картофель и свёклу, брось в бульон. Вари 20 минут.	Вари до готовности содержимое кастрюли, наполненной бульоном из-под сварившегося мяса, в которую положил порезанные и чищенные картофель со свёклой и обжаренные в подсолнечном масле порезанные чистый лук и морковь.

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

В самом тексте делается попытка объяснить программистам, что же такое функциональное программирование, и зачем оно нужно (таких текстов тысячи!), и зачем там вообще нужна математика, включая не самый её простой раздел — теория категорий^[4]. Автор руководства многократно сталкивался с тем, что профессиональные программисты буквально сражаются за то, чтобы разобраться с функциональным программированием, оно очень нелегко даётся. Но те, у кого произошла метанойя (термин объяснялся в «Системном мышлении») уже не помнят, что там у них было сложного — поэтому комментарии к этим всем статьям разнятся от «всё равно сложно, ничего не понял» от новичков до «зачем это разжёвывать, ничего сложного» от давно прошедших метанойю.

Тут можно напомнить, что когда-то школьное программирование вводилось в школах СССР в 1985 году ровно как попытка научить школьников планировать какие-то последовательности действий с условиями, описывать какое-то поведение. Под планированием имелось в виду не ресурсное планирование, то есть составление плана-графика (кто когда что с чем делает), но как раз методологическая работа — описание того, что вообще надо делать. В обосновании звучало, что выражению алгоритма как описанию каких-то действий (слово «метод работы» тогда не звучало, в лучшем случае звучало «описание работы», а не «описание методов работы») не учат ни в одном предмете, изучаемом в школе — физика, математика, география и любой другой предмет мог сам рассказывать о каких-то методах работы, но вот записать какой-то метод работы хоть в каком-то формальном виде ни один предмет не учил. Как и во всём мире для обучения школьников, для выражения алгоритма был выбран императивный язык.

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

Так что для возвращения тематики «обучения составлению алгоритмов выполнения работ» в обучение программированию нужно сделать довольно много:

Сразу вводить понятие метода как работ не только с описаниями (абстрактными объектами, информацией, работы с данными — «компьютерное программирование»), но и с предметами метода. Алгоритмика не компьютерная, а созидательная (программирование создателей/constructors из теории создателей).
Добавить обсуждение работы с типами предметов метода (а не только типами данных и структурами данных), ибо программа = алгоритм плюс данные.
Алгоритмы надо будет выражать на декларативном (скорее всего, функциональном) языке. Хотя, по большому счёту, нужно владеть мультипарадигмальным программированием — ибо для разных вариантов алгоритмов удобней разные варианты парадигм программирования^[5], отражённые в разных языках программирования, всё большее число современных языков программирования сегодня — мультипарадигмальные языки, поддерживают и процедурную, и функциональную парадигмы.
Придётся освоить азы математической теории категорий и конструктивного математического мышления, это нужно для глубокого понимания природы функционального программирования, а также природы компьютерных вычислений в связи с эквивалентностью всех возможных вычислений по каким-то алгоритмам на машине Тьюринга: логическое программирование (декларативное программирование логических рассуждений), функциональное программирование (декларативное программирование выполнения функций, в том числе функций над функциями), объект-ориентированное программирование, процедурное программирование, акторское программирование, аспектное программирование и т.д. — это просто разные способы описания разложения одного и того же метода.

Алгоритмика сама по себе связана как с выражением способа вычислений на языке какой-то парадигмы (выражение способа — это методология), так и скоростью вычисления (это операционный менеджмент, исследование операций), что зависит от физики компьютера. Так что алгоритмика — экспериментальная наука, физика компьютера вносит реализм, а формальность вычисления — математику. Поскольку каждая программа — это доказательство (соответствие Curry-Howard^[6]), то соответствие физического процесса в компьютере (классическом, квантовом, оптическом и т.д.) и абстрактного процесса вычислений «в математике» может быть проверено только экспериментально, через экспериментальную науку. Deutsch прямо называет алгоритмику «наукой о доказательствах», ведь программы — это доказательства, конструктивная математика — это программирование, и дальше через алгоритмику можно делать ходы на выполнение доказательств (алгоритмов) на компьютерах, проекты унивалентных оснований математики и языков Agda и Coq как раз нацелены на помощь математикам со стороны компьютерной техники (подробней об этом — в руководстве по интеллект-стеку, и там много ссылок на литературу).

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

Алгоритмика должна экспериментально подтверждать, что алгоритм эффективно выполним на каком-то железе. В силу no free lunch theorem нет универсально быстрого алгоритма для всех задач, для разных ситуаций будут эффективны разные алгоритмы, а разница в эффективности алгоритмов на разном «железе» с разной физикой может быть драматической, в пересчёте на методы — это как копать котлован лопатой по сравнению с экскаватором, по сравнению с гидромеханическим размытием, по сравнению со взрывным способом. Методология с задействованием исследования операций в паре с операционным менеджментом должна экспериментально подтверждать, что создатель с его мастерством (реализованным тоже аппаратно!) и инструментарием (tooling), реализуя метод, будут получать результаты заданного качества/точности (предметы метода в заданном состоянии) в приемлемое время и при приемлемом расходе ресурсов. В алгоритмике говорят, что синтез алгоритмов должен быть hardware aware для того, чтобы алгоритм был эффективен. Вот и метод должен быть оптимизированным по инструментам (hardware aware), то есть учитывать наличные особенности инструментария, включая аппаратуру для мастерства как «управляющей программы».

Алгоритм — это вроде как последовательность вычислений, а тут — последовательность каких-то трансформаций для создателя, обобщение алгоритма для вычислителя (машины Тьюринга) на материальный/физический мир. И тут надо разбираться с теоретическими обобщениями, например, constructor theory^[7] как обобщения машины Тьюринга как универсального вычислителя в сторону универсального преобразователя. С помощью подобной теории мы можем пробовать выдать какие-то достижения современной алгоритмики за начальные идеи в методологии, мы вполне можем понимать алгоритмы как «алгоритмы в том числе для станка с ЧПУ» и теории не математические, а вполне себе теории про реальный мир.

Вполне можно рассматривать методологию как учение по «программированию роботов и людей» (включая «нейролингвистическое программирование» людей в его оригинальном понимании, как бы оно ни было скомпрометировано, и современный prompt engineering систем AI). Эта идея тоже может быть обобщена и на организации. Скажем, какой-нибудь стадион со всем его персоналом и сооружениями — робот, хотя и неантропоморфный. Этот робот выполняет работы по каким-то методам (описанным алгоритмами разной степени формальности), чтобы как-то загнать в себя несколько десятков тысяч человек, малая часть из которых будут развлекать другую часть, затем провести развлечение, включая пропуск только по билетам, затем кормление всей этой толпы, физическую безопасность, предоставление услуг туалетов. Часть оборудования робота-стадиона — живые люди, которые ещё не заменены каким-то оборудованием, но они выполняют относительно простые программы. Надо понимать, какими методами работает такой робот, как эти методы непротиворечиво описать и поставить, как отследить их выполнение, как разработать и построить такого робота, как эксплуатировать такого робота — и это «как» тоже про методы, и это тоже про общую алгоритмику, ибо выполнение должно быть эффективно при заданном качестве выполнения! И ещё «цифровая трансформация стадиона», то есть сдвиг выполнения методов работы в стадионе с людей на какое-то оборудование.

В существенной мере алгоритмы методов работы зависят от представления/representation знаний о предметной области: алгоритм сложения чисел с мастерством, реализующимся мокрой нейронной сеткой в человеческой голове, даже при условии её усиления ручкой-бумажкой для безошибочно работающей памяти и облегчения удержания внимания существенно зависит от нотации. В римской нотации всё плохо, а в арабской^[8] нотации (позиционная запись и явно представленный ноль) — даже дети справляются не только с умножением десятизначных чисел, но и с делением, что казалось бы чудом ещё тысячу лет назад. Есть разница с нотациями, которые пригодны для непосредственно мышления об объектах (операции со знаками соответствуют операциям в реальном мире — вот как с арабскими цифрами, «рассуждение легко алгоритмизируется»), и «описаниями» каких-то операций в естественном языке или даже псевдокоде, которые не так-то легко алгоритмизируются^[9]. Хорошие нотации позволяют описать простые одинаковые последовательности операций с предметами метода для получения конечного состояния предметов метода. Плохие нотации заставляют каждый раз изобретать последовательность операций — это возможно, конечно, но только самым одарённым. А вот не для самых одарённых (тем более для компьютеров!) надо бы делать операции простыми и одинаковыми. Можно не «творить» каждый раз, а просто «посчитать по предлагаемой инструкции счёта». Не делать догадки и опровергать их, а просто «взять входные значения и без содержательного разбирательства с ними механически посчитать выходные значения».

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

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

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

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

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

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

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

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

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

Начальная путаница с методами происходит от типовых онтологических ошибок. Скажем, метод завязывания шнурков — это метод работы по завязыванию шнурков агентом, причём это само завязывание шнурков (паттерн действий в реальном мире) в его содержательной части. А описание метода — это алгоритм, оно же теория, оно же объяснение. Ввиду массовой путаницы между описаниями и реальной жизнью у методологов-аналитиков, а также часто у программистов (они работают с «данными», а не с «жизнью») обсуждения реальности не происходит, рабочий процесс вдруг оказывается «описанием», а не тем, что происходит в жизни, алгоритм путается с мастерством (программой на каком-то компьютере, то есть путаница с вычислителем, выполняющим алгоритм), статус алгоритма как описания/объяснения/теории исчезает.
Метод описывается алгоритмом, а алгоритм — это одновременно и теория, для объяснения надо разбираться в конструктивной математике, соответствии Curry-Howard и прочих основаниях математики и computer science.
Более того, это не просто алгоритм действий с данными, а алгоритм действий в реальном мире, и это тоже трудно понимается. Речь идёт об идее 4E (extended, embedded, embodied, enactive) cognition^[15], и это алгоритмы роботов с датчиками и актуаторами (станка с ЧПУ в простейшем случае), а не алгоритмы классического компьютера. Иногда это алгоритмы, реализуемые вычислителями на мокрой нейронной сетке (у людей) и задействующие сложные инструменты (станки), и ещё и многоуровневые (скажем, ваш заказ пиццы по каким-то методам в пиццерии обрабатывает довольно много людей и компьютеров, а также довольно много разного кухонного оборудования). Об этом трудно думать как-то в общем виде. Но именно такие размышления «в общем виде» позволяют переносить найденные в одних предметных областях методологические решения в другие предметные области. В частности, в ходе цифровой трансформации надо как-то сдвигать выполнение работ с физических двойников на цифровые двойники (например, подстройку режимов работы), а с людей на роботов. Это требует единообразного описания методов работы софта, людей, станков и даже AI-агентов.
Трудность ещё и в том, что разложение алгоритма представляется как код — и понимание разных парадигм этого разложения алгоритма трудно, с мультипарадигмальным программированием с трудом справляются и профессиональные программисты. Автор этих строк знает огромное число программистов, которые в начале своей работы буквально страдали, пытаясь писать объект-ориентированно, но выдавая императивный код, а когда речь шла о переходе на функциональное программирование, например программирование на Haskell, имели вообще непреодолимые трудности. Даже если прорваться через типизацию объектов (что тоже проблема для многих людей — поэтому-то и нужно использовать трюки типа «онтологического дребезга» и всякие другие альтернативные интерфейсы к мокрой нейросетке новоявленного методолога), то прорваться через функциональную парадигму будет очень трудно. Та же печальная судьба трудностей в изучении постигла средства логического программирования (прежде всего Prolog, но дальше и Agda^[16], и Coq^[17] — они считаются ещё более трудными в изучении, чем средства функционального программирования, ибо могут рассматриваться и как функциональные языки, и как логические языки с зависимыми типами^[18]). Радикальное решение тут — сразу учить конструктивизму, конструктивной математике, теории категорий, гомотопической теории типов. Но это оказывается ещё труднее, чем учить распространённым функциональным и логическим языкам программирования. В любом случае, пошаговые представления метода хорошо применимы в мизерном количестве случаев, сама методологическая/функциональная действительность требует функциональных/декларативных представлений, а не императивных/процедурных. Рабочий процесс какого-то завода нельзя разложить на более мелкие рабочие процессы — и так довести это разложение до рабочих процессов, выполняемых отдельными людьми, если использовать идею «пошагового выполнения процесса», ничего не получится.

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

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

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

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

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

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

Представление метода работы как алгоритма: методология как алгоритмика-на-стероидах ​

Представление метода работы как алгоритма: методология как алгоритмика-на-стероидах