УСВОЕНИЕ основ системного мышления (Глава №8)

Развиваю практику усвоения новых моделей мира, теперь буду писать раз в неделю пост по новой структуре: систематизация моделей, собственно моделирование примеров и разбор отдельных непонятных или интересных моментов. Прошлые два поста писал вперемешку по двум последним пунктам, чувствую, что не хватило явного увязывания материала воедино. Опробую формат на запоздалом усвоении главы №8 "Система".

Освоение модели основ системного мышления

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

Системное мышление 1.0

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

Основными системными методологиями в прошлом веке (да и сейчас) наиболее вероятно являлись системное мышление 1.0 и системная инженерия. Физический мир сложен, потому якобы впервые в биологии значимо развился подход, который позволял рассматривать даже наиболее малые вложенные объекты, не теряя связь с большими - насколько понял, это и породило теорию систем (системное мышление 1.0) и некоторые базовые методы системной инженерии. Параллельно и сложность систем, которые строили люди, начала расти быстрее: в производстве космической и военной техники уже участвовали исполнителей - тут явно получила развития системная инженерия. С повышением потребности в программных комплексах во второй половине XX века эту трансдисциплину также помогла развить уже прикладная программная инженерия.

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

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

Например, назовём типичный стол системой в понятиях системного мышления 1.0. Стол, однозначно, физичен, хотя и звучит как идеальный объект, то есть не конкретный "стол Кирилла", "стол артикул 34242", а какой-то общий образ физичного объекта. Минималистичный стол-по-умолчанию состоит из четырёх ножек, четырёх бортиков и столешницы (прямоугольной деревяшки) - исходя из картинки эти элементы явно связаны между собой сильнее, чем, например, с котом в углу. Благодарю этому появляются явные очертания стола, видны его границы - совокупность таких двух факторов говорит о целостности стола. Элементы объекта не входят физически друг в друга, однако можно говорить о том, что стол сам может входить в некие надсистемы, например в систему-процесс "обедающая семья" или "работающий человек". Потому утверждаем, что стол также обладает свойством вложенности. Проверку четырёх основных факторов провели, стол является системой.

Cистемное мышление 2.0

Пятое свойство - субъективизм

Что насчёт системного мышления 2.0? Что это и зачем придумано? Системное мышление 2.0 разработано Школой Системного Менеджмента на основе, очевидно, системных мышления / инженерии 1.0 и последних (state of the art) исследований в области системной инженерии за авторством организаций международных стандартов таких как OMG Essence, INCOSE, IEEE и прочих. Вызывающее "2.0" говорит о том, что со времени кристаллизации прошлой версии человечество значительно продвинулось в помышении полноты и эффективности методологии, модели существенно изменились.

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

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

Архитектурное отличие системного мышления 2.0 от 1.0 в том, что теперь и на уровне фундаментальной методологии рассматриваем любую систему как нужную каким-то... людям? Не всегда людям, интерес на уровне подсистем может исходить из автоматизированных средств. Ролям! В итоге получаем пятое обязательное свойство системы - субъективизм, или то, что система должна быть нужна неким ролям для решениях их потребностей, иными словами должна удовлетворять ролевые интересы. Далее называя объект "системой" будем подразумевать то, что она обладает всеми пятью перечисленными свойствами.

Виды систем по назначению

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

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

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

Три ключевые области интересов

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

Предпринимательство

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

Инженерия

Разбирается с тем, "какая?" целевая система будет наиболее оптимальной для того, чтобы удовлетворить интересы выявленных ролей. Сначала превращает интересы в требования, тем самым формирует общий образ системы и предлагает на каждый некую функцию. Также решает, "как работает?" целевая система, то есть разрабатывает архитектуру - наиболее важные аспекты решения. Оба артефакта передаёт на реализацию обычным инженерам по специальностям, при необходимости также нарезает на понятные работы.

Менеджмент

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

Жизненный цикл системы

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

Жизненный цикл - это модель стадий развития системы во времени по выбранной форме. Под стадией понимаем уникальную совокупность целей и рабочих продуктов на неком временном промежутке жизни системы. Типичными стадиями являются:

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

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

Системное описание

Добрались до самого вкусного. Успешная система - та, которая удовлетворяет интересам всех проектных ролей. Как уже говорили, для любой системы можно выделить три ключевые области интересов, по одному на каждую системную роль. Интуитивно хочется создать описание системы, которое построить непротиворечивую модель создания системы, учтёт все эти интересы. Также ощущается верным сделать это по стадиям ЖЦ, ибо жизнь системы не ограничивается одним только созданием или одной эксплуатацией. Тут и получим системное описание создания успешной системы!

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

Перейдём к самому сладкому - попрактикуемся и создадим разные варианты системных описаний!

Системное мышление 2.0 в действии

Что за роль "кассир в KFC" и зачем нужна?

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

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

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

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

Ура, применив системное мышление 2.0 разобрались в том, кто такой кассир в KFC и зачем он нужен :)

Как научиться плавать кролем?

На деле очень актуально, ибо как раз этим занимаюсь. Итак, как это водится давайте сначала исследуем надсистему и найдём целевую систему.

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

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

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

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

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

Разбор дополнительных моментов

Оценка пользы основ системного мышления 2.0

Прошился какой-то версией системного мышления / системной инженерии 1.0 ещё в универе. Оперировал понятием система, хотя спокойно мог сказать "система Менделеева" назвать архитектуру проекта системой. Не знаю, как мимо меня проскочило свойство физичности, не помню его в главы учебника "теория систем". Однако на дипломном проекте окончательно осознал, что программные системы, да и вообще любые используемые людьми системы - это лишь инструменты для решения неудовлетворённостей, то есть в отрыве от нужд значения не имеют. Базово освоил одну из практик разработки систем через выделение потребностей, анализ существующих решений, выделение их недостатков, которые затем становятся потребностями к новой системе, если таковую вообще нужно создать и т.д. Освоил проектирование архитектуры программных систем с помощью UML 2.0, базовые функциональные и структурные модели.

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

Наконец, уже крайне благодарен версии 2.0 за фокус на целевой системе. То есть за то, что целевой называем только именно ту систему, которую наша организация стремиться произвести, вместо того чтобы называть так "нашу систему" - модуль, над которой тружусь я в составе конкретной команды. Как говорили на тренинге, шутка про то, что уборщик в NASA запускает ракеты, а повар в Tesla самоуправляемые автомобили - это на деле классный ценный подход, который позволяет любым ролям, как бы глубоко по системным уровням они ни были, оптимизировать практики для воплощения общей целевой системы.

Я вот думал, что автоматизирую завод, а оказалось, сейчас что перевожу нефть! То есть как фрилансер участвую в автоматизации вагоноремонтных заводов, которые являются системой обеспечения для целевой системы перевозки нефти. Это я решил налегке перед разработкой новой функциональности отмоделировать систему как полагает, найти целевую и добраться до описания собственной. Голова закружилась, когда начал разбираться в устройстве корпорации по перевозке нефти, в надсистеме, в её подсистемах и системах обеспечения... но то, что перевожу нефть, понял точно. Хотя, чёрт возьми, сложно получить из этого ценность, когда думаешь о ремонте вагонов - для меня, software engineer далёкого от прикладной области, вагоны по перевозке песка и нефти не имеют отличий. Может, проблема в неосознанной компетентности? Считаю маловероятным, ибо по сути автоматизируем уже существующие бизнес-процессы, иными словами уже есть люди, которые в этом разбираются,и мне проще уточнять узкие моменты у них, нежели чем разбираться самому глубоко.

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

