4. Метод как объект первого класса

Понятие метода: повторение

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

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

Поведение трудно представимо без того, кто его осуществляет, поэтому при обсуждении бега обычно представляют «гифку»/видео бегуна — поведение агента в роли бегуна по методу работы бегуна («бег») хорошо видно, но это мы смотрим на бегуна и его изменения состояния. Но бег::метод первичен — мы распознаём не бег::метод по тому, что им занимается бегун::роль, а бегуна::роль по тому, что он бежит::метод! То есть:

Мы не фантазируем чью-то роль, мы определяем её по методу. Если человек, или система AI, или даже фирма занимается инженерией самолётов, то этот агент — авиаинженер по роли. Занимается инженерией самолётов этот агент не потому, что агент — авиаинженер, а агента мы классифицируем по роли как авиаинженера потому, что он занимается инженерией самолётов. Если он занимается менеджментом, то он менеджер. Если вдруг побежал (уж так получилось), то он (пока бежит) — бегун, выполняет роль бегуна.

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

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

Например, «метод инженерного обоснования chaos engineering»¹ — это составляющая «инженерного процесса» в целом, представляет собой набор практик планирования выключений основного (не тестового!) самого разного оборудования на какое-то время, чтобы посмотреть, как с этим справляется система, от которой ожидается большая надёжность. Или метод строительства железобетонных зданий и сооружений при помощи скользящей опалубки/climbing formwork² это часть «инженерного процесса» строительства зданий, сам состоит из практик обустройства опалубки, заливки бетона, перемещения опалубки и т.д. Мы понимаем, что «практики», которые по такому определению входят в метод — это тоже методы, только составляющие исходного метода, полученные разложением метода.

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

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

В инженерной профессиональной литературе все практики считаются примерно равны друг другу по уровню, но метод — он будет крупнее, ожидается его разложение на практики. При этом в инженерии ещё и синоним «метода» — «методология» с другим словарным значением, чем «учение о методе». Это даже будет не «учение об одном специальном методе», при этом не факт что это будет вообще «учение» как теория/объяснения/алгоритмы. Это часто именно выполняемая методология/метод/практика, например, «методология SCRUM» — способ работы бригады разработчиков.

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

Сегодня часто кроме слов «метод/методология», «практика» говорят и «процесс» (process) — за последние пять лет слово «процесс» перестало всегда означать развёртку в физическом времени работ, «физический процесс» (функционирование, работу физической системы). В менеджменте оно приобрело оттенок указания на функциональный аспект работ, развёртку в логическом/причинном времени — то есть стало синонимом «метода». Например, «процесс инженерного обоснования» сегодня означает метод в инженерном смысле, «много разных методов/практик, как составляющих метода в целом» инженерного обоснования: использование «формальных методов»³ прямо с термином «метод» в названии, а также методов экспертной оценки, проведения стендовых испытаний, методов «ведения дела безопасности»/«safety case»⁴ и всеобъемлющего «обосновывающего дела»/«assurance case», и так далее — см. раздел по методам/практикам инженерных обоснований в руководстве по системной инженерии.

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

Очень часто про множество всех возможных методов говорят «деятельность» (activity или action, например, книжка von Mises по праксиологии/методологии и основам экономики называется «Человеческая деятельность»/«Human Action»⁵), и ещё про это же говорят «труд» (например, «разделение труда»/«division of labor»  — разделение работ по разным агентам, опирающееся на разницу в видах труда, то есть разницу в методах этих работ). Эта терминология развивается дальше в сторону разговора о больших группах методов — видах труда, видах деятельности. Речь про труд и деятельность ведётся обычно при обсуждении профессионального разделения труда, выделении каких-то групп агентов, которые обладают мастерством работ по каким-то широким группам методов в каких-то предметных областях: инженерия, менеджмент, инвестиции и технологическое предпринимательство, здравоохранение, правоохрана, культурное строительство, политическое переустройство общества, и т.д.

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

Неправильно говорить, что это «профессии», ибо слово «профессия» закреплено за «пожизненным ролевым определением, полученным долгим начальным специальным обучением». Но можно говорить о «профессионализации» или «профессиональности» как синониме мастерства какого-то агента.

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

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

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

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

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

Метод меняет свои состояния в ходе проекта, он сам предмет метода, его состояния отслеживаются альфой метода. Сначала метод в проекте не только не используется, то есть по нему не ведутся работы, но о нём вообще не знают, потом только его выбирают, потом осваивают, потом получают полномочия работать новым освоенным методом, и только потом по нему ведутся работы — это и есть смена состояний метода в ходе получения оргвозможности, отслеживаемая альфой метода.

Альфа метода имеет три важных подальфы:

• дисциплина/теория/объяснения/алгоритм. Это описание метода, которое будет проходить разные состояния по мере инсталлирования в головы работников и в память компьютеров, потихоньку становясь мастерством. Отношения тут сложные, как между кодом программы (абстрактный объект) и работающим софтом (физический объект), часто мы можем видеть поэтому целевым состоянием мастерство (оргзвена в выполнении оргроли, то есть проведении работ по методу). При разработке метода (например, при стратегировании) важнее иметь на выходе его описание, по возможности отчуждённое от разработчиков. При обучении часто описание метода есть, но нужно на выходе получить мастерство. Поэтому подальфой метода могут считать и мастерство, и даже оргвозможность, как ситуацию, в которой возможно применение мастерства. Метод называют обычно по его дисциплине. Дисциплину можно найти в таких рабочих продуктах, как учебники (документы!), регламенты предприятия, Body of Knowledge (публичные документы), стандарты. Поскольку это подальфа описания, то в жизни состояние этой подальфы надо определять как презентованное в таких рабочих продуктах, как документы (в том числе электронные документы).

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

• Предметы метода, причём не все предметы метода физичны. Системы — они как предметы метода физичны, а вот описания требуют каких-то документов для своего представления, чтобы с ними можно было работать. Тут то же соображение, что и с дисциплинами/теориями::описаниями метода: в жизни надо будет искать рабочие продукты, чтобы понять состояние предмета метода.

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

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

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

Инструментарий — это поддерживающие дисциплину инструменты/«средства производства». Современные методы работы не подразумевают работу только «голого мозга» и «голых рук», они обычно используют инструменты как поддержки работы мозга или группы мозгов в организации (экзокортекс/«база данных»: от бумажки и карандаша до сложного софта), так и поддержки работы по изменению окружающего физического мира руками и/или какими-то инструментами (tools, instruments). Cлесарные методы подразумевают не только задействование мастерства на основе описаний, как обрабатывать металлические детали, то есть мастерства как «прошитой» в мозге слесарной дисциплины/объяснений, но и слесарный инструментарий. Это были токарные станки раньше и обрабатывающих центры/станки с ЧПУ/CNC⁷ сейчас. Датчики и измерительная аппаратура (штангенциркуль в слесарном деле) тоже попадают в инструментарий.

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

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

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

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

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

Для методологического рассуждения (рассуждения о методах работы) надо найти в жизни эти типы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Метод реально выполняется в жизни, это поведение (не описание, не система, не свойство)

• Метод описывается его дисциплиной/объяснениями/теорией/алгоритмом

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

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

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

А если гвозди начинает забивать автомат, а не люди? Тут возможны два варианта:

• Метод назовём функцией, автомат просто будет «выполнять функцию», а не «работать по методу». Рассуждение не меняется, но немного меняется терминология.

• Рассуждение и терминология не меняется: автомат просто считается частью оргзвена. И претензии к плохому выполнению метода идут не к автомату, а к людям в оргзвене.

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

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

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

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

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

TEST Методы

Семён пошёл на тренинг по продажам, потому что:

--- Хочет освоить эту стадию жизненного цикла проекта ### Нет, продажам учат не как стадии жизненного цикла (не как работам). Учат не логистической/менеджерской перспективе, поэтому акцент на проектности неуместен. Опять же, отсылки к «жизненному циклу» — это из старинной инженерной терминологии, сегодня это анахронизм.

+++ Хочет освоить метод работы ### Да, продажи — это метод работы, поведение роли «продавец», именно методы работы изучают на курсах/тренингах (корпоративных или внешних), а потом задействуют мастерство работы по методу в реальных проектах.

Идя на ежедневную тренировку, Петя сегодня увидел разбитую тротуарную плитку, и перепрыгнул через дырку. Для Пети это:

+++ Действие ### Да, это разовое действие.

--- Метод ### Нет, это не метод. Ничего деятельностного/типового/культурно-обусловленного в проекте ходьбы на тренировку в этом нет, дисциплины/теории/алгоритма одноразового перепрыга никакой нет, паттерна (а метод — это паттерн/шаблон) нет.

--- Работа ### Нет, это не работа (задействование ресурсов, сроки выполнения не обсуждаются).

--- Стадия пути на тренировку ### Нет, это не стадия (укрупнённая работа в ходе пути на тренировку), никакой типичной периодизации/деления на стадии обычного ежедневного пути на тренировку тут нет.

По дороге на тренировку Петя обычно не наступает на границы между тротуарными плитками, он их обязательно перешагивает. Для Пети это:

--- Действие ### Нет, это не разовое действие — тут есть повторение, а обязательность намекает на какие-то культурные нормы/правила.

+++ Практика ### Да, это метод/практика/стиль, в действиях Пети есть дисциплина/алгоритм, какая-то теория — почему нельзя наступать на границы плиток. Можно спорить, является ли эта практика культурно-обусловленной, или это личная практика Пети, но для самого Пети это практика, выполнение (возможно, его собственных) норм/правил, следование «инсталлированной в его голове» теории/алгоритму, проявление мастерства.

--- Работа ### Нет, это не работа (не обсуждается ресурсная сторона вопроса, время выполнения) — речь идёт об обязательности перешагивания каждый раз как видишь границу, это небольшая теоретическая дисциплина, чёткое указание на метод.

--- Стадия пути на тренировку ### Нет, никакой периодизации обычного ежедневного пути на тренировку и выделенного для перешагивания периода времени тут нет, это не укрупнённая работа/стадия. Управления работами (планирование ресурсов, контроль выполнения, отслеживание загрузки ресурсов, определение сроков начала и окончания стадии и т.д.) тут нет.

Саша поцеловал Дашу от избытка чувств. Для Саши это:

+++ Действие ### Да, это разовое действие. И не спрашивайте о теории/алгоритме/дисциплине.

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

--- Работа ### Нет, это не работа, не обсуждается наличие ресурсов, точное время начала и окончания работы и прочие вопросы операционного управления.

--- Стадия встречи ### Нет, это не укрупнённая работа, и обычно во встрече не выделяются работы для этого поцелуя.

Саша обычно целуется со знакомыми при встрече, на это уходит по двадцать секунд на каждого встреченного. Для Саши это:

--- Действие ### Нет, это не просто разовое действие: есть слово «обычно», подразумевающее какую-то закономерность, правила/теорию/дисциплину.

+++ Стиль ### Да, это повторяющиеся действия (паттерн поведения, метод/стиль/культура), в которых наблюдается использование какой-то дисциплины/теории/алгоритма для того, чтобы поведение считать вежливым. Есть субкультуры, где при встрече целуются даже троекратно, независимо от пола — это культурно-обусловленное поведение, метод работы.

+++ Стадия встречи ### Да, работа выполнения поцелуев при встрече может быть основной для первой стадии встречи со знакомыми людьми, стадия (укрупнённая работа, требующая ресурса и занимающая время участников) может быть названа по этому методу. Указание времени показывает, что имеется в виду работа (затрата ресурса, «уходит по 20 секунд») речь вполне могла идти о стадии, одноимённой с практикой. Если бы это было «чисто логическое время», не давалась бы отсылка к физическому времени «20 секунд».

Дмитрий поскользнулся и упал. Он подумал, что должен существовать метод безопасных падений, который убережёт его от ушибов, и пошёл искать курсы по этому методу. Он:

+++ Быстро найдёт подходящие курсы ### Да, такой метод найдётся, а раз есть метод/культура/практика, то и курсы по нему найдутся. Например, безопасному падению обучают в боевых искусствах (самбо, айкидо).

--- Это он просто упал, таких методов нет и курсов не будет ### Нет, падения в жизни повторяются, они массовы, значит знания (дисциплина/теория/алгоритм/объяснения) безопасных падений существуют, этому мастерству обучают. Нужно искать там, где падают чаще и это важно (например, этому обучают в боевых искусствах, ибо там часто падают).

Геодезист 1-й категории Игорь установил теодолит по уровню. Он:

+++ Выполнял практику установки теодолита ### Да, он выполнял практику/метод, которой его учили как геодезиста — следовал знаниям учебной дисциплины (применял своё мастерство, использовал инструменты).

--- Просто установил теодолит, никаких методов ### Нет, геодезист выполняет установку теодолита по каким-то правилам/знаниям/алгоритмам/объяснениям, в его действиях есть паттерн — это метод/культура/практика его работы.

--- Ответ «выполнял метод» или «просто установил, никаких методов» зависит от того, как его учили ### Нет, геодезиста (агента, который выполняет роль геодезиста) учат геодезии, в том числе знаниям/объяснениям/дисциплине метода установки теодолита. Различаться могут варианты метода (например, могут быть разные версии метода, принятые в той или иной школе геодезической мысли), но не то, что его установка должна делаться по какому-то методу, определяемому знаниями геодезии.

--- Ответ «выполнял культуру установки» или «просто установил» зависит от того, кто отвечает на этот вопрос ### Нет, это зависит от того, чем руководствовался сам Игорь при установке теодолита по уровню: он выполнял тот метод, которому его научили (культурно-обусловленный) или просто разово что-то сделал, что и не вспомнит, как он это делал, и не повторит (это не паттерн действий, не метод, никаких знаний/дисциплины тем самым, описывающих паттерн, нет — геодезия тут оказывается не задействована как знания).

Метод прыжков в высоту «ножницами» по отношению к методу прыжков в высоту является:

+++ Одним из вариантов метода ### Да, это вариант практики прыжков в высоту, отношение тип-подтип для поведения (специализация).

--- Функциональной частью ### Нет, тут нет отношения часть-целое, поэтому не говорим про «часть». Это тип-подтип (специализация, выбор вида из рода).

--- Независимым объектом, не связанным никакими отношениями ### Нет, эти методы связаны: «прыжки «ножницами»»::метод/практика являются специализацией::отношение «прыжков в высоту»::метод/практика.

Культура системного мышления:

+++ Является одним из видов мышления как метода работы ### Да, это специализация общей культуры мышления, отношение тип-подтип/род-вид/множество-подмножество/специализация.

--- Является функциональной частью практики мышления ### Нет, это не функциональная часть мышления, тут нет отношения часть-целое, важного для «частей».

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

Знания метода и как их описывать.

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

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

Donald Firesmith рассказывал, что они с друзьями занимались в начале 80-х объект-ориентированным программированием, что тогда было остромодно и ново. Как-то его вызвал начальник и сказал: «у тебя производительность программирования стала в последнее время в несколько раз выше, чем у остальных в нашей компании. Научи их своему методу работы». Дональд пошёл на своё рабочее место думать над новым заданием, и понял, что не понимает — что такое «метод работы», чему же он должен научить других сотрудников? Что происходит в ходе выполнения программистского проекта методом объектно-ориентированного программирования? Ему было понятно, что он работает уже не так, как до знакомства с объектно-ориентированным программированием, но как описать эту разницу в работе? Внешне ведь это выглядело просто как «на работе днём сижу и думаю, а о чём думаю на работе — вечерами обсуждаю с друзьями». Описывать нужно было не столько внешнее поведение (что и как записывать из мыслей в код объект-ориентированной программы), сколько происходящее «в мозгах» объект-ориентированное размышление. Более того, описывать надо было ещё и не само поведение «что происходит в мозгах», а «метод работы», задаваемый дисциплиной/знаниями/объяснениями/правилами/алгоритмами этого метода. Надо было описывать знания для мастерства самых разных людей, которое бы могло повторить происходящее в мозгах Donald Firesmith во многих и многих разных программистских проектах, которые не видел и сам Donald Firesmith.

После этого Donald Firesmith с друзьями начал разрабатывать новый метод «инженерия методов»/«method engineering»¹¹. Конечно, методология и традиция методологии, а также соображения по общей теории деятельности ему не были знакомы — он же был не философ, а программист! Поэтому у него с друзьями были собственные догадки/гипотезы о том, какие должны быть основные объекты методологии. Скоро выяснилось, что никакой метод/способ работы не может быть перенесён из того конкретного проекта, в котором он был разработан, в другой проект. Ситуация (технология и особенности целевой системы в конкретном проекте) меняла всё заранее пошагово/процедурно/императивно (например, на языке блок-схем, они эквивалентны процедурному языку программирования) записанный образец/шаблон/паттерн поведения. И тогда инженерию методов переименовали в «ситуационную инженерию методов»/«situational method engineering», чтобы подчеркнуть тот факт, что каждый метод работы зависит от ситуации, а между ситуациями выживает не сам метод как предзаданная последовательность операций, а только какие-то его части. В разных школах ситуационной инженерии методов эти части назывались компонентами/components, кусочками/chunks, ломтиками/slices, фрагментами/fragments и т.д. — главным образом компонентами/кусочками/фрагментами выступали «артефакты» (рабочие продукты, даже не предметы методов), «процессы», «инструменты», вариантов было много. Языки ситуационной инженерии методов (то есть языки переизобретённой инженерами методологии, формализованной до уровня псевдокодного полуформального языка записи шаблонов поведения), каждый из которых определял свой набор «компонент метода», оформлялись в виде стандартов, по которым далее разрабатывались описания самых разных методов. При этом только дисциплин/теорий/алгоритмов (описаний методов), то есть методов в разложении инженерного процесса программной разработки и «железной» разработки существует несколько десятков тысяч. Десятки тысяч идей о том, как нужно начинать инженерную работу, продолжать инженерную работу, заканчивать (или наоборот — никогда не заканчивать, «непрерывное всё», вечная эволюция) инженерную работу.

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

Трансдисциплинарной (общей, «для всего», а не прикладной для какой-то прикладной предметной области) методологии и посвящено наше руководство.

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

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

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

• первое, ориентированное на методологов, которым нужно было описывать методы работы и систематизировать эти методы работы. Это прежде всего стандарты OPF, ISO 24744 и OMG SPEM 2.0. В этих стандартах было стремление к строгости, модели были трудночитаемы¹⁴.

• второе, ориентированное прежде всего на удобство пользователей описаний метода (инженеров), а не на методологов. Пока это поколение стандартов состоит из стандарта OMG Essence¹⁵, версия 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, то знаете методы создания таких систем (развёрнутый пример был в первом разделе нашего руководства).

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

Это проблема танцев против плясок: с одной стороны «танец» — это следование какому-то канону стиля, культурно-обусловленным шаблонам, с другой стороны — «пляска» как полное игнорирование канонов, «движения по велению души». Если только шаблон — вроде как творчества нет, но как только вы пускаетесь в пляс, ваши паттерны становятся очень и очень простыми, в них нет накопленного эволюцией опыта! А «предписанные шаблоны» вдруг оказываются весьма разнообразными и никакая «пляска» близко не подходит к сложности этих шаблонов «танца», ибо сложность там создавалась длительной эволюцией, накоплением опыта. Подробней в работе «Чем танец отличается от пляски»¹⁶.

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

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

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

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

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

Гипотезы (например, существование квантовой информации и операций с ней) проверяются логикой, а потом ставятся проверочные эксперименты — точны ли в выражении реальности модели/теории больше, чем модели/теории с другими догадками. И если эти догадки более точны, то их принимают всерьёз. В том числе поддерживают инструментами. Так, догадки в части энергии атомного ядра поддержали инструментом «атомная бомба» («открытие на кончике пера» дисциплины, а затем создание инструмента для метода проведения атомных взрывов). Догадки по части квантовых вычислений в части дисциплины (идея David Deutsch, высказанная в 1985 году¹⁸) были тоже прокритикованы, выдержали критику, далее эти идеи приняты всерьёз — и поддержаны созданием инструментария квантовых компьютеров¹⁹.

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

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

Так что зачастую достаточно отобрать какой-то набор альф из уже известной литературы, гармонизировать их между собой, изложить в виде учебного курса, руководства, регламента, стандарта или справочника/handbook — это такое «мета-исследование»/«мета-наука»²⁰, исследование по материалам других исследований. Учебник по дисциплине — это уже переход к разработке мастерства (instructional design как дисциплина разработки учебных продуктов, роль — методист), и это хорошая форма выходного результата для работы методолога: дисциплина ведь «оживает» только после «загрузки» в чью-то голову (хотя есть вариант «оживления» её в виде компьютерной программы, использующей её понятия и выполняющей фрагменты её предметного мышления в экзокортексе, а ещё есть вариант «оживления» в системе AI). А затем эта дисциплина должна быть поддержана инструментарием. И ещё должны быть предметы метода надлежащего качества (самый искусный повар, знаток кулинарии, владелец шикарного кухонного инструментария не сможет приготовить вкусную еду из гнилых продуктов, или не сможет приготовить борщ из рыбы без овощей — увы, в рабочих проектах часто в таких ситуациях мастерам предлагают «сотворить чудо»).

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

Инструментарий для нашего варианта методологии как метода мышления предполагается обычный для методов мышления: какой-нибудь моделер, начиная от «ручки-бумажки» для текстовых моделей невысокого уровня формальности, заканчивая универсальным моделером для табличного моделирования типа notion.so, coda.io (и может быть ещё много самых разных вариантов моделеров, один другого сложнее — помним, что методы трудно формализовывать, но всё-таки можно).

Этот набор методологических понятий и понятий системного мышления был первоначально изложен для руководства по методологии в виде не слишком удобного для изучения «текста справочника» (без повторений, примернов, вопросов/quiz и заданий по моделированию и написанию постов) — это была проведена методологическая работа, получено сухое формальное описание метода, которое описывалось как «собрать под одной обложкой все знания о методологии». Затем содержание материала в ходе неоднократных переписок стало уже не «энциклопедией/справочником», а руководством/guide, причём не с нейтральным «информационным» изложением, а наставлением (предназначенным для исполнения, регламентом работы, указанием метода работы), более удобным для освоения, более удобным для понимания. В руководство были добавлены более подробные и понятные объяснения, указаны наиболее часто встречающиеся «новичковые ошибки» в применении его наставлений, появились вопросы/quiz на основе идей concept inventory²¹, задания на табличное моделирование/«мышление моделированием», задания на чтение литературы и текстовое моделирование/«мышление письмом» для удержания мозга на некоторое время в мышлении с использованием понятий дисциплины методологии в приложении к реальной жизни), это была методическая работа (instructional design). Причём в ходе методической работы были использованы материалы множества других прикладных (инженерия личности) и фундаментальных (интеллект-стека, например, семантика и онтология) методов мышления, прописаны связи предметов метода методологии с предметами многих других методов мышления: помним, что в одном руководстве могут излагаться знания/объяснения несколько разных дисциплин. Так, в руководстве по методологии много отсылок «назад» к руководствам по рациональной работе и системному мышлению, а также «вперёд», к руководствам по системной инженерии, инженерии личности, системного менеджмента.

Все тексты руководств для инженеров-менеджеров изложены так, что вместе они дают целостную, гармонизированную картину мира, изложенную на уровне абстракции: общей для инженеров-менеджеров современной мета-мета-модели мира.

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

• изменение текущей версии дисциплины методологии (отражение эволюции методологического учения, отслеживание SoTA) и

• изменения в части согласованности наставлений руководства с другими руководствами мастерской инженеров-менеджеров (управление конфигурацией знаний).

Это всё описывает соответствует третьему поколению системного подхода и современной эволюционной системной инженерии. Руководства — это «документация как код», так что руководства разрабатываются (создаются MVP, затем они развиваются) по эволюционным/agile методологиям, а затем они используются для такого же эволюционного создания и развития мастерства инженеров-менеджеров.

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

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

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

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

Технология моделеров для методологии позволяет делать модели методов в самой разной форме. Многие варианты представления методов обсуждались в первом разделе (например, принципиальные схемы), далее мы подробней рассмотрим представление методов работы в организации в виде регламента/стандарта/инструкции с шаблоном чеклиста.

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

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

Дисциплина метода меняется относительно редко, чаще всего речь идёт о цикле изменений в 10-20 лет, раньше это было больше, но сейчас это может быть и меньше. Например, системный подход относительно стабилен, знания его текущей третьей версии могут продержаться лет десять-пятнадцать, знания второй версии продержались почти тридцать лет. При этом прикладная методология систем AI меняется стремительно: крупные изменения там случаются каждые два-три года (например, переход к большим языковым моделям на базе группы методов их создания под общим названием трансформер/transformer).

Инструментарий меняется много чаще, чем SoTA дисциплин в поддерживаемых инструментарием методах. Моделеры для того же системного подхода меняют свои поколения каждые 4 года (средняя скорость смены поколений в информационных технологиях. Например, в 2019 году появился стандарт описания функциональной структуры системы для моделирования физических систем SSP, system structure and parametrization, а в 2020 году появились первые моделеры, его поддерживающие²² — технологии моделирования тоже меняются быстро). Но все эти моделеры по факту поддерживают одну и ту же много медленней меняющуюся дисциплину, даже не всю дисциплину, а какие-то её части.

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

Нельзя успокаиваться после получения мастерства в какой-то дисциплине, надо продолжать отслеживать развитие методов, которые основываются на этой дисциплине, развитие инструментария этих методов, появление новых предметов метода. Надо учитывать, что состояние state-of-the-art (SoTA, «лучшее известное на сегодняшний момент») методов мышления и работы описывается в учебниках и курсах обычно не меньше чем через пять лет после его появления в ходе исследований (в том числе R&D, «исследований и разработок» — речь тут не идёт только об академической науке, исследованиями и разработками занимаются практически все предприятия). Ещё пять лет проходит до начала массового изучения дисциплины в вузах (дисциплина попадает в учебные планы не сразу! Учебники и курсы уже есть, но в учебных планах вузов их нет). Всего через десять лет после окончания вуза можно обнаружить, что владеешь каким-то уже совсем антикварным пониманием метода работы — двадцатилетней «свежести». При этом время летит быстро, и «двадцатилетний опыт» задействования какого-то метода оказывается «однолетним опытом двадцатилетней давности, повторённым двадцать раз».

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

Lean manufacturing (элегантное/минимализированное/бережливое производство) впервые был упомянут в статье 1988 года²³, прошло более тридцати лет с момента появления этого метода! Kanban уже прокритикован, ему тоже уже десятки лет (см. критику канбана в подходе TameFlow и руководстве по рациональной работе. Этот момент будет затронут и в руководстве по системному менеджменту). Нужно регулярно отслеживать не только относительно частые смены инструментария методов, но и относительно редкие изменения в дисциплине метода!

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

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

TEST Дисциплины в основании методов работы

В детском саду дети освоили метод устного счёта. Какая дисциплина лежит в основе этого метода счёта?

--- Педагогика ### Нет, эта дисциплина лежит в основе методов, использованных воспитателями, а не освоенных детьми.

+++ Теория целых чисел ### Да, в основе устного счёта лежит теория целых чисел.

--- Опыт счёта, имеющийся у воспитателей ### Нет, «опыт» — это не дисциплина.

+++ Арифметика ### Да, это основная дисциплина в основе устного счёта.

--- В этом нет никакой дисциплины ### Нет, правильно считать без правил/теории/дисциплины/объяснений/алгоритмов/норм не получится. «Правильно» — это «по правилам»!

Какая дисциплина используется при разработке программных средств проектного управления?

+++ Проектное управление ### Да, проектное управление (project management) уже десятки лет составляет самостоятельную дисциплину (знания, теории, правила, нормы).

+++ Исследование операций ### Да, проектное управление в том числе использует теоретические результаты этой научной области, operations research.

--- Опыт проектных управляющих ### Нет, «опыт» — это не дисциплина.

+++ Математическая статистика ### Да, проектное управление в том числе использует теоретические результаты этой научной области.

--- Физика ### Нет, проектное управление практически не использует теоретические результаты этой научной области, хотя был краткий момент известности варианта операционного управления под названием factory physics (погуглите).

+++ Финансы ### Да, программные средства для проектного управления часто содержат блоки, реализующие учёт финансов, то есть используют правила этой дисциплины.

--- Не использует никакой дисциплины, только опыт разработчиков ### Нет, в разработке будут использованы понятия и правила многих разных дисциплин, а хоть и преломлённых опытом (неформальное, неявное знание, tacit knowledge) разработчиков.

Какая дисциплина лежит в основе метода ведения переговоров?

+++ Конфликтология ### Да, многие варианты практик ведения переговоров основываются на теоретических положениях конфликтологии.

+++ Социология ### Да, многие варианты практик ведения переговоров основываются на теоретических положениях социологии — науки о групповом поведении людей.

+++ Психология ### Да, многие варианты практик ведения переговоров основываются на теоретических положениях психологии (но тут надо особо заметить, что теоретические положения многих и многих школ психологии давно прокритикованы, тут надо быть очень осторожным).

+++ Логика ### Да, многие технологии ведения переговоров основываются на теоретических положениях логики и рационального мышления.

