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. They drove.
The first project and task management technique I learned was called PMBOK. It was a distant 2006 year.
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 at that time, although somewhere they already existed.
PMBOK was a purely cascade project management method, i.e. assumed a rigid structure of stages and tasks, terms and dependencies end-beginning. Accordingly, he 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 combination of PMBOK and then unknown to anyone 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 so much it turns out 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 to do additional work, add 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 will work 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. And 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 my own and colleagues, I started picking theory outside the PMBOK, and found in the store a book with the straightforward name “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 couldn’t 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 a long time ago, still at the institute, when I was practicing. I was then 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. Everything was so simple that it took your breath away. And at the factory, 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, one should not believe anyone, especially those who cannot show their results in practice.
Realizing that I had 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 must 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, we 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 thing: 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 information requirements, 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 it. Just take the 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 business system transformations. Although maybe something has already changed - I studied it several years ago, I don’t remember my last name under 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, are 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.
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 colossal.
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.
This is not 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 into 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 is it 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 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, for example, you are a programmer automating task management, you will not only be able to, 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.
Generally, 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 careers, 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 didn’t even find any opponents among people, he began to kill bulls for some reason.
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 does not fit - we throw it away, we take CORE PM, it does not 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, 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 else 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 torture 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 the process, the motivation, the goal, the control system, and automation. In general, all five components with which business programming works. We built our work ourselves.
The result impressed me, programmers, management, and 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 right scrum 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 scrum? 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 was, 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 understand, by various methods.
One of the problematic units was the supply. I still do not understand what is so difficult there - 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 is worthy of being written on a sticker and hung on a board. And what suppliers have tasks? Buy a hundred sleeves? And tomorrow - again to 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 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 the 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 love 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, "as it used to be."
The result was stunning in terms of quality and speed of achievement - within 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).
The theory of constraints of Goldratt systems is a principle that says that in any system there is a limitation, 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 consciously do not write “removing restrictions”, since TOC involves not only the elimination, but also the protection of restrictions, and sometimes - their artificial creation.
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 execution of a task takes 15 minutes, and acceptance into work, coordination, acceptance of 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 the 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 the buffer to determine when the task is started up, if it has a deadline. But the main thing in TOC, of course, is 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. ”
If in your own words, Goldratt says the same thing as samurai and systems thinking: do not fantasize, do not shout "Scram forever" or "TOC - garbage", because you will always be wrong. Take and try, and do not forget that no method in its pure form will suit you. You still have to watch, think and adjust.
Introducing the bottle in different teams, I watched a lot. It turned out that it is not only simple and interesting, but also useful. So the bottle was enriched with a bunch of methods, practices and life hacks of my own invention. I honestly understand that I have not invented anything new, and surely such methods are described in some books, but there is not enough life to read all the books.
For example, a lot has been written about the pernicious choice of the task. And if the task is chosen, but it is necessary to decide how to implement it, the programmer, for example, can spend a whole lot of time until the time is right, and he will not take the first available option.
As Maxim Dorofeev, the author of the Jedi techniques, wrote in a funny picture, what is the point of waiting for the deadline to be done through * an op if you can immediately do it through an op, but there will be time to fix it?
I have repeatedly seen, both in myself and in others, that the choice of a solution to a problem can take days. Moreover, the options may be completely identical in performance, optimality and user convenience. But something does not give way to decide, and that's it. Work - for 15 minutes, and thinking - like building a rocket.
There are many such examples, and they all influenced the bottle. And they continue to influence, because once I realized that my own observations are no worse than books, I can no longer stop - after all, there is no limit to perfection.
Once, having collected all my knowledge in a heap, I made a new version of the task management system, began to apply all the knowledge of the bottle, and got an unexpected result - the productivity of the programmers team increased 4 times. Probably, only the lazy have not yet watched the video of my reports on this topic - once and twice .
Actually, this experience and pushed me to the distribution of the bottle, as a technique. I began to systematize information and methods, write articles about the bottle and its methods, talk about my practice.
After that experience, I moved to a purely software company, and, naturally, continued the practice of using the bottle. But I ran into an interesting challenge - I didn’t have a task management system with me, in which I received acceleration 4 times.
At first I sat down and made a certain simplified analogue, in 1-2 days. When you know the technique, this is not a problem, especially if you don’t have to poke around with convenience, interface, etc.
But it was not long to work with this system, because our company communicated with clients through GitHub. If you know, there is also some kind of task management called Issues.
The challenge has become even more interesting. It is one thing to create the system yourself, from scratch, and quite another to adapt the existing one so that it meets the requirements of the methodology. Given that nothing can be changed in it - only a standard interface and an API are available.
Here I began with API. It is not to say that it is straight smart, but it gives enough data. The first problem was the impossibility of specifying the assessment of the task, as a number. It was necessary to get out through labels (labels) - they are of string type, but can be turned into a number by an external script. I wrote this script and used it for several months - he drew a graph of efficiency.
But there are problems that I could not solve in GitHub. For example, prioritization. There are tags, there are milestones (milestones), there are projects. Theoretically, with their help, it is possible to designate which task is more important, but it is extremely inconvenient to use this information - you cannot sort them by tags. I would have to do another script that, through the API, pulls out the tasks, sorts and displays the correct list.
In general, the branch was a dead end. I rummaged through other online task management systems - similar problems. Everywhere there is the possibility of data entry and storage, but very few configuration tools — namely, tuning transforms data into a control system. Everywhere there is an API, and through it you can build your system, but then the question is - why their system? Just as a data source?
This dilemma has been in my mind for several months. To do or not? To adapt a technique to GitHub, having made the nalepka? Or to another system? In its pure form, neither is suitable, but neither can be adapted, in a reasonable time. Yes, and use external scripts fed up already.
But, despite the dilemma, the experience was successful. The bottle worked quite well for itself, even though it was on the system that was standing up to it, and it accelerated the work - first 4 times, then at 6, it reached 10. It is clear that the coefficient depends on the reference point, but I stopped worrying about this topic a long time ago - I The bottle has already proved everything.
Then I remembered that there is 1C in the world, and such a wonderful product as 1C: Document circulation. If anyone does not know, this is a program in which you can customize any processes. Accordingly, it does not contain any method in itself, only a technique, and someone has to say a technique to it.
Here, just, the people gathered for the next 1Cnu conference, and I decided to participate there. I took a typical, empty 1C: Document flow, and began to customize my method in it - a bottle. Honor and praise 1C: Document management - it took several hours to set up, and it turned out to be quite a decent task management system, highly relevant to the bottle.
At the conference he said, people liked it, many were 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 is quite possible to be embedded in other systems. So we got consulting, and several projects to speed up teams on their own systems.
Consulting is, of course, fun, but long and expensive. Most people are not too sorry to throw out their old task management system, which is of little use. Well, they want two people in one - and the methodology, and the program, in which "everything is according to the method."
Therefore, we sat down to write our task management program, clearly sharpened under the bottle. There are few settings, because settings can be used to expel a bottle from the program, and this will be another task management system, more like a notebook.
Interestingly, the development of the program immediately began to give feedback to the methodology. Some things had to be thrown out of the bottle, some - add something - change. We ourselves, of course, quickly moved from GitHub to Flowcon.
I have never run a company before. Actually, I still do not say that I am in charge - there are two of us here, and the rights with duties are divided roughly in half. But you have to deal with all the issues of the life of the company, not just the development or implementation.
We have software development, services, refinement of old products, implementation of new customers, net sales without services, support for old customers, marketing, negotiations, exhibitions with seminars, domestic issues such as money, etc. In short, we are a company in miniature.
This state of affairs forced to reconsider the bottle, to introduce into it two new entities - flows and balance.
Every activity that I have to do is a stream. For example, I need to program new products, solve customer problems on implementations, and write articles. I am a keen person, like any programmer, so it’s not so difficult for me, but very reluctant to switch between these threads.
I would like to sit down, for example, for the development of a new product, and not get out a week. What happens? There will be no money, because the devil knows when the new product will be sold. It is necessary to switch to work with clients.
You get carried away with work with clients - there will also be a collapse, because building a business on some services is rather risky.
Well, writing articles to get carried away - generally spit. But then there will be no food or money. Therefore you have to restrain yourself. At first he did it on a whim, quite often mistaken, was fond of and received failures. And then I realized that these were flows, and everything fell into place.
There are flows that can be measured and planned. For example, 100 hours per month - for services, 300 points - for the development of new products, and in between - 4 articles. Each flow has its own unit and method of measurement, and its own purpose. And the bottle should balance these flows, providing uniform development of the company.
Of course, there are not three streams, but more - both here and there. And it is necessary to balance everyone who wants sustainable development, built on strategy, and not on the current context and extinguishing fires.
So the bottle turned from a task management technique into a company management technique. Well, it hasn't become straight - this process is still underway, but the results are impressive.
Previously, I did not have to deal with the development of mass-use software products, boxed or services. Therefore, the bottle did not contain methods that are specific to these types of activities.
Gaps were discovered when we had a problem - we work a lot and quickly, and the products do not enter the market. As they say in jokes about scrum, it remains to understand what kind of crap we do with such speed.
I had to adjust the vial - to introduce the concept of releases, and to rebuild the system of prioritization with their account. After all, a release is not a project, and not a task, but a kind of container of other tasks that need to be done in order for the release to take place. And the release, especially the first one, is entering the market. Until it happens, no one will see the product and, accordingly, there will be no feedback or money.
I feel it's time to wrap up. If you have read this far, then a big respect for you. About many things I have not written, but the main thing, like, is reflected in this material.
There are a lot of techniques and practices that have influenced the bottle, but I will not list them. Maybe someday, I will do something like a glossary, or a list of references - for those who strongly respect all scientific approaches, citation indices and "reliance on world-famous methods."
Yes, dear authors of the methods, from which I took something useful for the bottle, but did not mention in this article, I offer my sincere apologies.
As a result, we have a bottle - an explosive mixture of best management practices that improves efficiency. And there is exactly to increase efficiency.
What is important for me personally is the mixture, the set, and not the sequence. You can apply all the methods, you can - only one, or half, of your choice. Any method, in itself, gives an increase in efficiency. One more, the other less.
As mentioned in the article, over the years of practice I have tried parts of a bottle in different enterprises and, more importantly, in completely different types of human activity. There were programmers, design engineers, quality services, supplies, sales, manufacturing, accountants, economists, managers, and the devil knows who else.
It is clear that each profession needs its own set of bottle methods, and its own automation. But you can choose the right kit for everyone. But the most important thing is that the bottle develops, and at an accelerated pace. Because it went beyond the limits of my practice, and quickly became enriched with feedback from other people, companies and professions.
There are even people who have taken one or two ideas from published materials and put them into practice. What is particularly interesting is that they don’t write to me about this, but if they accidentally cross somewhere on a forum or conference, they honestly tell about their experience and don’t hesitate to say that they took the ideas from a bottle.
So, everything will be fine.
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. They drove.
PMBOK
The first project and task management technique I learned was called PMBOK. It was a distant 2006 year.
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 at that time, although somewhere they already existed.
PMBOK was a purely cascade project management method, i.e. assumed a rigid structure of stages and tasks, terms and dependencies end-beginning. Accordingly, he 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 combination of PMBOK and then unknown to anyone 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 so much it turns out 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 to do additional work, add 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 will work 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. And 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 my own and colleagues, I started picking theory outside the PMBOK, and found in the store a book with the straightforward name “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 couldn’t 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 a long time ago, still at the institute, when I was practicing. I was then 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. Everything was so simple that it took your breath away. And at the factory, 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, one should not believe anyone, especially those who cannot show their results in practice.
Russian management model
Realizing that I had 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 must 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, we 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 thing: 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 information requirements, 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 it. Just take the 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 business system transformations. Although maybe something has already changed - I studied it several years ago, I don’t remember my last name under 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, are 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
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 colossal.
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
This is not 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 into 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 is it 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 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, for example, you are a programmer automating task management, you will not only be able to, 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.
Generally, 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 careers, 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 didn’t even find any opponents among people, he began to kill bulls for some reason.
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 does not fit - we throw it away, we take CORE PM, it does not 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, 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 else 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 torture 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 the process, the motivation, the goal, the control system, and automation. In general, all five components with which business programming works. We built our work ourselves.
The result impressed me, programmers, management, and 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 right scrum 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 scrum? 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 was, 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 understand, by various methods.
One of the problematic units was the supply. I still do not understand what is so difficult there - 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 is worthy of being written on a sticker and hung on a board. And what suppliers have tasks? Buy a hundred sleeves? And tomorrow - again to 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 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 the 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 love 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, "as it used to be."
The result was stunning in terms of quality and speed of achievement - within 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).
System Restriction Theory (TOC)
The theory of constraints of Goldratt systems is a principle that says that in any system there is a limitation, 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 consciously do not write “removing restrictions”, since TOC involves not only the elimination, but also the protection of restrictions, and sometimes - their artificial creation.
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 execution of a task takes 15 minutes, and acceptance into work, coordination, acceptance of 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 the 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 the buffer to determine when the task is started up, if it has a deadline. But the main thing in TOC, of course, is 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. ”
If in your own words, Goldratt says the same thing as samurai and systems thinking: do not fantasize, do not shout "Scram forever" or "TOC - garbage", because you will always be wrong. Take and try, and do not forget that no method in its pure form will suit you. You still have to watch, think and adjust.
Observations
Introducing the bottle in different teams, I watched a lot. It turned out that it is not only simple and interesting, but also useful. So the bottle was enriched with a bunch of methods, practices and life hacks of my own invention. I honestly understand that I have not invented anything new, and surely such methods are described in some books, but there is not enough life to read all the books.
For example, a lot has been written about the pernicious choice of the task. And if the task is chosen, but it is necessary to decide how to implement it, the programmer, for example, can spend a whole lot of time until the time is right, and he will not take the first available option.
As Maxim Dorofeev, the author of the Jedi techniques, wrote in a funny picture, what is the point of waiting for the deadline to be done through * an op if you can immediately do it through an op, but there will be time to fix it?
I have repeatedly seen, both in myself and in others, that the choice of a solution to a problem can take days. Moreover, the options may be completely identical in performance, optimality and user convenience. But something does not give way to decide, and that's it. Work - for 15 minutes, and thinking - like building a rocket.
There are many such examples, and they all influenced the bottle. And they continue to influence, because once I realized that my own observations are no worse than books, I can no longer stop - after all, there is no limit to perfection.
Merciless automation
Once, having collected all my knowledge in a heap, I made a new version of the task management system, began to apply all the knowledge of the bottle, and got an unexpected result - the productivity of the programmers team increased 4 times. Probably, only the lazy have not yet watched the video of my reports on this topic - once and twice .
Actually, this experience and pushed me to the distribution of the bottle, as a technique. I began to systematize information and methods, write articles about the bottle and its methods, talk about my practice.
Arrangement for a new system
After that experience, I moved to a purely software company, and, naturally, continued the practice of using the bottle. But I ran into an interesting challenge - I didn’t have a task management system with me, in which I received acceleration 4 times.
At first I sat down and made a certain simplified analogue, in 1-2 days. When you know the technique, this is not a problem, especially if you don’t have to poke around with convenience, interface, etc.
But it was not long to work with this system, because our company communicated with clients through GitHub. If you know, there is also some kind of task management called Issues.
The challenge has become even more interesting. It is one thing to create the system yourself, from scratch, and quite another to adapt the existing one so that it meets the requirements of the methodology. Given that nothing can be changed in it - only a standard interface and an API are available.
Here I began with API. It is not to say that it is straight smart, but it gives enough data. The first problem was the impossibility of specifying the assessment of the task, as a number. It was necessary to get out through labels (labels) - they are of string type, but can be turned into a number by an external script. I wrote this script and used it for several months - he drew a graph of efficiency.
But there are problems that I could not solve in GitHub. For example, prioritization. There are tags, there are milestones (milestones), there are projects. Theoretically, with their help, it is possible to designate which task is more important, but it is extremely inconvenient to use this information - you cannot sort them by tags. I would have to do another script that, through the API, pulls out the tasks, sorts and displays the correct list.
In general, the branch was a dead end. I rummaged through other online task management systems - similar problems. Everywhere there is the possibility of data entry and storage, but very few configuration tools — namely, tuning transforms data into a control system. Everywhere there is an API, and through it you can build your system, but then the question is - why their system? Just as a data source?
This dilemma has been in my mind for several months. To do or not? To adapt a technique to GitHub, having made the nalepka? Or to another system? In its pure form, neither is suitable, but neither can be adapted, in a reasonable time. Yes, and use external scripts fed up already.
But, despite the dilemma, the experience was successful. The bottle worked quite well for itself, even though it was on the system that was standing up to it, and it accelerated the work - first 4 times, then at 6, it reached 10. It is clear that the coefficient depends on the reference point, but I stopped worrying about this topic a long time ago - I The bottle has already proved everything.
Arranging for another new system
Then I remembered that there is 1C in the world, and such a wonderful product as 1C: Document circulation. If anyone does not know, this is a program in which you can customize any processes. Accordingly, it does not contain any method in itself, only a technique, and someone has to say a technique to it.
Here, just, the people gathered for the next 1Cnu conference, and I decided to participate there. I took a typical, empty 1C: Document flow, and began to customize my method in it - a bottle. Honor and praise 1C: Document management - it took several hours to set up, and it turned out to be quite a decent task management system, highly relevant to the bottle.
At the conference he said, people liked it, many were 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 is quite possible to be embedded in other systems. So we got consulting, and several projects to speed up teams on their own systems.
Own system
Consulting is, of course, fun, but long and expensive. Most people are not too sorry to throw out their old task management system, which is of little use. Well, they want two people in one - and the methodology, and the program, in which "everything is according to the method."
Therefore, we sat down to write our task management program, clearly sharpened under the bottle. There are few settings, because settings can be used to expel a bottle from the program, and this will be another task management system, more like a notebook.
Interestingly, the development of the program immediately began to give feedback to the methodology. Some things had to be thrown out of the bottle, some - add something - change. We ourselves, of course, quickly moved from GitHub to Flowcon.
And again flows
I have never run a company before. Actually, I still do not say that I am in charge - there are two of us here, and the rights with duties are divided roughly in half. But you have to deal with all the issues of the life of the company, not just the development or implementation.
We have software development, services, refinement of old products, implementation of new customers, net sales without services, support for old customers, marketing, negotiations, exhibitions with seminars, domestic issues such as money, etc. In short, we are a company in miniature.
This state of affairs forced to reconsider the bottle, to introduce into it two new entities - flows and balance.
Every activity that I have to do is a stream. For example, I need to program new products, solve customer problems on implementations, and write articles. I am a keen person, like any programmer, so it’s not so difficult for me, but very reluctant to switch between these threads.
I would like to sit down, for example, for the development of a new product, and not get out a week. What happens? There will be no money, because the devil knows when the new product will be sold. It is necessary to switch to work with clients.
You get carried away with work with clients - there will also be a collapse, because building a business on some services is rather risky.
Well, writing articles to get carried away - generally spit. But then there will be no food or money. Therefore you have to restrain yourself. At first he did it on a whim, quite often mistaken, was fond of and received failures. And then I realized that these were flows, and everything fell into place.
There are flows that can be measured and planned. For example, 100 hours per month - for services, 300 points - for the development of new products, and in between - 4 articles. Each flow has its own unit and method of measurement, and its own purpose. And the bottle should balance these flows, providing uniform development of the company.
Of course, there are not three streams, but more - both here and there. And it is necessary to balance everyone who wants sustainable development, built on strategy, and not on the current context and extinguishing fires.
So the bottle turned from a task management technique into a company management technique. Well, it hasn't become straight - this process is still underway, but the results are impressive.
Development Management
Previously, I did not have to deal with the development of mass-use software products, boxed or services. Therefore, the bottle did not contain methods that are specific to these types of activities.
Gaps were discovered when we had a problem - we work a lot and quickly, and the products do not enter the market. As they say in jokes about scrum, it remains to understand what kind of crap we do with such speed.
I had to adjust the vial - to introduce the concept of releases, and to rebuild the system of prioritization with their account. After all, a release is not a project, and not a task, but a kind of container of other tasks that need to be done in order for the release to take place. And the release, especially the first one, is entering the market. Until it happens, no one will see the product and, accordingly, there will be no feedback or money.
Who else have forgotten?
I feel it's time to wrap up. If you have read this far, then a big respect for you. About many things I have not written, but the main thing, like, is reflected in this material.
There are a lot of techniques and practices that have influenced the bottle, but I will not list them. Maybe someday, I will do something like a glossary, or a list of references - for those who strongly respect all scientific approaches, citation indices and "reliance on world-famous methods."
Yes, dear authors of the methods, from which I took something useful for the bottle, but did not mention in this article, I offer my sincere apologies.
What is the result?
As a result, we have a bottle - an explosive mixture of best management practices that improves efficiency. And there is exactly to increase efficiency.
What is important for me personally is the mixture, the set, and not the sequence. You can apply all the methods, you can - only one, or half, of your choice. Any method, in itself, gives an increase in efficiency. One more, the other less.
As mentioned in the article, over the years of practice I have tried parts of a bottle in different enterprises and, more importantly, in completely different types of human activity. There were programmers, design engineers, quality services, supplies, sales, manufacturing, accountants, economists, managers, and the devil knows who else.
It is clear that each profession needs its own set of bottle methods, and its own automation. But you can choose the right kit for everyone. But the most important thing is that the bottle develops, and at an accelerated pace. Because it went beyond the limits of my practice, and quickly became enriched with feedback from other people, companies and professions.
There are even people who have taken one or two ideas from published materials and put them into practice. What is particularly interesting is that they don’t write to me about this, but if they accidentally cross somewhere on a forum or conference, they honestly tell about their experience and don’t hesitate to say that they took the ideas from a bottle.
So, everything will be fine.