Борьба со сложностью в мышлении
Edsger Dijkstra в 1974 году ввёл[1] понятие разделения****предметов интереса (separation of concerns, разделение важных характеристик/предметов интереса/озабоченностей) как способ упорядочивания человеческих мыслей о каком-то предмете. Этот принцип гласит, что нужно обсуждать сложные ситуации по одной важной характеристике (concern) за раз, удерживая внимание самых разных ролей на каком-то одном аспекте, одной ипостаси этой ситуации. Это не значит, что игнорируются все остальные. Просто это удерживание во внимании и одного прямо сейчас обсуждаемого аспекта проблемы, и одновременно удержание внимания на объемлющем обсуждении всей проблемы. По словам Edsger Dijkstra про такое мышление, «It is being one- and multiple-track minded simultaneously».
И это разделение мышления по предметам интереса проводится рекурсивно, в понимании системного мышления — это одинаковыми методами мышления на каждом из многочисленных системных уровней. У каждой системы на каждом системном уровне есть много предметов интереса/важных характеристик, и они там обсуждаются по очереди. Ввиду эмерджентности на каждом системном уровне системы, подсистемы и надсистемы проявляют разные наборы свойств, имеют разные характеристики, и нужно обсуждать и эти разные системы, и их разные характеристики. Предметов интереса много для каждой системы на каждом системном уровне, плюс ещё есть предметы интереса к создателям, там уже отношение не часть-целое, а отношение создания — но это ведь тоже системный подход, начиная со второго его поколения.
Сложность описания/обсуждения системы тем самым уменьшается за счёт разделения одного запутанного сверхсложного обсуждения на отдельные не очень запутанные и не очень сложные обсуждения по двум направлениям:
- деление полного обсуждения всей системы на обсуждение её отдельных частей по системным уровням. Каждая часть системы проще, чем система в целом, поэтому обсуждение проходит более-менее единообразно на каждом уровне, а каждая часть системы описывается концепцией её использования (ConOps или OpsCon с точностью до множества нюансов их сходства и различий, которые отличаются в каждой инженерной школе мысли), то есть описанием системы как «чёрного ящика». В ней игнорируется внутренняя структура системы и её частей, поэтому обсуждение начинается всегда с целых систем в составе надсистемы, или целых подсистем в составе системы, и так «до самого низа» и «до самого верха». Само системное мышление как бы стоит «сбоку», оно трансдисциплинарно, удерживает внимание на всём системном разбиении, чтобы ничего не забыть. А уж системы каждого отдельного системного уровня в их разбиении могут обсуждать или прикладные специалисты одной команды, или даже разных команд.
- деление полного обсуждения каждой системы на одном системном уровне на обсуждение с помощью множественных описаний****разных аспектов этой системы как прозрачного ящика. Важнейшие из этих описаний — это концепция системы (systems concept), включающая и функциональное, и конструктивное, и пространственное описание, и стоимостное, равно как и множество других. Тут разделение идёт по основным инженерным ролям (визионер, разработчик, архитектор, инженер внутренней платформы разработки), которые тоже специализируются на отдельных видах систем какого-то одного системного уровня.
- Отдельно обсуждаем создателей в их графе, то есть проходим уже не по отношению часть-целое, а по отношению создания. Системное мышление заставляет удерживать во внимании и создателей!
Д****етальное и в подробностях обсуждение огромных сложных систем и графов их создателейпринципиально (в силу самой сути системного подхода) может быть разбито на достаточно маленькие части, и ни одна часть этого обсуждения не будет забыта, ни одно описание не будет пропущено. Как съесть слона? По кусочку за раз!
Системное мышление по своей природе коллективно, оно позволяет разделить и умственный (по проектированию), и физический (по изготовлению и эксплуатации) труд, задействовать множество разных живых и не очень живых исполнителей для самых разных проектных ролей — и при этом детально продумываются части системы на всех системных уровнях для учёта всех известных ролевых интересов на каждом системном уровне.
Но как договориться о том, как склеивать все эти самые разные описания самых разных частей системы в одно целое системное описание? Как договориться всем этим ролям и их исполнителям? Все эти описания можно совместить, если понимать, что они описывают одно и то же место в пространстве-времени, относятся к одному и тому же воплощению системы. В центре любых системных обсуждений будет физическое воплощение системы, рассматриваемое в момент эксплуатации (run-time), к нему будут привязаны все остальные рассуждения.
Без системного подхода сложные проекты с задействованием большого количества разных специалистов выполнить в срок и вовремя невозможно: система будет неуспешна, ибо чьи-то интересы не будут соблюдены (то есть забыты, потеряны: на них не хватит внимания команды!), и в системе тем самым будет ошибка, люди не будут довольны её работой, или не будут довольны работой проекта, который создаёт систему (не будут довольны системами создания). Банально: если вы забыли обсудить какую-то систему, подсистему, надсистему «нашей» системы, или целевой системы, или даже создателя — быть беде, «если что-то может пойти не так, оно пойдёт не так». Неизбежны коллизии, что-то придётся переделывать/re-work, тратить незапланированные ресурсы.
Системы обсуждаются п****о одной части за раз, одному описанию части за раз**—** ни на секунду не теряя из вида целой системы в её окружении**, а также её****создателей.**
Создатели («системы создания», убираем слово для типа мета-мета-модели) — тоже системы, только нужно не забывать, что всё их существование связано с целевой системой и поэтому не нужно говорить, что они сами и есть целевые. Но они могут вполне быть «нашей системой» для менеджеров как инженеров предприятия. Если менеджер вдруг говорит, что «моё предприятие — это и есть моя целевая система», то это нарушение коллективности в мышлении, менеджер ни с кем не сможет договориться. Он должен честно сказать, что целевая система — это то, что делает его предприятие (даже если предприятие предоставляет сервис), а само предприятие — это для него «его система» (а не общая для всех система!).
Если вы поставляете какой-нибудь продукт для использования в составе какого-то предприятия или оргзвена (или его части, если речь не идёт обо всём предприятии или оргзвене в целом), то оно будет надсистемой для вашего продукта. Часы, которые вы поставили автомобильному заводу, могут быть использованы заводчанами (а не «пользователями часов») либо в выпускаемом заводом автомобиле (и заводчане тогда не «пользователи часов!»), либо в заводском цеху (и тогда заводчане сначала выступают в роли разработчиков цеха как надсистемы для часов, а потом и в роли интересующихся временем, «пользователи часов»).
В случае инженерии предприятия все системные рассмотрения остаются, но меняется терминология и практики. Так, модулями предприятия называются подразделения (тут реже говорят про оргзвенья, но системное мышление обращает внимание и на коллегиальные органы типа рабочих групп, советов и комиссий), функциональными частями предприятия являются его оргроли, функции/методы работы оргролей часто называют рабочими процессами, а управление конфигурацией предприятия называется учётом. А ещё важно, что оргзвенья не разрабатывают, а организуют, при этом само изготовление — это не производство, а лидерство (людям, которые вменяемы, объясняют, как устроено их оргзвено, и какое оргместо они там должны занять, сотрудничая с другими людьми — это и есть лидерство). Подробней — в руководстве по системному менеджменту.
Если речь идёт об организационных системах, то само понятие инженерии предприятия(enterprise engineering) как-то стало употребимым пару десятков лет назад, но терминология там не стала «железно-инженерной», а также не стала общесистемной, уровня мета-мета-модели. Если речь идёт о каких-то других видах систем (медицина, правоохрана, танцы, политика и т.п.), то терминология может отличаться от терминологии инженерии и системного мышления ещё больше. В образовании (инженерии личности) речь идёт об инженерии мастерства, и там выделяются все те же роли: визионер — это культуртрегер, проектировщик — это методолог, инженер-технолог — это методист, и т.д. (подробней об этом — в руководстве по инженерии личности).
Слова не важны, важно общее устройство мышления (на что обращать внимание во всех этих проектах: системное мышление занимается управлением вниманием). Слова важны: без терминологии какой-то предметной области вы вообще не поймёте, о чём идёт речь. А ещё важны типы мета-мета-модели: с ними вы сможете увидеть общее в самых разных ситуациях, самых разных проектах, самых разных системах самых разных видов.
- Вам потребуется в каждом проекте сопоставлять «яблоки из учебника» с «яблоками из жизни»: отождествлять понятия, соответствующие предметам самых разных предметных областей (domains, понятия из мета-модели) с фундаментальными понятиями системного мышления **(мета-мета-модели)**. Помним, что это просто ориентирование на местности: вы быстро поймёте, где находитесь. Дальше надо будет:
- Стратегировать, то есть разобраться, каким методом с какими предметами метода вы будете работать**—** даже если н****и вам, ни всем остальным не****ясно, что же надо делать, чтобы добиться успеха. Для этого предложить несколько наиболее вероятных для успеха всего дела методов, а затем при помощи методов принятия решений выбрать тот, который не удаётся раскритиковать.
- На основе выбранного метода спланировать ваши действия**, привязать к конкретному времени и ресурсам****.**
- Принять планы всерьёз: выделить (или даже добыть, если поначалу их нет) ресурсы и выполнить эти планы, даже если речь идёт о пошаговом планировании.
- И дальше продолжать системно мыслить, то есть продумывать то важное, на что указывает системное мышление, надёжно удерживать это важное в коллективном внимании участников проекта, не давать вниманию рассеиваться.