Анатолий Левенчук – Методология 2025 (страница 19)

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

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

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

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

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

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

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

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

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

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

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