Методология 2025

Дальше вы можете каким-то образом стратегировать (выбирать метод в ситуации, когда непонятно, что делать) развитие, то есть обучение мастерству плавания, продвигать его по состояниям к «умею и могу развивать метод». Результатом стратегирования будет стратегия (синоним метода) ваших тренировок, затем следует планировать тренировки (планировать трату ресурсов на тренировки), затем обязательно переходить к выполнению плана – демонстрировать собранность, неутерю внимания к выполнению метода (то есть выполнению стратегии тренировок) на длинных интервалах времени.

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

Вот практики (возьмём ещё один синоним) картинга на базе того же разложения телесной культуры, которое мы использовали для танцев и плавания27:

Вот капоэйра в таком же представлении, уберём оттуда линю спектра мастерства28:

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

Эти таблички демонстрируют два вполне совместимых взгляда на разложение метода/культуры/инженерии/практики работы:

• объяснение того, что в одной и той же работе какой-то системы (в том числе системы-создателя, работе агента) можно увидеть много разных шаблонов/методов, как много разных «частных» цветов можно увидеть в белом «полном» свете (много частей спектра29 можно разглядеть в полном спектре, «разглядеть» тут – буквально, spectrum – это «видение» от латинского spectare, «смотреть»). Говорим о шкале.

• объяснение того, что мы можем переиспользовать какую-то часть разложения метода как «методы платформы», «основание стека методов», а другую – заменять. Говорим не столько о шкале, сколько о «стеке».

Моделирование: разложение культурного движения в стек

Представьте табличку разложения какого-то знакомого вам метода культурного движения (спорт, единоборства, танцы, паркур и т.д.) по образу и подобию таблиц из предыдущего подраздела. Укажите свою степень мастерства в каждой из субкультур (по десятибалльной шкале, 0 – «вообще не умею», 10 – «я олимпийский чемпион»).

Представление разложения метода деревом

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

Так, semantic web technology stack легко гуглится, он также называется semantic web layer cake, но слои в нём весьма и весьма условны (более того, ещё и на разных картинках разных авторов их число и состав разнится). Вот только один из вариантов изображения этого «слоёного пирога», обратите внимание, что там отнюдь не только плоские «блины» в этом пироге, не получается чистой «стопки», это и есть беда всех «стеков» в платформах и разложениях методов:

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

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

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

В старом понятии архитектуры (примерно до 2017 года, когда именно архитекторы создавали концепцию системы в целом как «самые опытные разработчики») это означает, что функциональные описания в рамках разработки архитектуры делают разработчики-проектировщики. Вот доклад 2021 года одного из главных архитекторов крупной (единорог) компании, который так и изображает эту проблему в заголовке: «как из одного архитектора вырастить 100+ архитекторов»30. В самом докладе говорится главным образом о том, как сделать, чтобы разработкой функциональных описаний (методов, которыми работает система) занимались 100+ сотрудников, которых мы сейчас назвали бы прикладными методологами своих частей проекта общего проекта создания системы. А современное понятие архитектора подразумевает как раз разбиение системы на модули такое, чтобы прикладные методологи были по возможности автономны в своих решениях. В разработке каждого «микросервиса» в инженерии корпоративных программных систем надо определить его функцию и сделать так, чтобы все предложенные функции микросервисов укладывались в предложенный архитектором способ разбиения на части конструкции из микросервисов и способы организации коммуникации между этими частями конструкции. Это нужно для того, чтобы достичь удовлетворительных значений каких-то архитектурных характеристик «-остей», например, малое время отклика (малая латентность), высокие показатели доступности, высокие показатели в наработке на отказ (надёжность).

Если в порядке разделения труда для роли разработчика выделить роль методолога, владеющего методами работы предметной области и роль проектировщика, который задействует результаты методологической и архитектурной работы для разработки и реализации концепции системы – этот доклад смотрелся бы совсем по-другому.

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

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

Есть множество методов (в том числе методов описания системы, удобных для применения этих методов) ведения методической, методологической и архитектурной работы в их взаимоувязке. Для примера мы можем использовать классический фреймворк Wim Gielingh из работы «A Theory for The Modelling of Complex and Dynamic Systems»31, он был использован как один из источников идей для семейства стандартов описания систем STEP, ISO 15926 и далее BIM.

