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

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

Так как это пост по первому разделу, то опишу в нем и ожидания от курса в целом. С 2018 года это у меня уже где-то 4-5 проход по курсу разных версий: 2018, 2019, 2020, и текущий версии 2023. Всё как говорит Анатолий — каждый раз читается почти как новый курс.

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

Про бесполезность определений и глоссариев

Раньше, когда читал всякие сложные-умные и непонятные определения какого-то термина (особенно, что касается рабочих ИТ-шных тем), думал, что причина их непонимания была во мне (отчасти, конечно, это так).

Чтобы понять о чем я — посмотрите любой «глоссарий» в каком-нибудь ТЗ. Вот первый попавшийся при беглом гуглинге пример:

CASE-технологии — системы автоматизированного проектирования (САПР) для процессов и (или) программного обеспечения их поддержки. CASE-технологии являются программными инструментами, в которых автоматизированы те или иные методы (методологии) анализа, проектирования и разработки.
(источник)

Безусловно, о терминах (а точнее — о концептах, которые за ними стоят) надо договариваться. Но хорошо бы это делать так, чтобы не запутать друг друга еще больше. Как? Точно не с помощью глоссария.

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

1. Кто-то, кто не глубоко погружен в контекст, читает «ТЗ», встречает там множество новых для него терминов и говорит: «ничего не понятно, сделайте глоссарий, потом поговорим!»
2. «Так принято у нас в компании». Или это требования какого-нибудь ГОСТа, которого мы придерживаемся (особенно, когда документы делаются для гос.заказчиков или крупных организаций, где «по регламентам» глоссарий обязателен чуть ли не во всех документах
3. Автор документа верит, что глоссарии — это добро и они должны быть всегда. Этот случай похож на предыдущий, только тут это делается по собственной воле. Обычно, это добросовестно заблуждающиеся специалисты, которые хотят, но не знают хороших методов как сделать лучше. Или специалисты из старой школы, которые привыкли писать формальные «заумные» документы и думают, что без них вся разработка встанет и никто никакой системы не разработает — но по факту эти документы никто не читает в силу их бесполезности (или крайней сложности вычитать из них что-то полезное), в основном они нужны для галочки при подписании актов выполненных работ с заказчиками (чтобы подписать акт, заказчик должен увидеть тонны макулатуры, на которой написано «ТЗ на разработку ...» и с красивой ГОСТовской чертежной рамочкой на титульном листе).

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

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

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

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

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

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

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

Рекурсивность и фрактальность

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

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

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

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

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

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

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

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

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

Почему сложно переучиваться (контринтуитивным, фундаментальном вещам)

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

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

Последовательное увеличение сложности задач

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

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

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

Неустроенности между разными системными уровнями

Примеры из учебника:

• вирус и организм. Появляется иммунная система, убивает вирус. Вирус мутирует — обманывает иммунную систему. И так на усложнение.
• мемовирусы — информация, которая распространяется в людях и меняет их поведение. Например, в более агрессивную сторону.

Мои попытки найти примеры:

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

«Требований» больше нет

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

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

Просто короткие мысли

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