8 varieties 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. Commendable lesson in our fun time.
')
Well systematized the types of losses guys from Toyota. Toyootsev allocate 7-8 types of muda, production losses. Let's see if there are analogues between losses in the automotive industry and studio work.
In the studio: All unfinished or unworked work.
The more unfinished work in your company, the more receivables you have. The more you risk burning out.
Again, if you look from the point of view of the customer: unfinished work does not bring any benefit. She does not need him.
What to do: By hook or by crook, try to reduce the amount of undelivered, simultaneously performed work. It is better to bring one project to the end and then proceed to the next, than to take up 4-5 and do them in parallel.
In the studio: Repeated discussion of the same issue for which a decision has already been made (Relearning).
For example, you came to the conclusion that it would not be bad to use some version control system in the studio. Carefully studied the issue. Gathered, discussed the pros and cons. They deceived that it was better - GIT or SVN. Really completely understood the question. And as a standard, they decided to adopt svn. Implemented as standard. Trained. Began to use.
And six months later, some clever man says: “Guys! And why do we use SVN, and not GIT? SVN is a shit, because <argument>, and GIT is cool because <some other argument>. ” In fact, after half a year no one remembers whether these arguments were already considered (and together you came to the conclusion that they were insufficient), or you missed these arguments during the discussion. We have to study the issue again. Spending time instead of making money.
What to do: To fix not only decisions, but also context and reasoning on the decisions made. Charts work well here ( Root Cause analysis , Mind Map, A3 analysis ). Find a balance between revising your development processes / tools and adhering to accepted standards.
In the studio: Unnecessary functionality.
It is so cool to grind a couple of chips, easter eggs or polish photos on a page of the 5th level for which no one will ever enter or optimize the page “Our Guide” for a download speed of 0.005 sec.
The general idea: to make functions that no one will use (and on which your client will not earn) - this 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 jobs that do not benefit your customers and yourself.
In the studio: tightening approvals.
This is a very urgent loss - expectations. While the customer agrees the layout at 3 levels. While approving the texts. While a lawyer deigns to send edits to the contractor.
Especially a lot of resources flies to personal meetings on trivial matters. Often, in order to cover up the ass and not to make decisions - as many people as possible are invited to meetings on any issue. Moving bodies around Moscow to meetings to discuss "how big we will have letters" is an extremely expensive pleasure, but few really consider how much it costs to collect and hold one such meeting (hint: usually several tens of thousands of rubles). The agreements are not fixed, discussions fly 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. Even if we hold a meeting, we must have a clear regulation, fix and strictly observe the agreements.
In the studio: Bugs.
What is important to know about bugs: the later the defect is found, the more expensive it is. If you, say, a programmer, and find and fix the bug yourself and immediately - it is cheap. But if the client finds it, it is already fraught. Especially when a bug was found two years later, it destroyed the client database, and the programmer who wrote the code was on vacation in another city and died.
What to do: as early as possible testing. On large projects - automatic tests . Clear coding standards. Regular practice code review. Mentors for beginners.
In the studio: Loss of transmission project.
Transmission loss:
How many intermediate links between how the idea of the client 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 the project manager, then the project manager tells all the introductory analytics, then the analytics is passed on to the designer.
Each time a project is transmitted, there is a loss of time and information: verbal and non-verbal. Loss of information eventually lead to errors, alterations and, again, time-consuming. Losses are especially sensitive 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 the project is studied and analyzed for the first time - it has value for the client. Losses will only be repeated grind up 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 not well adapted to multitasking. While we are switching from project to project, we lose the context of the task. The restoration of the context takes from 15 minutes to half an hour. This is a net loss.
Consider, if you pulled a man - you leaked 15 minutes. Multiply by your rate, subtract from your salary. If it is greedy - do not jerk. If you do not mind and the question is worth it - you can pull.
By the way, if your programmer is able to switch context quickly - this means that the makings of a manager are strong in him.
What to do: do not tug people
In the studio: Fucking routine.
There is always a choice: to put on the project of the person who made 100,500 similar projects, or to put someone who has not figured out such a topic. By burdening developers with a routine and not allowing them to act independently, you increase the burden on your HR. Your choice is to invest resources in training or invest in HR.
What to do: try to set tasks from time to time to the limit of the abilities of programmers. It is not necessary to do this all the time, but sometimes the task-challenge must appear in any employee.
This short note is for those who are systematically looking for where his studio is losing money. Commendable lesson in our fun time.
')
Well systematized the types of losses guys from Toyota. Toyootsev allocate 7-8 types of muda, production losses. Let's see if there are analogues between losses in the automotive industry and studio work.
Muda No. 1. Losses due to excess stocks
In the studio: All unfinished or unworked work.
- Undelivered design.
- Untrusted layout.
- Untested code.
- Unprogrammed requirements.
- Undrusted code.
The more unfinished work in your company, the more receivables you have. The more you risk burning out.
Again, if you look from the point of view of the customer: unfinished work does not bring any benefit. She does not need him.
What to do: By hook or by crook, try to reduce the amount of undelivered, simultaneously performed work. It is better to bring one project to the end and then proceed to the next, than to take up 4-5 and do them in parallel.
Muda No. 2. Losses during unnecessary transportation
In the studio: Repeated discussion of the same issue for which a decision has already been made (Relearning).
For example, you came to the conclusion that it would not be bad to use some version control system in the studio. Carefully studied the issue. Gathered, discussed the pros and cons. They deceived that it was better - GIT or SVN. Really completely understood the question. And as a standard, they decided to adopt svn. Implemented as standard. Trained. Began to use.
And six months later, some clever man says: “Guys! And why do we use SVN, and not GIT? SVN is a shit, because <argument>, and GIT is cool because <some other argument>. ” In fact, after half a year no one remembers whether these arguments were already considered (and together you came to the conclusion that they were insufficient), or you missed these arguments during the discussion. We have to study the issue again. Spending time instead of making money.
What to do: To fix not only decisions, but also context and reasoning on the decisions made. Charts work well here ( Root Cause analysis , Mind Map, A3 analysis ). Find a balance between revising your development processes / tools and adhering to accepted standards.
Muda No. 3. Losses due to overproduction
In the studio: Unnecessary functionality.
It is so cool to grind a couple of chips, easter eggs or polish photos on a page of the 5th level for which no one will ever enter or optimize the page “Our Guide” for a download speed of 0.005 sec.
The general idea: to make functions that no one will use (and on which your client will not earn) - this 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 jobs that do not benefit your customers and yourself.
Muda No. 4. Time wasting due to waiting
In the studio: tightening approvals.
- Waiting for coordination with the customer;
- Internal approvals;
- Useless meetings, discussions and personal meetings;
This is a very urgent loss - expectations. While the customer agrees the layout at 3 levels. While approving the texts. While a lawyer deigns to send edits to the contractor.
Especially a lot of resources flies to personal meetings on trivial matters. Often, in order to cover up the ass and not to make decisions - as many people as possible are invited to meetings on any issue. Moving bodies around Moscow to meetings to discuss "how big we will have letters" is an extremely expensive pleasure, but few really consider how much it costs to collect and hold one such meeting (hint: usually several tens of thousands of rubles). The agreements are not fixed, discussions fly 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. Even if we hold a meeting, we must have a clear regulation, fix and strictly 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 the defect is found, the more expensive it is. If you, say, a programmer, and find and fix the bug yourself and immediately - it is cheap. But if the client finds it, it is already fraught. Especially when a bug was found two years later, it destroyed the client database, and the programmer who wrote the code was on vacation in another city and died.
What to do: as early as possible testing. On large projects - automatic tests . Clear coding standards. Regular practice code review. Mentors for beginners.
Muda No. 6. Losses due to unnecessary movements
In the studio: Loss of transmission project.
Transmission loss:
- Responsibility.
- Knowledge
- Projects.
- Action
- Applications
How many intermediate links between how the idea of the client 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 the project manager, then the project manager tells all the introductory analytics, then the analytics is passed on to the designer.
Each time a project is transmitted, there is a loss of time and information: verbal and non-verbal. Loss of information eventually lead to errors, alterations and, again, time-consuming. Losses are especially sensitive 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 the project is studied and analyzed for the first time - it has value for the client. Losses will only be repeated grind up 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 number 7. Losses due to unnecessary processing steps
In the studio: switching developers between a large number of different tasks
The human brain is not well adapted to multitasking. While we are switching from project to project, we lose the context of the task. The restoration of the context takes from 15 minutes to half an hour. This is a net loss.
Consider, if you pulled a man - you leaked 15 minutes. Multiply by your rate, subtract from your salary. If it is greedy - do not jerk. If you do not mind and the question is worth it - you can pull.
By the way, if your programmer is able to switch context quickly - this means that the makings of a manager are strong in him.
What to do: do not tug people
Muda number 8. Unrealized creative potential of employees
In the studio: Fucking routine.
There is always a choice: to put on the project of the person who made 100,500 similar projects, or to put someone who has not figured out such a topic. By burdening developers with a routine and not allowing them to act independently, you increase the burden on your HR. Your choice is to invest resources in training or invest in HR.
What to do: try to set tasks from time to time to the limit of the abilities of programmers. It is not necessary to do this all the time, but sometimes the task-challenge must appear in any employee.
What to read
Source: https://habr.com/ru/post/248441/
All Articles