Gielingh вводит понятия functional unit (функциональный объект, «роль» – то, что будет задействовать метод) и technical solution (конструктивный объект, который выбран как аффорданс для реализации роли, то есть выполнения работы функции/метода) и показывает концепцию системы в ходе её эволюции, то есть создания и развития: каким образом происходит совместный функциональный синтез/декомпозиция и модульный/конструктивный синтез/декомпозиция. Если смотреть на диаграммы снизу вверх – синтез, «разработка снизу вверх», bottom-up. Если смотреть на диаграммы сверху вниз – декомпозиция, «разработка сверху вниз», top-down. В реальности же рекомендуемый метод разработки – «изнутри среднего уровня наружу вверх и вниз, inside out»). Вот предложенная нотация концепции системы для определения системных уровней с учётом отношений род-вид и выбора вида:

Такая нотация называется гамбургер-диаграмма, где указывается множество кандидатур методов в разложении для какой-то сигнатуры (обсуждение ведётся не в терминах самих методов, а в терминах ролей, работающих по этим методам, Functional Units, FU) и дальше метод назначается какому-то типу конструктивов (Technical Solution), чтобы разобраться с модульностью в порядке формирования концепции системы. «Гамбургер» тут – половинки булки, между которыми «начинка» – это выбор назначений технических решений (конструктивы) на функциональные единицы (роли). В нотации предложено принимать решения по модульности на каждом уровне функциональной декомпозиции, чтобы поощрить выделение модулей в целях унификации. Но современные архитекторы сказали бы, что такой принудительный ход на унификацию модулей – способ ввести межмодульные зависимости, поэтому подход Gielingh не получил особого распространения, умер вместе с очень популярной в 90х годах идеей разработки модулей с повторной используемостью, reuse. Это подход второго поколения системного мышления, где система разрабатывалась как экземпляр, но не как развивающийся вид, не было «непрерывного всего», разработка мыслилась итеративной, но однократной.

Фреймворк от Gielingh важен тем, что различает generalization hierarchy (иерархия сигнатур), specification hierarchy (выбор вида из рода) и installation hierarchy – уже выбранное по типу и инсталлированное как экземпляры в целевой системе, работающее – и делает это на уровне проектирования («воображаемый проект») и конфигурации конечной воплощённой системы (as built). Вот шесть иерархий, служащих предметами рассмотрения во фреймворке Gielingh – верхний ряд это «воображаемый проект» в его общем/генерализованном виде, а нижний ряд – это с конкретными расчётными функциями и указанными уже моделями конструктивов, самого Gielingh тут интересовала знаниевая работа над проектом, уточнение ролей с какими-то их методами работы и их поддержки со стороны конструктивов:

Эта диаграмма характеризует важное для методолога, разработчика и архитектора:

• Методологу надо рассмотреть альтернативы разложения метода для какой-то сигнатуры. Если у вас в системе предусмотрен метод «чистка зубов», то вам надо рассмотреть варианты еды на ночь семян кунжута (удивительно хорошая очистка!), использования зубной нити, зубочистки, зубной щётки или ультразвуковой щётки с выбором из многих видов зубной пасты и вариантами щёток (например, V-образная зубная щётка, если у вас брекеты), задействование ирригатора (чистка водой под давлением), и т.д.. Каждый метод обладает своими плюсами и минусами, а если это верхнеуровневый метод, то может быть реализован очень по-разному, его составляющие будут иметь в свою очередь, разные разбиения – и надо будет опять выбирать, и там, скорее всего, будут какие-то другие предметные области. Это и есть работа. По большому счёту, именно методолог делает «разузловку», разбиение системы на функциональные единицы. Понятно, что в силу разделения труда это очень плохо делать «сверху вниз», ибо ключевое понимание того, как же именно работает система, будет на нижних уровнях. Но это уже нюансы, о которых будет в курсе «Системная инженерия».

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

• Проектировщик/designer будет принимать решение по тому, что же из имеющегося в культуре разнообразия видов методов работы (и, соответственно, разнообразия ролей), предлагаемых методологом, должно войти в разрабатываемую систему, и какими видами конструктивов с их интерфейсами, удовлетворяющих ограничениям, полученным от архитектора, это может быть реализовано – и он также собирает и другие ограничения (технология изготовления, общая стоимость владения, компоновка и т.д.), чтобы выдать многоуровневое «изобретение».

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

⠀

«Схемотехника»: представление метода работы графом потоков

А дальше можно сразу обратиться к традиционному представлению методов в виде функциональной диаграммы, часто называемой принципиальной схемой. Такие диаграммы разбирались в курсе «Системное мышление»: предметы метода текут/flow между создателями, которые меняют их состояния. Если это непрерывные потоки (поток/flow – это идентификация объекта на основе сохранения маршрута/пути, определение из ISO 81346:2022), то примеры сразу очевидны – методологи там называются «схемотехники», они строят принципиальные (принципиальность – это указание на функциональность, «метод работы», а не конструктивность) электрические схемы, радиотехнические схемы, но могут быть также и гидравлические схемы, и кинематические схемы и самые разные другие схемы.

• Так что очевидный следующий шаг в выражении методов – сразу пройти весь путь: от последовательностей/chains (последовательности методов, например, «стек» тут тоже последовательность вложений или последовательность использования, да и «шкала» – последовательность, упорядоченность в ряду объектов)

• к деревьям/trees (хорошо представимы разными MindMaps, которые легко сводимы к аутлайнам/outlines, по факту это «хорошо структурированное оглавление», где в листьях этого оглавления могут лежать какие-то более подробные описания, фреймворк Gielingh с диаграммами гамбургера как раз такой граф «почти дерева»),

• и далее к графам/graph как общей форме представления потоков чего бы то ни было – в том числе предметов метода между ролями, задействующими метод.

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

Потоковые (движение предметов метода по каким-то путям) представления, удобно представимые графом, распространены и в менеджменте. Фон Берталанфи выделял исследование потоковых представлений систем как «исследование операций» (operations research), речь шла о времени эксплуатации (operations) – и эта дисциплина легла затем в основу операционного менеджмента, логистики, теории массового обслуживания. Конечно, в исследованиях операций в основе лежали «работы», речь шла прежде всего о потоках ресурсов между рабочими станциями. Но это можно было представить и как специфически функциональное представление: «рабочая станция» – это ведь роль, её могут выполнять разные конструктивы, она может действовать разными методами (прикладными методами операционного управления!). Опять мы попадаем в то, что методология – фундаментальная дисциплина, и даже если речь идёт об управлении работами по методу, то это рассмотрение может быть функциональным, и тут методология будет задействована для разбирательства с работами и работниками как прикладная методология операционного менеджмента – несмотря на все предупреждения «не путать метод работы и работы по методу». Методы исследования операций, методы проектного управления работами, методы операционного управления – это всё методы, только ими занимается прикладная методология этих предметных областей.

С графами, которые описывают работы каких-то подсистем одного системного уровня по их взаимоувязанным методам (разложение методов одного системного уровня), есть разные ситуации их использования:

• Вы смотрите на них, как на «пассивную модель». Это означает, что интерпретатором модели является «тот, кто смотрит», алгоритм в вашей голове в виде программы «мастерство рассмотрения принципиальной схемы», а граф – данные для этой программы. Помним из курса «Рациональная работа», что модель – это программа, она исполняется, чтобы получить результат моделирования. Исполнитель программы, даже если он «просто смотрит на диаграмму» – тот, кто смотрит на эту диаграмму, и он также проводит с помощью диаграммы рассуждение, получает результат моделирования. Если нет рассуждения по диаграмме, то диаграмма не нужна. Когда вы пытаетесь разобраться в ходе ремонта «почему не работает», это как раз такая работа с графовым представлением разложения методов. Ваше мастерство проделывает рассуждения с описанием системы как графа связанных какими-то потоками предметов методов подсистем. Каждая из подсистем выполняет какие-то преобразования предметов метода, проводит их по состояниям, чтобы получить какой-то результат. Скажем, в логистической схеме – это работы по методам транспортировки и хранения предметов работ, а также работы по заказам партий предметов работ.

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

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

Увы, в курсах для архитекторов метод работы системы (в том числе системы-создателя) описывается в целом, без выделения специфической методологической/функциональной части. Да и в курсе для проектировщиков/designers не так много говорится про работу с функциями/методами, разве что упоминается, что проектирование надо начинать с работы с функциональными диаграммами. При этом функциональные диаграммы трудны для понимания, в них всё происходит как бы «одновременно», там законы типа закона Кирхгофа для электрических цепей. Помним, что разложения метода/функции тоже надо понимать, как работающие «одновременно». Но могут быть и всякие задержки и лаги (реактивные сопротивления в электроцепях, задержки на производство и логистику с момента выдачи заказа в цепях поставки, время продажи партии в розничных/retail сетях/chains).

В непрерывном производстве (нефтехимия, энергетика) функциональные диаграммы часто гибридны, в них приводится результат методологической работы (выбор метода) и одновременно указываются и результат проектирования: элементы конструкции. Это оформляется как P&ID диаграммы, piping and instrumentation diagram и PFD, process flow diagram диаграммами33.

Каждый отдельный тип конструктива из крупной «нарезки на модули» архитекторами проектировщики будут потом в концепции системы упоминать не просто сам по себе, а как реализующий какую-то подсистему в её роли в системе.