Знания метода и как их описывать.
Главное в методе — «невидимое», дисциплина/теория/«модель предметной области»/объяснения/знания/алгоритм. Мышление «по дисциплине» (дисциплину ума, дисциплину использования понятий теории при мышлении) у какого-то человека нельзя проверить каким-то простым образом, использование дисциплинированного (а не дикого, «самодеятельного», «народного») мышления в деятельности/труде/культуре/инженерии трудно обсуждать, описание дисциплины мышления (по факту — описание метода мышления) в общем случае непонятно как делать.
Скажем, сама методология — это тоже метод, базирующийся на одноимённой научно-практической дисциплине. Казалось бы, люди из сообщества инженеров могли бы почитать об этой дисциплине в учебниках, которые писали праксиологи, которые писали философы-методологи, которые писали методологи оригинальных школ мысли (например, системомыследеятельностные методологи[1]). Но с инженерной методологической культурой исторически получилось всё совсем не так. Более того, когда потребовалось описать сам метод методологии, способа записи методов не нашлось, кроме пространных текстовых рассуждений и примитивных диаграмм — методологии-то как метода в этот момент у инженеров не было! Похоже, что обучение методологии систем AI тоже столкнётся с проблемами записи дисциплин, записи знаний/объяснений/теорий — доступно множество описаний «просто текстом»: в научных статьях (описание метода исследования), книгах (передача опыта какой-то деятельности), учебниках (описание дисциплин в форме, удобной для изучения людьми, в форме, удобной для изготовления человеческого мастерства).
Donald Firesmith рассказывал, что они с друзьями занимались в начале 80-х объект-ориентированным программированием, что тогда было остромодно и ново. Как-то его вызвал начальник и сказал: «у тебя производительность программирования стала в последнее время в несколько раз выше, чем у остальных в нашей компании. Научи их своему методу работы». Дональд пошёл на своё рабочее место думать над новым заданием, и понял, что не понимает — что такое «метод работы», чему же он должен научить других сотрудников? Что происходит в ходе выполнения программистского проекта методом объектно-ориентированного программирования? Ему было понятно, что он работает уже не так, как до знакомства с объектно-ориентированным программированием, но как описать эту разницу в работе? Внешне ведь это выглядело просто как «на работе днём сижу и думаю, а о чём думаю на работе — вечерами обсуждаю с друзьями». Описывать нужно было не столько внешнее поведение (что и как записывать из мыслей в код объект-ориентированной программы), сколько происходящее «в мозгах» объект-ориентированное размышление. Более того, описывать надо было ещё и не само поведение «что происходит в мозгах», а «метод работы», задаваемый дисциплиной/знаниями/объяснениями/правилами/алгоритмами этого метода. Надо было описывать знания для мастерства самых разных людей, которое бы могло повторить происходящее в мозгах Donald Firesmith во многих и многих разных программистских проектах, которые не видел и сам Donald Firesmith.
После этого Donald Firesmith с друзьями начал разрабатывать новый метод «инженерия методов»/«methodengineering»[2]. Конечно, методология и традиция методологии, а также соображения по общей теории деятельности ему не были знакомы — он же был не философ, а программист! Поэтому у него с друзьями были собственные догадки/гипотезы о том, какие должны быть основные объекты методологии. Скоро выяснилось, что никакой метод/способ работы не может быть перенесён из того конкретного проекта, в котором он был разработан, в другой проект. Ситуация (технология и особенности целевой системы в конкретном проекте) меняла всё заранее пошагово/процедурно/императивно (например, на языке блок-схем, они эквивалентны процедурному языку программирования) записанный образец/шаблон/паттерн поведения. И тогда инженерию методов переименовали в «ситуационную инженерию методов»/«situational method engineering», чтобы подчеркнуть тот факт, что каждый метод работы зависит от ситуации, а между ситуациями выживает не сам метод как предзаданная последовательность операций, а только какие-то его части. В разных школах ситуационной инженерии методов эти части назывались компонентами/components, кусочками/chunks, ломтиками/slices, фрагментами/fragments и т.д. — главным образом компонентами/кусочками/фрагментами выступали «артефакты» (рабочие продукты, даже не предметы методов), «процессы», «инструменты», вариантов было много. Языки ситуационной инженерии методов (то есть языки переизобретённой инженерами методологии, формализованной до уровня псевдокодного полуформального языка записи шаблонов поведения), каждый из которых определял свой набор «компонент метода», оформлялись в виде стандартов, по которым далее разрабатывались описания самых разных методов. При этом только дисциплин/теорий/алгоритмов (описаний методов), то есть методов в разложении инженерного процесса программной разработки и «железной» разработки существует несколько десятков тысяч. Десятки тысяч идей о том, как нужно начинать инженерную работу, продолжать инженерную работу, заканчивать (или наоборот — никогда не заканчивать, «непрерывное всё», вечная эволюция) инженерную работу.
«Видимой» дисциплина может стать только путём её моделирования, путём описания — на документ (например, учебник) с описанием дисциплины можно посмотреть, ткнуть в него пальцем. По факту мало у кого наличествует мастерство/компетенции в работе с дисциплинами методов, как объектами первого класса. Это как раз методологическ****ое мастерство, то есть мастерство по дисциплине методологии**.** Методология — это и есть метод создания и развития самых разных прикладных методов, впрочем не только прикладных методов (то есть в том числе и фундаментальных методов мышления интеллект-стека, куда относится и сама методология, эти методы трансдисциплинарны, «мышление о самых разных других дисциплинах»). Методология в том числе занимается и методами описания методов, «метод описания метода» входит в «методы проектирования методов».
Трансдисциплинарной (общей, «для всего», а не прикладной для какой-то прикладной предметной области) методологии и посвящено наше руководство.
Конечно, было множество попыток моделирования методов. Но все они были весьма и весьма неформальны. Например, в 1977 году строительными архитекторами был предложен подход «языков паттернов/шаблонов»/«pattern languages»[3]. Из строительной архитектуры этот подход перекочевал в архитектуру программных систем, подробно мы разбираем его в руководстве по системной инженерии в подразделе «Прохождение архитектурных развилок»[4]. Паттерн тут — это и есть метод работы (или хотя бы принципы, которым надо следовать при выполнении работ). Если посмотреть, что же там моделируется, то мы увидим — основное внимание уделяется сигнатуре метода. Оговаривается, что в какой-то форме надо описать имя паттерна, тип из классификации паттернов, решаемую паттерном проблему, но вот само решение описывается произвольным образом, «текстом на естественном языке», хотя вот для обоснования этого решения (обоснования того, что предлагаемый метод сработает как надо) и говорится, что можно использовать какой-то формализм (особенно, если речь идёт об обосновании решений по безопасности и защите). Формализация дорогая, но в части безопасности на цену обращают внимания мало.
Не всегда описание паттерна даже с упором на структурированное описание сигнатуры метода делается как «структурированный текст» с предписанными разделами (эти разделы приводятся в подразделе «Прохождение архитектурных развилок» руководства по системной инженерии), хотя в разных сборниках паттернов чаще всего используется весьма структурированный вид. Тем не менее, в современной литературе от структурированного представления даже сигнатуры по большей части ушли, и используют не «букву», а «дух» работы с паттернами. Почему так? Мы в первом разделе, да и в первом подразделе текущего раздела указывали, что формализация метода сложна, разложение метода на какие-то простые составляющие — затруднено. При формализации вы тут же упрётесь в сложности выражения алгоритма метода в императивном «пошаговом» стиле, математика такого выражения тут же станет математикой теории категорий, формализация предметов метода окажется онтологически трудной (все эти «описания, переходящие в вещи», «поведения как объекты»), да ещё надо будет как-то владеть системным мышлением, чтобы показать место метода среди других методов работы по созданию успешных систем.
И всё-таки попытки формализации методов для их хотя бы каталогизации (на уровне списков сигнатур, если уж не описаний самих методов) продолжались. В попытках инженеров как-то «по-простому» отмоделировать методы своей работы появились два поколения ситуационной инженерии методов и отражающих эти поколения стандартов. С полным правом их можно назвать методологическими стандартами описания «инженерных процессов»/«методов разработки» (хотя поначалу это было больше ориентировано на более ранний термин «жизненный цикл»):
- первое, ориентированное на методологов, которым нужно было описывать методы работы и систематизировать эти методы работы. Это прежде всего стандарты OPF, ISO 24744 и OMG SPEM 2.0. В этих стандартах было стремление к строгости, модели были трудночитаемы[5].
- второе, ориентированное прежде всего на удобство пользователей описаний метода (инженеров), а не на методологов. Пока это поколение стандартов состоит из стандарта OMG Essence[6], версия 1.0 которого была выпущена в ноябре 2014 (последняя версия — 2024 года). Там давался свой набор объектов, который должен был описывать метод разработки и развития системы (language), одним из основных понятий которого стала альфа как объект внимания к изменениям в проекте, а также дополнительно некоторый «пример» из основных (kernel) семи альф (возможности, стейкхолдеры, программная система, требования, команда, работы, способ работы), к которому нужно было привязывать все остальные альфы как подальфы этих основых/kernel.
В нашем руководстве мы используем часть языка/language современной версии стандарта OMG Essence, гармонизировав этот язык с достижениями многих других исследователей-методологов. Но эти семь основных/kernel альф из даваемого в стандарте примера использования языка, устарели. Эти альфы отражали не саму методологию и её объекты внимания, а были уже моделью популярного на тот момент «инженерного процесса»/«метода создания и развития программных систем», включающего, например, требования (от этой альфы в современной программной инженерии уже отказались, рабочие продукты, отражающие требования, в последние пять лет в большинстве проектов перестали разрабатывать). Вопрос об отказе от требований вызывает повышенный интерес, ибо требования оказались прописаны во многих и многих стандартах, которые с отказом от требований оказались устаревшими. Подробно этот отказ будет описан в руководстве по системной инженерии, тут только заметим, что:
- Отказались от того, чтобы иметь отдельных «аналитиков», пересказывающих ситуацию у клиента разработчикам. Это «испорченный телефон», появились более простые и точные методы выяснения того, что именно хотят клиенты.
- Требования — это именно «требования», модальность долженствования/деонтическая. Сейчас же принято считать, что высказываем гипотезы, а потом пытаемся подтвердить их: это вообще другой способ мышления, когда у тебя «догадки», а не «требования».
- Догадки можно документировать, но вот «зафиксировать» их нельзя, ибо отказ от них в ходе проекта — это важнейшее их свойство. Изменение же требований — это всегда более тяжёлая административно процедура, чем отказ от одной догадки в пользу другой. Более того, на догадку можно ответить несколькими разными способами, чтобы попробовать найти лучший. А требования — они предполагают однозначный ответ. И требования — это пережиток однократного «жизненного цикла», а сегодняшний инженерный процесс отражает «непрерывное всё».
- Догадки можно высказывать и пытаться их поддержать свойствами системы асинхронно, работа с «требованиями» требует обычно собрать все требования и проверить из согласованность. В реальных условиях это существенно тормозит проект.
Изменение методов тут касается и самой методологии: методы выражения инженерного процесса меняются, они непрерывно эволюционируют. А примеры использования этих методов быстро устаревают.
Методология представляет собой тоже метод:
- Метод методологии работает над предметом метода «метод».
- Роль исполнителя метода методологии — методолог.
- Дисциплина/теория/знания/объяснения/алгоритмы метода методологии — учение методологии (это обычно, метод называется по дисциплине).
- Инструментарий — самые разные моделеры для описания метода.
Повторим:
- Мастерство в фундаментальной/«для всех предметных областей»/трансдисциплинарной методологии нужно всем агентам, это часть общего интеллекта. Всем надо уметь разобраться с собственными методами работы, а также с общим для проекта принятым там инженерным процессом. Если вы архитектор, то вам потребуется разбирательство с проблемами самых разных других предметных областей, не архитектуры: будете разбираться с предметными областями других ролей, будете разбираться с новыми проблемами, когда попадёте в ситуации архитектурной работы, не описанные в архитектурной литературе.
- Мастерство в прикладной методологии (разбирательство с тем, какие методы сегодня SoTA в какой-то прикладной системной области) нужно прикладным методологам. Если вы архитектор, то вам потребуется знать SoTA архитектурных методов, например, знать методы документирования архитектурных решений (ADR, architecture decision record — только один из таких методов, профи в архитектуре должны знать больше).
- И ещё мастерство в прикладной методологии нужно профессиональным методологам, которые в инженерном проекте занимаются именно методами работы. Скажем, в инженерии личности работают с мастерством в каком-то методе. Поэтому там визионерами по части методов/практик являются культуртрегеры, которые определяют необходимость в работе по какому-то методу. Регламенты, стандарты, справочники, инструкции по разным методам/практикам пишут методологи совместно с предметными экспертами (SME, subject matter expert) в соответствующей предметной области, а при подготовке материалов курсов (учебники, руководства, задания) к ним добавляются методисты (специалисты по instructional design, их мастерство — находить эффективные способы объяснения материала, подбирать задачи и упражнения и советовать способы удержания мотивации к обучению). Конечно, если рассматривать обучение кого-то методу как «изготовление мастерства работ по методу», то потребуется задействовать множество разных ролей (мы даже не помянули ещё роль ученика/студента, роль педагога/наставника, но и это не весь список), это подробней изучается в руководстве по инженерии личности. Если вы методолог программной инженерии, то знаете SoTA методы создания и развития программных систем и помогаете проектировщикам и кодировщикам в нахождении и разъяснении этих методов. Если методолог систем AI, то знаете методы создания таких систем (развёрнутый пример был в первом разделе нашего руководства).
Так что никакого обучения без методологии не бывает, никакой инженерии без методологии не бывает: если кто-то что-то делает (то есть работает), то всегда делает работы «как-то так, а не по-другому», по какому-то образцу/шаблону/паттерну. Можно, конечно, спорить — если я уникальным образом впервые выполнил одну работу, то задействовал ли я какой-то метод, или нет? С какого числа повторений можно говорить не просто о «действиях», а о «методе работы»? Формально — да, задействовал уникальный метод, впервые, нет работы без паттерна (даже если это единичный паттерн, множество из одного элемента — как чертежи Эйфелевой башни, говорим о методах обычно «в типах», как и проектируем). Но опыт показывает, что люди менее изобретательны: чаще всего они действуют по шаблону, который прихватывают из культуры, часто несознательно. Поэтому можно пообсуждать ещё, что там было реально уникального в этом «уникальном методе, выполненном первый раз». Уйти от шаблонности в «творчество» и «уникальное творчество» тяжелее, чем может показаться: если вы не учитесь хорошим методам, то можно ожидать, что вы «придумаете» плохой метод, от которого профи в данной предметной области давно отказались, ибо он с ошибками, это у вас первое исполнение метода, а с учётом других исполнителей работ в культуре — отнюдь не первое.
Это проблема танцев против плясок: с одной стороны «танец» — это следование какому-то канону стиля, культурно-обусловленным шаблонам, с другой стороны — «пляска» как полное игнорирование канонов, «движения по велению души». Если только шаблон — вроде как творчества нет, но как только вы пускаетесь в пляс, ваши паттерны становятся очень и очень простыми, в них нет накопленного эволюцией опыта! А «предписанные шаблоны» вдруг оказываются весьма разнообразными и никакая «пляска» близко не подходит к сложности этих шаблонов «танца», ибо сложность там создавалась длительной эволюцией, накоплением опыта. Подробней в работе «Чем танец отличается от пляски»[7].
Проблема танца против пляски проявляется для чего угодно: даже если вы занимаетесь выращиванием кристаллов, вы или знаете SoTA методов выращивания кристаллов, или знаете про выращивание кристаллов на уровне знаний из уроков химии в школе — и тогда вам будет казаться, что вы занимаетесь «творчеством», но это будет полный дилетантизм, кулибинство, явно не SoTA, игнорирование накопленного техно-эволюцией опыта выращивания кристаллов. Подставьте сюда то дело, которым вы занимаетесь — и определите, что у вас там SoTA и «танец» (строгое следование паттерну), а что «по вдохновению», «пляска». Это ровно та же проблема «рельсов мышления», которая обсуждалась в начале руководства по системной инженерии (и даже иллюстрация попала на обложку книжного издания руководства).
Конечно, тут скрыто явное противоречие: с одной стороны, работа строго по регламентам (следование если не SoTA, то хотя бы следование документированным методам работы) называется «итальянская забастовка», а работа мимо всех регламентов называется «произвол». А ещё бывают случаи, ни в каких регламентах и ни в какой литературе не описанные. И тут нужна методология, чтобы как-то профессионально, а не дилетантски обсуждать метод/практику/культуру/паттерны/шаблоны/образцы работы.
В науке часто обсуждается, что новая дисциплина (знания, которые потом лягут в основу мастерства по какому-то методу работы) чаще всего появляется как результат каких-то фундаментальных исследований. При этом сама «фундаментальность» обсуждается очень неформально. Иногда это «принадлежность к исторически определённым сферам науки, например, физике». Иногда это трансдисциплинарность (в наших руководствах принято такое толкование).
Вместе с тем консенсус сегодня в том, что новые дисциплины необязательно появляются как «фундаментальные», могут появляться и прикладные дисциплины, которые затем лягут в основу мастерства работы по прикладным методам, дадут начало новым видам инструментов. В любом случае, знания/объяснения/дисциплины предполагают предложение, проверку и улучшение гипотез/предложений/догадок по новым объектам внимания (предметов метода) и их отношениям (или операциям построения, если это конструктивизм), существование которых раньше не обсуждалось.
Скажем, дисциплина «квантовые вычисления» развивается на базе фундаментальных физических исследований, исследований по квантовой физике (ибо «квантовые») и исследований по информатике (computer science). К этой дисциплине потом добавляются инструменты: прежде всего сами квантовые компьютеры — и получается метод квантовых вычислений/компьютинга (называемый по дисциплине). В дисциплине квантового компьютинга[8] вводится понятие квантовой информации и единицы её измерения кубита — это новые понятия, которые сначала были высказаны как гипотезы, и которые оказалось трудно опровергнуть. Квантовый компьютер как инструмент (физический объект) эквивалентен функционально классическому компьютеру (то есть универсален по критерию Тьюринга: может выполнять все те же вычисления, что и машина Тьюринга, что и мозг человека — разница только в эффективности вычислений по тем или иным алгоритмам).
Гипотезы (например, существование квантовой информации и операций с ней) проверяются логикой, а потом ставятся проверочные эксперименты — точны ли в выражении реальности модели/теории больше, чем модели/теории с другими догадками. И если эти догадки более точны, то их принимают всерьёз. В том числе поддерживают инструментами. Так, догадки в части энергии атомного ядра поддержали инструментом «атомная бомба» («открытие на кончике пера» дисциплины, а затем создание инструмента для метода проведения атомных взрывов). Догадки по части квантовых вычислений в части дисциплины (идея David Deutsch, высказанная в 1985 году[9]) были тоже прокритикованы, выдержали критику, далее эти идеи приняты всерьёз — и поддержаны созданием инструментария квантовых компьютеров[10].
Дисциплина может быть прикладной, она появляется тогда в результате прикладных исследований, которые устроены точно так же, как фундаментальные в части метода исследований: догадки, критика, улучшение догадок, принятие всерьёз (на время! Ибо потом будут новые догадки, более точные) тех догадок, которые оказались лучше по сравнению с другими догадками. Альфы, состояние которых в ходе рабочего проекта меняет инженерный процесс, тоже появляются путём догадок, логической их критики, улучшений и накопления опыта. Поэтому если вы сами что-то придумали — это может быть ваша «пляска», если не сами — использование мирового опыта, но если вы вышли на фронтир, то вам время от времени надо будет что-то придумывать, что не придумывал ещё никто до вас. И тут вам потребуется интеллект (подробней об этом будет рассказано в руководстве по интеллект-стеку).
Монографий, стандартов, регламентов, справочников (работа методолога, описывающего методы в их разнообразии) и даже учебных курсов и менее формальных, чем жёсткие пошаговые инструкции/manuals руководств/guides (работа методиста, переводящего описания методов, полученные от методологов в форму, удобную для изучения людьми или системами AI) по самым разным фундаментальным и прикладным дисциплинам с их предложениями альф для каждой предметной области много, научных статей много, описаний практического опыта достаточно (не нужно самому делать эксперименты, по большей части они уже проведены, хотя проводившие их люди могли и не называть это «экспериментом», они «просто работали» с использованием понятий какой-то дисциплины).
Так что зачастую достаточно отобрать какой-то набор альф из уже известной литературы, гармонизировать их между собой, изложить в виде учебного курса, руководства, регламента, стандарта или справочника/handbook — это такое «мета-исследование»/«мета-наука»[11], исследование по материалам других исследований. Учебник по дисциплине — это уже переход к разработке мастерства (instructional design как дисциплина разработки учебных продуктов, роль — методист), и это хорошая форма выходного результата для работы методолога: дисциплина ведь «оживает» только после «загрузки» в чью-то голову (хотя есть вариант «оживления» её в виде компьютерной программы, использующей её понятия и выполняющей фрагменты её предметного мышления в экзокортексе, а ещё есть вариант «оживления» в системе AI). А затем эта дисциплина должна быть поддержана инструментарием. И ещё должны быть предметы метода надлежащего качества (самый искусный повар, знаток кулинарии, владелец шикарного кухонного инструментария не сможет приготовить вкусную еду из гнилых продуктов, или не сможет приготовить борщ из рыбы без овощей — увы, в рабочих проектах часто в таких ситуациях мастерам предлагают «сотворить чудо»).
В частности, дисциплина/теория самой методологии в варианте настоящего руководства не была придумана с нуля в результате фундаментальных научных исследований, предполагающих какие-то догадки о понятиях, которых не было раньше. Нет, она была документирована в формате руководства/guide/путеводителя (с объяснениями) как культурно-обусловленная. Авторами руководства был выявлен минимальный набор понятий самых разных школ методологии, которые опираются на понятия системного подхода в его инженерной версии (второе поколение системного подхода) и далее адаптирован к третьей версии (учёт безмасштабности и некоторая деантропоморфизация агента/IPU — выход за пределы агента как чистого «биологического человека»).
Инструментарий для нашего варианта методологии как метода мышления предполагается обычный для методов мышления: какой-нибудь моделер, начиная от «ручки-бумажки» для текстовых моделей невысокого уровня формальности, заканчивая универсальным моделером для табличного моделирования типа notion.so, coda.io (и может быть ещё много самых разных вариантов моделеров, один другого сложнее — помним, что методы трудно формализовывать, но всё-таки можно).
Этот набор методологических понятий и понятий системного мышления был первоначально изложен для руководства по методологии в виде не слишком удобного для изучения «текста справочника» (без повторений, примернов, вопросов/quiz и заданий по моделированию и написанию постов) — это была проведена методологическая работа, получено сухое формальное описание метода, которое описывалось как «собрать под одной обложкой все знания о методологии». Затем содержание материала в ходе неоднократных переписок стало уже не «энциклопедией/справочником», а руководством/guide, причём не с нейтральным «информационным» изложением, а наставлением (предназначенным для исполнения, регламентом работы, указанием метода работы), более удобным для освоения, более удобным для понимания. В руководство были добавлены более подробные и понятные объяснения, указаны наиболее часто встречающиеся «новичковые ошибки» в применении его наставлений, появились вопросы/quiz на основе идей concept inventory[12], задания на табличное моделирование/«мышление моделированием», задания на чтение литературы и текстовое моделирование/«мышление письмом» для удержания мозга на некоторое время в мышлении с использованием понятий дисциплины методологии в приложении к реальной жизни), это была методическая работа (instructional design). Причём в ходе методической работы были использованы материалы множества других прикладных (инженерия личности) и фундаментальных (интеллект-стека, например, семантика и онтология) методов мышления, прописаны связи предметов метода методологии с предметами многих других методов мышления: помним, что в одном руководстве могут излагаться знания/объяснения несколько разных дисциплин. Так, в руководстве по методологии много отсылок «назад» к руководствам по рациональной работе и системному мышлению, а также «вперёд», к руководствам по системной инженерии, инженерии личности, системного менеджмента.
Все тексты руководств для инженеров-менеджеров изложены так, что вместе они дают целостную, гармонизированную картину мира, изложенную на уровне абстракции: общей для инженеров-менеджеров современной мета-мета-модели мира.
В ходе управления конфигурацией и изменениями для наставлений руководств были устранены конфигурационные коллизии: руководство по методологии и излагаемый в нём вариант дисциплины методологии согласован терминологически и по стилю изложения со всеми остальными руководствами мастерской инженеров-менеджеров, равно как согласован по вариантам дисциплин/теорий, которые излагаются в этих руководствах. Равно и все остальные руководства мастерской инженеров-менеджеров и раскрывающиеся в них версии дисциплин согласованы с наставлениями руководства по методологии. Непрерывно идут (материал курса по факту был переписан десять раз) обновления руководства по двум линиям:
- изменение текущей версии дисциплины методологии (отражение эволюции методологического учения, отслеживание SoTA) и
- изменения в части согласованности наставлений руководства с другими руководствами мастерской инженеров-менеджеров (управление конфигурацией знаний).
Это всё описывает соответствует третьему поколению системного подхода и современной эволюционной системной инженерии. Руководства — это «документация как код», так что руководства разрабатываются (создаются MVP, затем они развиваются) по эволюционным/agile методологиям, а затем они используются для такого же эволюционного создания и развития мастерства инженеров-менеджеров.
Метод работы по описанию метода, то есть описанию того, «как что-то делать» (например, «как заниматься методологией», «как заниматься ловлей рыбы в тропических морях», «как программировать квантовые компьютеры», «как создать политическую партию») — это и есть задействование методологии как метода. Понятие метода/способа/стиля/культуры/практики/стратегии, видов деятельности/труда/инженерии — в методологии главное, это как раз предмет метода методологии, определяется дисциплиной методологии, «учением о методе».
Дисциплина (учение, знания/объяснения/теория) методологии, задающая метод методологического мышления — это фундаментальный/трансдисциплинарный метод, равно как и дисциплина онтологии, задающая метод онтологического мышления, рациональность как дисциплина, задающая метод рационального мышления и все остальные методы интеллект-стека.
Метод описывается и документируется в культуре очень часто крайне неформально, как «описание в энциклопедии», «описание в научной монографии», «описание в научных статьях». Учебный курс (учебник с задачником, онлайн-курс), руководство/guide — это всё-таки переработка «энциклопедии» или «монографии» и «статей» в текст наставлений с объяснениями и набор заданий, разработка объяснений для облегчения понимания уже имеющегося знания по дисциплине. А ещё в курсе или руководстве (а также регламенте, инструкции, описании рабочего процесса и прочих описаниях метода, предназначенных для выполнения людьми или даже выполнения AI) излагаются положения не одной дисциплины/теории, а нескольких: речь идёт о концептуальном синтезе, создании общего гармонизированного описания, общей модели какого-то уровня абстракции из нескольких частных.
Например, в руководстве по системному мышлению описано довольно много разных фундаментальных методов мышления разной степени подробности, в том числе и какие-то части методологии как метода мышления, но также и семантики, и онтологии, и понятизации. В нашем руководстве по методологии излагаются главным образом методы методологии, но даётся и много включений из описаний методов системной инженерии и системного менеджмента.
Технология моделеров для методологии позволяет делать модели методов в самой разной форме. Многие варианты представления методов обсуждались в первом разделе (например, принципиальные схемы), далее мы подробней рассмотрим представление методов работы в организации в виде регламента/стандарта/инструкции с шаблоном чеклиста.
Так что саму методологию тоже надо считать полноценным методом мышления: содержание её дисциплины «загружается в голову» (или систему AI) и формирует мастерство агента-методолога, а «на местности» необходимо развернуть моделер как инструментарий моделирования методов работы. Чтобы получить оргвозможность занятий методологией, нужно ещё и иметь «политическую волю» задействовать ресурсы агентов, исполняющих роли методологов и ресурсы моделеров для занятий методологией, а также разобраться с тем, откуда методологи будут брать свои предметы методологии как метода мышления (как раз наше руководство их описывает) и где и кем потом будут использованы результаты их работы. Помним, что методологи — это каждый инженер-менеджер в части фундаментальной методологии, но ещё и исполнители выделенной роли прикладного методолога как участника инженерного разделения труда в инженером процессе (подробно описано в руководствах инженерной серии).
Именно дисциплина определяет, каким инструментарием она может быть поддержана, а не инструментарий (в данном случае моделер) определяет дисциплину. Именно по дисциплине называют метод работы. Методология — это прежде всего «учение», дисциплина. А моделер как инструмент для методологии может быть ровно тот же самый, что и для многих других инженерных методов в «процессе разработки»/«инженерном процессе». Как моделировать создание и развитие целевой системы, как моделировать развитие личности (о создании тут говорим с осторожностью), создание и развитие предприятия::создатель, будет подробней рассказано в руководствах по системной инженерии, инженерии личности, системного менеджмента, а также более подробно дано в прикладных руководствах по отдельным составляющим методам прикладной инженерии и менеджмента (например, планируется создание руководства по архитектурным решениям в киберфизических системах, руководство по администрированию организаций).
Дисциплина метода меняется относительно редко, чаще всего речь идёт о цикле изменений в 10-20 лет, раньше это было больше, но сейчас это может быть и меньше. Например, системный подход относительно стабилен, знания его текущей третьей версии могут продержаться лет десять-пятнадцать, знания второй версии продержались почти тридцать лет. При этом прикладная методология систем AI меняется стремительно: крупные изменения там случаются каждые два-три года (например, переход к большим языковым моделям на базе группы методов их создания под общим названием трансформер/transformer).
Инструментарий меняется много чаще, чем SoTA дисциплин в поддерживаемых инструментарием методах. Моделеры для того же системного подхода меняют свои поколения каждые 4 года (средняя скорость смены поколений в информационных технологиях. Например, в 2019 году появился стандарт описания функциональной структуры системы для моделирования физических систем SSP, system structure and parametrization, а в 2020 году появились первые моделеры, его поддерживающие[13] — технологии моделирования тоже меняются быстро). Но все эти моделеры по факту поддерживают одну и ту же много медленней меняющуюся дисциплину, даже не всю дисциплину, а какие-то её части.
SSP — это больше про физическое имитационное моделирование/simulations функциональности технических систем. Это инструментарий, скорее, ещё первой версии системного мышления, причём учитывающий многоуровневость только в функциональном разбиении системы (но это имеет непосредственное отношение к методам работы этих систем! Подробней мы разбирали в первой части нашего руководства). Так что даже «системным» этот инструментарий можно назвать довольно условно, хотя авторы включили слово «система» в название метода — дисциплина устарела, это «системность первого поколения». Всегда обращайте внимание сначала на дату используемой версии вашей дисциплины, и только потом на дату выпуска инструмента**!** Иначе вы получите что-то типа самого современного инструментария поддержки расчётов по теории флогистона.
Нельзя успокаиваться после получения мастерства в какой-то дисциплине, надо продолжать отслеживать развитие методов, которые основываются на этой дисциплине, развитие инструментария этих методов, появление новых предметов метода. Надо учитывать, что состояние state**-of-the-**art (SoTA, «лучшее известное на сегодняшний момент») методов мышления и работы описывается в учебниках и курсах обычно не меньше чем через пять лет после его появления в ходе исследований (в том числе R&D, «исследований и разработок» — речь тут не идёт только об академической науке, исследованиями и разработками занимаются практически все предприятия). Ещё пять лет проходит до начала массового изучения дисциплины в вузах (дисциплина попадает в учебные планы не сразу! Учебники и курсы уже есть, но в учебных планах вузов их нет). Всего через десять лет после окончания вуза можно обнаружить, что владеешь каким-то уже совсем антикварным пониманием метода работы — двадцатилетней «свежести». При этом время летит быстро, и «двадцатилетний опыт» задействования какого-то метода оказывается «однолетним опытом двадцатилетней давности, повторённым двадцать раз».
Например, большинство сегодняшних инженеров-теплотехников, операционных менеджеров, основателей компаний, спортсменов, преподавателей/наставников, политиков и т.д. если и знают хоть как-то системный подход, то только давно устаревшую его первую версию (помним, что в руководстве по системному мышлению мы сейчас говорим уже о третьей версии с безмасштабностью и деантропоморфизацией агентов/создателей, с эволюцией), в которой ещё нет проектных ролей (stakeholders) создателей (enabling systems). Не все даже знают о выходящем из употребления сейчас в пользу «инженерного процесса» понятии «жизненный цикл системы», и уж точно в жизненном цикле у них работы, а не методы работы, и уж точно не постоянное эволюционное развитие системы, а разовое «удовлетворение требований».
Lean manufacturing (элегантное/минимализированное/бережливое производство) впервые был упомянут в статье 1988 года[14], прошло более тридцати лет с момента появления этого метода!Kanban уже прокритикован, ему тоже уже десятки лет (см. критику канбана в подходе TameFlow и руководстве по рациональной работе. Этот момент будет затронут и в руководстве по системному менеджменту). Нужно регулярно отслеживать не только относительно частые смены инструментария методов**, но и относительно редкие изменения в** дисциплине метода**!**
Краткий совет в том, что делать со своим образованием в текущей ситуации быстрой смены методов — уделять больше внимания мастерству задействования интеллект-стека фундаментальных методов мышления, в том числе методологии как фундаментальному методу мышления. Мышление на основе сильного интеллекта (мастерства современной версии интеллект-стека) даёт возможность быстро и надёжно отслеживать изменения методов/технологий, предметов методов, инструментов, быстро разбираться в том, что становится SoTA, а также быстро овладевать новыми версиями методов.
Ситуация по отслеживанию изменений обычно лучше в случае регламентов, стандартов (не международных, а стандартов предприятия), руководств: они создаются относительно быстро, по месту, обновляются часто, про них не задают вопросы «почему вы так быстро всё обновляем, не успеваем доучиться», ибо их осваивают в рабочем порядке, а не в порядке «официального обучения». Но всё не так, если речь идёт об участии государства в утверждении этих описаний метода. Официальные документы обычно сильно отстают от жизненных реалий, но обязательны к применению. Поэтому в мире утвердился общий метод, как с этим справиться: работы делаются по рациональному современному SoTA методу, а отчётность о выполнении работ делается по методу, требуемому стандартом. Это в разы и разы дешевле и быстрее, чем выполнять безумные устаревшие официальные регламенты (например, требующие бумажного документооборота в ситуациях, когда отлично справляется электронный документооборот), а также в разы и разы дешевле и быстрее, чем участвовать в инициативах по изменению этих устаревших документов. Работайте рационально, отчитывайтесь по выполненной работе для каждой проектной роли так, как надо этой проектной роли.
https://aisystant.system-school.ru/lk/#/course/systems-engineering/2023-05-17/8271 ↩︎
https://www.researchgate.net/publication/220349352_Situational_Method_Engineering_State-of-the-Art_Review ↩︎
https://en.wikipedia.org/wiki/Church–Turing–Deutsch_principle ↩︎
Термин «lean» был впервые предложен John Krafcik в его статье 1988 года, "Triumph of the Lean Production System". Эта статья была основана на материале его магистерской дипломной работы в Слоановской школе управления MIT. ↩︎