Метод работы как предмет методологии
Для того, чтобы «спастись», агенту нужно как-то трудиться (тратить ресурсы на достижение результата), чтобы на основе имеющихся (часто — альтернативных, несколько гипотез!) моделей себя и мира добыть данные о состоянии себя и мира, а затем трудиться, чтобы (разделение себя и мира — это как раз системный подход, «внутри границы системы» и «окружение/среда системы»):
- Улучшить модели/теории/объяснения себя и/или мира (выбрать новую модель/теорию/объяснение как SoTA, и дальше принять её всерьёз) — труд познания.
- Улучшить себя и мир (физически изменить себя и/или мир, чтобы предотвратить наступление неприятного сюрприза, уменьшить неопределённость) — инженерный труд.
И мы помним, что по большому счёту раньше в прагматицизме, который считает «практику критерием истины» упор делался на познание и эксперимент (изменение мира, чтобы получить данные для проверки теории) как критерий для выбора лучших объяснений, а теперь упор делается на само изменение мира к лучшему, для которого должны делаться объяснения — и поэтому труд познания подчиняется инженерному труду.
В любом случае, мы должны запланировать какие-то действия/операции, чтобы получить какие-то изменённые состояния моделей/теорий/знаний (провести вычисление над знанием, чисто информационная работа). Это может быть или up-front планирование, или использование какого-то паттерна планирования из ранее удачных планов, или пошаговое планирование (планируем одно действие «на лету», затем выполняем, планируем следующее действие). Это подробно обсуждалось в разделах семантики, физики, математики, алгоритмики. Методология изучает распространение алгоритмики с «вывода на моделях» на «вывод на мире». По большому счёту, вычисления**—** это операции над изменением содержимого памяти компьютера/вычислителя с одного устойчивого состояния на другое**, проводимые** для каких-то целей по какому-то алгоритму. Аналогично, работы — это операции над изменением каких-то частей мира агентом/работником (включая изменения в самом работнике как части мира), проводимые для каких-то целей по какому-то методу. Тем самым о методе/практике/виде труда в рамках разделения труда можно думать как об аналоге алгоритма, только речь идёт об изменениях мира какой-то ролью (роль в методологии — это аналог части вычислителя, настроенной на выполнение конкретного алгоритма, агент как изменяющий мир и себя в этом мире деятель выполняет работы по какому-то методу, задействуя свою роль как функциональную часть).
Например, книга кулинарных рецептов — это сборник описаний методов/практик приготовления пищи. Очень легко найти сходство с алгоритмами: описание алгоритмов на псевдокоде выглядит примерно так же. И такие же проблемы с нахождением элементарных операций: является ли элементарной операцией в компьютере умножение (в том числе умножение матриц)? В каком-то из языков программирования — да! Но эта элементарная операция оказывается вызовом подпрограммы из библиотеки, а там ещё будут вызываться и микпропрограммы внутри процессора! Точно так же и в практиках: все эти «печь пирог до готовности» неявно ссылаются на процедуры измерения готовности, которые считаются известными (скажем, протыкать пирог ножом или зубочисткой и смотреть на кончик — если в тесте, то пирог ещё не готов, а если без теста — уже готов). Или «пассировать овощи» неявно отсылает даже не к технике обжаривания нашинкованных овощей, а к технике шинковке — первое, чему учат поваров, это шинковать самые разные продукты быстро и безопасно.
Алгоритмы интересны тем, что для самых разных значений входных данных они выдадут правильный результат. Методы интересны тем, что для самых разных предметов, для которых они будут употреблены, они выдадут правильный результат. Алгоритмы чаще всего формулируются на формальном языке программирования, много реже — на «полуестественном языке», ещё реже — на естественном языке, хотя в Software 3.0 самый модный язык программирования — это как раз английский естественный язык. В методологии ровно наоборот: формальное описание изменения мира (например, программа для станка с ЧПУ) используется крайне редко, языки псевдокода — чаще, но чаще всего методы как некоторые паттерны описания операций/действий над предметами мира (и часто ещё и моделями этих предметов) описываются на естественном языке. Более того, очень часто эти методы есть (то есть паттерны действий существуют), но они нигде не описаны, а передаются «из уст в уста», или просто «обезьянничаются» (копируются с задействованием зеркальных нейронов[1]) людьми друг у друга.
Методология**—** это трансдисциплина о паттернировании в действиях создателей, а также о способах разделения действий между создателями. Нормативная версия методологии**—** это о том, какие именно паттерны действий создателей ведут к созданию успешных систем, и этот метод как рекомендуемый набор паттернов действия (практик) называется практикой системной инженерии.
Поначалу «методологией» называли только учение о методах познания/исследований, но в силу распространения прагматицизма речь пошла не только о создании моделей (включая проверку экспериментом), но и вообще о методах изменения мира, методах инженерии.
Методология даёт объекты управления вниманием, когда речь идёт о (прежде всего коллективной) деятельности агента-деятеля/практика, когда он добивается своих целей, изменяя окружающую его среду какими-то практиками/методами/способами работы. Агент, проводящий методологические рассуждения, выходящие в действия по изменению мира**—** практик/деятель**/инженер****.**
Главный объект, который изучает методология — это метод/способ осуществления/ведения какой-то деятельности/практики/труда. Иногда и сам метод ведения какого-то труда называют «методология», и приходится замечать, что есть, например, «методология сварки» и «методология операционного менеджмента» как «метод сварки» и «метод операционного менеджмента», а есть «методология» как трансдисциплина, изучающая методы ведения деятельности, способы организации коллективного труда (такие же проблемы, помним, были с именованием логики как трансдисциплины про правила рассуждений и логик как конкретных вариантов правил рассуждений, и те же проблемы с онтологией — это и трансдисциплина, и конкретный способ нарезки мира на объекты).
Методология описывает самые разные затраты ресурсов на получение результатов: и на моделирование себя и мира, то есть исследования, и на изменение себя и мира, то есть инженерию — какими бы разными эти модели и изменения ни были. Тем самым методология вынесена из прикладных практик в трансдисциплины.
Методология обсуждает (раньше человеческую, а теперь лучше говорить про просто) деятельность/труд/практику/способ выполнения работ на трёх уровнях:
- Личности — работы одного человека, ведущиеся каким-то способом. В принципе, можно выделять отдельные операции и способы их выполнения, можно считать, что личность выполняет множество ролей как функциональных частей личности, и уже эти роли выполняют те или иные практики, работают теми или иными методами.
- Организации: когда агенты договорились об общих целях и о том, кто будет какими ресурсами распоряжаться, и речь идёт об их кооперации в организации/проекте.
- Общества или сообщества: когда агенты не имеют шансов явно договориться о разделении труда, ибо отсутствуют общие цели. Например, агентов слишком много, или они плохо знакомы и не доверяют друг другу, или не согласны с самими принципами выбора целей. Достаточно предположить, что этих агентов/деятелей/практиков много: скажем, все люди с их компьютерами в одной стране, или даже в городе (даже и небольшом).
Сам термин «методология» чаще всего соотносят со второй ветвью, способ выполнения работ/ролевое разделение труда в масштабах какой-то организации. Организация — это когда известно, кто имеет какие права в распоряжении трудом и капиталом. Сто человек, которые попали со своими пожитками на необитаемый остров — это просто сообщество в сто человек, но не организация. Но если они договорятся как-то, кто может кому выдавать распоряжения по использованию их ресурсов, то тогда это будет организация.
Первая ветвь по факту рассматривает личность как сложную систему, в которой есть какие-то части личности, которые тоже надо как-то организовать на выполнение работ. Методология — важный предмет, для неё есть отдельный курс в Школе системного менеджмента. Но есть и курс «Системный менеджмент», где постоянно подчёркивается, что многие и многие методы работы с организацией могут быть использованы и для работы с личностью.
Третья ветвь методологии чаще всего называется праксиология, как общая теория деятельности. Она необходима для того, чтобы обсуждать те же самые вопросы разделения труда (способов достижения самых разных целей самых разных людей и их организаций) в условиях отсутствия организации, когда нет лиц, полномочных давать распоряжения по использованию труда и задействованных в труде рабочих продуктов. Но организации учитывают то, что ресурсы имеют свою полезность и ими кто-то распоряжается, а общества выступают как среда, в которой практики договариваются при создании организации — поэтому обе ветви методологии плотно переплетены и используют общий набор понятий.
Методология даёт возможность проводить рациональные рассуждения о деятельности/методах/практиках коллективного труда, масштаб ли это труда в проекте одной личности, или проекте команды, или масштаб группы связанных проектов, или масштаб множества не поддающихся учёту проектов общества одной страны или даже планеты.
Методология рассматривает и тот труд, который людьми не считается «трудом» (а, например, хобби как получение какого-то специфического удовольствия — игра на музыкальных инструментах в оркестре, например. Для кого-то это работа, а для кого-то удовольствие, для кого-то и то, и другое вместе), но вполне может считаться «деятельностью»: связан с затратами времени, координацией разных участников, преследующих какие-то цели, и т.д. Мы не различаем труд, деятельность, практику — хотя признаём, что в разных ситуациях лучше использовать разные слова, чтобы быть понятыми. Мы ещё и будем различать работы (то, что делает исполнитель трудовой роли) и труд/деятельность (то, что делает роль). Работы реализуют труд, это обычное онтологическое отношение реализации 4D-конструктивным объектом-агентом поведения 4D-функционального объекта-трудовой роли. Интеллект-стек позволяет легко понять, о чём тут идёт речь, ибо всё это подробно рассматривалось в ранее обсуждавшихся дисциплинах семантики и онтологии.
Объекты внимания в методологии одни и те же, как бы вы ни назвали деятельность/труд/практику в их отличии от работы. К тому же они могут ещё и делиться на части, и там тоже трудности в именовании: подпрактика говорят, а вот подтруд и поддеятельность (равно как и подработы) как-то «не звучат». Так что будьте гибкими в выборе слов. Например, говорите про части труда, части деятельности, подпрактики.
Основная проблема методологии — это невидимость поведенческого паттерна (процесса/практики), пока на него явно кто-то не укажет. Вы просто «чистите зубы», не задаваясь вопросом о том, каким способом вы это делаете.
Компьютер вычисляет какую-то функцию, не задумываясь о том, какой алгоритм (эффективный или неэффективный в привязке к конкретным входным данным, точный или не очень точный, часто ошибающийся или надёжный) он использует. Вычислитель с AI уже может сделать два шага: 1. Рационально выбрать алгоритм и 2. Выполнить его. Продвинутый вычислитель с AI может даже включить элемент творчества, создать несколько альтернативных новых алгоритмов, чтобы иметь потом из них возможность выбора.
Если мы переходим к обсуждению методов, то агент тоже может не задумываться о том, какой метод он исполняет (то есть работает по какому методу, какой исполняет набор практик). Критерии тут очень похожи на алгоритмические, вопрос об эффективности или неэффективности для конкретной ситуации работы, точность или не очень большая точность в результатах, надёжное получение результата, или большие риски того, что что-то пойдёт не так и результата не будет. Агент с сильным интеллектом может 1. рационально выбрать метод и 2. Выполнить его. Продвинутый творческий агент с сильным интеллектом может даже включить элемент творчества, создать несколько альтернативных новых методов, чтобы иметь потом из них возможность выбора.
Проблемы в том, что паттернирование в действиях довольно сложно, этот вопрос уже обсуждали в эстетике: попробуйте сказать, что общего в методах создания и развития мастерства (обучение), создания и развития организации (менеджмент), создания и развития корпоративного софта (программная инженерия), создания и развития космической ракеты (аэрокосмическая инженерия, инженерия киберфизических систем). Каким языком надо говорить, чтобы стала заметна похожесть и удобно было обсуждать неминуемые различия в методах создания и развития таких разных систем? Это и есть задача методологии.
Сама методология непрерывно развивается. Так, ещё десяток лет назад в методологии было принято говорить по примеру онтогенеза в биологии о жизненном цикле систем. Сейчас в рассмотрение принимается и филогенетическое рассмотрение, «время эволюции», и вместо обсуждения времени «жизненного цикла» говорят просто о времени создания и развития системы, «непрерывной разработке» и даже «непрерывном всём»/continuous everything, имея в виду непрекращающуюся работу систем создания.
Другая особенность — это невозможность даже очевидно паттернированную деятельность, где вроде как очевидно в общих чертах способ выполнения каждой отдельной работы повторяется, описать хоть как-то формально, как это принято для компьютерной программы. Даже в приготовлении пищи это становится очевидным. Один и тот же алгоритм, исполняемый на самых разных компьютерах самой разной архитектуры, если речь идёт о классическом компьютере или даже квантовом компьютере с квантовым алгоритмом, даёт одинаковые результаты. Но если «выполнять метод по его описанию» в реальном мире, используя агента вместо компьютера, результаты не будут столь очевидными. Можно, конечно, привести в пример «итальянскую забастовку», где работа останавливается, если чётко соблюдать все её описания, но проще будет опять обратиться к приготовлению пищи: существует даже пословица, объясняющая различные результаты приготовления разными поварами одного и того же блюда из одних и тех же ингридиентов по одному и тому же рецепту: «из той же мучки, но не те ручки». Все агенты разные, все ситуации разные, все работы разные — но описание метода/практики/деятельности/вида труда (паттерна изменений создателем каких-то систем окружающего мира) не очень точно описывает всё возможное разнообразие. Поэтому исполнение метода требует обычно сильного интеллекта, который на ходу совершенствует метод, адаптируя его для текущей ситуации, когда реальность явно не соответствует ожидаемым результатам предусмотренных методом действий.
Поскольку методология связана с выявлением паттернов действий в окружающем мире, то развитие методологии можно как-то связать с развитием AI на базе искусственных нейронных сетей, которые как раз познают (как говорят сами специалисты AI — выучивают/learn) паттерны окружающего мира, включая паттерны деятельности. В результате получается «языковая модель», как модель языка и мира, включая модель действий и последовательностей действий, приводящих к тем или иным состояниям мира.
Создание новых эффективных практик в чём-то равно созданию новых алгоритмов, например, генетическим программированием/genetic programming[2] (использование эволюции для создания алгоритмов). Но тут речь идёт об обобщении алгоритмики с очень ограниченного по числу возможных состояний мира компьютера (неважно, это классический или квантовый компьютер) до неограниченного по числу состояний реального мира. Методы должны работать в реальном мире.
Как промежуточный ход тут может помочь моделирование реального мира в компьютере. С одной стороны мы тогда можем говорить об алгоритмах (поскольку в виртуальном мире мы можем контролировать результаты любой операции, проводимой на известных данных), с другой — о методах/практиках/деятельностях работы с теми или иными объектами виртуального мира. Объект-ориентированное программирование берёт этот подход, и там поведения (функции, процедуры), которые меняют состояние каких-то объектов так и называют «методами»[3].
Следующий шаг — это DDD[4] (domain-driven design), когда для каждого объекта предметной области должен быть создан компьютерный объект, имитирующий его поведение (например, помнящий состояние этого объекта). По большому счёту, речь идёт о создании виртуального мира, отражающего обычный физический мир, «имитационное моделирование».
На этом подходе основаны и некоторые методы (способы!) обучения программированию для дошкольников: создаётся «учебный мир», в котором предлагается описывать последовательности операций, приводящих к заданному результату для самых разных начальных состояний этого мира. Например, в учебном мире «Робот» системы «КуМир» (расшифровывается как «комплект учебных миров», ссылки автор не даёт, ибо сам когда-то придумал это название), демонстрируется связь нескольких роботов, и детям явно предлагается думать про соответствие всех этих роботов[5]:
- Абстрактный математический/идеальный объект «робот», отражающий поведение (прежде всего — способы работы, понимаемые как способы передвижения по космодрому и операцию починки участка, которого он достиг) реального робота где-то в космосе, который чинит космодромы в каком-то из возможных миров/possible worlds. Это как раз предмет рассмотрения методологии: понятие о роботе::агенте.
- Виртуальный робот (информационная модель абстрактного робота, отражающего поведение возможного реального робота). Виртуальный робот отображается на экране компьютера, в среде КуМир или ПиктоМир, это объект виртуального мира «Робот». Этот робот управляем компьютерным алгоритмом.
- Игрушечный физический робот (физическая модель : ардуино-тележка на коврике из квадратиков). Этот робот вполне реален, отображается ардуино-тележкой, управляется тем же компьютерным алгоритмом.
Но это те же "концепт-знак-денотат" или "мысль-слово-вещь" из семантики. Тут можно поспорить, является ли выдуманный робот реальным объектом из возможного мира или «платоновской идеей», идеальным объектом: детям-то про него как про реальный объект рассказывают, просто недоступный для них непосредственно! Можно написать «реальный платоновский», акцентировать странность.
Такой подход к обучению программированию легко обобщить на обучение планированию (собственно, это была начальная идея группы разработчиков школьного образования по информатике[6], эта группа занималась введением обязательного обучения информатике в средней школе ещё в СССР, это обучение началось в 1985 году): дать детям не столько способ разговора о программировании компьютера, сколько способ разговора о планировании — составлении последовательности операций, ведущей к результату в условиях предположений и неопределённости. Метод должен был приводить к заданному результату в условиях самых разных начальных ситуаций и возможных осложнений в выполнении операций, ровно как алгоритм решает задачу на всех возможных входных данных. Основная концепция программирования в головах тогда была императивная/процедурная, другие парадигмы (функциональное, логическое, акторское и т.д.) программирования не рассматривались. Методология тогда (да во многом и сейчас) тоже занималась процедурными/пошаговыми описаниями последовательностей операций. Хотя в «процессном подходе» описания практик заявлялось о функциональной парадигме описания действий (язык IDEF0[7], функциональные диаграммы), на деле это превращалось в использовании нотации IDEF0 не для функционального (как раньше говорили, «декларативного», то есть неисполняемого непосредственно как действия) описания декомпозиции функций, а описания последовательности действий — то есть путали с другим стандартом, IDEF3[8] — описание упорядоченной последовательности событий. И затруднения у методологов, которые «описывали процессы» были такие же, как у программистов, которые писали «процедурно на функциональном языке». При этом исполнять описанные методы должны были агенты-люди, которые не понимали этих языков и требовали переписывать все эти формальные нотации в текстовые регламенты, весь выигрыш от формальности тут же терялся.
Дальше это должны были делать или люди, или компьютеры, и совместные работы людей и компьютеров назвали workflow, часть методов надо было описывать формально для (классических) компьютеров, появились языки описания работ вроде BPMN2[9] и ожидание, что формализация описания методов даст методологический прорыв. Но этого не случилось, ибо «программы» (их уже трудно называть методами) на BPMN2 обрастали всё большим и большим количеством обработки исключений и возможных ветвлений. Процедурная парадигма оказалась в методологии такой же плохой для описания способа работ, как в программировании компьютеров для описания способа вычислений (алгоритма).
Сейчас можно ожидать очередных прорывов в методологии, и эти прорывы связаны с Software 3.0, когда языком программирования становится естественный язык. В методологии он всегда и был основным методологическим языком, формализация как раз была нехарактерна ввиду неминуемых сложностей. Но формализация неминуемо будет продолжаться, ибо в творчестве мы должны иметь возможность проверки описания гипотетически успешной деятельности. Если это описание оказывается противоречивым (что проверяется только при изложении со строгим контролем типов и с использованием понятных операций с известным их результатом), то можно порождать новое описание, или модифицировать старое противоречивое, чтобы снять противоречие. Главное — это не пользоваться вновь придуманным противоречивым методом как описанием способа выполнения работы. Но и неформальное изложение метода тоже важно — ибо сравнение методов, понимание метода агентами-людьми (с нейросеткой в головах, а не логическим компьютером) идёт проще на естественном языке, допускающем использование, например, прототипной системы понятий, то есть использование аналогий и рассуждений по аналогии, а не дедукции.
Это означает, что развитие методологии продолжится, в чём-то отражая в части формальности представления методов развитие computer science в части формальности представления алгоритмов, а развитие системной инженерии («железной», по изменению мира) продолжится, в чем-то отражая развитие программной инженерии в части формальности представления программ (движение от Software 1.0 к Software 3.0). При этом программирование «тупых» агентов типа станков с ЧПУ — это именно программирование, а не «обучение работе по методу» (вменяемость станка с ЧПУ небольшая), но вот про человекоподобных роботов с нейронной сетью в вычислителе уже говорят «методологически» — таких роботов «обучают новым работам», то есть обучают работать по новым методам.
Методология и алгоритмика сливаются вместе в робототехнике как инженерии кибер-физических систем.