Man, pause on caught exceptions

    Let's talk about the practical application of one very interesting topic - system thinking.

    There are many principles and methods in systems thinking, I highly recommend reading the relevant literature. For example, a simple and interesting book . Today we will touch on only one principle - the emergent, or emerging properties of systems.

    I'll tell you about the theory, and, most importantly - about the practical aspects of the application. In our lives - programmers, implementers, architects, analysts and project managers.

    First, however, a bit of theory.

    Systems and properties

    At work, we almost always deal with systems — complex aggregates of people, processes, relationships (formal and informal), explicit and hidden leaders, material objects, information systems, customers, suppliers, equipment, etc., to infinity.

    If you have all the elements in front of you, you know them, or even see them - for example, you have collected all this in one place - then the system is not a system, but a set of elements. Just a bunch of details.

    How to make a system out of this heap? You need to put the elements in their places and turn it on - start the system to work.

    This is well understood by ordinary programmers, or engineers. Here is the program code, here is the computer or server, here is the input for processing. You press ON - the system has earned. Well, or not earned, if there is an error.

    In systems consisting of people, usually the opposite is true, and this difference is key. Systems of people worked before you, and will work after you. But they will not work with you , in your presence. Actually, in your presence they cease to be systems, and again turn into a set of elements.

    Returning to the example above, when you have collected all and all elements of the system in one place. What did you do? You turned off the system.

    What is the difference between the system in the on and off states? People seem to be the same, positions are the same, processes are the same, the head is the same - everything is in place.

    The difference in the properties of the system, which manifest themselves only when it is "turned on", i.e. when the system works.

    Examples of such properties of systems - everywhere, you will find them without difficulty.

    A TV without electricity is a switched off system that does not show us its main function - to show an image. Turn on the TV - see the image, the function will manifest. Splash water on a working TV - you will see a new feature of the system, which, perhaps, was unaware.

    Such properties of the system are called emergent , or arising .

    They arise when the system is assembled and switched on from a set of elements. Both conditions are important - both assembled and activated. In our case - when it does not turn off.

    So, our task is to understand the system in order to subsequently change it. How to understand the system?

    Do not turn off

    Very simple - watch her without turning off.

    Just as we are debugging the code, we turn it on and see what happens. In principle, it is possible to debug the code and with your eyes, but in printout - remember, at the institute, the “program listing”? But so, like, very few people do. The systems we create are too complex. There are a lot of dependencies that are not so much beyond our control, but picking at them while debugging is a thankless task.

    With conventional, non-computer systems, it is still more complicated. There is no "listing". Imagine how high the work with “human” systems would be if the “Pause on caught exceptions” flag were there?

    As we usually turn off the system:

    1. We talk with employees separately
    2. We talk with all employees at once.
    3. We take all to an informal event
    4. We make a request to employees, set a task, ask for a report.
    5. Просим описать их деятельность, или написать бизнес-процесс
    6. Собираем руководителей на совещание
    7. Спрашиваем у бывших сотрудников, как работает система
    8. И т.д.

    It turns out that all our usual actions lead to the shutdown of systems and attempts to understand the emergent properties of a set of elements.

    Sherlock Holmes did a great job with such work, he called it deduction - to understand the picture in detail. True, he had no other way out - you would not ask the criminal to repeat the atrocity in the presence of the detective genius.

    Our situation is simpler, and there is an opportunity to observe working, unchanged systems.

    The best method, of course, is to be constantly present in the system, to be part of it and at the same time observe it detached. This is, for example, the path of the scrum master. And, by definition - the role of the immediate supervisor. If he, of course, does not run to meetings instead of work.

    A similar example is the coach, for example in a football team. There, monitoring the system in action, in all its power, is part of the job.

    What do we, office workers, divided by partitions, offices, sometimes continents?

    Concealed surveillance, in person or using technical means.


    Personal observation is not always possible, it all depends on your position relative to the observed system.

    If you work inside an organization, you can simply place your workplace where the system is located - people whose interaction you want to understand.

    At first, you will be a foreign element that turns off the system. But gradually they will get used to you and stop paying attention to you.

    To get used to you quickly, pretend that you are not particularly interested in what is happening around. You can pretend that you are enthusiastically working at the computer, put on headphones and turn on the music - but quietly to hear what is happening around. Do not pretend to listen to conversations. More precisely, pretend that you are not listening to conversations. I think, then you yourself will figure out how to join.

    If there are people in your team who will be easier to integrate into the system, then you can send them by giving a clear installation.

    You can use a variety of tools to track the actions of people in the systems . You won't see the whole system in this way, but at least you will find out if people use your tools or not. In words they say one thing, but in deed - another.

    Practice shows that usually 2-5 days are enough to get an idea of ​​the system. It will not be an extremely accurate picture, but a sketch, giving a general, integral vision of the system.

    The sketch can then be supplemented with details, without the use of observation. For example, add hypothesis testing data, controlling system data, etc.

    What is interesting - observation helps develop the ability to predict. Forecasting helps to quickly understand, based on experience and knowledge about the behavior of systems, which methods and changes will work and bring results, and which will not. This is another application of systems thinking and the emergent properties of systems; let's talk about this below.

    As a result, monitoring the system that is not turned off is an excellent method that is difficult to replace with something. Observation helps to see the system as accurately, impartially and objectively as possible, without interpretation.

    Any other variant is interpretation or projection in a certain coordinate system. Especially if you ask the system manager about the system (as it often happens). This applies not only to the work of the programmer, but also to the daily routine of management.

    Actually, there is nothing new in this approach; it is often used in certain areas.

    For example, in the retail and services sector, secret buyers are used - people who are purposefully sent to a store, hotel, etc., so that they see the system in action as it is.

    New in this approach is its use in the work of an ordinary enterprise, usually not related to retail - production, for example. We take the old known method, we find a new application.


    Now about forecasting. In the work of the programmer often there is a situation when you need to give a forecast of the success of a project. Usually we are talking about the company's internal organizational development projects. Simply put, about change projects.

    People usually ask about other people's projects - those in which the business programmer is not involved. Those. about projects that are not executed according to the rules of business programming, but according to the rule “as I can”.

    A business programmer, after a brief study of information about a planned project, usually says that nothing will come of it. Or - nothing happens at all. The difference is clear - the project can be completed successfully, in terms and budgets, but will not bring any benefit to the company.

    The expressed opinion, i.e. The prognosis of a business programmer usually causes negative reactions - depression, anger, rejection, “who the hell are you?”, “acting. God on earth, or what? ”Etc.

    The negative reaction increases when the forecast comes true, and it comes true very often.

    However, not everything is so sad, and gradually people begin to get used to such a “superpower” of a business programmer, and even use it adequately for the benefit of the company, or their own. Some even keep records of forecasts - a notebook in which they tick off "he was right." For example, such a notebook was with two of my fellow leaders. I do not know, really, virtual or real.

    Now let's look at how a business programmer makes such predictions.

    Where do forecasts come from?

    It's all about the use of knowledge about the behavior of systems.

    The draft of changes always contains at least two systems: variable and modifying.

    Variable - what we are going to improve . Business process, work unit, the interaction of functions, etc. We will call it the object of change .

    Changing - the one who comes up with, implements and implements the changes . Simply put - the change implementation team. We will call it the subject of change .

    Both systems consist of a set of elements and connections between them. These are people, information systems, goals, formal and informal relationships, a management model, leadership approaches, influencing forces, etc.

    In the subject, i.e. project and team changes, there are specific elements - the algorithm for selecting the implemented methods, the goal and motivation of the project manager and team, the implementation methodology, the principles of project management, leadership approaches to assessing the progress and results of the project, the team’s plans for life after the project, the choice of the problem being solved .d

    Nobody, even the most experienced business programmer, can reliably see all the elements and connections. But everybody sees a certain part, both the project manager of the implementation, and the head of the company, and all surrounding colleagues.

    However, the most accurate forecast is given by a business programmer. Everyone is looking at the same thing. See the object, see the subject, the project plan, resources, environment. But the forecast is radically different. Why?

    The answer is very simple, and even boring: a business programmer takes into account historical information . Historical and statistical information about the behavior of similar systems.

    The result of a change implementation project is made up of a combination of two systems - an object and a subject. If the systems are combined incorrectly, the result will be negative.

    If a new project is being changed, but the systems of the object and the subject have practically not changed, the result with high probability will be the same. The same people are trying to implement the same method in the same unit.

    Examples of mass. If you look at the systemic view of the introduction history of changes in your company, you will see confirmation of this pattern.

    It is possible to look for examples on the street, now just the right system is called “winter”. Winter + city + these, like them, that snow must clean. Years go by, and the result is similar. Because all systems are in place, unchanged. Oh yes, sometimes winter happens without snow - then the result is quite good. Just whose is he?

    The most difficult thing in this approach is to determine whether there are differences in the systems or not. To do this, you need to learn how to rank the elements and connections of the system by importance - to highlight its key, system-forming elements and connections.

    There is no single recipe, there are many options. There is, for example, the 7S method created by McKinsey, which breaks down the system into 7 parts. Personally, I prefer not to limit myself, otherwise you can see something new for yourself.

    Understanding the key elements can be done intuitively, but you have to recheck yourself, because the quality of intuition depends on the current level of your development as a business programmer, and may deceive you.

    The selection of key elements will allow you to make a forecast faster, without plunging into details and not studying the noise. You simply see that the key elements of both systems remained in place, and you can be sure that the result will repeat with high probability.

    The more often you do this exercise, the faster your skills will develop, and the more accurate your predictions will become.

    There is such a popular expression in our country - “we wanted the best, but it turned out as always.” Now, after reading, you understand that something is missing here. It would be more correct to "like the best, we acted as always, well, here's the result ...".

    I saw an example of this approach from our Foreign Minister, Sergey Lavrov. At a press conference after a meeting with US Secretary of State Rex Tillerson, Lavrov said: “With regard specifically to the problems of Syria, in particular B. Assad, today we discussed historical excursions, and R. Tillerson said that he is a new person and prefers not to delve into history , and deal with today's problems. However, the world is designed so that if we do not learn lessons from the past, we can hardly succeed in the present. ”

    Then Lavrov listed several examples - combinations of object and subject systems, with the same goal of the subject - the introduction of a model of democracy through the overthrow of the dictator. NATO and Iraq, NATO and Libya. And predicted the result of a combination of systems of NATO and Syria.

    For now, it seems, Lavrov is right.

    Also popular now: