Анатолий Левенчук – Методология 2025 (страница 13)

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

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

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

⠀

«Схемотехника»: представление метода работы графом потоков

А дальше можно сразу обратиться к традиционному представлению методов в виде функциональной диаграммы, часто называемой принципиальной схемой. Такие диаграммы разбирались в курсе «Системное мышление»: предметы метода текут/flow между создателями, которые меняют их состояния. Если это непрерывные потоки (поток/flow – это идентификация объекта на основе сохранения маршрута/пути, определение из ISO 81346:2022), то примеры сразу очевидны – методологи там называются «схемотехники», они строят принципиальные (принципиальность – это указание на функциональность, «метод работы», а не конструктивность) электрические схемы, радиотехнические схемы, но могут быть также и гидравлические схемы, и кинематические схемы и самые разные другие схемы.

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

• к деревьям/trees (хорошо представимы разными MindMaps, которые легко сводимы к аутлайнам/outlines, по факту это «хорошо структурированное оглавление», где в листьях этого оглавления могут лежать какие-то более подробные описания, фреймворк Gielingh с диаграммами гамбургера как раз такой граф «почти дерева»),

• и далее к графам/graph как общей форме представления потоков чего бы то ни было – в том числе предметов метода между ролями, задействующими метод.

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

Потоковые (движение предметов метода по каким-то путям) представления, удобно представимые графом, распространены и в менеджменте. Фон Берталанфи выделял исследование потоковых представлений систем как «исследование операций» (operations research), речь шла о времени эксплуатации (operations) – и эта дисциплина легла затем в основу операционного менеджмента, логистики, теории массового обслуживания. Конечно, в исследованиях операций в основе лежали «работы», речь шла прежде всего о потоках ресурсов между рабочими станциями. Но это можно было представить и как специфически функциональное представление: «рабочая станция» – это ведь роль, её могут выполнять разные конструктивы, она может действовать разными методами (прикладными методами операционного управления!). Опять мы попадаем в то, что методология – фундаментальная дисциплина, и даже если речь идёт об управлении работами по методу, то это рассмотрение может быть функциональным, и тут методология будет задействована для разбирательства с работами и работниками как прикладная методология операционного менеджмента – несмотря на все предупреждения «не путать метод работы и работы по методу». Методы исследования операций, методы проектного управления работами, методы операционного управления – это всё методы, только ими занимается прикладная методология этих предметных областей.

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

• Вы смотрите на них, как на «пассивную модель». Это означает, что интерпретатором модели является «тот, кто смотрит», алгоритм в вашей голове в виде программы «мастерство рассмотрения принципиальной схемы», а граф – данные для этой программы. Помним из курса «Рациональная работа», что модель – это программа, она исполняется, чтобы получить результат моделирования. Исполнитель программы, даже если он «просто смотрит на диаграмму» – тот, кто смотрит на эту диаграмму, и он также проводит с помощью диаграммы рассуждение, получает результат моделирования. Если нет рассуждения по диаграмме, то диаграмма не нужна. Когда вы пытаетесь разобраться в ходе ремонта «почему не работает», это как раз такая работа с графовым представлением разложения методов. Ваше мастерство проделывает рассуждения с описанием системы как графа связанных какими-то потоками предметов методов подсистем. Каждая из подсистем выполняет какие-то преобразования предметов метода, проводит их по состояниям, чтобы получить какой-то результат. Скажем, в логистической схеме – это работы по методам транспортировки и хранения предметов работ, а также работы по заказам партий предметов работ.

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

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

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

В непрерывном производстве (нефтехимия, энергетика) функциональные диаграммы часто гибридны, в них приводится результат методологической работы (выбор метода) и одновременно указываются и результат проектирования: элементы конструкции. Это оформляется как P&ID диаграммы, piping and instrumentation diagram и PFD, process flow diagram диаграммами33.

Каждый отдельный тип конструктива из крупной «нарезки на модули» архитекторами проектировщики будут потом в концепции системы упоминать не просто сам по себе, а как реализующий какую-то подсистему в её роли в системе.