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