--- В практике переговоров нет никакой дисциплины, важен опыт ### Нет, в переговорах надо использовать объяснения/знания/правила/теорию/нормы многих разных дисциплин.

Дисциплинарный комитет ООО «Профтехснабстроймонтажавтоматика» рассмотрел жалобу слесаря В. Пупкина на оскорбления со стороны начальника участка К. Щеглова и объявил ему порицание. На какой дисциплине основан метод работы дисциплинарного комитета?

--- Положение о дисциплинарном комитете ### Нет, это назван документ, описывающий организацию работы комитета, но не дисциплина/теория/правила/нормы.

+++ Этика ### Да, работа дисциплинарного комитета основывается, в том числе, на этических нормах и правилах.

--- Здравый смысл ### Нет, «здравый смысл» — это не дисциплина.

+++ Конфликтология ### Да, работа комитета основывается, в том числе, на рекомендациях дисциплины конфликтологии (и плохо, если не основывается).

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

Инструменты метода как поддержка его дисциплины

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

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

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

Например, управление проектами может быть классическим с предметом метода критический путь (critical path), но теория ограничений Голдратта критикует использование предмета метода «критический путь» и предлагает другой предмет: критическая цепь (critical chain)²⁴ и управление проектом основывается на отслеживании подальфы буфера проекта²⁵ альфы «работа». Если вы не понимаете связи между инструментами (в данном случае софт управления проектами) и разными вариантами дисциплин/теории проектного управления с их «специфическими понятиями для отслеживания»/«альфами и подальфами», а купите просто какую-нибудь «популярную программу управления проектами», то вас может ожидать сюрприз: программы будут развёрнуты, кнопки на них будут как-то нажиматься, формы заполняться, но практика управления проектами выполняться не будет, проектам лучше не станет! Подальфы буфера проекта в некоторых методах управления проектами попросту нет, она не существует в дисциплине с критическим путём — и поэтому софт для этой дисциплины её не отражает!

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

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

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

Инструментарий различается не столько удобством в использовании, сколько поддерживаемыми дисциплинами: тем, какие понятия в мышлении инструментарий способен отразить. Удобный в использовании негодный для дела инструментарий помочь не может, а неудобный в использовании, но годный для дела — плохо, но поможет. Вы сможете различить эти две ситуации, если кроме инструментов метода обратите внимание на поддерживаемую ими дисциплину. Она невидима, но вы можете научиться о ней думать. Методы/культуры/технологии определяются по своим дисциплинам/знаниям/теориям/объяснениям, чаще всего носят названия этих дисциплин, а не инструментов.

TEST Инструментарий

Выберите части, которые могут входить в инструментарий тренировок прыжков в высоту:

--- Учебник «Как научиться прыгать» ### Нет, это документация дисциплины (знания, теория, правила), а не часть поддерживающего дисциплину инструментария.

--- Учебник физики для физкультурных вузов ### Нет, это документация дисциплины (знания, объяснения, дисциплина), а не часть поддерживающего дисциплину инструментария.

+++ Планка и стойки для её крепления ### Да, это часть инструментария/оборудования тренировок.

+++ Мягкий мат ### Да, это часть инструментария/оборудования тренировок

+++ Секундомер ### Да, это часть инструментария тренировок

+++ Рулетка ### Да, это часть инструментария тренировок

+++ Покрытие дорожки для разбега ### Да, это часть инструментария тренировок

--- Зрители соревнований по лёгкой атлетике ### Нет, зрители не входят в инструментарий тренировок как часть, они не используются в ходе тренировки

+++ Видеокамера для замедленной съёмки ### Да, это часть оборудования тренировок

--- Соревнования по прыжкам в высоту ### Нет, соревнования не входят в инструментарий тренировок, они не задействованы в тренировке

В инструментарий инженерных расчётов могут входить:

--- Учебник математического анализа ### Нет, это документация дисциплины (теория, алгоритмы, объяснения, правила), а не часть поддерживающего выполнение алгоритмов/объяснений инструментария.

--- Задачник по математическому анализу ### Нет, это документация дисциплины (знания, объяснения, дисциплина, правила), а не часть поддерживающего выполнение дисциплины инструментария.

+++ Логарифмическая линейка ### Да, это часть одного из вариантов инструментария инженерных расчётов

+++ Калькулятор ### Да, это часть одного из вариантов инструментария инженерных расчётов

+++ Научный калькулятор (с корнями, тригонометрией, логарифмами и т.п.) ### Да, это часть одного из вариантов инструментария инженерных расчётов

+++ Математические программы (Mathematica, Maple, Sagemath, Oscar или аналогичные) ### Да, это часть одного из вариантов инструментария (софт — это современное оборудование, «мягкое оборудование», software) инженерных расчётов.

+++ Специализированные программы инженерных расчётов ### Да, это вариант инструментария (софт — это современное оборудование, «мягкое оборудование», software) инженерных расчётов.

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

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

Инструментарий машинописи может включать в себя:

--- Слепой десятипальцевый метод ### Нет, «метод» (он же «практика», «деятельность», «технология») подразумевает задействования инструментария, а не инструментарий включает в себя метод!

--- Повязку на глаза ### Нет, это часть инструментария тренировки машинописи по одному из методов обучения машинописи, но не часть самого инструментария машинописи.

+++ Десять пальцев ### Да, это часть одного из вариантов инструментария машинописи — где инструментами являются все десять пальцев, а не меньшее их число.

+++ Компьютерную клавиатуру ### Да, это часть одного из вариантов инструментария машинописи, где текст вводится в компьютер (а не механически пропечатывается на бумаге, как в пишущей машинке).

+++ Механическую пишущую машинку ### Да, это часть одного из вариантов инструментария машинописи, где текст переносится от клавиш к бумаге механическим устройством.

Культура приёма экзаменов может задействовать следующий инструментарий:

+++ Наборы вопросов на листочках (билеты) ### Да, это часть определённого инструментария приёма экзаменов, билеты тут инструменты полного отображения тем в заданиях и одновременно внесения случайности в выбор тем для экзамена.

--- Учебник по предмету экзамена ### Нет, это документация с описанием знаний/дисциплины, по которой сдаётся экзамен, а не часть инструментария приёма экзаменов.

--- Учебник «Как вести себя на экзамене» ### Нет, это документация с описанием дисциплины сдачи экзаменов, хотя в нём могут быть описаны разные части инструментария приёма экзаменов, но документация по дисциплине — это не инструментарий.

--- Методическое пособие «Что нужно знать экзаменатору» ### Нет, это документация дисциплины приёма экзаменов, хотя в этой документации могут быть описаны и разные части инструментария. Но это не часть инструментария: карта не территория, документация на систему (инструментарий) — это не её воплощение.

+++ Помещение для приёма экзамена (отвечающее требованиям к уровню шума, освещению, входу-выходу, глушению сигнала мобильных телефонов) ### Да, это часть одного из вариантов инструментария приёма экзаменов, дающего безопасность и удобство.

+++ Экзаменационная ведомость ### Да, это документ/артефакт/«рабочий продукт» — часть варианта инструментария приёма экзаменов, учётная система для регистрации результатов (меняет состояние в ходе экзамена).

+++ Шпаргалки ### Да, это артефакт/«рабочий продукт» в одном из вариантов инструментария сдачи экзамена (приём экзаменов — то же самое, только другой референтный индекс, описание от другого лица), его учитывают в дисциплине/правилах/знаниях/объяснениях приёма экзаменов и экзаменатору нужно знать правила/нормы, как на этот артефакт (не на его содержание! На сам артефакт!) реагировать в случае появления в физическом мире в ситуации приёма экзамена. Это функциональный физический объект (носитель информации подсказок), конструктив тут может быть записью формулы шариковой ручкой на бедре под юбкой, бумажной маленькой книжечкой с подсказками, смартфоном с беспроводным аудиоинтерфейсом и беспроводным микрофоном и наушником прямо в ухе, замаскированными волосами.

+++ Оборудование для записи устных ответов (диктофон, вебкамера, видеорегистратор) ### Да, это инструменты для одного из вариантов инструментария приёма экзаменов, используется для документирования непредвиденных ситуаций.

--- Вскрытие конвертов с вопросами непосредственно перед экзаменом ### Нет, это метод («вскрытие» — отглагольное существительное) из разложения метода приёма экзаменов. А вот частями инструментария тут являются конверты с вопросами.

+++ Бланки для подачи апелляции на результаты экзамена ### Да, это артефакты/рабочие продукты, части варианта инструментария приёма экзаменов.

Совершенствование и развитие

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

Методы работы (методы в составе инженерного процесса) при совершенствовании меняются главным образом в части замены инструментария на более производительный и изменения моментов начала и конца выполнения работ в целях их ускорения. К совершенствованию будут относиться и меры по надзору за выполнением рабочих процессов «как надо» (в соответствии с описанной в регламентах, инструкциях, стандартах дисциплиной), а не «как придётся», что поднимет качество выполнения работ и уменьшит переделки/re-work. Это и дообучение сотрудников, и работа с чеклистами и даже автоматизация (сдвиг части работ людей на не очень живых агентов). Главное, что лежащие в основе метода его знания/теории/дисциплины/объяснения/алгоритмы — они не меняются.

Например, при совершенствовании люди переучиваются (training) на работу с новым инструментом, скажем, осваивают новый софт для той же дисциплины: пересаживаются с одного САПР на другой, или с одного issue tracker на другой — ничего не меняя в своём мышлении. При совершенствовании не нужно дополнительно образовываться в части прикладных дисциплин выполняемых методов, читать учебник с новыми понятиями — мышление остаётся тем же. Резал салаты обычным кухонным ножом, поменял нож на профессиональный поварской из лучших сортов стали — всё, затачивать нож надо реже, огрехов в нарезке меньше, но ничего в умениях резки менять не надо. Если в фирме годовой цикл бюджетирования был без поддержки софта, а стал с поддержкой софта — это совершенствование, но не развитие. Развитие — это когда надо будет поменять метод бюджетирования с ежегодного на постояннотекущее, beyond budgeting (будет проходиться в «Системном менеджменте»), для этого развития придётся переучить всех сотрудников, соприкасающихся с тратами средств предприятия. Для совершенствования переучивать не надо, дисциплина не меняется, из неё просто выжимают с каждым шагом совершенствования всё, на что эта дисциплина способна в плане роста производительности.

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

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

Развитие (development) предприятия/оргзвена (помним, оргзвено — это от одного человека, даже и участвующего part time, а не полный рабочий день) происходит тогда, когда меняются знания, используемые мастерством выполнения метода. Это означает чаще всего, что меняется и поддерживающий это мастерство инструментарий. Поменяли синхронную коммуникацию (совещания) на асинхронную (форумы и чаты)²⁶ — и тут же изменились инструменты: исчезли большие столы в комнатах начальников, исчезло изобилие переговорок, зато появились многочисленные треды комментов в самых разных информационных системах, начало работать множество чатов в мессенджерах.

Для возможности развития люди образовываются (education, «как в школе и вузе») для получения возможности быстро учиться, осваивать новое, не теряться в новых ситуациях. Затем для освоения новой прикладной дисциплины мышления по новому методу, они изучают новые понятия и их отношения, а дальше обучаются/тренируются (training, часто на рабочем месте) в работе с новым инструментарием поддержки новой дисциплины.

По факту при развитии происходит коррекция мемома, знаний по созданию систем — те самые smart mutations/«умные мутации», которые потенциально (не факт! Это всё «гипотезы», хотя и тщательно продуманные) приведут к получению новых качеств. Скажем, когда подхакивают гены утёнка и он становится больше похожим на лебедя, и если теперь повторять создание системы по этим генам, то сразу и шея бывшего утёнка будет длиннее, и тело крупнее. Это, конечно, не отменяет того факта, что новую систему тоже можно совершенствовать, но шея у даже плохонького «нового развитого утёнка» будет подлинней, и тело покрупней, чем у хорошо тренированного и откормленного «старого долго совершенствованного», а уже если его совершенствовать — то и шея несказанно длинней, и тело существенно крупней. Гены решают всё. Без развития, то есть смены знаний, а не только совершенствования как «надлежащей настройки» при тех же знаниях, будет «лысенковщина»²⁷: попытки получить путём «надлежащего ухода за организмом» такой феном (набор отличительных признаков организма), который можно получить только модификацией генома. Ничего хорошего из такого подхода «много совершенствования даст развитие» обычно не получается: сколько ни совершенствуйте прыжок в высоту методом «ножниц» (знания/алгоритм там — прыгать к планке лицом, перекидывая одну ногу за другой над планкой), двух метров планки вам не преодолеть. Придётся полностью перестроить объяснения/теорию/знания того, как надо прыгать: учить мастерству разворачиваться в полёте к планке спиной и перелетать её лицом вверх — переучивать в прыжке придётся всю технику прыжка, прошивать в виде мастерства новую дисциплину. А заодно менять инструментарий: накачивать другие мышцы в их другой координации, нежели дающие максимальный результат для прыжков «ножницами».

Текущий тренд (впрочем, этот тренд был всегда — просто это было трудно заметить, в развитии работают экспоненциальные законы, и ещё совсем недавно тренд был не так очевиден, об этом будет рассказываться чуть дальше) в том, что периоды совершенствования становятся всё короче и короче, и всё чаще и чаще приходится осуществлять шаги развития: предприятие/оргзвено начинает использовать незнакомые членам команды методы работы. Чаще меняться в работах по каким-то методам начинает не только инструментарий, но и весь метод в целом (часто вместе с агентами, которые меняются с имеющих великолепное мастерство в старом методе на имеющих хотя бы едва приемлемый уровень мастерства в новом методе). В конкурентной борьбе оказывается недостаточно использовать «лучшие инструменты», необходимо использовать и «лучшее мышление», которое происходит в силу обучения лучшим на сегодня (SoTA) знаниям. И уж это «лучшее мышление» поддерживать «лучшими инструментами». Скажем, признать, что в текущей деятельности невозможно какое-то планирование up front и перейти от классического управления проектами с софтом управления проектами к управлению кейсами и освоить софт трекеров/issue tracker — тут описан массовый переход от одного поколения методов операционного менеджмента к другому, который описан в предыдущих двух разделах.

Интересно, что некоторые наши инженеры-менеджеры воспринимают материал предыдущих разделов как справочно-исторический, «художественную вставку в текст учебника, передышку в изучении». Но нет:

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

