Ford, Toyota and Guinea Pigs
- What does the guinea pig have to do with the sea?
- About the same as the duckbill to the design of airships.
I have the habit of scrolling information from several sources while walking, matching the pieces. One of the curious findings is the almost complete correspondence of the statistical observations of DeMarco and Lister in Peopleware and the theoretical calculations of Goldratt in the Critical Chain.
In the fall of 2011, I turned in my head:
[1] “Standing on the shoulders of giants” by Eli M. Goldratt © Eliyahu M. Goldratt, 2008
[2] “Production Management: Flow Management” Oded Cowen, Elena Fedurko
[3] “The History of One Board” (http://cartmendum.livejournal.com/tag/theboard).
')
Further, I would like to write: “Suddenly ...” - but this will not be true. It did not happen all of a sudden. It took me a couple of weeks, but in the end, I had a rather solid picture in my head.
What exactly am I hooked for:
Flow types are usually classified from the dominant pattern. In a pure (degenerate) form, the types of flows can be represented as follows:
If you need more detailed information, it is better to refer to the articles of Oded Cohen (Oded-Cohen) and Helena Fedurko.
In the software world, an analogy can be drawn:
The main difference is that there are often no materials in software production. It is not entirely clear what to use as an analogy to materials in the world of software production. Orders are there and there. As a rule, production does not start at the factory without an order either. It is probably possible to consider ideas coming in as materials. During the development process, these ideas are transformed into requirements specifications, then into architectural solutions, and finally into a final product.
Perhaps someone wants to change the classification. For example, I wanted. I would prefer to add two more types:
But this is a deviation from the standard, and the standard, even the bad, is better to adhere to.
The easiest to control I-type flow.
But even for this type, there are a number of common mistakes. The most frequently made mistake is the use of “pushing” control models.
Consider a classic example typical of the IT industry. Take a simple, even trivial chain "Sales Department" -> programming department -> testing department.
Process flow:
Let the departments can handle accordingly:
To this we will add a bonus system depending on the number of orders processed by the department. It is logical that the sales department will take all orders that can be processed. It is also logical that most top managers will order to take all orders. Here is an example of a discussion about a year ago:
> To beat sales and not let them recruit projects, more than programmers manage to do. Naturally, there should be a small buffer of projects in front of the programming department.
The first thing that the head of the company will do at least minimally sane, after reading this, will hit the author's head, then he will give him a Napoleonic triangle and send him to the fool. This is the extent to which programmers have to go to decide how much a company should sell? I understand that it is difficult for them to increase production to the requested sales, but having sales opportunities is not a reason to beat sales, but to work on the possibilities of satisfying their requests.
In Russian: money is brought to the company, and some intend to send it.
The result is fairly obvious. The production chain will very quickly become clogged up with the orders being fulfilled and the average lead time will increase to an indecent value. In this case, in just half a year, the average time to complete orders will increase to two years. That is not too competitive, but it occurs very often.
Balancing sites for performance also does not bring happiness. In the system there are "beats" and the average lead time again increases to indecent values.
Max Kramarenko's blog describes the modeling of a balanced production chain:
Simulations show that as a result of the beats, the production chain is quickly clogged. At the end of the experiment, for a short chain of only 4 sites, there were one hundred and fifty tasks in production. Translating into “modern managerial” this means that the task of labor-intensive in four man-days will be realized in six months. To the manager's question: “Why is it so long for something ?!”, the answer is simple: “Because you are controlling this.”
The problem with this type of flow is the missing components in assembly operations.
The production chain of I-type is primitive as a rake and simple as a young radish. I believe that the optimal way to manage such chains was known long ago, but unfortunately I have not yet found the information in which century this technique was first described. However, at some point, childhood ends and managers face up to truly challenging tasks. With a similar challenge, along with others faced Henry Ford. At that time, the production of cars in the Ford enterprise was the production of the A-type. Difficult, with many branches, but having one peak. One single car brand, one single color. The lack of a stock of any part on any part of the assembly leads to an increase in the production time of the car. But an excessive supply of parts also leads to an increase in the time it takes to get the finished car out of the iron rock. Time increases, because every detail takes a substantial part of the time in the waiting line.
In 1913, Henry Ford introduced in his company a conveyor method for assembling cars. And by 1926, the production cycle from the extraction of iron ore to the production of a finished car (consisting of more than 5,000 parts) on the railway platform and ready for shipment reached 81 hours! .. [1] Outstanding achievement. Imagine the complexity of setting up a software production process consisting of at least 50 production sites. I believe that most modern managers would request a complex automated control system (automated accounting system) to manage the work flow. But at the beginning of the century there were no computers ...
Contrary to popular belief, the Henry Ford production line is not our usual belt conveyor, along which the collected cars synchronously move. These are separate work centers, with manual transmission of parts. “In order to improve the production flow, Ford limited the space for storing work in progress stocks between every two work centers. This is the essence of production lines, which is confirmed by the fact that the first production lines had no mechanical devices, such as conveyors, for moving stocks (work in progress) from one working center to another. ”[1]. For lack of computers, Ford has created a visual work management system. Extremely easy to use.
Yes, naturally, this system would not have worked if an additional rule had not been introduced: “when the allocated space is filled, the workers who fill it must stop production” . Go for a walk, take a nap, sit on the VKontakte, ...
Ford abandoned one of the main provisions of modern management. However, even now, 99 years later, little has changed. I suppose, come Ford to a typical Russian firm for an interview and voice that incomplete workload of employees is a necessary condition for increasing the firm’s revenues , he would have been told that he does not know how to manage real production.
V-type flow problems - “material theft”;
T-type flow problems - “theft” and missing components;
Ford’s visual model works great for the A-type. But as soon as there is no merger, but a fork (one work center supplies parts for several centers) problems begin. It was these problems that eliminated the advantage of the Ford production lines at the moment when General Motors entered the market with a wide range of models. Company managers were challenged again.
The glove was raised by Taichi Ono, who began work at the Toyota Motor Corporation in 1943. In the mid-1950s, he began to build a special system of production organization, later called the Toyota Production System (also mistakenly referred to as Kanban, Lean, Just-In-Time).
It, like Ford, did not have an ACS and he developed a visual kanban-based workflow management system (translation option: a visual card). However, this system would not bring such an effect without additional requirements. At each point in time, in areas with a power reserve, one needs to make one of two improvements: either to reduce the size of the lot (to increase the number of switching and associated losses), or to reduce the changeover time.
“At that time and until TPS gained worldwide fame, increasing the batch size was considered the traditional way to reduce changeover time -“ economically reasonable batch size ”was a very popular term to which thousands of articles were dedicated. It rejected all this traditional experience. ”[1]
It challenged its modern management system. It is logical that he was not forgiven. From the late 40s to the early 60s, his system was called the “disgusting system of Ono”.
However, even now, after six decades, among people who call themselves Lean supporters, the elimination of switching is considered one of the most powerful methods of increasing the passage. It did not think so. I believe, come Taichi Ono to the conference on lean manufacturing and voice your positions, he would be told that he simply does not know how to manage the real production.
And then the fun begins. If the work center participates in more than one of the chains, then these chains should be folded in the diagram:
The left and right streams are A-type and could be controlled by Ford’s visual model, but due to the joint use of work centers “3” and “4” the scheme becomes more complicated and we need to switch to the Ono model. If you do not want to use such a complex model, then you should divide the working centers "3", "4" into "3 '", "3" "," 4' "," 4 ""
Understanding the applicability of management models and their complexity should have a significant impact on the decision to change the organizational structure of the enterprise and development regulations.
The matrix system also leads to negative effects when an employee has two managers at once: the head of the functional unit and the project manager. Even Truffaldino did not cope well with the service of two masters. And in real companies on real projects, this leads to a fantastic mess and a monstrous increase in the time of ALL projects.
Sometimes in large firms they go for a hard suppression of cases of manifestations of the “Servant of two masters”. One of the options I've heard about is the internal exchange of works. The engineer of the relevant specialization is located in the structural unit (programmer in the programmer pool) and reports to the pool manager. Submits until it is transferred to the project. After that, it only reports to the project manager. Giving a direct order to an engineer involved in a project, someone other than the project manager, is a hack that may well end in personnel changes. The firm sags a little due to the under-employment of employees, but the benefits of ease of management are so huge that they outweigh these losses. In addition, the principle “My vassal's vassal - not my vassal” is used - the platoon commander cannot give the order directly to the soldier. And if he returns, he will look for new sergeants. Or sergeants will look for a new platoon commander.
MSProject, popular in Russia, is not bad for project planning. For planning processes, it fits somewhat worse. For process planning, a commonplace tracker is often better. But it is not important. Both the tracker and the Project are “Information Refrigerators” (the term was introduced by Alistair Cobern in one of the best books on “Rapid Software Development” methodologies). To increase the efficiency of development, an “Informational radiator” is needed. And of course, we need rules for managing work.
There may be an impression that the board is an information radiator. In fact, fashion boards are the same trackers, that is, the same refrigerators. To turn the board into a radiator, you need to hang it in a public place. And as soon as a web tool is used under the board, it immediately becomes a fridge. Well, if it is not displayed on the plasma in the corridor or under the ceiling.
A few years ago it was suggested to use a board on which stickers with the description of tasks are placed. Now this is quite a fashionable hobby. On request "Kanban Board" search engine gives a lot of links to something like this:
The figure clearly depicts the visual control system for I-type streams. Not having any relation to the system Taichi Ono. Moreover, this system is more primitive than even the system of Henry Ford. This “progressive” model lags behind the theory and practice of the science of managing the flow of “all” work by 99 years.
It would seem, well called wrong what? And the fact that the wrong term gives the illusion of universal applicability of the tool. Too often, counselors try to apply this board for inappropriate types of flows. Naturally, the attempt fails, but the consultants for some reason blame the performers. “You simply misused XP / SCRUM / Kanban / ...” Lord, if screwdriver screwdriver failed with a cross screwdriver, then you shouldn’t blame the contractor for holding the screwdriver incorrectly. You just need to give him a hammer.
I recommend to be wary of “consultants” on “XP / SCRUM / Kanban” who do not know the theory of production flows. Not that they could not be used at all, but the inability to apply the theory of flows, Shewhart maps, the inability to add probabilities of fulfillment with significant deviations of the deadline, and so on and so on should alert you.
In the future, I will call this board I-board.
As for the management rules, at the seminar Suren Samarchan (videocast: http://spmguild.org/news/618/) said that the production task can be taken only if someone from the programmers is free. It is quite easy to understand that this will work only if the system limitation (often mistakenly referred to as the “bottleneck”) is at the beginning of the production chain (see the management of the tourists column in Goldratt’s The Purpose Book).
Quite often in isolated small cross-functional development teams this is exactly what happens. The constraint is at the beginning of the production chain. And everything is going well. But as soon as the limitation of the system goes somewhere else ... All finita la comedia. You need the system "a little podshamanit." Maxim Dorofeev found the rule of thumb "The number of tasks in production should not exceed the number of programmers by more than 2." Normal is the shaman rule.
More interesting tuning of the board was proposed by Oleg (did not indicate the names) in the article “Kanban in IT (Kanban Development)” (http://habrahabr.ru/blogs/development/64997/).
And now the most important thing. See the numbers under each column? This is the number of tasks that can be simultaneously in these columns. The numbers are chosen experimentally, but it is believed that they should depend on the number of developers in the team.
Resembles a Ford production line, but applied to an I-type stream. Actually, this is the visualization of the rule of Henry Ford: "The volume of work in progress between two work centers should be limited."
Strangely enough, but often the limitation of the system is the task acceptance section by the customer. I know at least three companies where this effect was observed.
There is another restriction on the use of I-boards. This limitation is due to the efficiency of the cycle at one production site (with one performer). If the cycle efficiency is less than 50%, then the rule “there is only one job for one performer” starts to fail.
Note. The efficiency of the cycle is the ratio of the processing time to the total time spent at the production site. If in the morning you received a task, and you did it just before leaving, then the total time is 8 hours. If you worked on the task for 2 hours, then the cycle efficiency is 25%.
I will give examples when the restriction to one task of the executor per unit of time will be ineffective:
And one more limitation. I-board poorly visualizes the connections between tasks. It is well suited for maintenance processes with independent tasks and worse for projects. Although for short projects with poorly related tasks it may be suitable.
However, this board is very easy to use and if the unit is suitable for implementation, then this is one of the most effective ways to manage flows. All the same, and the Ford system and the system It is quite difficult to visualize.
Just before introducing such a board, you need to go through the checklist:
Often the stumbling block is a complex flow. To simplify the type of flow, an effective medicine is the isolation and isolation of individual project groups and functional units.
But, too often, we hear the phrases: “We cannot but pull it. Nobody can do this other than him. And it is impossible to fully translate it to us. We need him only four hours a week. ”
The way out is to eliminate the irreplaceable effect. XP-sharing co-ownership of the code will go along with the introduction of coding standards and training in related specialties (one of the exotic combinations that helped us greatly in one of the projects is the “system administrator” and the “computer artist” in one person).
From the division of the company into isolated groups, you can get the greater benefit, the more cross-functional specialists.
In one of the companies, you seriously discussed the expediency of admitting a system administrator to a development group, and a programmer to a system administration group. Colleagues say that this rule, implemented as an experiment, showed a good result.
Andrei Orlov in the “Notes of the Automator” proposed a simple rule of thumb: “If the programmer has become indispensable, immediately dismiss him”.
The proposal makes perfect sense. An indispensable employee may well have the highest local productivity, but his indispensability too destabilizes the flow too much.
Another option is to reduce the length of the stream. Reducing the number of work centers can drastically change the picture.
A curious task based on observations of real processes in real firms.
From observations: Chains from five to six work centers not connected by rigid general management often make it meaningless to launch a project into production. It will become unnecessary before it is completed. The chains with two work centers are relatively stable. Three already have problems. The chain 1-> 2-> 1 is supposedly more stable than 1-> 2-> 3.
Reduce the number of work centers in the value stream. Go even to increase direct costs. Stabilizing the flow and reducing the average lead time will more than cover these costs.
You can refuse the selected analyst - refuse. You can refuse the selected tester - refuse. If you can not refuse either the selected testing or the selected analysis, try to combine the roles of the tester and the system analyst in one person.
Then you need to go to a full TOC. And as a visualization of the work management system, I want to try the priority change system proposed by Goldratt in the article “Standing on the shoulders of giants”. But how to implement it in the "metal"? An interesting task for the system analyst: "Understand the idea, choose the engine and write a statement for customization." The intuition suggests that it is quite possible to take the middle level tracking system as an engine. TrackStudio may come up.
If you confuse the type of flow and try to apply the I-board to the flow of the T-type, the result may surprise you less, but the consequences for the company will be significantly worse than if you mixed up the medicine for diarrhea.
- About the same as the duckbill to the design of airships.
Introduction
I have the habit of scrolling information from several sources while walking, matching the pieces. One of the curious findings is the almost complete correspondence of the statistical observations of DeMarco and Lister in Peopleware and the theoretical calculations of Goldratt in the Critical Chain.
In the fall of 2011, I turned in my head:
[1] “Standing on the shoulders of giants” by Eli M. Goldratt © Eliyahu M. Goldratt, 2008
[2] “Production Management: Flow Management” Oded Cowen, Elena Fedurko
[3] “The History of One Board” (http://cartmendum.livejournal.com/tag/theboard).
')
Further, I would like to write: “Suddenly ...” - but this will not be true. It did not happen all of a sudden. It took me a couple of weeks, but in the end, I had a rather solid picture in my head.
What exactly am I hooked for:
- Taichi Ono (Ă–no Taiichi) did not understand why his system was working.
- There are several different types of production flows - V, A, T, I. Each type of flow poses specific tasks.
- Failures of the introduction of the board Maxim Dorofeev in some units
- A number of companies could not implement the Toyota system, despite all efforts.
- The Toyota system and the Ford system are based on the same principles, but application solutions are limited to certain types of production.
Theory. Stream types
Flow types are usually classified from the dominant pattern. In a pure (degenerate) form, the types of flows can be represented as follows:
If you need more detailed information, it is better to refer to the articles of Oded Cohen (Oded-Cohen) and Helena Fedurko.
In the software world, an analogy can be drawn:
The main difference is that there are often no materials in software production. It is not entirely clear what to use as an analogy to materials in the world of software production. Orders are there and there. As a rule, production does not start at the factory without an order either. It is probably possible to consider ideas coming in as materials. During the development process, these ideas are transformed into requirements specifications, then into architectural solutions, and finally into a final product.
 | Disclaimer I'm not sure that the problems of the same type of production chain are the same for the material production worlds and the software development world. This is a hypothesis that has many supporting examples. But even one exception can put this hypothesis into question. |
Perhaps someone wants to change the classification. For example, I wanted. I would prefer to add two more types:
But this is a deviation from the standard, and the standard, even the bad, is better to adhere to.
| There is a suspicion that the G-type is a more correct T-type name, just the Americans are not lucky with the alphabet. ;-) |
I-type
The easiest to control I-type flow.
But even for this type, there are a number of common mistakes. The most frequently made mistake is the use of “pushing” control models.
Consider a classic example typical of the IT industry. Take a simple, even trivial chain "Sales Department" -> programming department -> testing department.
Process flow:
Let the departments can handle accordingly:
- Sales department - 20 orders per week
- Programming department - 10 orders per week
- Testing department - 5 orders per week
To this we will add a bonus system depending on the number of orders processed by the department. It is logical that the sales department will take all orders that can be processed. It is also logical that most top managers will order to take all orders. Here is an example of a discussion about a year ago:
> To beat sales and not let them recruit projects, more than programmers manage to do. Naturally, there should be a small buffer of projects in front of the programming department.
The first thing that the head of the company will do at least minimally sane, after reading this, will hit the author's head, then he will give him a Napoleonic triangle and send him to the fool. This is the extent to which programmers have to go to decide how much a company should sell? I understand that it is difficult for them to increase production to the requested sales, but having sales opportunities is not a reason to beat sales, but to work on the possibilities of satisfying their requests.
In Russian: money is brought to the company, and some intend to send it.
The result is fairly obvious. The production chain will very quickly become clogged up with the orders being fulfilled and the average lead time will increase to an indecent value. In this case, in just half a year, the average time to complete orders will increase to two years. That is not too competitive, but it occurs very often.
Balancing sites for performance also does not bring happiness. In the system there are "beats" and the average lead time again increases to indecent values.
Max Kramarenko's blog describes the modeling of a balanced production chain:
- http://maximkr.livejournal.com/18940.html
- http://maximkr.livejournal.com/18971.html
Simulations show that as a result of the beats, the production chain is quickly clogged. At the end of the experiment, for a short chain of only 4 sites, there were one hundred and fifty tasks in production. Translating into “modern managerial” this means that the task of labor-intensive in four man-days will be realized in six months. To the manager's question: “Why is it so long for something ?!”, the answer is simple: “Because you are controlling this.”
| It is important. The blame for the enormous duration of order fulfillment almost always lies with the workflow management system (management), and not with the executors. Well, who does not believe - he can try to write the simulator and experiment. In fairness, it should be mentioned that a balanced chain is quite possible to use if you follow the rule: “The average downtime of employees must be at least 20-25%.” But then again, who among the managers will do this? |
Ford's A-Type and Solution
The problem with this type of flow is the missing components in assembly operations.
The production chain of I-type is primitive as a rake and simple as a young radish. I believe that the optimal way to manage such chains was known long ago, but unfortunately I have not yet found the information in which century this technique was first described. However, at some point, childhood ends and managers face up to truly challenging tasks. With a similar challenge, along with others faced Henry Ford. At that time, the production of cars in the Ford enterprise was the production of the A-type. Difficult, with many branches, but having one peak. One single car brand, one single color. The lack of a stock of any part on any part of the assembly leads to an increase in the production time of the car. But an excessive supply of parts also leads to an increase in the time it takes to get the finished car out of the iron rock. Time increases, because every detail takes a substantial part of the time in the waiting line.
In 1913, Henry Ford introduced in his company a conveyor method for assembling cars. And by 1926, the production cycle from the extraction of iron ore to the production of a finished car (consisting of more than 5,000 parts) on the railway platform and ready for shipment reached 81 hours! .. [1] Outstanding achievement. Imagine the complexity of setting up a software production process consisting of at least 50 production sites. I believe that most modern managers would request a complex automated control system (automated accounting system) to manage the work flow. But at the beginning of the century there were no computers ...
Contrary to popular belief, the Henry Ford production line is not our usual belt conveyor, along which the collected cars synchronously move. These are separate work centers, with manual transmission of parts. “In order to improve the production flow, Ford limited the space for storing work in progress stocks between every two work centers. This is the essence of production lines, which is confirmed by the fact that the first production lines had no mechanical devices, such as conveyors, for moving stocks (work in progress) from one working center to another. ”[1]. For lack of computers, Ford has created a visual work management system. Extremely easy to use.
Yes, naturally, this system would not have worked if an additional rule had not been introduced: “when the allocated space is filled, the workers who fill it must stop production” . Go for a walk, take a nap, sit on the VKontakte, ...
Ford abandoned one of the main provisions of modern management. However, even now, 99 years later, little has changed. I suppose, come Ford to a typical Russian firm for an interview and voice that incomplete workload of employees is a necessary condition for increasing the firm’s revenues , he would have been told that he does not know how to manage real production.
More complex types and Toyota system
V-type flow problems - “material theft”;
T-type flow problems - “theft” and missing components;
Ford’s visual model works great for the A-type. But as soon as there is no merger, but a fork (one work center supplies parts for several centers) problems begin. It was these problems that eliminated the advantage of the Ford production lines at the moment when General Motors entered the market with a wide range of models. Company managers were challenged again.
The glove was raised by Taichi Ono, who began work at the Toyota Motor Corporation in 1943. In the mid-1950s, he began to build a special system of production organization, later called the Toyota Production System (also mistakenly referred to as Kanban, Lean, Just-In-Time).
It, like Ford, did not have an ACS and he developed a visual kanban-based workflow management system (translation option: a visual card). However, this system would not bring such an effect without additional requirements. At each point in time, in areas with a power reserve, one needs to make one of two improvements: either to reduce the size of the lot (to increase the number of switching and associated losses), or to reduce the changeover time.
“At that time and until TPS gained worldwide fame, increasing the batch size was considered the traditional way to reduce changeover time -“ economically reasonable batch size ”was a very popular term to which thousands of articles were dedicated. It rejected all this traditional experience. ”[1]
It challenged its modern management system. It is logical that he was not forgiven. From the late 40s to the early 60s, his system was called the “disgusting system of Ono”.
However, even now, after six decades, among people who call themselves Lean supporters, the elimination of switching is considered one of the most powerful methods of increasing the passage. It did not think so. I believe, come Taichi Ono to the conference on lean manufacturing and voice your positions, he would be told that he simply does not know how to manage the real production.
Addition rules
And then the fun begins. If the work center participates in more than one of the chains, then these chains should be folded in the diagram:
The left and right streams are A-type and could be controlled by Ford’s visual model, but due to the joint use of work centers “3” and “4” the scheme becomes more complicated and we need to switch to the Ono model. If you do not want to use such a complex model, then you should divide the working centers "3", "4" into "3 '", "3" "," 4' "," 4 ""
Understanding the applicability of management models and their complexity should have a significant impact on the decision to change the organizational structure of the enterprise and development regulations.
 | Example. Suppose, historically, that the company has four different development centers responsible for supporting four different internal products. At some point, a test group was created at the first center. This innovation turned out to be quite effective and the issue of separating the testing team into a separate service that provides testing services to all four development centers is being considered. Pros and cons? Cons: a change in flow type will occur, and handling problems will arise. Instead of 4 I-type chains, there will be one complex chain:  If a power reserve is provided in the working testing center, the conversion will not lead to negative consequences. But something tells me (all my previous experience) that testing will be a limitation of the system with all the sad consequences. |
| Suppose, historically, that the company has one department responsible for supporting domestic products and performing improvements for several customers. Take the fairly common structure of "programming -> testing." The simplest, trivial I-stream, easy to manage. At some point in time, the quality of delivery ceased to satisfy customers and the company is considering the introduction of the acceptance stage. Pros and cons? Cons: a change in flow type will occur, and handling problems will arise. Instead of one I-type chain, there will be one complex chain.  If deliveries of improvements are organized into packages common to all customers, then a single customer can block both the current and subsequent deliveries to all others. |
The matrix system also leads to negative effects when an employee has two managers at once: the head of the functional unit and the project manager. Even Truffaldino did not cope well with the service of two masters. And in real companies on real projects, this leads to a fantastic mess and a monstrous increase in the time of ALL projects.
 | Retreat. In the book of Lyker about the system of product development in Toyota it is written that in the research centers of Toyota is just a matrix management. Moreover, they came to this meaningfully and do not want to change it. In fact, they have all sorts of other tricks to make the matrix workable. One of them is that the project manager is a specialist with enormous prestige among colleagues. As a rule, he must work in the company 10-25 years. In this case, he is the leader and the formal controls are not necessary for him. The matrix is ​​not evil, it's just difficult to cook |
Sometimes in large firms they go for a hard suppression of cases of manifestations of the “Servant of two masters”. One of the options I've heard about is the internal exchange of works. The engineer of the relevant specialization is located in the structural unit (programmer in the programmer pool) and reports to the pool manager. Submits until it is transferred to the project. After that, it only reports to the project manager. Giving a direct order to an engineer involved in a project, someone other than the project manager, is a hack that may well end in personnel changes. The firm sags a little due to the under-employment of employees, but the benefits of ease of management are so huge that they outweigh these losses. In addition, the principle “My vassal's vassal - not my vassal” is used - the platoon commander cannot give the order directly to the soldier. And if he returns, he will look for new sergeants. Or sergeants will look for a new platoon commander.
Kanban board and guinea pig
MSProject, popular in Russia, is not bad for project planning. For planning processes, it fits somewhat worse. For process planning, a commonplace tracker is often better. But it is not important. Both the tracker and the Project are “Information Refrigerators” (the term was introduced by Alistair Cobern in one of the best books on “Rapid Software Development” methodologies). To increase the efficiency of development, an “Informational radiator” is needed. And of course, we need rules for managing work.
There may be an impression that the board is an information radiator. In fact, fashion boards are the same trackers, that is, the same refrigerators. To turn the board into a radiator, you need to hang it in a public place. And as soon as a web tool is used under the board, it immediately becomes a fridge. Well, if it is not displayed on the plasma in the corridor or under the ceiling.
A few years ago it was suggested to use a board on which stickers with the description of tasks are placed. Now this is quite a fashionable hobby. On request "Kanban Board" search engine gives a lot of links to something like this:
The figure clearly depicts the visual control system for I-type streams. Not having any relation to the system Taichi Ono. Moreover, this system is more primitive than even the system of Henry Ford. This “progressive” model lags behind the theory and practice of the science of managing the flow of “all” work by 99 years.
 | What do kanban board and guinea pig have in common? Kanban board has about the same attitude to kanban as a guinea pig to the sea. |
It would seem, well called wrong what? And the fact that the wrong term gives the illusion of universal applicability of the tool. Too often, counselors try to apply this board for inappropriate types of flows. Naturally, the attempt fails, but the consultants for some reason blame the performers. “You simply misused XP / SCRUM / Kanban / ...” Lord, if screwdriver screwdriver failed with a cross screwdriver, then you shouldn’t blame the contractor for holding the screwdriver incorrectly. You just need to give him a hammer.
I recommend to be wary of “consultants” on “XP / SCRUM / Kanban” who do not know the theory of production flows. Not that they could not be used at all, but the inability to apply the theory of flows, Shewhart maps, the inability to add probabilities of fulfillment with significant deviations of the deadline, and so on and so on should alert you.
In the future, I will call this board I-board.
As for the management rules, at the seminar Suren Samarchan (videocast: http://spmguild.org/news/618/) said that the production task can be taken only if someone from the programmers is free. It is quite easy to understand that this will work only if the system limitation (often mistakenly referred to as the “bottleneck”) is at the beginning of the production chain (see the management of the tourists column in Goldratt’s The Purpose Book).
Quite often in isolated small cross-functional development teams this is exactly what happens. The constraint is at the beginning of the production chain. And everything is going well. But as soon as the limitation of the system goes somewhere else ... All finita la comedia. You need the system "a little podshamanit." Maxim Dorofeev found the rule of thumb "The number of tasks in production should not exceed the number of programmers by more than 2." Normal is the shaman rule.
More interesting tuning of the board was proposed by Oleg (did not indicate the names) in the article “Kanban in IT (Kanban Development)” (http://habrahabr.ru/blogs/development/64997/).
And now the most important thing. See the numbers under each column? This is the number of tasks that can be simultaneously in these columns. The numbers are chosen experimentally, but it is believed that they should depend on the number of developers in the team.Resembles a Ford production line, but applied to an I-type stream. Actually, this is the visualization of the rule of Henry Ford: "The volume of work in progress between two work centers should be limited."
Strangely enough, but often the limitation of the system is the task acceptance section by the customer. I know at least three companies where this effect was observed.
There is another restriction on the use of I-boards. This limitation is due to the efficiency of the cycle at one production site (with one performer). If the cycle efficiency is less than 50%, then the rule “there is only one job for one performer” starts to fail.
Note. The efficiency of the cycle is the ratio of the processing time to the total time spent at the production site. If in the morning you received a task, and you did it just before leaving, then the total time is 8 hours. If you worked on the task for 2 hours, then the cycle efficiency is 25%.
I will give examples when the restriction to one task of the executor per unit of time will be ineffective:
- Police projects (www.toc-center.ru/politseiskie_proekty.html)
- Writing TZ and PMI (GOST 34.602 and 34.603). Documents strongly influence each other and it is sometimes easier to write two documents at the same time.
- Cooking a festive dinner. The broth supplied to cook requires the participation of a person during cooking for a couple of minutes at most. At this time, it is possible to do the preparation of salads. If the hostess was preparing a festive Christmas dinner according to the Suren Samarchan system, the guests would be left hungry. Just there the system does not apply.
- Often this category includes applications sent to the technical support service. For example, applications requiring procurement often have a long suspension period, during which an employee can do something else.
And one more limitation. I-board poorly visualizes the connections between tasks. It is well suited for maintenance processes with independent tasks and worse for projects. Although for short projects with poorly related tasks it may be suitable.
However, this board is very easy to use and if the unit is suitable for implementation, then this is one of the most effective ways to manage flows. All the same, and the Ford system and the system It is quite difficult to visualize.
Just before introducing such a board, you need to go through the checklist:
- I-type stream? If not, then most likely you will have to abandon attempts to introduce a simple board.
- Is the limit at the beginning of the chain? If not, then take care of the supply buffer. Come up with a sham rule.
- Does the cycle efficiency at one production site exceed 50%? If not, then remove the restriction on processing only one task at a time.
- Are incoming orders related or can they be carried out in isolation? If they are related, then you need something else to visualize. , . -.
Often the stumbling block is a complex flow. To simplify the type of flow, an effective medicine is the isolation and isolation of individual project groups and functional units.
But, too often, we hear the phrases: “We cannot but pull it. Nobody can do this other than him. And it is impossible to fully translate it to us. We need him only four hours a week. ”
The way out is to eliminate the irreplaceable effect. XP-sharing co-ownership of the code will go along with the introduction of coding standards and training in related specialties (one of the exotic combinations that helped us greatly in one of the projects is the “system administrator” and the “computer artist” in one person).
From the division of the company into isolated groups, you can get the greater benefit, the more cross-functional specialists.
In one of the companies, you seriously discussed the expediency of admitting a system administrator to a development group, and a programmer to a system administration group. Colleagues say that this rule, implemented as an experiment, showed a good result.
Andrei Orlov in the “Notes of the Automator” proposed a simple rule of thumb: “If the programmer has become indispensable, immediately dismiss him”.
The proposal makes perfect sense. An indispensable employee may well have the highest local productivity, but his indispensability too destabilizes the flow too much.
Another option is to reduce the length of the stream. Reducing the number of work centers can drastically change the picture.
A curious task based on observations of real processes in real firms.
. $2 000 ( ). . , , . , $2 000 : + . , . – 4 , – 6 , - $12 000 4 , . , . – 4 , – 4 , - $8 000.: « ROI ?» : : 18*2000 = $36000… , , , , . : 1 , (18-1)*… , , , , , .… : . « ». «, », «, » « ». - . . – (18-4)*2 000 = 28 000, – 28 000-12 000=16 000, ROI=133%. . . . . . . , . (18-12)*2000 = 12 000. – 4 000, ROI – 50% ROI, . , .From observations: Chains from five to six work centers not connected by rigid general management often make it meaningless to launch a project into production. It will become unnecessary before it is completed. The chains with two work centers are relatively stable. Three already have problems. The chain 1-> 2-> 1 is supposedly more stable than 1-> 2-> 3.
Reduce the number of work centers in the value stream. Go even to increase direct costs. Stabilizing the flow and reducing the average lead time will more than cover these costs.
You can refuse the selected analyst - refuse. You can refuse the selected tester - refuse. If you can not refuse either the selected testing or the selected analysis, try to combine the roles of the tester and the system analyst in one person.
And if the system It is not applicable?
Then you need to go to a full TOC. And as a visualization of the work management system, I want to try the priority change system proposed by Goldratt in the article “Standing on the shoulders of giants”. But how to implement it in the "metal"? An interesting task for the system analyst: "Understand the idea, choose the engine and write a statement for customization." The intuition suggests that it is quite possible to take the middle level tracking system as an engine. TrackStudio may come up.
Instead of epilogue
And try not to confuse the type of production flow of your group. Treatment of diarrhea or constipation is quite simple. But if you mix up the drugs, the result may surprise you a little.If you confuse the type of flow and try to apply the I-board to the flow of the T-type, the result may surprise you less, but the consequences for the company will be significantly worse than if you mixed up the medicine for diarrhea.
Source: https://habr.com/ru/post/139194/
All Articles