По мелочи

  • Хм, всегда думал, что инженер по требованиям... ага, думал, что имел на этот счёт мнение, а оказалось, что никогда его нормально не формулировал. Короче, думал, что инженер по требованиям больше писец, чем разработчик, то есть как бы собирает интересы внешних проектных ролей в единую непротиворечивую модель, решая противоречия и заполняя пробелы. Нового не изобретает, не решает о том, как система должна выглядеть. Хех, прописал, выходил так и есть! Было подумал, что эта роль принимает решение об общем виде целевой системы, однако нет, это конкретный вид это уже ответственность архитектора, разве что общее видение ещё предприниматель может предоставить. Хм, а чем тогда занимается технический писатель?
  • Раньше условно целевой системой в проектах личного обучения видел нейроны в голове, на что Анна в комментах к одному из предыдущих постов указала, что это слишком глубоко по системным уровням. Теперь полностью согласен, считаю модель "человек, умеющий выполнять роль X" или "человек, умеющий выполнять практику Y" в личных системах лучше, ибо фокусирует внимание на функции целой системы человека, ведь не только нейроны реализуют деятельность! Также сразу фокусируем внимание на конкретной роли или практике.
  • Когда прочитал, что целевые системы бывает выделять сложно, то недоумевал. Казалось, это легко, мы ведь знаем что делаем, верно? Применил модель к рабочему проекту и понял, что это отнюдь непростая задача. Через какое-то время только осенило, понял, что выполняю роль в подсистеме обеспечения, а целевая система, оказывается, вообще далеко... пример того, что для уборщицы Tesla целевой системой является самоуправляемый автомобиль сильно помог.
  • Теперь понимаю, что такое проект! Как-то давно вели в компании дискуссию, мол, кто как понимает отличие продукта от проекта. По моделям ШСМ вижу однозначно: продукт - это одна из целевых систем, а проект - это система обеспечения по производству продукта, которая включает в себя команду из внутренних проектных ролей; документацию требований, архитектурную и неархитектурную; менеджерские модели по воплощению системы. Хотя корректно ли проект назвать именно системой, он вообще физичен? Если смотреть на него как на модель воплощения целевой системы, то есть совокупность её описаний, моделей процесса - то нет. Если смотреть как на процесс, то есть "проект-процесс" по воплощению системы, то да. Но почему-то проект по умолчанию процессов не воспринимается, есть какое-то другое понятие?
  • Надсистема - а какой именно уровень надсистемы имеется в виду? Как будто на уровень выше, чтобы не нарушать очередность, иначе, как будто, может возникнуть путаница. Только на практике нужно будет проверить, полагаю.
  • Решил, что буду исследовать пользу от системного мышления 2.0. Примерный образ исследования интереса таков: системно поставлю задачу; скорее всего попробую глубоко изучить учебник, одновременно итеративно практикуясь; под конец попробую применить на учебном проекте под менторством преподавателей на практике; уже потом буду рассчитывать получить качественный рабочий результат. До этого, конечно, и в работе и в личных системах также буду даже большее ранние версии трансдисциплины тестировать. Только не знаю, а как понять, что трансдисциплина реально даёт пользу или наоборот замедляет, как измерить?

P.S. Почему-то радуюсь объёму вычислений в этот раз, но с другой стороны терзаюсь сомнениями. Это я плохо подумал, что так много вышло? "Чем меньше - тем лучше!" - гласит мудрость, которая как и любая мудрость без контекста цели является бессмысленной. Да нет, цель ведь самому вычислить, нет цели именно выдать читателю минимально востребованный результат мышления, так что ок. Протестировал новый формат, крайне доволен простоте структуры из трёх разделов, а также субъективно ощущаемой эффетивности (хотя сложно из под positive bias такое оценивать). Как и всегда, сердечно благодарю за внимание и желаю успеха в ваших личных проектах, надеюсь было интересно :)

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

Можно ловить блох, типа того, что наша система - это не всегда подсистема целевой системы (она может быть и подсистемой системы обеспечения), а системы в окружении не всегда входят в надсистему. Однако, все эти тонкости вы уже постигнете в курсе “Системное мышление 2020”, тк у нас только введение в системное мышление.

Описание проектов также вполне достаточное для нашего курса. Рекомендую по каждому проекту сделать резюме, выделив основные системы, подсистемы, потребности и требования, роли и практики.

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

Кирилл, спасибо за отличный пост!
Присоединяюсь к похвалам Церена) очень круто получилось!

По поводу вашего проекта: в целом, мы рекомендуем проводить системное разбиение на много уровней вверх до целевой, если вы играете в проекте роль предпринимателя и/или хотите получить повышение в должности. Но это может быть сложно, особенно если учесть, что у нас только вводный курс) поэтому можно пока ограничить инвестиции вычислительного ресурса и сосредоточиться на системном разбиении вокруг “нашей системы”: ваша система +1 уровень вверх, и система обеспечения. Можно и сейчас начинать, почему бы и нет) потом возьмете учебник СМ2020 и доработаете описания.

Что касается технических писателей / системных аналитиков и пр: они отличаются от роли "инженер по требованиям", тк инженер принимает решения по поводу включаемых требований (согласует с остальными ролями, но принимает и влияет на систему), а "аналитики" и "технические писатели" часто трудятся только над описаниями, которые далеко не всегда влияют на ЦС. И из-за этого может быть куча проблем в проекте) На эту тему у Анатолия есть пост "Доклад на конференции AnalystDays 11", рекомендую почитать)