• Самое страшное тут — это взглянуть в зеркало: что у вас в голове? Поднимите вашу переписку, пересмотрите ваши видео. Каким языком вы говорите о вашем инженерном процессе? Например, «итеративность» — вы имеете в виду «спринты» в «непрерывном всём», но почему говорите «итерации»? Или более древние «итерации» из RUP — докрутку в несколько спринтов до заранее запланированного результата? А что понимают под этим ваши коллеги? Какой у них в голове инженерный процесс, как отражаются в этих головах ваши слова? Попробуйте выявить использование терминов в вашей речи, провести контроль типов, буквально понимать то, что вы же говорите. Совпадает ли то, что вы реально сообщаете с тем, что вы думали сказать? Опыт наших учебных потоков показывает — нет, не совпадает. Материал разделов не был использован как учебный, как инструкция для мышления и проверки качества коммуникации.

Всё то же самое надо смотреть и в самых разных других материалах, в которых рассматривается смена инженерной культуры, смена методов работы. Это, например, новостные ленты профессиональных медиа, занимающихся прикладной методологией той или иной предметной области. Скажем, вы пошли учиться самому модному языку программирования для разработки вебсайтов (веб-разработка, «инженерный процесс разработки приложений, доступных в виде интернет/веб-сайта через веб-браузер») — PHP, и вдруг (по историческим меркам — действительно вдруг!) этот язык стал абсолютно немодным. И то же самое произошло с другим самым модным языком — Perl. При этом вы изучили ещё один язык JavaScript, и угадали, он вроде бы немного задержался. Но нет, каждые несколько лет вам приходится выучивать «язык на языке», который вроде бы является инструментом (программный фреймворк), но на деле требует мастерства в некоторых весьма специфических методах веб-разработки. И вам приходится переучиваться каждые несколько лет, хотя вроде бы вы и знаете язык! Ужас же ещё и в том, что «вышел из острой моды» — это ничего обычно не значит, ибо перспектив у метода вроде уже нет, но в мире полно людей, которые пользуются этим методом после долгих периодов совершенствования, и новые перспективные методы на самых первых шагах, не имея шанса показать себя полностью, в глазах многих и многих людей имеют равные примерно возможности со старыми методами и их инструментарием. Вот она, неустроенность (не путаем с конфликтами, не путаем с неудовлетворённостью) — наличие огромного числа вариантов методов с похожей эффективностью для каждой сигнатуры метода. Но если приглядеться, то окажется, что в тех же языках программирования популярность их разительно меняется, скажем, до 2002 года мы ничего не слышали о языке PHP, затем через восемь лет в марте 2010 он оказался третьим по популярности среди всех языков в индексе TIOBE²⁸ (ибо на нём программировали Мордокнигу, поэтому довольно много людей сочло, что в их проекте этот язык тоже будет хорош), в апреле 2024 он уже семнадцатый, взлёт и падение прошли за какой-то десяток лет²⁹:

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

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

Отследить развитие трудно:

• Надо иметь мастерство методолога (владеть фундаментальной методологией, часть хорошего образования, один из методов мышления интеллект-стека), чтобы работать с методами, как объектами первого класса: моделировать их, обсуждать, сравнивать.

• Надо быть прикладным методологом, чтобы обладать кругозором в уже вышедших из употребления (но живущих в народной памяти!) использующихся и перспективных к использованию методов. Надо знать быстро меняющееся SoTA, уметь подобрать метод из огромного их числа, оценив ситуацию задействования метода. Ибо (как всегда в системном мышлении) нет абсолютно эффективных методов, для каждого частного случая будет эффективен свой метод (помним теорему бесплатного обеда, обобщаемую со случая алгоритмов для вычислителя на алгоритмы для создателей/constructors как универсальных преобразователей физического мира)

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

Умение увидеть объекты мышления в объектах из жизни (понятийное наведение внимание) и удерживать их во внимании в течение всего хода проекта (собранность, в том числе личная и коллективная) тренируется. Это умение — основное, что отличает людей с хорошим базовым образованием от дилетантов, просто запомнивших наиболее часто встречающиеся последовательности нажатия кнопок на вверенном им инструментарии какого-то оргзвена. Люди с хорошим базовым образованием обычно способны провести элементарное рассуждение в терминах знаний/дисциплины/объяснений/онтологии/правил/алгоритмов метода и грамотно (без новичковых ошибок!) применить инструментарий с учётом области применимости знаний метода — и у них будут smart мутации метода, а дилетанты-кулибины обычно будут предлагать варианты с новичковыми ошибками, и у них будут не smart, а обычные мутации (ошибки репликации! Огромное число мутаций в природе смертельны, удачны мутации крайне редко!) будут приводить к неэффективности и неудачам. Если речь идёт о хорошем владении инструментами, то автоматизмы ими владения не освобождают от мыслительных ошибок из-за невладения знаниями метода. В музыке вы можете играть на саксофоне интуитивно, в танце вы можете танцевать интуитивно, в кулинарии можете готовить борщ интуитивно, но вот если будете интуитивно проектировать ракету, то она вряд ли улетит далеко — нужны знания. В том числе нужны знания о том, как проводить оргразвитие (развитие организации, то есть получение оргвозможности какого-то метода работы). Про оргразвитие подробно рассказывается в руководстве по системному менеджменту. Но идеи развития одного человека или системы AI и оргзвена (команды проекта, стартапа, предприятия) одни и те же, и даже в какой-то мере могут быть распространены на сообщества и общества. Поэтому наше руководство по методологии включает в себя и раздел по теории стратегирования — теории метода выбора метода в ситуации, когда непонятно что делать. Для стратегии вы будете затем получать оргвозможность, чтобы реализовать эту стратегию (метод, выбранный в ходе работ стратегирования). Описание этого выбранного метода — стратегия, затем надо спланировать ресурсы, это планирование, затем получить ресурсы и принять решение о деятельности, затем приступить к выполнению работ по стратегии. Так что наше руководство по методологии в том числе нужно использовать и для стратегирования организационного развития, и для стратегирования личного развития, и для стратегирования развития сообществ.

Где искать описания современных методов менеджмента и инженерии

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

• слова важны (у нас кроме слов обычно ничего нет), и

• не важны (слова терминов имеют много словарных значений, размытые значения, неправильно употребляются, искажаются при переводе и с греческого, и с латыни, и с английского или наоборот, на английский, в них может быть метонимия, и т.д.).

Наиболее типичны для документирования прикладных методов классического инженерного процесса и основных методов менеджмента такие публичные документы и стандарты, как своды знаний (body of knowledge³⁰, корпус знаний), описывающие различные подпрактики какой-то более-менее крупной практики/деятельности и возможные варианты выбора этих подпрактик в какой-то связный метод. Но описания методов могут быть найдены и в справочниках, и в учебниках, в монографиях, небольшие методы могут быть описаны в статьях и блог-постах, набирает форму и видео рассказ-показ в соцсетях. Скажем, культура социальных танцев редко документируется текстами, чаще это видеоролики — по понятным причинам, но если речь идёт о предъявлении культуры/стиля на соревновании/конкурсе для оценки соответствия предъявляемого стиля танцевания судьями, то ассоциации танцоров какого-то стиля готовят стандарты, которым надо соответствовать, чтобы считаться победителями. Если есть несогласие с тем, что сделала одна какая-то ассоциация в плане документирования метода, в спор включается другая ассоциация с другим стандартом.

Все эти стандарты и публичные документы используют разные методы описания (viewpoints), дающие разные описания (view) даже одних и тех же методов, которыми ведутся работы проекта по созданию и развитию того или иного вида систем. Даже название метода и название знаний метода будет существенно различаться, могут быть неожиданности.

Например, в медицине лечат сегодня по протоколам диагностики и лечения³¹ — эти протоколы и есть методы лечения, лечение/работа идёт по описаниям способов лечения/работы в этих протоколах. В сводах знаний могут запросто метод обозвать мастерством, могут обозвать способностью/ability.

В организационном менеджменте чаще всего встречаться будут процессы (следуя традиции «функционального описания процессов», заложенной серией стандартов ISO 9000). Не реже будут и методы (помним, что в инженерии термин «метод» часто используется как набор составляющих его более мелких практик, достаточный для решения какой-то содержательной задачи «под ключ»), и даже методологии (ISO 24744 предложил считать метод/method и методологию/methodology синонимами), а иногда и «область знаний» (knowledge area), с которой связывают какую-то «деятельность» (activity).

У СМД-методологов используется термин «деятельность» и даже «труд» (когда говорится о разделении труда, division of labour/labor). А с учётом того, что методы что-то меняют в окружающем мире для того, чтобы изменить этот мир к лучшему путём создания успешных систем, их называют ещё и инженерией (и не только классической «железной» или программной инженерией, но и генной инженерией, социальной инженерией и т.д.). Деятельность, труд, инженерия всё-таки сами по себе общи, часто ими называют и все возможные методы, которыми работают интеллектуальные агенты, например, «человеческая деятельность» — это отсылка ко всем методам, которыми работает человек, всё, что делают люди. Так что тут могут сужать значение, говоря о виде деятельности, виде труда, виде инженерии — это будет достаточно широко понимаемый метод работы, с вариантами разложения для очень широко понимаемой сигнатуры. Скажем, инженерия путей сообщения как вид инженерии — все методы работы путевых инженеров. Формально пути сообщения — это и автомобильные дороги, и водные пути, и железные дороги. Часто инженерия путей сообщения понимается вообще узко, только как инженерия железных дорог³². Программная инженерия (software engineering) тоже весьма и весьма широко понимаемый набор методов создания программных систем. Посмотрите на то, как «программная инженерия» таки сводится к «методу разработки» в статье Википедии³³, вы там увидите в определении множество знакомых слов из синонимов метода работы, все эти слова как-то ссылаются на одно и то же: Software engineering is an engineering approach to software development. A practitioner, called a software engineer, applies the engineering design process to develop software. Неявно из синонимов метода тут помянута даже «практика», через роль practitioner, но ещё и процесс, и разработка, и инженерия. И тут прямо в определении сужение понимания границ инженерного процесса, ограничиваемое только проектированием и кодированием как аналогом проектирования/design в машиностроении. Помним, что сначала процесс разработки касался только разработки как проектирования, затем разработки до момента получения работоспособного образца целевой системы, затем в инженерный процесс (который продолжали называть «разработкой») начал включать в себя и производство, затем включили эксплуатацию и вывод из эксплуатации, затем только перешли к тому, что всё это, только повторяемое для множества и множества версий системы — поэтому вывод из эксплуатации перестал быть особо актуальным, но ведение всего остального подразумевалось непрерывным. Конечно, в «народной памяти» (памяти инженеров самых разных поколений) живут одновременно все эти воспоминания, которые прорываются в тексты — и мы видим ровно вот такие попытки объять необъятное и плохо совместимое, как в обсуждаемой статье Википедии. Поэтому обращайте внимание на смысл, а не на употребляемые слова — и не ждите, что про методы вам будут писать тексты со строгим контролем типов. Даже если формализацией методов занимаются математики или онтологи, будьте внимательны: оторванная от жизни, незаземлённая логика может не сработать. Что верно в математике и физике, может быть неверно в системном мышлении: в математике у стада может быть хвост, а системное мышление говорит, что так думать нельзя. Этот пример был в «Системном мышлении».

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

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

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

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

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

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

Вот примеры документирования некоторых методов работы (видов инженерии, методов разработки) в сводах знаний:

• свод знаний по организационному анализу (business analysis body of knowledge, BABoK)³⁴. Тут в главе 10 третьей версии кратко охарактеризован набор из 50 методов (так и называемых «метод»), начиная с 10.1 Acceptance and Evaluation Criteria (Определение критериев приемки и оценки), 10.2 Backlog Management (Управление бэклогом), 10.3 Balanced Scorecard (Сбалансированная система показателей, ССП), 10.4 Benchmarking and Market Analysis (Бенчмаркинг и Анализ рынка), 10.5 Brainstorming (Метод мозгового штурма), 10.6 Business Capability Analysis (Анализ бизнес-возможностей), 10.7 Business Cases (Бизнес-кейсы), …, 10.47 Use Cases and Scenarios (Сценарий использования и Сценарии), 10.48 User Stories (Пользовательские истории), 10.49 Vendor Assessment (Оценка поставщика), 10.50 Workshops (Воркшопы или Семинары)

• свод знаний по проектному управлению института проектного управления (Project Management Institute, project management body of knowledge, PMI PMBoK)³⁵. То, что называется «метод работы» в нашем руководстве, в PMBoK называют «процесс». Например, группа процессов планирования определяет и уточняет цели, а также планирует действия, необходимые для достижения целей и содержания, ради которых был предпринят проект. В группу процессов планирования входят следующие процессы: Разработка плана управления проектом, Планирование содержания, Определение содержания, Создание иерархической структуры работ (ИСР), Определение состава операций, Определение взаимосвязей операций, Оценка ресурсов и т.д. (всего 47 процессов в 6 версии PMI PMBoK 2017 года). В 2021 году вышла 7 версия PMI PMBoK, которая была существенно переработана.

• свод знаний по системной инженерии (systems engineering body of knowledge, SEBoK)³⁶. Сами методы тут не выведены явно, а рассыпаны по всему тексту. Это, скорее, «краткое оглавление для большой литературы по предмету системной инженерии», поделенное на «области знаний».

• … множество других BoK, это сегодня стандартная форма выражения знаний по разложению какого-то инженерного или менеджерского метода на составляющие.

Можно спорить, описывают ли подобные документы методы, включая возможный инструментарий («гвозди должны быть забиты быстро и ровно, для этого используйте молотки, а не любые попавшиеся под руку камни»), или только «чистые объяснения», «чистую теорию», оставляя какое-то описание возможных инструментов за своими пределами («гвозди должны быть забиты быстро и ровно»). Авторы подобных документов обычно уделяют не столь большое внимание таким вопросам, не различают «научную дисциплину» и «инженерную дисциплину, включающую указания на методы работы с инструментарием». Но нужно помнить, что знания о методе меняются медленно, а инструменты — крайне быстро. Пример нового инструмента — ChatGPT в 2023 году получил 100 миллионов пользователей за первые два месяца. Это пример скорости распространения нового инструментария. Новые инструменты часто приводят к тому, что появляются и новые методы работы, опирающиеся на новые объяснения, новые знания: так, появилось несколько инструментов поиска для интернета, а метод «погуглить» появился только с появлением достаточно продвинутого инструмента интернет-поиска от Google, теперь поиску в интернете учат в некоторых вузах как отдельному методу в составе исследовательского процесса (исследовательский процесс — метод получения знаний, о котором думать надо ровно так же, как об инженерном процессе — методе получения успешных систем).

