January 21, 2015 at 15:118 kinds of muda in your web studio
Muda, which in Japanese means “loss”, is any activity that consumes resources but does not create value for the client. ( Source ).
This short note is for those who are systematically looking for where his studio is losing money. A commendable lesson in our fun time.
Well systematized types of losses guys from Toyota. Toyotovtsy allocate 7-8 types of muda, losses in production. Let's see if there are analogues between the losses in the automotive industry and the work of the studio.
In the studio: All unfinished or unfinished work.
The more unfinished work in your company, the more you have receivables. The more you risk being burned out.
Again, if you look from the point of view of the customer: unfinished work does not bring any benefit. He doesn’t need her.
What to do: By hook or by crook, try to reduce the amount of work that was not delivered at the same time. It is better to bring one project to the end and then proceed to the next than to take on 4-5 and do them in parallel.
In the studio: Re-discussion of the same issue on which a decision has already been made (Relearning).
For example, you came to the conclusion that it would be nice to use some kind of version control system in the studio. We carefully studied the issue. Gathered, discussed the pros and cons. They praised what is better - GIT or SVN. Really fully understood the issue. And as a standard we decided to host svn. Implemented as standard. Learned. Started to use.
And six months later, some wise guy says: “Guys! And why do we use SVN and not GIT? SVN is shit, because <argument>, and GIT is cool because <another argument>. " In fact, after half a year no one remembers whether these arguments were already considered (and you came to the conclusion that they were insufficient), or you skipped these arguments during the discussion. I have to study the question again. Wasting time instead of making money.
What to do: Fix not only decisions, but also the context and argumentation of the decisions made. Charts work well here ( Root Cause analysis , Mind Map, A3 analysis ). Find a balance between reviewing your development processes / tools and complying with accepted standards.
In the studio: Unnecessary functionality.
So it’s fun to get a couple of chips, easter eggs for a client or polish photos on some page of the 5th level, which no one will ever go to or optimize the Our Guide page for a download speed of 0.005 sec.
The general idea: to make functions that no one will use (and which your client will not earn) is a loss. An example leader is MS Excel: 95% of users constantly use only 5% of functions. What the rest?
What to do: critically evaluate what you are doing in terms of benefits. Mark and eliminate work that does not benefit your customers and yourself.
In the studio: Delaying approvals.
Such a very actual loss is expectations. While the customer agrees the layout at 3 levels. While approving the texts. While the lawyer deigns to send edits to the contractor.
Especially a lot of resources flies to personal meetings on trifling issues. Often, in order to cover up the ass and not make decisions - as many people as possible are invited to meetings on any issue. Moving bodies around Moscow to meetings to discuss “what size letters will be” is an extremely expensive pleasure, but few people really think how much it costs to collect and hold one such meeting (hint: usually several tens of thousands of rubles). Agreements are not fixed, discussions fly away into the void.
What to do:reduce the number of people involved in the project to a minimum. Make decisions as quickly as possible. Reduce the number of meetings and personal meetings. If we already have a meeting, we must have a clear schedule, record and clearly observe the agreements.
In the studio: Bugs.
What is important to know about bugs: the later a defect is found, the more expensive it is. If you, say, a programmer, find and fix the bug yourself and immediately, it is cheap. But if the client finds him, then this is already fraught. Especially when a bug was found two years later, it destroyed the client’s database, and the programmer who wrote the code went on vacation in another city and died.
What to do: testing as early as possible. On large projects - automatic tests . Clear coding standards. Regular code review practices. Tutors for beginners.
In the studio: Project Transfer Loss.
Transmission loss:
How many intermediate links between how the client’s idea gets from his head to the person who will specifically do it? It is possible that the client first tells his story to the account manager, then to the project manager, then the project manager tells all the introductory analytics, then the analytics is passed to the designer.
Each time a project is transferred, there is a loss of time and information: verbal and non-verbal. Loss of information in the end lead to errors, alterations, and again - a waste of time. Particularly sensitive are losses when transferring projects from one project manager to another, or when changing a programmer in a project. And the most difficult case is the change of the responsible person on the client side.
An important subtlety: when a project is studied and analyzed for the first time, it is of value to the client. Losses will only be repeated grinding of the same information.
What to do: minimize the number of people involved in the project to the required minimum. Exclude the transfer of projects between teams and responsible persons.
In the studio: switching developers between a large number of different tasks. The
human brain is poorly adapted to multitasking. While we are switching from project to project, we are losing the context of the task. It takes 15 minutes to half an hour to restore the context. This is a net loss.
Consider, if you pulled a person - that you leaked 15 minutes. Multiply by your rate, subtract from your salary. If it is greedy - do not pull. If it’s not a pity, and the question is worth it - you can pull.
By the way, if your programmer is able to switch context quickly, it means that manager’s inclinations are strong in him.
What to do: do not pull people
In the studio: Fucking routine.
There is always a choice: to put on the project the person who made 100500 similar projects, or to put the one who has not figured out such a topic. By loading developers with a routine and preventing them from acting independently, you increase the burden on your HR. The choice is yours to invest in training or invest in HR.
What to do: try to set tasks from time to time to the limit of the ability of programmers. It is not necessary to do this all the time, but sometimes a challenge task should appear for any employee.
This short note is for those who are systematically looking for where his studio is losing money. A commendable lesson in our fun time.
Well systematized types of losses guys from Toyota. Toyotovtsy allocate 7-8 types of muda, losses in production. Let's see if there are analogues between the losses in the automotive industry and the work of the studio.
Muda No. 1. Losses due to excess stocks
In the studio: All unfinished or unfinished work.
- Undelivered design.
- Untrusted layout.
- Untested code.
- Unprogrammed requirements.
- Unshaded code.
The more unfinished work in your company, the more you have receivables. The more you risk being burned out.
Again, if you look from the point of view of the customer: unfinished work does not bring any benefit. He doesn’t need her.
What to do: By hook or by crook, try to reduce the amount of work that was not delivered at the same time. It is better to bring one project to the end and then proceed to the next than to take on 4-5 and do them in parallel.
Muda No. 2. Losses during unnecessary transportation
In the studio: Re-discussion of the same issue on which a decision has already been made (Relearning).
For example, you came to the conclusion that it would be nice to use some kind of version control system in the studio. We carefully studied the issue. Gathered, discussed the pros and cons. They praised what is better - GIT or SVN. Really fully understood the issue. And as a standard we decided to host svn. Implemented as standard. Learned. Started to use.
And six months later, some wise guy says: “Guys! And why do we use SVN and not GIT? SVN is shit, because <argument>, and GIT is cool because <another argument>. " In fact, after half a year no one remembers whether these arguments were already considered (and you came to the conclusion that they were insufficient), or you skipped these arguments during the discussion. I have to study the question again. Wasting time instead of making money.
What to do: Fix not only decisions, but also the context and argumentation of the decisions made. Charts work well here ( Root Cause analysis , Mind Map, A3 analysis ). Find a balance between reviewing your development processes / tools and complying with accepted standards.
Muda No. 3. Losses due to overproduction
In the studio: Unnecessary functionality.
So it’s fun to get a couple of chips, easter eggs for a client or polish photos on some page of the 5th level, which no one will ever go to or optimize the Our Guide page for a download speed of 0.005 sec.
The general idea: to make functions that no one will use (and which your client will not earn) is a loss. An example leader is MS Excel: 95% of users constantly use only 5% of functions. What the rest?
What to do: critically evaluate what you are doing in terms of benefits. Mark and eliminate work that does not benefit your customers and yourself.
Muda No. 4. Loss of time due to waiting
In the studio: Delaying approvals.
- Waiting for agreement with the customer;
- Internal approvals;
- Useless meetings, discussions and face-to-face meetings;
Such a very actual loss is expectations. While the customer agrees the layout at 3 levels. While approving the texts. While the lawyer deigns to send edits to the contractor.
Especially a lot of resources flies to personal meetings on trifling issues. Often, in order to cover up the ass and not make decisions - as many people as possible are invited to meetings on any issue. Moving bodies around Moscow to meetings to discuss “what size letters will be” is an extremely expensive pleasure, but few people really think how much it costs to collect and hold one such meeting (hint: usually several tens of thousands of rubles). Agreements are not fixed, discussions fly away into the void.
What to do:reduce the number of people involved in the project to a minimum. Make decisions as quickly as possible. Reduce the number of meetings and personal meetings. If we already have a meeting, we must have a clear schedule, record and clearly observe the agreements.
Muda No. 5. Losses due to the release of defective products
In the studio: Bugs.
What is important to know about bugs: the later a defect is found, the more expensive it is. If you, say, a programmer, find and fix the bug yourself and immediately, it is cheap. But if the client finds him, then this is already fraught. Especially when a bug was found two years later, it destroyed the client’s database, and the programmer who wrote the code went on vacation in another city and died.
What to do: testing as early as possible. On large projects - automatic tests . Clear coding standards. Regular code review practices. Tutors for beginners.
Muda No. 6. Losses due to unnecessary movements
In the studio: Project Transfer Loss.
Transmission loss:
- Responsibility.
- Of knowledge.
- Projects.
- Action.
- Applications.
How many intermediate links between how the client’s idea gets from his head to the person who will specifically do it? It is possible that the client first tells his story to the account manager, then to the project manager, then the project manager tells all the introductory analytics, then the analytics is passed to the designer.
Each time a project is transferred, there is a loss of time and information: verbal and non-verbal. Loss of information in the end lead to errors, alterations, and again - a waste of time. Particularly sensitive are losses when transferring projects from one project manager to another, or when changing a programmer in a project. And the most difficult case is the change of the responsible person on the client side.
An important subtlety: when a project is studied and analyzed for the first time, it is of value to the client. Losses will only be repeated grinding of the same information.
What to do: minimize the number of people involved in the project to the required minimum. Exclude the transfer of projects between teams and responsible persons.
Muda No. 7. Losses due to unnecessary processing steps
In the studio: switching developers between a large number of different tasks. The
human brain is poorly adapted to multitasking. While we are switching from project to project, we are losing the context of the task. It takes 15 minutes to half an hour to restore the context. This is a net loss.
Consider, if you pulled a person - that you leaked 15 minutes. Multiply by your rate, subtract from your salary. If it is greedy - do not pull. If it’s not a pity, and the question is worth it - you can pull.
By the way, if your programmer is able to switch context quickly, it means that manager’s inclinations are strong in him.
What to do: do not pull people
Muda number 8. Unrealized creative potential of employees
In the studio: Fucking routine.
There is always a choice: to put on the project the person who made 100500 similar projects, or to put the one who has not figured out such a topic. By loading developers with a routine and preventing them from acting independently, you increase the burden on your HR. The choice is yours to invest in training or invest in HR.
What to do: try to set tasks from time to time to the limit of the ability of programmers. It is not necessary to do this all the time, but sometimes a challenge task should appear for any employee.