Проект можно рассматривать и как нефизичную сущность (описания проекта, документация и тп), и как вполне физичную (субъективизм рассмотрения действует везде в СМ))). Когда мы рассматриваем проект как систему обеспечения, мы в первую очередь рассматриваем выполняемые командой проекта практики в ходе работ. Мы можем указать на конкретные результаты работ команды (рабочие продукты), есть содержание деятельности (практики), наконец, сама команда состоит из физичных людей-в-ролях, которые где-то на свете существуют (приходят работать в одно здание или работают удаленно). Если "проект" сложно воспринимается как сущность, то можно вспомнить такие сущности, как "танец" или "матч" (тоже системы и можно описать, почему).

Надсистемой называем систему на 1 уровень выше по отношению к той, что прямо сейчас в центре внимания. Если в центре внимания “наша система”, то у нее будет своя надсистема. Если целевая – то надсистема к целевой.

Пользу от трансдисциплины сложно замерить “в лоб”. Более того, скорее всего, на первых этапах ее изучения она либо вообще не будет давать прироста (потому что еще недостаточно знаний для ее применения), либо замедлит вас. Тут вопрос в том, насколько длинный период вы рассматриваете в проекте/ах. Если конкретная трансдисциплина нужна для проектов определенного типа, с которыми вы больше не собираетесь сталкиваться, то изучать ее – это оверкилл. Если вы с такими проектами будете сталкиваться еще не раз, то изучение ее может не дать на текущем проекте прироста, зато дать его где-то в будущем. Так что тут надо в первую очередь встать в роль предпринимателя и постратегировать) тогда станет понятнее, и что изучать, и как замерять.

Пост крайне интересный! В следующий раз можно просто разделить, например, выделить теорию отдельно, и примеры по каждому проекту описать отдельными постами, как и предложил Церен.

Церен, благодарю за комментарий! На мой взгляд, действительно, материал здорово структурирован и понятен, спасибо вам за это :slight_smile: Отмечу, что мне ещё помог “прогрев” в виде ранее усвоенной версии методологии 1.0. Про резюме принял, действительно, так будет проще отслеживать объекты внимания. А за углублением обязательно пойду на выделенный курс!

Анна, благодарю за обратную связь!

По рабочему проекту принял, тоже решил, что пока стоит сосредоточиться на “моей системе”. А что для роста в должности нужно делать описание по уровням вверх - интересная идея, не думал об этом.

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

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

“В лоб” сложно, но можно смотреть на то, что удалось достичь другим выпускникам))
Например, на последней конференции Антон Меркулов рассказал, как пришел в новый проект, разобрался с интересами – и все завелось. Иван Падабед пришел в новую организацию и смог обучить 100+ архитекторов.

После конференции опубликовано видео, где Юрий Геронимус рассказывает об успешно движущемся к завершению большом проекте для нефтегазовой компании.
В прошлом году Сергей Пчеляков рассказал об успешном завершении проекта модернизации опорной сети Мегафона (когда пришел в проект, он уже слегка опаздывал, плюс в процессе был риск опоздать на 12-18 месяцев – в итоге не только не опоздали, но и завершили проект почти на полгода раньше срока).
Еще несколько кейсов, когда студенты СМС прямо в ходе курса становились “директорами по развитию”)

Так что успехи/outcomes есть. Но сложно замерить, потому что трансдисциплины не дают моментальной выгоды, нужно изучить, пропитаться и попрактиковаться в этом. Большинство выпускников не сразу, после лишь одного курса, смогли вот такие успехи получить, а несколько лет СМ применяли.
Плюс, если говорить об СМ и других дисциплинах интеллект-стека, то мы тоже ведь концепты уточняем / меняем, чтобы они быстрее усваивались. Так что это тоже влияет на скорость освоения и получения результатов. Как написал Церен выше, то, что сейчас объясняется в подготовительном курсе за 3 мес, раньше в “основных” курсах медленно и тяжело ставилось за год.

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

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

Ощущения - да, это огонь, взял на вооружение :slight_smile:

Кирилл, спасибо, шикарный пост! Каким-то образом он прошел мимо меня, хорошо, что далеко все же не ушел :wink:

Константин, благодарю за комментарий :slight_smile: