Where did we get the bottle?
Flowcon, or Flacon - a management technique, including tasks. Flow, project, development, routine functions, regular, etc.
Many, having learned about the methodology and solutions based on it, ask questions - what and how, what is the essence, on the basis of what “world practices” have been done, what metrics are used, who suits them, where they come from. I answered each one individually, but I decided - everything, stop, I got tired of writing the same thing a hundred times. I'm a programmer, or what? Reuse can be not only for the code, but also for information. I will write once, I will try to answer all the questions in the article, and come what may.
Best of all, it seems to me, to state in the form of a story, because the birth of a bottle is closely related to my career, if I may say so. So do. Chased.
')
The first project and task management technique I learned was called PMBOK. It was the distant 2006.
At that time, PMBOK was almost a monopolist in project management. In resumes and vacancies only heard that PMBOK. There were no flexible methodologies on the air then, although somewhere they already existed.
PMBOK was then a purely cascade project management method, i.e. assumed a rigid structure of stages and tasks, terms and dependencies end-beginning. Accordingly, it quickly and beautifully crumbled into fragments in the then 1C implementation projects, due to the constant violation of the famous (then) Triangle Budget - Time - Content rule.
In those days, neither clients nor implementers could do sensible TK, write functional requirements, model the work of an enterprise. Yes, and configurations, such as UPP, constantly threw surprises - they evolved. As a result, the compiled list of works became irrelevant about a day after the start of the project.
But the brains of programmers are inquisitive, and they came up with some kind of combination of PMBOK and then unknown Agile (Agile). Let's call it "Yellow Edzhil." And I, too, had to become his apologist.
Yellow Ajile was based on the stages created by the PMBOK, only fundamentally replacing the goal of each of them. What is the goal in PMBOK? Perform all tasks of the stage.
Yellow Edgele came up with another goal: to sign the act . For example, there is a stage - “Implementation of warehouse accounting”. At the stage of designing and drafting TK, certain works appear in it, such as “Material report”, “User training”, “Setting access rights”, etc. - depending on the depth of study at the stage of rapid survey.
This list of works served as a starting set to start somewhere. A programmer comes to the warehouse manager, or to storekeepers, or materialistic accountants, starts talking to them, and it turns out ... Well, there it turns out so much that the notebooks ended with terrible force.
At first, the brains spoiled by the PMBOK said: no! You can not do it this way! It is necessary to do only what is written in the TZ! And project managers entered into long-term negative negotiations with the client. Someone managed to persuade the customer for additional work, additional TZ, and so on. Most don't. The customer said: damn it guys, I don’t know in my heart what TK is, and what improvements in your program need to be done so that everything works for me, but if it does not work, I will not sign the act .
Reality basically won, and the project lived in two dimensions - a plan and a fact. The plan, it would seem, can be thrown out, but there is a snag - a budget has been drawn up for it, which protects the project manager on behalf of the customer in front of someone and cannot be touched. But the fact remained a fact - it is necessary to make a minimum of the maximum of what the customer wants in order to sign the act, otherwise there will be neither a payment, nor, accordingly, a salary.
So a model of Ejayl, even a yellow one, formed in my head. The vial began to form, and contained two task management practices. It seems that they contradict each other, but in life they got along well.
So, to the heap I will mention. Seeing problems with project management in myself and colleagues, I started picking theory outside the PMBOK, and found in the store a book with the straightforward title “Project Management”, written by the Tate couple. They called their method CORE PM.
The point is about the same as in the PMBOK. The main thing is the immutability of the plan. Straight separate large, complex and bureaucratic procedure invented how to make changes to the plan.
By that moment, having already learned the yellow Edgele, I could not add anything from this book to my bottle. And this is very good, because I realized again that there are no Smart Uncles in the world.
About the fact that there is no Smart Uncle in the world, I understood long ago, still at the institute, when I was practicing. At that time I was fascinated by statistical methods of product quality management, and went to the factory, where I spent a month, collecting data for a diploma.
At first, the goal was to collect the data that the teacher and I then wanted to use in specialized software (Statistica?). It seems that the idea was to build a mathematical model of conveyor production in order to understand the influence of different stages on the quality of the final product.
Before the trip, the lecturer put some books about Shewhart maps, statistical process control (SPC), general quality management (TQM) to me. He himself, apparently, did not read them - otherwise he would not suggest building a mate. production model. They were suitable, for example, for pressure sensors, where the construction of the model and the regression analysis of the Draper were the basis of calibration, but not for the automotive industry.
And I read books. It was all so simple that it took your breath away. And at the plant, too, were Smart Uncles, in the service of quality management. They knew the basic concepts from these books, but, to my great surprise, they never used not only quality improvement methods, but even the simplest formulas for assessing the current state of the technical process.
And the formulas were megaprosma. You take a hundred details, measure, enter numbers in Excel, consider the mean, standard deviation (that sigma), and derive a simple and understandable indicator - the fitness index, or the reproducibility index (if the process is stable). Actually, this indicator clearly said, everything is normal with the process, or not.
When I figured this figure, they were shocked. And from the fact that they finally saw this figure, and from how terrible it turned out to be. They asked me to count for a few more parts and machines - and what am I?
Then there was a lot of interesting things, including those that were possible through simple efforts, during my presence, to radically improve the quality of production. But that's not the point.
A key thought came to me then: Smart Uncles know a lot, but don't do a damn thing .
The methods are complete - both in quality management, and in task / project management, and in management in general. Ask any effective manager - you will read a whole lecture on how and what to do according to such and such methods. And ask briefly - does he do what is written in the methodology? FIG there.
The bottle is enriched with very useful knowledge. Everything should be done and checked by oneself; nobody can be trusted, especially to those who cannot show their results in practice.
Having understood that I will have to comprehend everything myself, I decided to read something else. I didn’t want to master a new method, but to understand something more fundamental. I came across the book "Russian Model Management" by Alexander Prokhorov.
To say that a book is brilliant means to say nothing. You have to read it, if you work in Russia. There, fortunately, there are no ready-made recipes, but all the root reasons for why we have everything as it is are elegantly painted.
For a long time I will not paint, I will name only some key thoughts that are important in the context of this material.
The first is that the work of the Russian people must be measured, and so that they do not turn out. Because we are so used to deceiving any system that we do it subconsciously. We do not accept rules, restrictions and laws. More precisely, we nod our head, agree, and we ourselves are already thinking how to deceive.
The second is that Russian people work best in the so-called. cluster cells, i.e. small teams not controlled too tightly. Open space is not for us. As you understand, the same principle is inherent in scrum.
Third, the Russian people do not do a damn thing the way they are told. This is a key idea in the implementation of any technique. You give instructions on how to act, let people go and wait for the result, but it is not. Because people throw out your instructions, and do as they used to.
The bottle after this book is incredibly enriched. True, the methods of solving these "Russian" problems had to be found independently. I found controlling.
Controlling is a digit-based control. One of my favorite techniques. I emphasize the main point: controlling is not control. This is management.
If there are no numbers, control is carried out blindly, on the basis of indirect information. When working with tasks, this is especially true, because the measurement system of tasks, as a rule, is no good. Usually, these are labor costs in hours, deadline (and getting into it) and, in fact, pieces of solved problems. To effectively manage on the basis of this data is impossible.
Most of the benefit to the bottle came from that part of the controlling, which formulates the requirements for information, i.e. to numbers, methods for their production, reproducibility, quality, depth of study, etc.
The figure should be of high quality, but such are rare. I have already written several articles about this, I will not repeat. Just take a word - quality, according to the criteria of controlling, you will not often see numbers. Probably because no one has read a Wikipedia article about controlling.
So, in the vial appeared controlling. It is universal, and henceforth governed the formation of any numbers that were required by any method.
Boundary management, or border management, is a little-known science about the transformation of business systems. Although maybe something has already changed - I studied it several years ago, I don’t remember the last name about the articles about the works of Eric Trista and someone else. Now the Internet says that there is some English-language book on this topic - I can not say anything, I have not read it.
The essence is insanely simple: boundaries . Inside the business systems, processes, even in one person - a lot of boundaries. Physical, emotional, energy, etc.
Borders are bad and good, useful and harmful. Some interfere with the normal course of the process, others divide the mixed stream into two parts, helping to process it faster. Some isolate a person from the necessary information, making it difficult to respond in time, while others protect him from unnecessary information, allowing him not to be distracted.
In short, the boundaries and management of them - is megakruto. To understand this, you have to try. Sensible people, like you, enough to understand the key principle, to begin to apply it. The rest need case studies and concrete practices, and there are, in fact, many such. Only they are not on the Internet, but it is necessary to invent themselves.
I came up with a few, from published - Iceberg and the method of swimming lanes .
Boundary management had a very strong influence on the bottle, and almost all of its parts - on the management of the life cycle of the task, on the organization of priorities, on the regular management.
He called this section the same as the publication of the same name. This was the first experience in building a system for managing orders, memos, plans and projects based on accumulated knowledge.
The experience is rather successful, although the article sounds more negative. When constructing the system, the principles of controlling, boundary management and iceberg (from business programming) were mainly used. Of course, it turned out to be too technocratic, but the experience, in its usefulness, was enormous.
First, it was a system for the entire company, and not for a small team of programmers. Secondly, the system has reached its goal - it has increased executive discipline to previously unprecedented heights.
But the main thing for me is the practical use of parts of the bottle on a large scale, and not on programmers, but on ordinary people. Something, according to the results, had to be thrown out of the methodology, but some methods proved to be effective. For the most part, of course, controlling.
I am not talking about myself, but about a field of knowledge called systemic thinking. It is full of books and cases, so I will not retell. I will note only one very important principle that strongly influenced the bottle - emergent, or emerging properties. These are any properties of the system that can only be seen in the on state.
While you are sitting away from the system, and fantasizing about how it works, you do not see the emergent properties. You can design, draw, program, test, even in humans, but when you start the system in real work, emergent properties will begin to work.
For example, you assumed that one person sets a task, and another takes it up. Oh well. The second person may simply not see the task. And if he sees, he will not read. And if he reads, he will say that he has not read. Or did not understand. Or it is not his job. Etc.
Or you thought that the team coordinator - the head. Provided for him AWS, with a list of incoming tasks, which he will distribute to the performers. You start the system, and you find that it doesn't distribute the devil, but only runs around the meetings and corporate parties. And the tasks are distributed by a quiet, homely-looking guy sitting in the corner - the hidden leader. And he, offended that he was not noticed, will also begin to sabotage the implementation of your system.
These are the emergent properties. They are not visible when speculative design, they appear when you start the system to work.
It is clear that “emergent properties” are just such an abstraction that someone invented to call a phenomenon that everyone understands — you need to start the system, and always come up with something else, from architectural design errors to banal bugs.
But in the case of task management, we always deal with a complex system consisting of automation, management, people with their relationships, and team goals, customers, managers, etc. The success of task management depends on all components, albeit to varying degrees, and none of them can be ignored.
And if you, for example, are a programmer automating task management, you can not just, but you will ignore a lot. It's easier. Therefore, the system may and will not work. There will be no bugs, but there will be no sense to it either.
And I wanted to work. Therefore, I added system thinking to the vial, both as one of the fundamental principles and as concrete accents and practices.
It sounds strange, but these very books made a bottle with a bottle. Now briefly explain.
A decent samurai in life did this. First went to learn martial arts to some master. He studied until he exceeded him. And here we have a decent samurai who owns the technique of a certain school (by analogy - PMBOK).
He left school and went to shuffle through ancient Japan, in search of a new challenge. I went to different schools, called the local master to a duel, and made a decision based on the results. If the master turned out to be weaker than a samurai - well, not destiny. If the samurai lost, then he fell on his knees and asked to take him as an apprentice. And he studied until he surpassed the master again.
This went on several times. And at some certain point, the samurai was born his own style.
In general, he was not born at all, this is normal. Some remained “without a face”, being only masters of several well-known schools (this is the type of MBA).
And some thought out the style even before receipt in the first school. For example, one of the national heroes of Japan, Miyamoto Musashi, the inventor of the style of two swords and the author of the Book of Five Rings. Or Masutatsu Oyama, a Korean by nationality, the creator of the Kyokushinkai karate school. Both of them invented their method somewhere at the beginning of their career, and then they perfected it. And he and the other on their way met more powerful masters, and remained to learn from them.
But neither the one nor the other did not throw their equipment to replace it with someone else’s, which seemed stronger at a particular moment. They simply enriched their technique.
And, well, in the end a decent samurai, who won all in the world, opened his school. And other samurai came to him, someone won and left, someone lost and stayed. And so on to infinity. Masutatsu Oyama, in general, not finding enemies among people, began, for some reason, to kill bulls.
So, after reading this book, I first realized what I was doing. I, like a decent samurai, started from the school that was within walking distance - from PMBOK. Then he began to add other schools. True, I often made a mistake indecent for a decent samurai - I did not combine practice, but replaced one another, in search of a silver bullet. PMBOK doesn't fit - we throw it away, we take CORE PM, it doesn't work - we throw it again, we rush into scrum, and so on. Therefore, I changed tactics - I began to apply new practices as an experiment, to see what happens and leave the most successful solutions in a bottle.
Business programming is a set of simple methods and practices for business improvement. At least the whole, at least a certain part.
It so happened that business programming was developing in parallel with the bottle, and everything except the native IT department became the object of improvement.
But, at a certain point, understanding suddenly came. Well, I'm not quite right. I know how to improve any process, but I torment my own process with some foreign techniques.
In general, I applied business programming, and for the first time in my life I received a measurable increase in the efficiency of programmers, and immediately - twice. The changes concerned and process, and motivation, and goals, and control systems, and automation. In general, all five components with which business programming works. We built our work ourselves.
The result impressed me, the programmers, the management, and the specialists in motivation systems. But I, not being a decent samurai, threw all the results in the trash, because at the sale I bought a book about scrum.
There are two scrams in this world - the right one and the wrong one. The correct one is described in the book by Jeff Sutherland. Wrong - in the so-called. scrum guide, and in the authors listed all the same Jeff Sutherland.
Right scrum says: you can and should speed up the work 4 times. Wrong does not say anything, just gives some rules.
The correct scram honestly gives references to Japanese quality management methods, calling them one of the foundations of the scram philosophy. In particular, it recommends using the rules of a decent samurai - take scram as a basis, and create your own method. Wrong scrum says - do as we have written here. And if you do it differently, it is not a scrum.
In general, I took the book and did everything as it says. Blackboard, stickers, rallies, retrospectives, etc. The result met all expectations - we have accelerated by half, that is, we began to produce twice as much result per unit of time.
However, the scrum in its pure form had to be thrown out for one simple reason - the team of programmers dispersed to different offices, and the opportunity to use one board was lost. For some time, we suffered from the use of two boards, but there are still rallies, retrospectives that require personal participation. Therefore scrum abandoned.
But the best left in the bottle. What is the best in a scram? That's right, the task measurement system is planning poker. There is nothing more decent for assessing the tasks of programmers in our world.
The earlier system of normal hours is much worse, because either inflation or estimation deflation constantly occurs. Points are much more stable.
Of the remaining elements of the scram in the vial, there is, perhaps, only a sprint, as one of the planning options. Who has worked with 1C, then he knows that the sprint is the most usual volumetric scheduling, i.e. a certain amount of products that need to sell / buy / produce for a certain period.
So, thank you, scrum, for everything you taught us, but you dug your own grave yourself, with your scrum guide. We took only the best.
Then I had such experience as the implementation of the company's strategy. The experience is unique, for a programmer - one can say that I was very lucky. It was necessary to change the work of most divisions of the company, and, as you know, a variety of methods.
One of the problematic units was the supply. I still do not understand why there is so difficult - the simplest function. Then I still enjoyed scrum, and decided to use it for purchases.
But then he ran into methodological contradictions. Programmers are one thing - each task is unique there, and it’s worthy of being written on a sticker and hung on a board. And what suppliers have tasks? Buy one hundred sleeves? And tomorrow - again buy a hundred sleeves? And the day after tomorrow?
In short, the stickers - not that. And the combustion diagram is not that. Scrum is designed for project implementation, but what is a project? This is some kind of activity that will end someday. It must end, this is the meaning, this is the goal.
And here - purchases. Can purchases ever end? Well, only with the company. Then what is the purchase? Not a project, but a process. But the process is just a word for itself, because it also gives a certain completeness, and there is both a beginning and an end to it. And between them - a smoke break, the Internet and chat in the kitchen.
The answer was given by the Russian President when he spoke about his work as Prime Minister in 2008-2012. He said: being a prime minister is like standing under a waterfall of endless tasks, problems and goals. Work never ends. How many do not try, there will always be something to do.
What is a waterfall? This is a stream. So the idea of ​​threads appeared. Thank you, Vladimir Vladimirovich.
Since I strongly loved scrum at that time, I didn’t want to give up this name, and at first I called the work method “German Scrum” (because he was heavily involved in controlling, which the Germans like most), then “Kazakh scrum” (for fun), and, finally, “streaming scrum”.
The bottom line is simple. The tasks of the supplier always come from outside - from the needs of sales and production. The priority system for these tasks is very simple. And the essence of the work is even simpler - from the fence to lunch.
There was a need for sleeves - order sleeves. You need bolts - well, you know what to do. And so on, ad infinitum. Because the flow.
And controlling, which has long been firmly seated in a bottle, provided the correct metrics and individual indicators. It quickly became clear that the old, experienced suppliers, alas, work much worse than "girls" who simply take and do, and do not argue about "how it used to be."
The result was stunning in terms of quality and speed of achievement - in a month the consignment stock was filled to a level unattainable earlier, over the years of “normal” management.
Well, here, at some point, it dawned on me that there are no projects on the internal automation either, but there is a stream. The division of internal automation into projects is a convention that has come as a legacy of the big love of 1snikov for PMBOK. Projects are needed where there is money, time, budgets, formalities and bureaucracy. If all this is in the internal automation, then obviously it is necessary to do something.
In general, the flow and management of them firmly entered into the bottle. Looking ahead, I will say that the name Flowcon is derived from the flows control (flow control) phrase.
The theory of constraints of Goldratt systems is a principle that says that in any system there is a restriction, the slowest link, the speed of which determines the overall speed of the system. Well, a bunch of methods based on this principle developed, and by Goldratt himself, and his followers. For example, the technique of Velocity, described in the book "New Goal" - TOC and Lean are involved in it.
Of course, the main principle came from the TOC, the understanding of the presence of limitations, and the means of working with it. I do not consciously write “removal of restrictions”, since TOC involves not only eliminating, but also protecting the restrictions, and sometimes - creating them artificially.
It was TOC who made me look not only at the phase of the task, but also at the “body kit” - what happens before and after the work of the direct executor. It is no secret that often the task takes 15 minutes to complete, and taking into work, agreeing on, accepting the result, in total, takes several days. And all these few days the customer, or the initiator of the task, is waiting.
These bureaucratic stages, within the life cycle of a task, can be analyzed from different angles. TOC will say that these are limitations, because they take the most from the rate of generation of target units. The same boundary management will say that the problem is in the presence of excess boundaries, in this case between people involved in the reconciliation. A great deal of time is spent on overcoming these boundaries.
The points of view are different, and the result is the same - the problem is solved prohibitively long. And reconciliation is just one example. And the choice of the task by the programmer, when the “bulletin” is prohibitively long? Is this not a limitation? And the wrong choice of the performer, when tasks of the same type always get to the same performer, and a super-long queue is built up before him?
We got into the vial and specific methods from the TOC, for example - using a buffer to determine when the task is launched, if it has a deadline. But the main thing in TOC is, of course, the principle, not the methods. Goldratt himself wrote about this in the article "Standing on the shoulders of giants."
This is such a famous article Goldratt, in which he puts everything in its place, including - with his goldrattovskim words tells who are decent samurai. I will not retell the article, it is in the public domain on the Internet.
I will give only a key quote.
“There is a difference between the applied solutions (applications) and the fundamental concepts on which these solutions are based. Concepts are common, applied solutions are the adaptation of concepts to a specific environment. As we have already seen, such an adaptation is not simple and makes it necessary to develop certain elements of the solution. We have to remember - the application decision is based on the initial premises (sometimes hidden) about a specific environment. Do not expect that this application will work in an environment for which the initial premises are not correct. We can save a lot of effort and avoid disappointment if we carefully formulate these initial premises. ”
, , : , « » « — », . , , . , .
, . , , . , . , , - , .
, . , , , , , , , .
, , , *, *, ?
– , , . , , . - , . – 15 , – .
, . , .. , , – .
, , , , – 4 . , — .
, , . , , .
, , , . – , 4 .
, 1-2 . , , , ..
, GitHub. , , Issues.
. – , , – , . , – , API.
API . , , . , . (labels) – , . , – .
, GitHub. , . , (milestones), . , , , – . , API , .
, . - – . , – . API, , – ? , ?
. ? GitHub, ? ? , , . .
, , . , , – 4 , 6, 10. , , – .
, 1, , 1: . , , . , , , - .
, , 1 , . , 1: , – . 1: – , , .
At the conference he said, people liked it, many people became interested in the methodology. However, it turned out that very few people use 1C: Document management for task management - this was a surprise for me. They take some kind of online systems in which nothing can be set up properly, and there is no intelligible method inside, like the concept of effectiveness. Anyway.
The result is still positive. He, along with the use of tasks in GitHub, showed that the bottle itself can be embedded in other systems. So we got consulting, and several projects to speed up teams on their own systems.
– , , , . , . – , , « ».
, . , , , .
, . , – , - – . , , GitHub Flowcon.
. , , – , . , .
, , , , , , , , , , .. , – .
, – .
, – . , , , . – , , , .
, , , . ? , . .
– , .
– . , . . , , . , – , .
, . , 100 – , 300 – , – 4 . , . , .
, , – , . , , , .
. , – , .
, . , .
, – , . , , .
– , . – , , , , . , – . , , , , .
, . , . , , , .
, , . , -, - , – , , « ».
, , - , , .
– , . , .
– , , . , – , , . , , . , .
, , , . , -, , , , , , , , .
, , . . – , . , , .
, - , . – - , - , , .
, .
Many, having learned about the methodology and solutions based on it, ask questions - what and how, what is the essence, on the basis of what “world practices” have been done, what metrics are used, who suits them, where they come from. I answered each one individually, but I decided - everything, stop, I got tired of writing the same thing a hundred times. I'm a programmer, or what? Reuse can be not only for the code, but also for information. I will write once, I will try to answer all the questions in the article, and come what may.
Best of all, it seems to me, to state in the form of a story, because the birth of a bottle is closely related to my career, if I may say so. So do. Chased.
')
PMBOK
The first project and task management technique I learned was called PMBOK. It was the distant 2006.
At that time, PMBOK was almost a monopolist in project management. In resumes and vacancies only heard that PMBOK. There were no flexible methodologies on the air then, although somewhere they already existed.
PMBOK was then a purely cascade project management method, i.e. assumed a rigid structure of stages and tasks, terms and dependencies end-beginning. Accordingly, it quickly and beautifully crumbled into fragments in the then 1C implementation projects, due to the constant violation of the famous (then) Triangle Budget - Time - Content rule.
In those days, neither clients nor implementers could do sensible TK, write functional requirements, model the work of an enterprise. Yes, and configurations, such as UPP, constantly threw surprises - they evolved. As a result, the compiled list of works became irrelevant about a day after the start of the project.
But the brains of programmers are inquisitive, and they came up with some kind of combination of PMBOK and then unknown Agile (Agile). Let's call it "Yellow Edzhil." And I, too, had to become his apologist.
Yellow edgyl
Yellow Ajile was based on the stages created by the PMBOK, only fundamentally replacing the goal of each of them. What is the goal in PMBOK? Perform all tasks of the stage.
Yellow Edgele came up with another goal: to sign the act . For example, there is a stage - “Implementation of warehouse accounting”. At the stage of designing and drafting TK, certain works appear in it, such as “Material report”, “User training”, “Setting access rights”, etc. - depending on the depth of study at the stage of rapid survey.
This list of works served as a starting set to start somewhere. A programmer comes to the warehouse manager, or to storekeepers, or materialistic accountants, starts talking to them, and it turns out ... Well, there it turns out so much that the notebooks ended with terrible force.
At first, the brains spoiled by the PMBOK said: no! You can not do it this way! It is necessary to do only what is written in the TZ! And project managers entered into long-term negative negotiations with the client. Someone managed to persuade the customer for additional work, additional TZ, and so on. Most don't. The customer said: damn it guys, I don’t know in my heart what TK is, and what improvements in your program need to be done so that everything works for me, but if it does not work, I will not sign the act .
Reality basically won, and the project lived in two dimensions - a plan and a fact. The plan, it would seem, can be thrown out, but there is a snag - a budget has been drawn up for it, which protects the project manager on behalf of the customer in front of someone and cannot be touched. But the fact remained a fact - it is necessary to make a minimum of the maximum of what the customer wants in order to sign the act, otherwise there will be neither a payment, nor, accordingly, a salary.
So a model of Ejayl, even a yellow one, formed in my head. The vial began to form, and contained two task management practices. It seems that they contradict each other, but in life they got along well.
CORE PM
So, to the heap I will mention. Seeing problems with project management in myself and colleagues, I started picking theory outside the PMBOK, and found in the store a book with the straightforward title “Project Management”, written by the Tate couple. They called their method CORE PM.
The point is about the same as in the PMBOK. The main thing is the immutability of the plan. Straight separate large, complex and bureaucratic procedure invented how to make changes to the plan.
By that moment, having already learned the yellow Edgele, I could not add anything from this book to my bottle. And this is very good, because I realized again that there are no Smart Uncles in the world.
Smart Uncles
About the fact that there is no Smart Uncle in the world, I understood long ago, still at the institute, when I was practicing. At that time I was fascinated by statistical methods of product quality management, and went to the factory, where I spent a month, collecting data for a diploma.
At first, the goal was to collect the data that the teacher and I then wanted to use in specialized software (Statistica?). It seems that the idea was to build a mathematical model of conveyor production in order to understand the influence of different stages on the quality of the final product.
Before the trip, the lecturer put some books about Shewhart maps, statistical process control (SPC), general quality management (TQM) to me. He himself, apparently, did not read them - otherwise he would not suggest building a mate. production model. They were suitable, for example, for pressure sensors, where the construction of the model and the regression analysis of the Draper were the basis of calibration, but not for the automotive industry.
And I read books. It was all so simple that it took your breath away. And at the plant, too, were Smart Uncles, in the service of quality management. They knew the basic concepts from these books, but, to my great surprise, they never used not only quality improvement methods, but even the simplest formulas for assessing the current state of the technical process.
And the formulas were megaprosma. You take a hundred details, measure, enter numbers in Excel, consider the mean, standard deviation (that sigma), and derive a simple and understandable indicator - the fitness index, or the reproducibility index (if the process is stable). Actually, this indicator clearly said, everything is normal with the process, or not.
When I figured this figure, they were shocked. And from the fact that they finally saw this figure, and from how terrible it turned out to be. They asked me to count for a few more parts and machines - and what am I?
Then there was a lot of interesting things, including those that were possible through simple efforts, during my presence, to radically improve the quality of production. But that's not the point.
A key thought came to me then: Smart Uncles know a lot, but don't do a damn thing .
The methods are complete - both in quality management, and in task / project management, and in management in general. Ask any effective manager - you will read a whole lecture on how and what to do according to such and such methods. And ask briefly - does he do what is written in the methodology? FIG there.
The bottle is enriched with very useful knowledge. Everything should be done and checked by oneself; nobody can be trusted, especially to those who cannot show their results in practice.
Russian management model
Having understood that I will have to comprehend everything myself, I decided to read something else. I didn’t want to master a new method, but to understand something more fundamental. I came across the book "Russian Model Management" by Alexander Prokhorov.
To say that a book is brilliant means to say nothing. You have to read it, if you work in Russia. There, fortunately, there are no ready-made recipes, but all the root reasons for why we have everything as it is are elegantly painted.
For a long time I will not paint, I will name only some key thoughts that are important in the context of this material.
The first is that the work of the Russian people must be measured, and so that they do not turn out. Because we are so used to deceiving any system that we do it subconsciously. We do not accept rules, restrictions and laws. More precisely, we nod our head, agree, and we ourselves are already thinking how to deceive.
The second is that Russian people work best in the so-called. cluster cells, i.e. small teams not controlled too tightly. Open space is not for us. As you understand, the same principle is inherent in scrum.
Third, the Russian people do not do a damn thing the way they are told. This is a key idea in the implementation of any technique. You give instructions on how to act, let people go and wait for the result, but it is not. Because people throw out your instructions, and do as they used to.
The bottle after this book is incredibly enriched. True, the methods of solving these "Russian" problems had to be found independently. I found controlling.
Controlling
Controlling is a digit-based control. One of my favorite techniques. I emphasize the main point: controlling is not control. This is management.
If there are no numbers, control is carried out blindly, on the basis of indirect information. When working with tasks, this is especially true, because the measurement system of tasks, as a rule, is no good. Usually, these are labor costs in hours, deadline (and getting into it) and, in fact, pieces of solved problems. To effectively manage on the basis of this data is impossible.
Most of the benefit to the bottle came from that part of the controlling, which formulates the requirements for information, i.e. to numbers, methods for their production, reproducibility, quality, depth of study, etc.
The figure should be of high quality, but such are rare. I have already written several articles about this, I will not repeat. Just take a word - quality, according to the criteria of controlling, you will not often see numbers. Probably because no one has read a Wikipedia article about controlling.
So, in the vial appeared controlling. It is universal, and henceforth governed the formation of any numbers that were required by any method.
Boundary management
Boundary management, or border management, is a little-known science about the transformation of business systems. Although maybe something has already changed - I studied it several years ago, I don’t remember the last name about the articles about the works of Eric Trista and someone else. Now the Internet says that there is some English-language book on this topic - I can not say anything, I have not read it.
The essence is insanely simple: boundaries . Inside the business systems, processes, even in one person - a lot of boundaries. Physical, emotional, energy, etc.
Borders are bad and good, useful and harmful. Some interfere with the normal course of the process, others divide the mixed stream into two parts, helping to process it faster. Some isolate a person from the necessary information, making it difficult to respond in time, while others protect him from unnecessary information, allowing him not to be distracted.
In short, the boundaries and management of them - is megakruto. To understand this, you have to try. Sensible people, like you, enough to understand the key principle, to begin to apply it. The rest need case studies and concrete practices, and there are, in fact, many such. Only they are not on the Internet, but it is necessary to invent themselves.
I came up with a few, from published - Iceberg and the method of swimming lanes .
Boundary management had a very strong influence on the bottle, and almost all of its parts - on the management of the life cycle of the task, on the organization of priorities, on the regular management.
Hell do it yourself
He called this section the same as the publication of the same name. This was the first experience in building a system for managing orders, memos, plans and projects based on accumulated knowledge.
The experience is rather successful, although the article sounds more negative. When constructing the system, the principles of controlling, boundary management and iceberg (from business programming) were mainly used. Of course, it turned out to be too technocratic, but the experience, in its usefulness, was enormous.
First, it was a system for the entire company, and not for a small team of programmers. Secondly, the system has reached its goal - it has increased executive discipline to previously unprecedented heights.
But the main thing for me is the practical use of parts of the bottle on a large scale, and not on programmers, but on ordinary people. Something, according to the results, had to be thrown out of the methodology, but some methods proved to be effective. For the most part, of course, controlling.
System thinking
I am not talking about myself, but about a field of knowledge called systemic thinking. It is full of books and cases, so I will not retell. I will note only one very important principle that strongly influenced the bottle - emergent, or emerging properties. These are any properties of the system that can only be seen in the on state.
While you are sitting away from the system, and fantasizing about how it works, you do not see the emergent properties. You can design, draw, program, test, even in humans, but when you start the system in real work, emergent properties will begin to work.
For example, you assumed that one person sets a task, and another takes it up. Oh well. The second person may simply not see the task. And if he sees, he will not read. And if he reads, he will say that he has not read. Or did not understand. Or it is not his job. Etc.
Or you thought that the team coordinator - the head. Provided for him AWS, with a list of incoming tasks, which he will distribute to the performers. You start the system, and you find that it doesn't distribute the devil, but only runs around the meetings and corporate parties. And the tasks are distributed by a quiet, homely-looking guy sitting in the corner - the hidden leader. And he, offended that he was not noticed, will also begin to sabotage the implementation of your system.
These are the emergent properties. They are not visible when speculative design, they appear when you start the system to work.
It is clear that “emergent properties” are just such an abstraction that someone invented to call a phenomenon that everyone understands — you need to start the system, and always come up with something else, from architectural design errors to banal bugs.
But in the case of task management, we always deal with a complex system consisting of automation, management, people with their relationships, and team goals, customers, managers, etc. The success of task management depends on all components, albeit to varying degrees, and none of them can be ignored.
And if you, for example, are a programmer automating task management, you can not just, but you will ignore a lot. It's easier. Therefore, the system may and will not work. There will be no bugs, but there will be no sense to it either.
And I wanted to work. Therefore, I added system thinking to the vial, both as one of the fundamental principles and as concrete accents and practices.
Samurai Code and the Book of the Five Rings
It sounds strange, but these very books made a bottle with a bottle. Now briefly explain.
A decent samurai in life did this. First went to learn martial arts to some master. He studied until he exceeded him. And here we have a decent samurai who owns the technique of a certain school (by analogy - PMBOK).
He left school and went to shuffle through ancient Japan, in search of a new challenge. I went to different schools, called the local master to a duel, and made a decision based on the results. If the master turned out to be weaker than a samurai - well, not destiny. If the samurai lost, then he fell on his knees and asked to take him as an apprentice. And he studied until he surpassed the master again.
This went on several times. And at some certain point, the samurai was born his own style.
In general, he was not born at all, this is normal. Some remained “without a face”, being only masters of several well-known schools (this is the type of MBA).
And some thought out the style even before receipt in the first school. For example, one of the national heroes of Japan, Miyamoto Musashi, the inventor of the style of two swords and the author of the Book of Five Rings. Or Masutatsu Oyama, a Korean by nationality, the creator of the Kyokushinkai karate school. Both of them invented their method somewhere at the beginning of their career, and then they perfected it. And he and the other on their way met more powerful masters, and remained to learn from them.
But neither the one nor the other did not throw their equipment to replace it with someone else’s, which seemed stronger at a particular moment. They simply enriched their technique.
And, well, in the end a decent samurai, who won all in the world, opened his school. And other samurai came to him, someone won and left, someone lost and stayed. And so on to infinity. Masutatsu Oyama, in general, not finding enemies among people, began, for some reason, to kill bulls.
So, after reading this book, I first realized what I was doing. I, like a decent samurai, started from the school that was within walking distance - from PMBOK. Then he began to add other schools. True, I often made a mistake indecent for a decent samurai - I did not combine practice, but replaced one another, in search of a silver bullet. PMBOK doesn't fit - we throw it away, we take CORE PM, it doesn't work - we throw it again, we rush into scrum, and so on. Therefore, I changed tactics - I began to apply new practices as an experiment, to see what happens and leave the most successful solutions in a bottle.
Business programming
Business programming is a set of simple methods and practices for business improvement. At least the whole, at least a certain part.
It so happened that business programming was developing in parallel with the bottle, and everything except the native IT department became the object of improvement.
But, at a certain point, understanding suddenly came. Well, I'm not quite right. I know how to improve any process, but I torment my own process with some foreign techniques.
In general, I applied business programming, and for the first time in my life I received a measurable increase in the efficiency of programmers, and immediately - twice. The changes concerned and process, and motivation, and goals, and control systems, and automation. In general, all five components with which business programming works. We built our work ourselves.
The result impressed me, the programmers, the management, and the specialists in motivation systems. But I, not being a decent samurai, threw all the results in the trash, because at the sale I bought a book about scrum.
Scrum
There are two scrams in this world - the right one and the wrong one. The correct one is described in the book by Jeff Sutherland. Wrong - in the so-called. scrum guide, and in the authors listed all the same Jeff Sutherland.
Right scrum says: you can and should speed up the work 4 times. Wrong does not say anything, just gives some rules.
The correct scram honestly gives references to Japanese quality management methods, calling them one of the foundations of the scram philosophy. In particular, it recommends using the rules of a decent samurai - take scram as a basis, and create your own method. Wrong scrum says - do as we have written here. And if you do it differently, it is not a scrum.
In general, I took the book and did everything as it says. Blackboard, stickers, rallies, retrospectives, etc. The result met all expectations - we have accelerated by half, that is, we began to produce twice as much result per unit of time.
However, the scrum in its pure form had to be thrown out for one simple reason - the team of programmers dispersed to different offices, and the opportunity to use one board was lost. For some time, we suffered from the use of two boards, but there are still rallies, retrospectives that require personal participation. Therefore scrum abandoned.
But the best left in the bottle. What is the best in a scram? That's right, the task measurement system is planning poker. There is nothing more decent for assessing the tasks of programmers in our world.
The earlier system of normal hours is much worse, because either inflation or estimation deflation constantly occurs. Points are much more stable.
Of the remaining elements of the scram in the vial, there is, perhaps, only a sprint, as one of the planning options. Who has worked with 1C, then he knows that the sprint is the most usual volumetric scheduling, i.e. a certain amount of products that need to sell / buy / produce for a certain period.
So, thank you, scrum, for everything you taught us, but you dug your own grave yourself, with your scrum guide. We took only the best.
Stream scrub
Then I had such experience as the implementation of the company's strategy. The experience is unique, for a programmer - one can say that I was very lucky. It was necessary to change the work of most divisions of the company, and, as you know, a variety of methods.
One of the problematic units was the supply. I still do not understand why there is so difficult - the simplest function. Then I still enjoyed scrum, and decided to use it for purchases.
But then he ran into methodological contradictions. Programmers are one thing - each task is unique there, and it’s worthy of being written on a sticker and hung on a board. And what suppliers have tasks? Buy one hundred sleeves? And tomorrow - again buy a hundred sleeves? And the day after tomorrow?
In short, the stickers - not that. And the combustion diagram is not that. Scrum is designed for project implementation, but what is a project? This is some kind of activity that will end someday. It must end, this is the meaning, this is the goal.
And here - purchases. Can purchases ever end? Well, only with the company. Then what is the purchase? Not a project, but a process. But the process is just a word for itself, because it also gives a certain completeness, and there is both a beginning and an end to it. And between them - a smoke break, the Internet and chat in the kitchen.
The answer was given by the Russian President when he spoke about his work as Prime Minister in 2008-2012. He said: being a prime minister is like standing under a waterfall of endless tasks, problems and goals. Work never ends. How many do not try, there will always be something to do.
What is a waterfall? This is a stream. So the idea of ​​threads appeared. Thank you, Vladimir Vladimirovich.
Since I strongly loved scrum at that time, I didn’t want to give up this name, and at first I called the work method “German Scrum” (because he was heavily involved in controlling, which the Germans like most), then “Kazakh scrum” (for fun), and, finally, “streaming scrum”.
The bottom line is simple. The tasks of the supplier always come from outside - from the needs of sales and production. The priority system for these tasks is very simple. And the essence of the work is even simpler - from the fence to lunch.
There was a need for sleeves - order sleeves. You need bolts - well, you know what to do. And so on, ad infinitum. Because the flow.
And controlling, which has long been firmly seated in a bottle, provided the correct metrics and individual indicators. It quickly became clear that the old, experienced suppliers, alas, work much worse than "girls" who simply take and do, and do not argue about "how it used to be."
The result was stunning in terms of quality and speed of achievement - in a month the consignment stock was filled to a level unattainable earlier, over the years of “normal” management.
Well, here, at some point, it dawned on me that there are no projects on the internal automation either, but there is a stream. The division of internal automation into projects is a convention that has come as a legacy of the big love of 1snikov for PMBOK. Projects are needed where there is money, time, budgets, formalities and bureaucracy. If all this is in the internal automation, then obviously it is necessary to do something.
In general, the flow and management of them firmly entered into the bottle. Looking ahead, I will say that the name Flowcon is derived from the flows control (flow control) phrase.
System Restriction Theory (TOC)
The theory of constraints of Goldratt systems is a principle that says that in any system there is a restriction, the slowest link, the speed of which determines the overall speed of the system. Well, a bunch of methods based on this principle developed, and by Goldratt himself, and his followers. For example, the technique of Velocity, described in the book "New Goal" - TOC and Lean are involved in it.
Of course, the main principle came from the TOC, the understanding of the presence of limitations, and the means of working with it. I do not consciously write “removal of restrictions”, since TOC involves not only eliminating, but also protecting the restrictions, and sometimes - creating them artificially.
It was TOC who made me look not only at the phase of the task, but also at the “body kit” - what happens before and after the work of the direct executor. It is no secret that often the task takes 15 minutes to complete, and taking into work, agreeing on, accepting the result, in total, takes several days. And all these few days the customer, or the initiator of the task, is waiting.
These bureaucratic stages, within the life cycle of a task, can be analyzed from different angles. TOC will say that these are limitations, because they take the most from the rate of generation of target units. The same boundary management will say that the problem is in the presence of excess boundaries, in this case between people involved in the reconciliation. A great deal of time is spent on overcoming these boundaries.
The points of view are different, and the result is the same - the problem is solved prohibitively long. And reconciliation is just one example. And the choice of the task by the programmer, when the “bulletin” is prohibitively long? Is this not a limitation? And the wrong choice of the performer, when tasks of the same type always get to the same performer, and a super-long queue is built up before him?
We got into the vial and specific methods from the TOC, for example - using a buffer to determine when the task is launched, if it has a deadline. But the main thing in TOC is, of course, the principle, not the methods. Goldratt himself wrote about this in the article "Standing on the shoulders of giants."
Standing on the shoulders of giants
This is such a famous article Goldratt, in which he puts everything in its place, including - with his goldrattovskim words tells who are decent samurai. I will not retell the article, it is in the public domain on the Internet.
I will give only a key quote.
“There is a difference between the applied solutions (applications) and the fundamental concepts on which these solutions are based. Concepts are common, applied solutions are the adaptation of concepts to a specific environment. As we have already seen, such an adaptation is not simple and makes it necessary to develop certain elements of the solution. We have to remember - the application decision is based on the initial premises (sometimes hidden) about a specific environment. Do not expect that this application will work in an environment for which the initial premises are not correct. We can save a lot of effort and avoid disappointment if we carefully formulate these initial premises. ”
, , : , « » « — », . , , . , .
, . , , . , . , , - , .
, . , , , , , , , .
, , , *, *, ?
– , , . , , . - , . – 15 , – .
, . , .. , , – .
, , , , – 4 . , — .
, , . , , .
, , , . – , 4 .
, 1-2 . , , , ..
, GitHub. , , Issues.
. – , , – , . , – , API.
API . , , . , . (labels) – , . , – .
, GitHub. , . , (milestones), . , , , – . , API , .
, . - – . , – . API, , – ? , ?
. ? GitHub, ? ? , , . .
, , . , , – 4 , 6, 10. , , – .
, 1, , 1: . , , . , , , - .
, , 1 , . , 1: , – . 1: – , , .
At the conference he said, people liked it, many people became interested in the methodology. However, it turned out that very few people use 1C: Document management for task management - this was a surprise for me. They take some kind of online systems in which nothing can be set up properly, and there is no intelligible method inside, like the concept of effectiveness. Anyway.
The result is still positive. He, along with the use of tasks in GitHub, showed that the bottle itself can be embedded in other systems. So we got consulting, and several projects to speed up teams on their own systems.
Own system
– , , , . , . – , , « ».
, . , , , .
, . , – , - – . , , GitHub Flowcon.
. , , – , . , .
, , , , , , , , , , .. , – .
, – .
, – . , , , . – , , , .
, , , . ? , . .
– , .
– . , . . , , . , – , .
, . , 100 – , 300 – , – 4 . , . , .
, , – , . , , , .
. , – , .
, . , .
, – , . , , .
– , . – , , , , . , – . , , , , .
?
, . , . , , , .
, , . , -, - , – , , « ».
, , - , , .
What is the result?
– , . , .
– , , . , – , , . , , . , .
, , , . , -, , , , , , , , .
, , . . – , . , , .
, - , . – - , - , , .
, .
Source: https://habr.com/ru/post/434456/
All Articles