Алгоритмы поисковой системы Google меняются часто, но дисциплина «гугления» меняется много медленней. Хотя и тут уже происходят драматические изменения, ибо вопросы можно теперь задавать не только Гуглу, но ещё и AI-агентам на базе больших языковых моделей, так что знание/теория правильного вопрошания кардинально изменились и получили название prompt engineering³⁷. Но и с prompt engineering как новым методом работы с системами AI на основе новой дисциплины уже происходят драматические изменения: оказалось, что AI-системы отлично пишут промпты сами себе, и специальных знаний для задания вопросов большим языковым моделям иметь не нужно, надо просто быть достаточно умным, чтобы сформулировать вопрос и уточнить его — примерно так же, как это было бы в любой беседе с людьми. И этот вопрос может быть и поисковым запросом на получение знаний, с каким раньше обращались к Гуглу.

Так что дисциплину/знания/правила/алгоритм метода вполне можно смотреть по сводам знаний, понимая, что эти знания эволюционируют, но и могут устаревать. Скажем, SEBoK на сегодня отражает версию методов системной инженерии, бывших SoTA много лет назад. Сегодня лучшие методы в жизни уже поменялись, а в SEBoK они ещё не отражены. А ещё эти своды знаний правильно адаптировать к новым инструментам, ибо в части новых инструментов эти своды знаний обычно заведомо устаревшие, даже если основная теория метода в них рассказывается более-менее SoTA.

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

За современностью в методах и поддерживающих их инструментах, современностью материалов в предметах метода нужно внимательно следить. Например, понятие критической цепи/critical chain некоторое время назад было контркультурным, свежим словом в дисциплине проектного управления, сам термин мало кто знал. Сегодня это общее место, все уже понимают разницу критического пути/critical path и критической ресурсной цепи в объяснениях/теории метода проектного управления, и обращают внимание на возможности софта поддержки проектного управления по поддержке соответствующих расчётов — чтобы не промахнуться с инструментарием (мы приводили уже этот пример).

Не уделяют авторы сводов знаний внимания и вопросам выбора варианта метода по его сигнатуре, оставляя этот выбор за агентом, готовящимся к выполнению метода в какой-то проектной роли. Например, есть вариант метода проектного управления, описанный в PMI PMBoK, но есть и альтернативный вариант метода проектного управления, описанный в APM BoK³⁸ — и нужно выбирать, каким из этих двух вариантов метода надо будет работать, поэтому каким из этих сводов знаний воспользоваться для изучения метода проектного управления. Содержание этих сводов знаний абсолютно разное. Это химия или физика в двух учебниках окажется одной и той же, хотя и это не всегда факт для более современных учебников, а проектное управление обычно будет очень разным!

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

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

И даже на этом уровне разбиения могут быть самые разные варианты. Например, если брать такой метод проектирования как ТРИЗ, то за последние двадцать лет ТРИЗ-методы создания концепции системы были дополнены ТРИЗ-методами создания концепции использования. Так что для создания концепции использования можно или использовать методы ТРИЗ³⁹ (включая инструменты их поддержки: моделеры специфических для этого диаграмм ТРИЗ), или альтернативные методы, например сценарии использования (use cases, включая инструменты: моделеры, поддерживающие специфические языки для моделирования use cases).

Методология — это фундаментальный метод мышления, входит в интеллект-стек. Она работает с прикладными методами как предметами метода «методология». Вы уже освоили мышление по методам первой половины руководства по методологии, поэтому вам легко будет понять, почему ТРИЗ — это не вариант системной инженерии. В составе ТРИЗ::«инженерный метод», например, нет процесса/метода изготовления из практик разработки, нет архитектурной деятельности, которая даже не входит в разложение процесса/метода разработки. Зато в ТРИЗ есть довольно изощрённые методы создания концепции системы, проектирования, «изобретения». Если методологией не владеть, то можно вечно спорить: что могут, а что не могут делать инженеры-тризовцы/«мастера ТРИЗ». Они мастера отнюдь не во всех «инженерных методах»/«видах труда» из состава методов системной инженерии! Вам всё равно нужны будут кроме тризовцев в командах разработчиков и мастера других инженерных практик, дисциплины которых отсутствуют в ТРИЗ. Например, мастера организационного развития (которых готовит наша полная учебная программа, «Методология» как раз входит в эту программу). Сами ТРИЗовцы при этом не будут удерживать чеклист со всеми инженерными методами работы, которыми надо будет заниматься в проекте — или они будут рассказывать об этих методах «по наитию», вне своей ТРИЗ-экспертизы, исходить «из опыта», а не «из теории». Когда ТРИЗовцы сделают ошибку в рассуждениях о современном инженерном процессе, они её не заметят, ибо в их профессиональном мышлении нет необходимых понятий из методологии для рассуждения о методах работы, а также нет знания SoTA системной инженерии хотя бы на кругозорном уровне. Так что знание фундаментальной методологии тут существенно поможет: методология позволяет вам обсуждать границы применимости того или иного метода (и тем самым мастерства по этому методу), в том числе границы применимости ТРИЗ (и тем самым границы полезности в проекте мастерства ТРИЗ, которое может найтись у каких-то агентов).

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

Стандарты классической системной инженерии

Стандарт процессов жизненного цикла системной инженерии ISO/IEC/IEEE 15288:2023⁴⁰ Systems and software engineering — System life cycle processes является примером документирования метода не в формате свода знаний, но если приглядеться, то это оказывается очень близким форматом. Он устанавливает наиболее общие описания методов создания (но не развития) систем, созданных людьми в ходе системноинженерных проектов. Название «процессы жизненного цикла» как раз отражает, что он стандарт уже прошлого (второго) поколения системного мышления, соответственно, там инженерия ещё времён опоры на «прохождение полного жизненного цикла, от замысла через рождение до смерти», это было остромодно на момент выхода первой версии стандарта в 2002 году и преодолевало понятие «разработки» как только «подготовки к серийному выпуску, но не само производство, не запуск в эксплуатацию, не эксплуатация, не вывод из эксплуатации».

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

Эти методы/процессы определены для всего времени создания/«жизненного цикла» (развитие может быть, но явно не предусмотрено) и существования созданной системы. В выполнение этих практик вовлекаются все проектные роли (stakeholders: и внутренние, и внешние), с главной целью — удовлетворить клиента.

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

Стандарт задуман так, чтобы проверять: если вы выполняете все эти методы/процессы (то есть готовите указанные там рабочие продукты, которых огромное изобилие), то вы занимаетесь системной инженерией. Если не выполняете — то это просто инженерия, не системная. Единственная поблажка: вы должны для каждого случая сверяться не со стандартом, но с адаптированным стандартом.

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

Жизненный цикл в стандарте понимается в его одном из самых ранних пониманий — это стадии работ проекта (замысел, разработка, производство, использование, поддержка, выбрасывание), привязанные к нахождению системы в каком-то состоянии. Признаётся, что стадии жизненного цикла могут следовать в самом разном порядке, в том числе перекрываться, формируя самые разные варианты соответствий предложенных методов системной инженерии стадиям работ. То, что стадии работ привязаны к нахождению системы в определённом состоянии и параллельность стадий тем самым означает, что система одновременно находится в разных состояниях — это авторов стандарта не очень заботит. Они просто хотят выразить мысль, что методы и работы должны рассматриваться отдельно. И отсылают за концепциями собственно жизненного цикла к другим стандартам по управлению жизненным циклом (ISO/IEC/IEEE 24748-1 и ISO/IEC/IEEE 24748-2), где этот вопрос соотношения управления работами и организации инженерного процесса рассматривается подробней.

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

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

Аналогичный свод знаний в статусе стандарта для заведомо дорогой и заведомо долгой коммерчески невыгодной (то есть требующей госфинансирования) системной инженерии, который существенно объёмней (у него подзаголовок «Энциклопедия», хотя в заголовке «Учебник»), чем ISO 15288, но основан на тех же идеях второго поколения системного подхода и «водопада» — это SEH 4.0 NASA (Systems Engineering Handbook)⁴¹. Если вы хотите за государственные деньги с отставанием от всех возможных сроков создать космическую систему прошлого поколения, то вы вполне можете следовать рекомендациям этого свода знаний.

Сегодня в инженерии существует тренд перехода на методологические принципы agile, lean, lightweight methodologies, идеи типа minimal viable product — погуглите все эти понятия, если они плохо вам знакомы. Все эти принципы входят в современный кругозор менеджеров, основателей компаний, инвесторов: нужно выполнять минимум работы (lean переводим как «элегантный», «ничего лишнего»), и главное тут — не тратить ненужных ресурсов на выполнение ненужных работ по ненужным методам. В программной инженерии это уже культура. Аналогичный ISO 15288 стандарт программной инженерии ISO 12207 выглядит уже полным анахронизмом, ибо в программной инженерии новые методологические принципы, соответствующие третьему поколению системного мышления, уже победили. Но во многих других видах инженерии идёт борьба старых инженерных процессов на основе второго поколения системного мышления и понятия «жизненного цикла», а также объёмнейших сводов знаний и новых инженерных процессов, в которых вы не должны выполнять никому не нужную работу и доделывать её обязательно до конца, потому как «так надо», и «так принято», «так прописано в стандарте». Это всё приложение принципа минимального действия в физике к инженерии в целом и к менеджменту (инженерии организации) в частности.

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

Как и для любой другой классификации, для технических методов системной инженерии из стандарта можно предложить и альтернативные варианты. Например, наше руководство по системной инженерии использует более короткий список методов (и соответствующих им ролей), которые имеют отличающиеся названия от технических процессов ISO 15288. Это методы визионерства, разработки (и мы уже говорили, что разработку мы тоже раскладываем на множество составляющих методов), архитектурной деятельности, инженерии производственной платформы. Эти же методы в менеджменте и исполняющие эти методы роли называются по-другому: методы бизнеса, организовывания, орг-архитектуры, администрирования. Так что международный стандарт методов системной инженерии вроде как есть, но он устарел. И немудрено: разработки международных стандартов и голосования стран в ISO тянутся годами, методы инженерной работы и менеджмента успевают измениться раньше, чем международная бюрократия успевает менять стандарты и BoK, которые вроде как документируют лучшие практики. Но нет — это становится документированием лучших практик прошлого поколения, причём явно избыточного количества лучших практик (зато удобно отчитываться перед государственными надзорными органами, а также отчитываться об огромных затратах бюджетных денег). Лучшие на сегодня (а не на вчера) практики, то есть лучшие методы работы, надо искать уже не в стандартах и сводах знаний, и даже не в академических журналах — там опоздание в свежести знания будет на год, что сегодня ведёт к отставанию в конкуренции. Знание сегодня распространяется в препринтах, а самое современное вообще сегодня публикуется в блогах, подкастах, докладах на промышленных и научно-практических конференциях.

Но знать о существовании стандартов и публичных документов (типа BoK) с описаниями методов надо. Ими руководствуется довольно много людей, с которыми вам придётся разговаривать — и незнание их может быть сочтено профессиональной неграмотностью. Поэтому можно показывать их знание, но совсем необязательно им следовать, вам необязательно воплощать в жизнь старые методы работы из этих стандартов, когда можно сразу воплощать в жизнь современные (state-of-the-art, SoTA) методы. Другое дело, что всегда есть риск по незнанию взять за основу своей работы какой-нибудь неработающий метод. Но брать стандарт или публичный документ с заведомо устаревшим и уже известно по каким причинам не работающим методом — это будет ещё хуже. Подробней эти «муки выбора метода в условиях неопределённости» будут разбираться в разделе о теории стратегирования.

Закат тяжеловесных методологий

Мы уже упоминали, что один из стандартов ситуационной инженерии методов (ISO 24744) подчёркивал синонимичность метода/method и методологии/methodology. У термина «методология/methodology» есть в инженерии значения как минимум:

• отдельного метода/практики/«вида инженерии»,

• метода как совокупности частных методов в его разложении (процессов, практик) для достижения каких-то значимых результатов «под ключ», например, «инженерный процесс»/«метод разработки»/«методология разработки» или одного достаточно объёмного метода, например «методология управления проектами»,

• общего метода мышления о методах (предмет нашего руководства)

• учения/теории/дисциплины о методах (описание метода мышления о методах).

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

Популярные полные/исчерпывающие/comprehensive методы/методологии/процессы разработки (development process), т.е. разные варианты agile методов/методологий/процессов (например, DSDM, SCRUM, SAFe и т.д.)⁴², они же «гибкая методология разработки» (но она не одна, их много вариантов!), обеспечения качества (например, six sigma⁴³), архитектурной работы для предприятия (TOGAF⁴⁴, но осторожней: там те же проблемы с архаичностью, что и у ISO 15288, и у NASA SEM) и даже многочисленные варианты старинных по их идеям (но по датам выпуска стандарта — вроде свежих!) методологий системной инженерии, оказываются все согласованными между собой наборами множества детально прописанных разложений методов создания и развития систем или каких-то отдельных свойств систем.

Такие «полные/исчерпывающие/comprehensive/тяжеловесные/heavyweight методологии» в реальной работе сегодня прекращают использоваться, хотя их знание помогает в общении с коллегами, имеющими опыт работы в предыдущих, ныне уже безнадёжно устаревших культурах инженерии и менеджмента. При этом до сих пор процветает деятельность по продаже сертификатов на знание таких методологий. «Сертифицированный профессионал/специалист» по системной инженерии, проектному управлению и т.д. — это как раз тот, который сдал экзамен, чтобы подтвердить, что он «знает BoK исчерпывающей методологии». Вовсе необязательно, что этот специалист имеет мастерство этой методологии, то есть может по этому методу реально работать так, чтобы получать запланированные методом результаты, но он выучил пухлый томик «методологии» как описания метода и сдал экзамен на то, что может отвечать на вопросы по тексту.

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

• Общее описание дисциплины/объяснений для многих составляющих методологию методов. Эта дисциплина вводит предметы общего метода, поэтому можно сформулировать сигнатуры составляющих методов и ввести альфы общих предметов для этих составляющих методов. Составляющие методы прикладной методологии потом могут работать с подальфами этих альф. Например, agile-методологии вводят альфу backlog⁴⁵ как некоторый «список хотелок к реализации». Практики ТРИЗ-методологии используют понятие «идеального конечного результата»⁴⁶, методологии социальных танцев работают с понятием «коннекшн»⁴⁷.

• Множество отдельных методов как инструкции «что и как нужно делать» в каждой конкретной ситуации: «если встретил ситуацию X, то делай в ней Y с объектами Z». Их обычно много разных (десятки, если не сотни в одной методологии), они могут вводить свои подальфы, но в целом посвящены переводу альф из одного состояния в другое.

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

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

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

Для методологий разработки Ivar Jacobson (один из ведущих соавторов стандарта описания методов/процессов создания и развития систем OMG Essence) призывает «освободить практики от методологий» (помним, что «метод» и «методология» часто используются как указание на то, что они содержат в себе довольно много мелких методов, называемых в этом случае практиками). По Ivar Jacobson небольшие объяснения/знания отдельных методов являются отличными единицами накопления опыта — его доклад на SECR’17 так и называется: «Kill All Methods — Free the Practices»⁴⁸. Никакого метода как полного набора практик для достижения результата «под ключ», работаем с отдельными культурно-обусловленными практиками, которые выбираем не из тяжеловесных методов/методологий, а сразу изо всех возможных источников знаний. А если эта практика оказалась слишком большой (её в инженерии часто называют «методом»), то разбираем на составляющие практики и её — но используем в работе всегда только небольшую часть известных нам практик, а не работаем по детально прописанным сотням практик из какой-нибудь тяжеловесной всеохватной методологии.

Переход от тяжеловесных/heavyweight методологий (описываемых документами на сотни страниц и требующих неукоснительного соблюдения сразу всех требований этих сотен страниц) к легковесным/lightweight методологиям (описываемых короткими документами, и упирающих на очень компактный набор принципов, без длинных указаний о том, что и когда делать и без обязательного учёта всех этих принципов в их неразрывной совокупности) отражает современную культуру элегантности, стремление избавиться от ненужной работы в пользу только минимально необходимой.

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

Заявления о том, что «у вас метод SCRUM не работает, потому как вы не выполнили все до одного требования 600-страничного документа, её описывающего» хороши были в 2000 году, сегодня они вызывают улыбку. А что следование немногим принципам отслеживается много жёстче, чем следование заведомо невыполнимым уложениям сотен страниц тяжеловесных методологий, сегодня уже понятно: порядка в следовании легковесным методологиям оказывается в итоге больше, чем порядка в следовании заведомо невыполнимым тяжеловесным методологиям.

Разборка крупных методологий на отдельные небольшие методы происходит даже в танцевальных методологиях/методах/стилях. Повсеместно происходит переход от жёсткого соблюдения в танце одного какого-то стиля (хотя на конкурсах жёстко отслеживается чистота стиля!) к fusion dance⁴⁹ как сплаву разных танцевальных стилей. Например, в социальных танцах это может быть смесь/mix или сплав/fusion танцевальных стилей танго, кизомбы, форро, сальсы (см. как пример проект системного мультиданса⁵⁰).

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

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

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

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

Сами методологии необязательно ограничиваются практиками, взятыми из какой-то одной сферы человеческой деятельности. Так, agile-методологии появились как некоторый сплав (fusion) классических инженерных (главным образом software engineering) и менеджерских практик, хотя за последний десяток лет там практически не осталось инженерных практик создания целевой системы, но только инженерии и эксплуатации команды разработчиков, то есть менеджерские⁵¹.

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

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

Моделирование: методология разработки

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

Онтологические нюансы в основе рациональности при стратегировании

Ключевое понятие методологии — это метод работы. Синонимический ряд на русском языке для метода можно продолжать и продолжать. На английском тоже много аналогичных понятий: activity/action/practice/labor/engineering/method/methodology/culture/style/strategy/way of working, и тоже этот ряд можно продолжать и продолжать. Определения тут мало помогают, они выхватывают обычно только какой-то один аспект метода как объекта внимания и мало пригодны к заземлению/grounding⁵², обнаружению метода в рабочем проекте, в жизни, в физическом мире.

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

• Мыслью надо дотягивать успешность изменения описания до успешности создания и развития какой-то системы, для которой эти изменения описания делаются (прагматический аспект: если не меняем физический мир, то можно ничего и не делать).

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

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

• Привязка к физическому миру должна быть на уровне индивидов, но обсуждение обычно ведётся в типах/классах индивидов.

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

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

Методы нужны, чтобы уметь их выбирать, то есть проводить стратегирование — постоянный выбор (continuous everything!) изо всего множества возможных методов того, который оптимально ведёт к успешному изменению предметов какой-то работы (стратегия), затем планирование работ по нему, работа, затем коррекция стратегии.

Работа — это всегда действие в реальном мире, использование конкретных ресурсов, это уже не говорильня и размышления, это переход к действиям, к изменениям индивидов. Чтобы получить ожидаемый полезный (а не неожиданный бесполезный) результат работ, надо проводить эту работу по тщательно выбранному методу, который обычно называется стратегией, а саму работу вести по плану**.**

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

• Сначала вы определяете сигнатуру метода: какие предметы метода в каких их состояниях вы должны будете получить в результате реализации стратегии.

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

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

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

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

• И ещё надо обеспечить надзор: 1. отслеживание результатов выполнения метода (проверка того, что делаются все важные операции и достигаются все предписанные методом состояния предметов метода) и 2. отслеживание выполнения плана работ (наличие всех ресурсов, старты и окончания работ совпадают с запланированными, об окончании работ извещается исполнитель следующих работ по supply chain, и так далее).

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

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

Попробуйте сравнить (найти общее и описать различия), например, для спектакля балета «Лебединое озеро» и чемпионата мира по греко-римской борьбе. А ведь это два образца телесной культуры (культура — синоним метода!), это должно быть проще, чем сравнить бурение скважин на дне Тихого океана и производство берберских ковров в Марокко (бурение и производство — «инженерные процессы», синоним метода!). И это всё примеры методов.

Методолог учится смотреть на мир прежде всего как на изменения состояний каких-то объектов мира, вызываемые агентами/IPU — видеть во всём методы этих изменений объектов мира как предметов методов. Для этого он задействует все остальные методы фундаментального мышления интеллект-стека. Возможно, будет полезно не изучать подробно, но хотя бы «по диагонали» просмотреть руководство по интеллект-стеку фундаментальных методов мышления, в котором много говорится о том, как формализовать мышление, в том числе формализовать мышление о методах работы.

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

Чтобы увидеть работающих по паттерну/способу/методу работы создателей, надо понимать, что «увидеть» — это «измерить», то есть сначала буквально физически вы должны затащить свои органы чувств в ситуацию работы в каком-то месте пространства-времени, где эти органы чувств могут воспринять непосредственно или через какие-то инструменты самые разные объекты окружающего мира. Затем вы должны этими своими органами чувств воспринять всё, что можете воспринять — и вниманием вы как-то из фона должны выделить из фона важные объекты, одновременно соответствующие типам

• «работник», «работа», «предмет работы»,

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

Работник и мастер — это две роли какого-то создателя, причём с учётом всех его инструментов (можно говорить по аналогии с «расширенным предприятием»/«extended enterprise», куда включаем множество предприятий, занимавшихся созданием и развитием какой-то системы на основе каких-то контрактов, о «расширенном создателе», extended constructor, куда будем включать и инструменты, и даже множество каких-то автономных создателей, организацию (команду или коллектив как команду команд) создателей, или даже ровно то самое «расширенное предприятие» из множества самых разных предприятий/создателей. Работник, ведущий работы по методу и мастер, задействующий метод работы — это один и тот же создатель, описываемый в двух его ипостасях/ролях, работающих по методу «работа» и «метод» соответственно. Тут опять онтологические нюансы, но не будем особо в них углубляться, разве что заметим, что на работу вполне можно смотреть как на метод, которым кто-то::работник работает::метод — работа как метод задействования ресурсов для получения необходимых состояний предметов работы, и у этого метода есть свои предметы метода, свои объяснения/правила/знания и даже свой инструментарий, прежде всего инструментарий планирования и отслеживания выполнения планов (в руководстве по рациональной работе вы уже касались «работы» как метода). Но не рекомендуем настаивать на том, что «работа и метод это одно и то же, потому что я могу посмотреть на работу как на метод, это у вас же в руководстве говорится». Потому мы и говорим, что тут много онтологических и семантических нюансов (онтология, семантика — это всё отсылки к интеллект-стеку), с которыми вы постепенно разберётесь.

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

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

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

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

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

Как узнать, что работа двигается? Конечно, отслеживать состояние рабочих продуктов (например, чеклистов с отметками о выполнении каких-то операций работы), по рабочим продуктам мы можем свидетельствовать/evidence состояние предметов метода.

Так что вы:

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

• Находите/выявляете (предпринимаете усилия, чтобы найти! Сами они не бросятся вам в глаза!) для этих типов рабочие продукты (материальные объекты: документы для моделей::описаний как предметов метода, конструктивные объекты для систем, в том числе создателей), чтобы по этим рабочим продуктам оценить состояние альфы.

• Оцениваете состояние альфы.

• Стратегируете, каким методом можно продвинуть состояние альфы в текущей ситуации, понимая, что двигать придётся чаще всего множество подальф.

• Планируете ресурсы для выполнения работ по методу.

• Задействуете ресурсы: проводите работы по выбранному методу (реализуете стратегию).

• Убеждаетесь, что результаты работ используются (если не используются, то всё это можно было бы не затевать).

Это обманчиво короткий список:

• Типов мета-мета-модели в наших руководствах множество, они связаны друг с другом, имеют множество нюансов в их использовании, они крайне абстрактны, гипотеза о том, что именно для вас сейчас будет самое важное — это ведь только гипотеза. Формальных алгоритмов тут нет, поможет знание руководств, кругозор и интуиция.

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

• Оценивать состояние альфы у вас сразу тоже не получится, ибо обычно приходится оценивать состояние множества альф. Скажем, стартовали ли работы, если речь идёт о сотне работников? Вот эти пятеро уже работают, эти шестеро ещё и не знают, что им надо будет работать, но мы уже решили, что надо, а вот эти восьмеро — мы ещё сами не знаем, будем ли мы их задействовать, обо всех остальных мы ещё просто не знаем. Так стартовали ли работы? Пятеро-то уже работают, а 95 — ещё нет, и многие даже не знают, что им надо «впахать»! Это типичная ситуация при оценке альф.

• Стратегирование — тут только одно слово, но посмотрите на разложение метода стратегирования в текущем подразделе! У стратегирования довольно много шагов.

Безмасштабность методологии

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

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

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

И вы ещё и гуглите в ходе стратегирования (ну, или спрашиваете AI-помощника, или опытного коллегу-методолога), чтобы увеличить количество гипотез о методах, которые вы оцениваете при выборе метода в ходе стратегирования.

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

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

Даже просто «наблюдение» за происходящим, то есть отслеживание изменений в предметах метода в ходе работ с предметами работ оказывается абсолютно проактивным «измерением», в котором тесно переплетены чисто вычислительные/мыслительные (обработка информации) шаги с моделями мира и себя-агента, и вполне телесные (да ещё и с экзотелом/инструментом, если речь идёт о людях, но это может быть и робот, у которого сплошное экзотело/инструмент) шаги по изменению/трансформации физического мира. IPU (information processing units) оказываются вполне деятельными, агенты оказываются вполне вычислительными, это одно и то же, алгоритмика оказывается обобщённой для вычислителей из computer science и для создателей/constructors из теории создателей (constructor theory). И это рассуждение безмасштабно!

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

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

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

В зачёт идёт только работа по получению данных для мышления::вычисление и приложение результата мышления::вычисление для изменения состояния объектов физического мира. Если такой работы нет, то это надежда на дарвиновскую эволюцию (а вдруг свезёт и когда-нибудь кто-то результат размышления применит с пользой для стратегирования в реальном проекте? Это ж бывает! Хотя удачно — очень редко, дарвиновская эволюция дико медленна). У нас же на Земле достаточно интеллектуальных агентов, которые совместно занимаются техноэволюцией: они обдумывают (вот оно, мышление!) такие изменения имеющихся объяснений/алгоритмов для имеющихся методов, которые с меньшими усилиями (меньшими затратами энергии, в том числе меньшими затратами вещества) ведут к уменьшению неприятных сюрпризов от окружающей среды — повышают шансы к выживанию отдельных агентов и экосистемы этих агентов прямо сейчас и в будущем.

Так что мышление будет признаваться рациональным, возможно по длинной цепочке рассуждений и с запоминанием промежуточных результатов на несколько лет, если понятно причинно-следственно, что оно ведёт к росту успешности имеющихся на сегодня систем физического мира. Да ещё эти проекты создания успешных систем на базе сильного/универсального и SoTA прикладного мышления по стратегированию с последующими работами по реализации стратегий тесно и многоуровнево переплетены. Исследовательские (добыча новых объяснений) вопросы к миру и результаты работы по изменениям систем реального мира появляются в ходе проекта не так, чтобы «сначала исследовали, затем разработали, то есть R&D, потом сделали, потом пользуемся» (водопад), а вперемешку, параллельно и рекурсивно на разных системных уровнях.

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

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

Кроме метода с его описанием нам важно подчеркнуть материальность создателя, который задействует метод, а также наличие у создателя мастерства (вычислитель/контроллер, ведущий вычисление по алгоритму/объяснениям/знаниям/дисциплине метода) и инструментария метода.

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

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

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

Методология по мере перехода от систем с индивидуальными агентами к мультиагентным системам организаций (понятные полномочия по распоряжению работниками, инструментарием, предметами работ) как дисциплина/объяснения становится менее внятной — ибо методы с участием многих создателей моделировать крайне трудно, в частности, моделировать инженерные процессы. Когда говорят о гибких методах разработки, то чаще всего имеют в виду масштабы одной команды из 5-12 человек. Если речь идёт о scaled agile, то есть «масштабированной гибкости» — работе множества команд разработчиков над одной системой, тем более команд в разных предприятиях (extended enterprise), методология даёт только основные методы рассуждений, но готовых «рецептов», готовых методов, готовых теорий для таких сложных объектов — нет.

Метанойя, которую должен получить методолог::роль — это смотреть на действующих в мире агентов (IPU/constructor: существ, людей, организации и т.д.) и как-то выделять тот метод, работу по которому выполняет агент, его степень мастерства в этом методе, насколько SoTA этот метод (насколько SoTA дисциплина/теория/объяснения, насколько SoTA инструментарий, насколько SoTA предметы метода), насколько силён интеллект агента (то есть что будет происходить, когда при выполнении практики «что-то пойдёт не так», а не так всегда будет что-то идти). Методы — это не физические объекты, о них трудно мыслить. В последнее время появляются новые способы это делать, тут можно указать на конструктивистское понимание построение целого из частей как операций конструирования (а не как структур по отношениям «часть-целое»), предложенное Kit Fine⁵⁵.

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

А если мы говорим о самых простых (неинтеллектуальных) агентах, например, будильнике — мы всё равно можем говорить о методах, которыми он работает, хотя терминология поменяется, предпочтительным термином тут будет «функция».

Методологическое мышление тем самым безмасштабно по отношению к системным уровням как предметов метода, так и создателей, выполняющих метод.

Метод как объект первого класса

Объект первого класса — это такой объект, понятие типа для которого имеет собственное имя, который известным образом связан объектами других типов, методы работы с которым известны и тоже имеют свои имена. Методы работы с методом как объектом (обсуждение способа работы/действий, универсальное для самых разных способов и самых разных работ для получения самых разных результатов задействования метода для разных его предметов) редко встречаются, им нужно учиться, что вы и делаете, осваивая методологическую работу по нашему руководству. Дадим несколько заметок на эту тему, а также ещё и ещё будем проговаривать разные рассуждения о методах работы, чтобы нейронная сеть в вашем мозгу привыкла к рассуждениям о методе.

Метод работы имеет невидимую часть (его описание: знания/объяснения/дисциплину/теорию/правила/алгоритм в голове человека, зверя или контроллере робота, проявляющуюся в ходе работы) и видимую часть (экземпляры инструментария, изменяющие своё состояние в ходе работы предметы работы, которые по факту — предметы метода). Можно отмоделировать знания метода, получить модель — модель делает невидимые знания/теорию видимыми. Но не факт, что отмоделировать можно все знания: часть знаний так и остаётся в головах людей, которые их получили в ходе исследований (мы уже обсуждали, что исследования и разработки — это по большому счёту одно и то же). Иногда эту «невидимую», неотмоделированную и поэтому «необсуждаемую» часть знания называют «неявное знание»/«tacit knowledge»⁵⁶.

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

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

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

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

Без знаний/теорий/объяснений/алгоритмов метода (полученных или самостоятельно исследованиями, или полученных из текстов, или полученных из устного обучения и демонстраций, или полученных неявно из «насмотренности») мастерства выполнения работ по методу не будет. При этом знания могут быть явными или неявными, причём неявные нельзя будет обсудить, откорректировать ошибки в выполнении метода, сравнить эти знания со знаниями других вариантов метода. Методология требует явного моделирования знаний/теорий/алгоритмов/объяснений/дисциплин.

Для того, чтобы метод был задейстован, универсального (программируемого) создателя надо научить знаниям/объяснениям/теории метода, чтобы у него появилось мастерство выполнения метода. Так что в рассуждениях о методе всегда должно всплывать обучение как метод и как результат обучения — мастерство. Подробней будет в руководстве по инженерии личности, где личность даётся как совокупность всех видов мастерства, а основное в инженерии личности — это научение личности очередному мастерству в её составе, «развитие личности».

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

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

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

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

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

Ключевой тут вопрос: «как ещё по-другому можно выполнить эту работу? Написано ли об этом где-то в учебниках, не вышло ли новых статей?».

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

• Осознать метод, понимать, что любая работа делается не «просто так», а следует какому-то содержательному паттерну, происходит каким-то способом, и у этого способа наверняка есть варианты — это и есть метод. Это ключевой момент! Этот метод/способ работы должен как-то попасть во внимание, стать предметом рассуждения, иметь собственное имя!

• Назвать метод, назвать роль работника по этому методу. Тут важно иметь кругозор, «начитанность», «насмотренность». Название лучше бы не сочинить, а взять из культуры.

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

Как выявить метод, когда он неочевиден? Вот ряд вариантов:

• Вы можете «зацепиться» за самые разные моменты: обратить внимание на незнакомые слова и термины — и поинтересоваться, из какой они предметной области, области знаний, дисциплины, теории. По дисциплине затем восстановить весь метод.

• «Зацепиться» в ситуации за то, что используется специфический рабочий продукт или инструмент — и поинтересоваться, какую дисциплину он поддерживает, какие для его использования приводятся объяснения, где учат таким пользоваться. И опять же, восстановить метод по его знаниям/теории.

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

Главным приёмом появления метода как объекта вашего внимания будет задаться вопросом: откуда исполнитель проектной роли (человек, команда, коллектив, предприятие, AI-агент) знает, как ему выполнять свою работу. Вот какой-то работник занят какой-то работой:

• Он сам придумал, как именно эту работу нужно делать? Или подглядел у других работников? Он читал учебник, проходил курсы, следовал какому-то регламенту, инструкции или стандарту, и когда это было?

• А что сейчас говорят на эту тему в университетах, что пишут в блогах ведущие мастера этого метода? Что тут SoTA?

• Можем ли мы представить, что мы должны получить такие же результаты его работы, но быстрее и дешевле, поменяв способ работы? Как бы мы начали искать этот новый способ работы?

• Можем ли мы использовать тот же метод работы, но задействовать инструментарий получше, а также получить повыше степень мастерства для выполнения этого метода, взять покачественней предметы метода?

Если вы задались этими вопросами (в этом-то и проблема, что они не приходят в голову! Нужно иметь специальную привычку эти вопросы задавать!), то поздравляем: в вашем внимании появился метод как объект первого класса. Методологическое рассуждение по нашему руководству поможет описывать/моделировать метод (в том числе описывать «рабочие процессы» в предприятии), осознанно менять варианты метода в зависимости от ситуации, развивать выбранные варианты метода, учить себя и других работе по методу, готовить оргвозможности выполнения метода.

Главным тут будет переход от обсуждения собственно работы (быстро, медленно, какие ресурсы) к способу/методу/культуре/стилю выполнения работы и далее к альтернативным вариантам в способах выполнения работы.

Вариативность культур

Давайте рассмотрим «приготовление кофе»::культура/«рабочий процесс»/метод. «Кофе готовит»::метод бариста::роль. Мастерство бариста приобретают в школах бариста, где студентов учат знаниям/объяснениям/теории приготовления кофе и тренируют в использовании инструментария.

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

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

1. Отмер и трамбовка кофе

2. Пролив

3. Опциональное приготовление молока и пены

   1. Отмер молока и пены

   2. Капучинирование

      1. Обеспечение пара

      2. Контроль температуры

      3. Контроль объёма пены

      4. Очистка насадки панарелло после капучинирования

      5. ???Простукивание

   3. ???Простукивание

4. Латте-арт

   1. ???Простукивание

   2. …

5. Подача

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

• Поверхность молока (состояние по итогам простукивания: без «холмов» пены)

• Крупные пузыри (состояние по итогам простукивания: отсутствуют)

Простукивание у нас условно (с вопросительными знаками и курсивом) показано трижды:

• Предположительно, как последняя операция капучинирования

• Предположительно, как последняя операция приготовления молока и пены

• Предположительно, как первая операция латте-арта

Как правильно? Предписанного ответа на этот вопрос нет. Ответ существенно зависит от вашего проекта, от особенностей «вашего варианта метода»/«принятой у вас культуры» приготовления кофе.

Итак, вы познакомились с культурой/методом приготовления кофе с молоком. Какие вы можете предложить варианты метода? Например, вы можете менять варианты отдельных составляющих методов/практик в разложении этой культуры, например, для приготовления кофе дома:

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

• Капучинирование можно делать дома индуктивным капучинатором, то есть не нужно пара. Это чуть дольше, но существенно проще, не нужно очищать насадку панарелло (её попросту нет).

• Можно не обращать внимание на особенности подачи, ибо вкус зависит только от соотношения кофе и молока. Дома «красоту» и обычаи что куда лить, в какой посуде подавать, каких слоёв в итоговом напитке добиваться (латте макиато, например, должно иметь при правильном приготовлении три слоя, хорошо различимых в прозрачной чашке) можно игнорировать: вкус будет одинаковый, это как раз и говорит объяснительная теория.

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

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

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

Каждая прикладная культура работы имеет носителей этой культуры — агентов-мастеров, которых в совокупности называют «профессиональным сообществом», community of practice. Эти сообщества имеют свои своды знаний (в том числе в форме учебников и курсов, руководств и даже в случае религиозных сообществ «святых книг») по рациональным или не очень рациональным объяснениям методов, свои вузы (магистерские программы в вузе, если точнее, ибо бакалавриаты посвящены больше не прикладным объяснительным теориям, а фундаментальным), свои конференции, свои выставки, свои СМИ, форумы и чаты, у них есть свои знаменитости/celebrities как образцы для подражания.

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

• IEEE Systems Council⁵⁸, который выпускает стандарты и публичные документы по системной инженерии, а также проводит в том числе IEEE International Systems Conference и издаёт IEEE Systems Journal по вопросам системной инженерии

• INCOSE⁵⁹, International Council of systems Engineering, который тоже выпускает своды знаний и стандарты, а также проводит международные конференции по системной инженерии и издаёт журнал Systems Engineering.

• Сообществами системных инженеров в крупных организациях, например, мы уже приводили пример свода знаний по инженерному процессу системной инженерии, разработанного сообществом системных инженеров NASA⁶⁰, можно привести аналогичный учебник, разработанный сообществом системных инженеров MITRE⁶¹.

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

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

TEST Онтология метода

С какими утверждениями можно согласиться?

+++ Вид труда — это метод работы исполнителей какой-то профессиональной роли. ### Да, «вид труда»/«метод работы» — это поведение проектной/деятельностной/орг роли. Инженерный труд (инженерия как метод работы) — это то, что делают инженеры, менеджмент — это то, что делают менеджеры.

--- Метод — это использование инструментов в оргзвеньях ### Дважды нет: 1. Метод — это функция не оргзвеньев (конструктив организации), а оргролей (функциональный объект организации). 2. Использование инструментов не главное, главное — следование знаниям/объяснениям/дисциплине/алгоритмам метода.

+++ Технологии — это практики работы. Скажем, технология получения сверхчистых полупроводников — это просто синоним для практики получения сверхчистых полупроводников. ### Да, и технологии, и практики — это синонимы метода работы.

--- Практика — это какая-то инженерная или менеджерская дисциплина. Практика операционного менеджмента, например — это дисциплина операционного менеджмента. ### Нет, практика/метод как поведение описываются дисциплиной/объяснениями, описание поведения/изменений и само поведение/изменения — это разные объекты.

+++ Метод можно выполнять ### Да, оргроли выполняют методы/функции в ходе работы.

Выберите примеры разложения метода:

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

+++ приготовление борща делится на подготовку овощей, подготовку мяса, варку. Подготовка овощей состоит из их очистки, нарезки, пассировки. ### Да, это разложение метода в одном из простейших случаев, на шаги императивно/процедурно описанного алгоритма.

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

+++ плавание включает в себя дыхание, движения руками, движение ногами ### Да, это пример разложения метода плавания: одновременно происходит работа по методам дыхания, движения руками, движения ногами в общем методе плавания.

Моделирование: методы вашей работы

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

Вспомните три последних ваших разговора с коллегами по работе и заполните табличку (степень мастерства оценивайте по десятибалльной шкале, 0 — «абсолютно не владеет методом работы, ничего не умеет, допускает абсолютно все новичковые ошибки», 10 — «владеет методом работы лучше всех в мире, умеет делать этим методом работы с неизменно превосходным результатом»):

Приведите основные профессиональные сообщества, в которых вы формально участвовали:

Задание

Поставьте отметки о выполнении:

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

Эволюция методов

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

• время создания оргвозможности (время создания мастерства практики в создателе, «вызревание мастера»), это обычно довольно быстро.

• время одного исполнения работы по методу,

• время существования оргвозможности, где метод задействуется многократно,

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

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

Всё, что мы знаем про эволюцию, в эволюции практик тоже будет соблюдаться:

• Если метод существует некоторое время, то можно считать, что он как-то субоптимален (то есть не абсолютно оптимален, но лучше многих других, «победил в конкуренции», «наименее плохой»)

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

• Вариантов методов, которые дают примерно одинаковые субоптимальные результаты — огромное количество, это явление называется неустроенностью/неустаканенностью (не путать с неудовлетворённостями, термин не из психологии, он взят из физики, обобщение geometrical frustrations⁶⁴). Нет «единственно верного метода»: 1. Верный метод вообще недостижим, есть приемлемый, субоптимальный (и эта субоптимальность — только на сегодняшний день! Среда, для которой идёт оптимизация, тоже эволюционирует, поэтому статическое рассмотрение «оптимума» опасно). 2. Приемлемых методов с примерно похожей эффективностью — множество, все они наличествуют одновременно, делят одну и ту же эволюционную нишу.

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

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

• Вся эта оптимизация метода временная, речь идёт о динамическом ландшафте приспособленности: эволюция не останавливается и не заключается в бесконечном приближении к какому-то неподвижному оптимуму. Нет, оптимум сам непрерывно движется, что было оптимально вчера — уже неоптимально сегодня, а что оптимально сегодня утром — будет неоптимально уже сегодня вечером!

Иногда говорят о модах и поветриях в методах работы. Мода — это когда новый метод работы (и его теория) уже появился, и мастерство выполнения этого метода становится популярным, знание/теория быстро распространяется по агентам, метод становится «культурой», и так и остаётся популярным.

Это прямая ассоциация с индустрией моды. Скажем, некоторое время назад (первая половина 1960-х) появилась практика носить мини-юбки, и так и осталась до настоящего времени. В 60х это и была «мода». А вот в 1920 годах женщины рисовали брови, ниспадающие наружу-вниз — это быстро прошло и уже забылось⁶⁶, это можно считать «поветрием», неудачной мутацией.

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

Мемы задают варианты методов в их разложениях так же, как гены задают биологические виды: виды приходят и уходят, новые виды появляются, живут виды разное время и неожиданно по каким-то причинам вымирают или появляются. Трилобиты и динозавры вымерли, млекопитающие остались, люди появились буквально «вдруг» в масштабах времени дарвиновской/биологической эволюции, а насекомые были давно и останутся, видимо, надолго.

Вот и методы работы надо рассматривать как результат эволюции, накопления полезных для чего-то мутаций в знаниях о методе. Мемом (как геном, но из мемов, а не генов — знание о методах, поведении агента) организации состоит из мемов, определяющих организацию, но примерно то же можно сказать и про личность, где небиологическая часть огромна, и про сообщество, и про общество. Мемы приходят и уходят. Вот интерес к некоторым распространённым технологиям (синоним метода!), определяемый на основе интереса к поиску слов, которыми эти технологии обозначаются (на август 2024)⁶⁷:

Термин Web 2.0 пришёл и ушёл из обращения, но его технологии/методы остались, это было не поветрие, это была острая мода — и термин для этой группы методов появился как раз для того, чтобы отслеживать эту «острую моду». Социальные сети (user generated content) и рекомендательные системы, в которых собирают оценки, которые дали читатели-слушатели-зрители, до сих пор с нами, они никуда не ушли, их и называли технологиями Web 2.0. Web 1.0 был про «порталы» как «точки входа в сеть», порталы вполне остались (скажем, поисковая страница Гугла), но в Web 2.0 упор делался на разные варианты социальных сетей.

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

А вот с Web 3.0 другая история. Этот термин появился для обозначения технологий семантических сетей (semantic networks)⁶⁸ в конце нулевых годов 21 века. Термин отражал прогноз для «большого нового тренда интернет-технологий», потом термин подзабылся, ибо семантические сети «не взлетели», они остались довольно маргинальной технологией с не очень большим распространением.

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

Искусственный интеллект вышел из острой моды конца 80х годов прошлого века (так называемая «зима искусственного интеллекта»), но после появления ускорителей вычислений интерес к нему возобновился после появления успешных искусственных нейронных сетей в 2012 году, и продолжает расти, особенно с выходом ChatGPT в марте 2023 года.

Конечно, все эти новации были не такими сильными потрясениями, как приход социальных сетей после порталов, то есть появление технологий Web 2.0. Web 2.0 оказался очень сильным потрясением для всего человечества: каждый человек получил методы работы, дающие возможность стать писателем, журналистом, телестанцией, радиостанцией без организаций-посредников. Это был цивилизационный сдвиг, это широко обсуждалось. После появления ChatGPT ситуация меняется, искусственный интеллект очень активно обсуждается, просто терминология ушла от «поколений», моды и поветрия перестали быть хорошо наблюдаемыми.

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

Если взять методы инженерии предприятия (больше известным как «менеджмент»), то там примерно такая же картина с разными вариантами разложения этих методов. Мода — это когда практика приходит, и остаётся. Но бывают и поветрия. Вот использование терминов «тотальный чего-то менеджмент» в базе данных книг⁶⁹:

Видно, что метод total cost management появилась раньше, чем total quality management, смысл тотальности тут в том, что управлением ценой должны были заниматься все сотрудники предприятия прямо на своих рабочих местах, речь шла о «трансдисциплинарности» знаний метода. Эта идея/мем росла в популярности десяток лет, а потом немного упала в популярности, но в целом осталась. Это была мода. А ещё эта идея/мем мутировала и стала идеей, что так же тотально нужно управлять качеством: каждый должен заняться качеством на своём рабочем месте. И вот эта «вторичная мода» оказалась мощней тотального управления стоимостью, если сравнить графики в одном масштабе (на картинке это первый график), то на фоне графика роста популярности и последующего падения острой модности (но из жизни эта идея никуда не делась!) тотального управления качеством рост популярности раньше появившейся идеи тотального управления стоимостью практически оказывается не виден, нужно приводить график другого масштаба, чтобы разглядеть его форму.

Интернет привёл к тому, что идеи/мемы знаний/объяснений/теорий/дисциплин/алгоритмов новых методов и их мутаций для уже популярных методов распространяются исключительно быстро. Развитие промышленности и компьютерного инструментария дают возможность быстрого размножения реализаций этих мемов в физическом мире (как геном реализуется в клетках и организмах, так и мемом реализуется в мастерстве агентов: людей, систем AI, организаций, новые эффективные методы быстро становятся культурой в сообществах, обществах и даже человечестве, формируют фенотип. И если лет двадцать назад в доинтернетную эпоху мы видели «эволюционный срок» появления нового метода и угасания либо моды на этот метод (но сам метод остаётся! Мода приходит и уходит, но её объект остаётся), либо поветрия (метод вымирает, оказывается эволюционно неудачным) лет так в двадцать, сегодня это явно не больше пяти-шести лет, завтра это будет пару лет года (или уже сегодня такое можно видеть?), а в ближайшем будущем можно ожидать технологической сингулярности⁷⁰, одно из определений которой гласит, что это такие времена, когда технологии (синоним метода!), становящиеся культурой (то есть методы, мастерство в которых получает широкое распространение) обновляются так быстро, что ни один человек не может сориентироваться в происходящем, настолько быстро меняется мир — и поэтому смотреть надо на системы искусственного интеллекта, которые будут приобретать агентность (автономность в работе), успевать отслеживать ситуацию и тем самым получат преимущество перед людьми.

Методы с их дисциплинами и инструментарием влияют на вас, ваши организации, сообщества, общества много больше, чем вы можете себе представить. К эволюции этих методов нужно относиться серьёзно — распространение новых культур нужно отслеживать, для этого важно быть прикладным методологом в своей предметной области.

Вот, например, результаты⁷¹ постановки новых практик менеджмента в компании BHP Billiton за полтора года, и это было ещё десяток лет назад:

BHP Billiton сумела уменьшить за счёт освоения методов элегантного управления (lean management — вариант операционного управления, в котором минимизируется количество лишней работы) стоимость бурения и заканчивания скважин⁷² за 18 месяцев на 50% в бассейне Permian и на 49% в бассейне Eagle Ford. Аналогичные результаты показали и другие нефтегазовые компании, которые применяли lean management. Сам метод минимизирования лишней работы lean появился под этим названием в 1988 году⁷³, и он «пришёл, чтобы остаться», мутируя в lean manufacturing, lean construction, lean project management и далее приобретая форму, пригодную уже не просто для промышленного производства, но и для разработки (это будет подробно изложено в руководстве по системному менеджменту).

Так что с методами та же ситуация, что и с биологическими видами: общее число и сложность их растёт, численность популяций носителей мастерства в этих методах существенно меняется со временем (растёт или падает), причём каждый день появляется много новых методов и вымирает много старых.

Например, вот организационные моды и поветрия, которые были собраны Томасом Давенпортом и Ларри Прусаком в 2003 году⁷⁴, сколько из этих методов вам знакомы? Много этих методов стали культурой (то есть мастерство в них широко распространилось), а затем уже вымерло с тех пор, оказалось поветрием — но до сих пор имена этих методов встречаются в литературе. Динозавры-то вымерли, но название «динозавр» встречается много чаще, чем слово для каких-то вполне живущих сегодня видов! Более того, дети сегодня могут различать разные виды динозавров, но могут не различать ныне живущие виды зверей: это особенности бытования культур. С методами работы происходит всё то же самое, что со знаниями про динозавров и людей, будьте внимательны. Вот этот список того, что было модно более двадцати лет назад:

• Activity-based costing

• Activity value analysis

• Adaptive enterprises

• Artificial intelligence

• Attention management

• Balanced scorecard

• Benchmarking

• Brainstorming

• Brand management

• Business modeling

• Cannibalization

• Centralization/decentralization

• Change management

• Chaos/complexity

• Competitive intelligence

• Complex adaptive systems

• Concurrent engineering

• Conglomeration

• Continuous improvement

• Co-opetition

• Core capabilities

• Core competence

• Corporate culture

• Cost-benefit analysis

• Creative destruction

• Crisis management

• Critical-path analysis

• Cross-selling

• Customer relationship management

• Customer satisfaction

• De-layering

• Decision trees

• Diversification

• Double-loop learning

• Downsizing

• e-Commerce

• e-Marketplaces

• Economic value analysis (EVA)

• Economies of scale/scope

• Electronic data interchange (EDI)

• Empowerment

• Enterprise systems

• Entrepreneurship

• Evolutionary modelling

• Excellence

• Experience curves

• Experience economy

• Five forces analysis

• Flat organizations

• Franchising

• Game theory

• Globalization

• Growth/share matrix

• Hawthorne effect

• Hierarchy of needs

• Horizontal organization

• Information ecology

• Information management

• Intellectual capitalism

• Intellectual property management

• Interorganizational systems

• Intrapreneurship

• Just-in-time delivery

• Keiretsu

• Knowledge management

• Lead user analysis

• Leadership

• Lean production

• Learning organizations

• Lifetime customer value

• Loyalty management

• Management by objectives

• Management by walking around

• Managerial grid

• Marketing myopia

• Mass customization

• Mass production

• Matrix management

• Mentoring

• Mission statements

• One-minute managing

• Open-book management

• Operations research

• Organizational ecology

• Outsourcing

• Paradigms

• Pay-for-performance

• Permission marketing

• Portfolio analysis

• Portfolio management

• Process improvement

• Product life cycles

• Profit pools

• Prototyping

• Quality circles

• Quality of work life

• Real options

• Reengineering

• Resource-based strategy

• Restructuring

• S-curves

• Satisficing

• Scenario planning

• Scientific management

• Scientific retailing

• Segmentation

• Services

• Seven S model

• Simulation

• Six Sigma

• Social capital

• Sociotechnical systems

• Spans of control

• Strategic alignment

• Strategic business units

• Strategic planning

• Strenghts, weaknesses, opportunities, threats (SWOT) analysis

• Succession planning

• Supply chain management

• Synergy

• Systems dynamics

• T groups

• Teams

• Technology transfer

• Theories X and Y

• Theory Z

• Time-based competition

• Total quality management (TQM)

• Unbundling

• Value chain

• Value disciplines

• Value migration

• Value proposition

• Vertical/horizontal integration

• Virtual organizations

• Vision

• War for talent

• Wellness

• Yield management

• Zero-based budgeting

Это только то, что показалось авторам списка достаточно известным и популярным в 2003 году.

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

Меметическая эволюция инженерных процессов, методов менеджмента, способов обучения продолжается, а от эволюции всегда можно ждать неожиданностей. Будьте бдительны, отслеживайте новые практики.

Системные уровни целевой системы и стратегирование

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

• Того, на котором ведётся работа с системой. Например, работы менеджмента ведутся с системным уровнем организации как системы из множества организованных индивидуальных агентов (людей, систем AI).

• Уровня ниже. Если целевой уровень — это организация и методы менеджмента, то уровнем ниже будет уровень индивидуального агента и там методы различных вариантов инженерии личности, в том числе разные варианты методов коучинга, психотерапии, обучения на рабочем месте.

• Уровня выше. Если целевой уровень — организация, то уровнем выше будут какие-то бизнес-эко-системы, в которые входит организация. Там будут, например, методы организации торговли (организации рынка).

Грубо говоря, если ты строишь стену, то тебе хорошо бы разбираться в:

• стенах и их свойствах, методах работы со стенами (твой уровень),

• кирпичах и что с ними можно делать, растворе (уровень ниже твоего, но тут можно подумать и о других методах строительства стен, например, методе скользящей опалубки — и кирпичей там уже не будет, равно как не будет кирпичей при крупнопанельном строительстве, и в этом надо тоже разбираться),

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

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

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

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

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

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

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

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

Давайте посмотрим на ещё один способ использования этого знания о разных системных уровнях, разложении методов в стек, а затем использование этого стека как шкалы для спектра степени мастерства. Если вам известен спектр мастерства для какого-то стека методов, то вы можете составить

• многоуровневую программу совершенствования агента как повышения эффективности выполнения каких-то методов из текущего их набора (например, стека — но помним материал первого раздела нашего руководства: вариантов представления разложения методов множество!)

• многоуровневую программу развития агента как замену методов работы на более эффективные.

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

1. Работа с телом (уровни общего движения, усилий в масштабах тела, усилий и амплитуды в частях тела). Обеспечить себе прямую постуру (позу и мышечные усилия) и мягкую спину за счёт работы по обмяканию в области груди и поясницы. Цель ближайших трёх месяцев: приводить себя в рабочую постуру в течение не полуминуты, как сейчас, а полусекунды (танцевальное время, а не йога!), удерживать прямую постуру в вертикальной скрутке, а также делать это в ходе перформансов (не терять собранности), а не в спокойных упражнениях перед зеркалом. [это всё общетанцевальное] Увеличить угол выноса руки назад. [потребуется для поворотов партнёрши за спиной, растяжки мышц груди и рук при этом не хватает]

2. Общетанцевальный уровень. Добиться управления атаками (скорость нарастания силы в импульсе) в ведении, разобраться с инерционным ведением. [обратите внимание, что появился метод этого уровня — «ведение» — но вот дальше разговор идёт явно в терминах методов более низкого системного уровня. Чтобы поправить исполнение вышестоящего метода, нужно чаще всего работать с методами уровня ниже: «чтобы починить стену, нужно работать на уровне кирпичей и раствора». При этом даже не поминаются понятия вышестоящего уровня, то есть названия танцевальных стилей.] И поднять, наконец, голову от пола! [это, конечно, отсылка к собранности, но в данном случае речь идёт об общетанцевальном: нехорошо танцевать с опущенной головой, «смотреть в пол», это общее для всех стилей социального танца. Собранность нужна для того, чтобы это исправить — не смотреть в пол легко, особого мастерства для этого не надо, но надо просто не забывать, поставить привычку!]

3. Уровень стильного танцевания. В танго: приходить на ось ритмически точно на сильную долю, чтобы не было «недохода», выжим с места вперёд и вниз (а не вверх). Освоить «заднюю саккаду». В modern swing: чётко удерживать rolling count. В форро: отработать поворот партнёрши за спиной.

4. Уровень композиции/перформанса. Упражнение по музыкальности Рони Салеха в ритме slow-beat-beat-quick*4 (замедление в начале восьмерки, ускорение в конце, а не ускорение в начале и замедление в конце, как обычно). [вроде как обращение идёт к уровню ниже, ритмике как «движению вовремя», но тут это используется для того, чтобы разнообразить ритмические паттерны в ходе танцевальной импровизации, работа хореографа, это не совсем ритмика, это использование мастерства ритмики в хореографии]

5. Уровень вечеринки. Приглашать как минимум одну незнакомую партнёршу за вечеринку.

6. Уровень сообщества/субкультуры конкретного танца. Бывать на вечеринках как минимум двух разных стилей танцев в неделю. Познакомиться с идеями танго нуэво и стрит танго, смотреть видео, читать литературу. Осмыслить тренд разнообразия видов стайлинга и размытия стиля урбан киза. Посмотреть в Сети развитие культуры альтернативной музыки для разных стилей социальных танцев. Писать в Сети посты, популяризирующие культуру мультиданс/микс/нуэво/фьюжн танцевания.

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

Обычная стратегия роста предприятия (но и личности тоже, почему бы и нет!): освоить некоторые методы работы с предметами метода из какого-то одного системного уровня, а потом переходить к освоению методов создания и развития систем из системных уровней выше (надсистемы) и ниже (подсистемы).

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

Моделирование: практики для различных системных уровней

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

Задание

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

1. Внимание в течение полного круга удерживается без отвлечений на мышечных ощущениях от ходьбы: что напрягается, что расслаблено, что в теле двигается, а что нет.

2. Внимание в течение полного круга удерживается на равномерности движения по кругу (что в ходьбе инерционно, что требует «тяги» для поддержания скорости, можно ли сделать движение более равномерным, без рывков и толчков. Проверка: ходить со стаканом воды — насколько там будет плескаться вода?)

3. Внимание в течение полного круга удерживается на форме круга и прохождении его за ровно восемь шагов (счёт шагов при их заданной длине, диаметр круга и насколько это круг, а не эллипс).

4. Внимание в течение полного круга удерживается на окружающей обстановке в целом (помещение, включающее в себя вас, ходящего по кругу)

5. Внимание в течение полного круга удерживается на контексте ситуации (управление вниманием в ходе выполнения задания из руководства по методологии).