Methodological modeling ​

Modeling something in this situation graphically is not possible. The impossibility of graphical modeling is discussed in the book by A. Levenchuk, "Visual Thinking. A report on why one cannot rely on it," 2018, https://ridero.ru/books/vizualnoe_myshlenie/. Here is an attempt at such modeling: we start drawing for agent-1 and his intention, then add the second agent and his intention, mention his strategy/method and action plan, a couple of important characteristics and preferences of his first role, then add the second role of the second agent, and here we understand that the diagram is already complex and continuing in this way will only lead to confusion. But we have not yet drawn the methods by which the roles act! And in the picture, there are still no systems with which the methods work! And even with the already mentioned agents, intentions, strategies, action plans, concerns, and preferences, we return to listing the difficulties from the previous paragraph, and realize that we have just begun modeling!

But aren't all these important objects in the situation that must be considered? This is how methodological thinking works, finding objects of missing types in the situation and drawing attention to them, forcing one to reason about them. Without this, there will be no systems thinking (remember that important characteristics/concerns are characteristics of various systems encountered in the project, all these roles expressing their interests work with systems).

What is the solution here? Conducting all mental operations in one's mind? Also not a solution, as with numerous systems and all the agents with their rapidly expanding descriptions, one cannot keep everything in mind. Therefore, the solution lies in tabular (or even text) modeling. There are many objects and their relationships in the real world, but not so many object types in the methodology (agent, intention, strategy, plan, role, concern, preference, skills, and so far we will limit ourselves to this set of concepts. The method of work, work, position, will be considered later), and these types will be mentioned in the columns of quite long tables.

What does this look like in practice? More about this will be explained in the course "Methodology." There, it will be shown how to turn graphs into lists, and then present these lists in the form of easily editable tables. The key to solving the problem of systemic modeling is understanding that the objects of attention in the project have types, and for project objects from "real life," one must move from the real objects to the types from textbooks and then think, using these textbook types to understand what to do with the objects from real life.

In the course, we denote the type with the symbol :: (two colons). In everyday speech, this would often be either "object type" ("agent Vasya") or "object-type" ("Vasya-agent"), but we do not rely on a completely everyday language and show the classification relationship with the :: symbol, presenting first the object, and then its type. We do not say "aircraft system" or "aircraft-system" in life, we omit the type designation, this is normal. But why use the type designation if the type is not indicated in real life?

Types improve understanding (Ford::car, Ford::US President, Ford::founder Ford Motor Company::company - types greatly facilitate the understanding of the meaning of words), but most importantly - types help in modeling. Modeling is creating a model, an object that in some important aspects replicates the behavior (often in thought, in computation) of the object being modeled. This means that the model substantially compresses information about the object being modeled, indicating only the important aspects. This is where types are used to indicate the important aspects.

In a project, one needs to understand the type of each object/entity/concept. If it is about some transdisciplinary (i.e., systemic, methodological, etc.) reasoning from our course, then one needs to find the missing objects in life, pay attention to them - and do this in writing, "systematic modeling." This is the "involvement of systemic thinking" (if you don't write - you don't think! If you don't model - you don't think systematically!).

Methodological thinking, systemic thinking, and all other types of thinking are ways to manage attention in a complex situation, to find objects for which it is convenient to discuss cause-effect relationships, convenient to build explanations. All the material about methods, roles, and agents is precisely the material about types that are somehow related in the text of the course, with relationships established between them.

So if someone is doing something in a project (if someone is doing nothing - don't pay attention!), then they are working with a method. What is this method/practice/culture/style? Are there other ways to do the work, achieve the expected results faster and cheaper? This "someone" is thus an agent in a role! What is this culturally conditioned role? When a role is found, one moves on in the reasoning: the role performing a certain method of work will have certain important characteristics/concerns, in which the role will have its preferences/interests that the method according to this role would like to see realized.

So, if you see someone selling something (and the sale can be done in very different ways!), you still need to figure out which actions of the agent represent "selling"::"method of work." Thus, you see the agent/actor/"role player"/org unit as a seller::role. If there is a "seller," then immediately look for the object of interest (the price) and preference (the price must be higher). Then you can come up with your strategies (methods to act further) and build plans to implement them. For example, look for a second role for the agent (Vasya, playing the role of a seller), or go find another seller, or propose cooperation (realize that at such prices, you should not buy from Vasya but become his dealer and abandon your previous project, i.e., leave one of your roles or even the project, and implement a completely different strategy).

If roles with opposite preferences/interests in one important characteristic of the system or project are performed by one org unit/agent/actor, such a situation is called a "conflict of interests," and this is a very common situation. Let's remember the proverb "let the goat guard the cabbage patch": the goat itself believes that it will balance obeying the preferences in eating the cabbage and protecting the cabbage from this eating. People from the outside will have a different opinion. The conflict of interests inside the head of the participant of this conflict is poorly discernible, but usually noticeable by other project members. To the person themselves (or to the representative of the organization - an organization with many people, but in a conflict of interests), they seem like experts, deeply familiar with their conflicting roles, and thus making "informed decisions." But no, these decisions do not seem "informed" to other participants in the situation! The goat guarding the garden certainly makes "informed decisions" about how much to eat from the garden and how much to preserve from any encroachments.

Positivity in terms of preferences in their concerns for project roles is not necessary. Just the preferences of "negative characters" and "anti-clients" are considered in projects with a reverse sign - thieves are not allowed to steal, murderers are not allowed to kill, terrorists are not allowed to commit attacks. At the same time, it is remembered that in one project there will be a "cursed spy and traitor", but the same person in another project will be a "brave scout, risking his life in the holy struggle". Thus, this "positivity of preferences" is related to ethical reasoning, more about this in the ethics section of the "Intellect-stack" course.

Project/work/activity/organizational roles are indeed roles that are played, not "incarnated." Agents embody role-playing skills: safely enter a role, safely exit a role, remain in a role for an extended period. And they never forget that they can change roles, that it's a "role-playing game." Vasya Pupkin, imagining that he is not playing the role of Prince Hamlet in Shakespeare's play, but that he is actually Prince Hamlet — this is a sign of a mental issue. When changing Prince Hamlet for Vasya Pupkin to an engineer-architect or a cardiologist, nothing fundamentally changes.

Pyotr Petrovich plays the role of a husband in one system project, a buyer in a project related to another system (and at this moment he can both continue to play the role of a husband if the purchase is related to the role of a husband, and the husband may disappear during this time - just as Prince Hamlet disappears while the actor plays Othello in another play, or even just sleeps at home, resting from the theater), a patient in a project related to a third system. If Pyotr Petrovich has actually reincarnated into Prince Hamlet, in the acting profession it's a sign that Pyotr Petrovich has gone crazy and is confusing himself with Hamlet. Similarly, if a person at work forgets that they are playing the role of an engineer or a manager: they've gone mad if they believe that they are the engineer or manager! Roles are played, not incarnated!

Project roles, work roles, activity roles, organizational roles, labor roles, team roles, cultural roles, simply roles: you name the role of an agent with various epithets, but it's not that important. It's all synonymous, simply by specifying you will accentuate different shades of meanings, here the synonymy is of the same kind as the synonymy of methods/practices/cultures of work. We will remind about this synonymy several times. And the role itself is not that important. What is important is that the functional object is considered at the moment of its functioning. The role is a system as a functional object; for the functional object, it is important what changes the role makes in the environment, that is, what this role does, what function/method/practice this role performs. The role is always viewed at the moment of its work/functioning, evaluating the changes that its behavior makes in the surrounding world (evaluating, for example, according to some checklist, which objects in the environment of the role system have changed one state to another state).