Alphas are the common object of observation for the organization/team/collective/cooperation of the project ​

On one hand, many members of the organization/team/collective/"working group"/project cooperation as individual organizational units play certain organizational roles in the project in the order of labor division and deal with each "own" alphas. Here we will not list all possible synonyms (including "project" as a synonym for "project organization", not the work of this organization - this enumeration includes everything that is involved in the work of the organization, as in the 4D ontology, all physical objects that interact in the project, enter the object "project" through the participation relation, so that the organization and the project work considered in this way are represented more or less the same, albeit with different focuses in this consideration). The team will be considered in its functional consideration: as organizational roles, rather than as organizational units playing these roles.

The project system diagram (and even the enterprise as a whole) implies that all members/roles of the team take responsibility for all project alphas, not just their own. In systems management, this is collaboration. Division of roles into subroles is a division of labor, but how to divide roles into organizational units in each case needs to be decided separately, and the problem of collaboration may arise even when all roles are performed by different parts of one personality, and the individual unexpectedly does not coordinate their own actions (the reasons are different, for example, a desire to be paid for two jobs that together will not improve the system but worsen it, or simple carelessness, or just a lack of understanding of what is happening).

Lower levels of interaction lead to different results. For example, in coopetition, the result of one operation is fed into the input of another operation, but no one takes responsibility for the outcome as a whole. If someone provides rotten threads, and someone sews a sail, then someone can provide rotten threads, and someone will sew a sail from them, and the one who sews will sew brilliantly (and receive a premium for their sewing), but the sail will tear! And the person who provides the rotten threads will also be sure that they did a good job (because the threads rotted on the way to the seamstress - what complaints can be made to the thread manufacturer?). As a result: there is coopetition, everyone seems to have earned bonuses, but there is no collaboration - the sail tears, the customer does not pay for the bonus, and doesn't even pay for the torn sail, the company has problems. Of course, each new level of interaction includes the previous ones (there is no collaboration without coopetition):

• Ignoring what others are doing, we may even harm them. Sometimes the excuse is “it’s not personal, it’s business” – and the interesting part is that the one suggesting this believes it’s a great justification, and even those who are harmed seem to “understand the motives”. And since we are ignoring, there is no communication, we are not interested in what others are doing, we don’t show our work to anyone.
• Informing and communicating: willing to communicate, but not willing to change anything in our plans and actions. If someone is willing to adapt to us, then it’s fine. But we work as we work. For example, we display the hours of our work – but we are not willing to change them even when someone really needs us to.
• Coordinating: willing to change some of our plans and actions. For example, to look at the working hours of a neighbor and come during their working hours. Fill out the form required in the system where it is required, rather than submit an application in any format and send it by personal email.
• Cooperation: participating in the division of labor and resources, agreeing on how to interact at input and output interfaces, coordinating everything with neighbors. At the same time, the participants in cooperation do not have responsibility for ensuring that everything works as it should. If a jacket is poorly sewn, and it comes to me for sewing on the buttons, I will sew the buttons on tightly, you won’t be able to pull them off with your teeth: there will definitely be no complaints about the buttons, but if the jacket turns out to be crooked, it's not my concern.

Collaboration: sharing not only work and resources, but also responsibility for the overall outcome of all work participants. However, this is difficult to achieve, as it requires every participant to understand not only their own operations, but also their impact on the overall results (in fact - it requires system thinking from cooperation participants).

Of course, this is all a very simplified version. For example, the architecture of the organization simply requires some autonomy in the activities of different organizational units - this means that some requests must be ignored. So, in fact, each of these steps includes all the previous ones, and in a collaborating organization, in fact, you will find all other types of behavior. But the opposite is not true: if only coordination is available to you, cooperating and even collaborating will be difficult. In different organizational units of a large organization, there may well be different levels of readiness to collaborate, and this is specifically addressed in management practice as "catalyzing collaboration."

The goal of systems thinking is for all project participants to agree on objects of collective complex work, while the goal of the methodology practice is to cooperate and collaborate in collective complex work! Team members agree on what these alphas are (what objects in the physical world correspond to them) and on their actions regarding these alphas, in such a way that there are no configuration conflicts.

For example, you can take a sub-alpha of the usage concept for the system description alpha. This alpha can be considered both as a description of the target system as a black box, and as a description of a transparent box for the supra system, connecting the needs of some external project roles (customers, users, etc.) with the description of the target system as a black box, which is part of the transparent box of the supra system as the environment of the target system. Here are some states for this alpha (do not take them directly as they are described here into your project! Be sure to adapt them so that they make sense in your project, so that the team understands these states and agrees with them). The usage concept (or its increment) goes through the states:

• Conceived (external project roles agreed on the need for a new system to satisfy the needs)
• Bounded (functions of the new system in its environment are understood)
• Coherent (the usage concept coherently describes the essential characteristics of the new system)
• Acceptable (the usage concept describes a system that is acceptable to project roles)
• Addressed (functions are sufficiently embodied in the system to be accepted by external project roles as satisfying their needs)
• Fulfilled (at the moment, the needs of external project roles are satisfied)

The developer of the target system is primarily interested in the realization of the target system, but they can also have some influence on the supra system (for example, suggesting some minor changes to the systems in the environment of the target system to improve the interface between the target system and the systems in its environment). Therefore, the states of the system description alpha, i.e., the state of the usage concept content, as well as the state of the system realization alpha as satisfying the usage concept, are of interest to the system developer. However, the alpha of the external project roles is also of interest to them - the needs from them, and the usage concept shows how to satisfy them with the target system.

We will not continue to write type, as in the previous paragraph "system description alpha", or even "system description"::alpha. People do not pronounce the names of types, you must carefully watch the types of concepts hidden behind the terms! They do not say "airplane system", they just say "airplane". They do not say "system description alpha", they say "system description" (but this is an alpha/concern: the object you should focus on in the project). If something changes in the project and it is important to track these changes - this is an alpha (most often a sub-alpha of one of the main alphas, possibly from the area of interest further down the creation chain). The same goes for "project/labor/activity/engineering role" as a type. We do not write "labor role of a businessman/merchant/entrepreneur/seller", we write "businessman/merchant/entrepreneur/seller". Occasionally, we will remind you that we are talking about alphas or project roles, or systems. You should keep track of the object types, engage the "type machine" in your brain! Otherwise, you will not be able to link the knowledge of the type that you have learned from our course to the objects in reality. Roughly speaking:

• In your mind you hold the meta-meta-model types from fundamental disciplines (for example, from our courses, systems thinking and methodology),
• In the headers of columns in tables, you specify types from the domain meta-model with the terms accepted in the textbook (metaU-model) or in the current situation at the enterprise (metaS-model) . That is, you select from "almost synonyms" what will be understandable to people around you. But the types in the headers of the columns in the tables will be typed with the types of the meta-meta-model "in your mind",
• In the cells of the rows in the tables there will be values of characteristics of objects in the operational model (models of real-world instances), classified by types of the meta-model (from the textbook, or the situational/accepted in the enterprise) in columns , which are classified by types of the meta-meta-model "in your mind".

You need to track all three levels of models! Without the types of the meta-meta-models (types from our courses, keeping the focus on them "in your mind"), you would poorly distinguish important objects in the subject areas (from the textbook, or in the enterprise), you would surely forget to consider culturally-conditioned/"civilizationally known" important characteristics of the system and project, make rookie mistakes (or simply errors due to lack of personal or collective focus).

If you still didn't understand what was written in these highlighted paragraphs, you need to retake the courses "Modeling and Focus" and "Systems Thinking" and complete all the modeling tasks there. This is a prerequisite for the methodology course.

The visionary is interested in external project roles and commercial opportunity (they must find a sufficient number of paying agents with needs that can be met by the system being developed - the "market"). Therefore, they are interested in tracing/correlating the characteristics of the target system with the needs of external project roles, controlling the focus of the engineering team on achieving project goals: creating a successful system realization, which satisfies needs (not "our system works well," but "the supra system of our client with our system in it works well").

The operational manager (in small projects, this role is often played by the person appointed to the position of "project manager", "team lead") is interested in the enabling system, their organizational unit. To advance through the states of the usage concept of the target system (alpha of the area of interest of the target system), the operational manager needs to allocate time and resources for developers.

The "machine park" of many projects today often corresponds to the "corporate information system park". This is the responsibility of the platform engineering engineer. This role is usually performed by organizational units under the guidance of the CTO and/or CIO. Usually, in their task lis...