Is production running a company or a company producing?
We want to share with the community information, how we figured out who controls whom (manager vs programmer) and how we changed the management strategy of the developers.
One of the goals was to get rid of what is in the picture:
')
Our story began like everyone else:
First, oral instructions to employees: do this, do this, why did you forget? Well, of course, that does not work.
Then came the task manager. First BugZilla, then Mantis, then an attempt to switch to JIRA, then Redmine (here we have to admit we are stuck for 6 years), and then we went to our OneBox . But, these are only task managers, they do not set the strategy for the priority of task selection and performance indicators.
What happens when you have a task manager? The manager (for example, the Project manager) assigns tasks and distributes them among the developers. But there are two BUT:
The question arises: does anyone even control the process?
If we add to this all the hourly payment of developers for the time spent, then this is hell:
The second question arises: who controls whom? Is the programmer or programmer everyone?
This scheme we had 5 years. And instead of recognizing the curvature of this scheme, we first invented a crutch for it “let's ask the developers for an estimate of time”. This cool idea led to:
Therefore, the developers quickly cut through what is necessary to overestimate estimate a couple of times and do it as quickly as possible (quality suffers): I called 20, and now I’ll do it in 10, and even better in 5. Wow, what a fine fellow I am.
In total, it took us more than 6 years to recognize that things would not go on like this. To recognize that the developers (and they are essentially the production) manages the company, not the company production.
Paying for hours, freedom to choose a task by developers are all uncontrollable processes, and all attempts to control them are reduced to inventing crutches on crutches.
And we radically changed the scheme:
It became better, much better. We didn’t ask “what developer X is doing now”, because we knew what his task was in the plan now under priority No. 1. Developers did not bother deadlines.
Later we learned how to predict how many, on average, a specific developer does tasks per day, so we could calculate approximately when what task would be completed. We learned how to make plans for the day, right on the calendar. Simple mechanism. Later, our CRM-system was taught to automatically distribute and group similar tasks in our product so that it would not be necessary to jump “project A, then project B, then again A.”
Here is the weekly developer calendar. The developer just needs to follow the plan.
At first, it seems strange to require the implementation of a plan from the developer.
But on the other hand, if you are not working on R & D tasks, then your developers are production. The plant is also a production. Where did you see the factory manager approach the master on the machine and say “how many blanks do you do today?”. Production has a plan, you have to do so much per day.
The developers, too, just need to find the right indicators and put the correct and realistic plans.
And yet, we generally removed the priorities of the tasks. All tasks have one priority. Priority is now the order of tasks.
And then before (Redmine) was something like this:
But even this scheme got its sides in 6 months.
Example: a project consists of 120 tasks that need to be done. We have learned to predict when all 120 tasks will be ready. Managers have a deadline. But the developer suddenly does 118 tasks and doesn’t put on just 2 tasks in time, and it’s impossible to force him to “kick”. And “kick” is a violation of our rules, so that developers do not think about deadlines.
In reality, the developer does not put pressure on these 2 tasks, because he understands that he has done a lot of things, and he thinks that “well, two more tasks on the RFP will not have much influence”.
The scheme was fixed as follows: salary segmentation was done, and not linear.
For N completed tasks - X USD.
For 1.5N tasks - 2X USD
For 2N tasks - 3X USD
etc.
This scheme motivates to do more and more.
And her sides got on: developers do as many tasks as possible, and forget about the quality. A bug is also a task, so if I make a bug, and then they find it and I fix it, I will have a +1 task.
Immediately there was the thought “not to pay for the bugs and not to count the bugs”, but this is the wrong way:
And we introduced the second KPI - quality .
Quality is the ratio of the number of completed tasks per month to the number of found bugs for this month.
For example, the developer made 100 tasks, and testers found 15 bugs - it means the percentage of the developer’s buggy = 15%.
And developers KPI - the percentage of bugs must be less than 15%, otherwise it is impossible to jump above the first bar of the RFP. In other words, always junior.
And at that moment it became at first bad (because 3 developers quit), and then just fine, because the bugs stopped appearing. One has only to start to monitor some indicator - and he immediately begins to change and adapt.
After 2 months, we stopped counting quality, because the percentage of bugs was less than 10% for all developers. All set up.
We guess that this is not the limit, something will break, and after a while it will again have to do the following scheme.
Be sure to share information.
Our company has existed since 2006 and we started off like everyone else, just like a regular web studio. When it all started, we still did not know anything about personnel management, we did not know anything about hiring and delegation of functional duties and responsibilities. Now we are obsessed with the efficiency of employees and the automation of all processes. We have 40 employees, we can train +20 developers in 4 weeks, but more on that in the next article.
One of the goals was to get rid of what is in the picture:
')
Our story began like everyone else:
First, oral instructions to employees: do this, do this, why did you forget? Well, of course, that does not work.
Task Manager
Then came the task manager. First BugZilla, then Mantis, then an attempt to switch to JIRA, then Redmine (here we have to admit we are stuck for 6 years), and then we went to our OneBox . But, these are only task managers, they do not set the strategy for the priority of task selection and performance indicators.
What happens when you have a task manager? The manager (for example, the Project manager) assigns tasks and distributes them among the developers. But there are two BUT:
- the developer himself decides what task to do now. And, as a rule, chooses the "most interesting".
- the manager does not know what is being done until he explicitly asks about it.
- the manager and developer do not know when it will be done.
The question arises: does anyone even control the process?
Hourly payment
If we add to this all the hourly payment of developers for the time spent, then this is hell:
- What prevents the developer from stretching the time? In fact, the task is for 30 minutes, does he do it for 60 minutes?
- what prevents to accelerate?
- then the manager cannot sell because it comes out “expensive”
- In general, this scheme obviously or not explicitly motivates developers to do for a long time, just to work the clock, and the result is not important.
- and constantly a bunch of tasks that need to be done "suddenly."
The second question arises: who controls whom? Is the programmer or programmer everyone?
Estimate crutch
This scheme we had 5 years. And instead of recognizing the curvature of this scheme, we first invented a crutch for it “let's ask the developers for an estimate of time”. This cool idea led to:
The manager gives the task, asks her to evaluate.
The developer says estimate and in most cases the developer “hit.” If he guessed estimate (which as we know never happens), then he is good. If he did not have time - the developer will get angry, he will try to do it as quickly as possible (and not qualitatively), because I called estimate 10 hours, and I have been doing the task for the 12th hour, and they will pay for 10.
Therefore, the developers quickly cut through what is necessary to overestimate estimate a couple of times and do it as quickly as possible (quality suffers): I called 20, and now I’ll do it in 10, and even better in 5. Wow, what a fine fellow I am.
First production management
In total, it took us more than 6 years to recognize that things would not go on like this. To recognize that the developers (and they are essentially the production) manages the company, not the company production.
Paying for hours, freedom to choose a task by developers are all uncontrollable processes, and all attempts to control them are reduced to inventing crutches on crutches.
And we radically changed the scheme:
- the developer does not choose what task to do. The order of tasks is assigned by the head of department through our CRM system.
- All tasks are set so that they are not more than 2 hours. That is, everything is split up into the smallest of the first level tasks that answer the simple question “what needs to be done”.
- KPI developers - do as many tasks per month as possible. Salary is charged for the tasks performed.
It became better, much better. We didn’t ask “what developer X is doing now”, because we knew what his task was in the plan now under priority No. 1. Developers did not bother deadlines.
Later we learned how to predict how many, on average, a specific developer does tasks per day, so we could calculate approximately when what task would be completed. We learned how to make plans for the day, right on the calendar. Simple mechanism. Later, our CRM-system was taught to automatically distribute and group similar tasks in our product so that it would not be necessary to jump “project A, then project B, then again A.”
Here is the weekly developer calendar. The developer just needs to follow the plan.
At first, it seems strange to require the implementation of a plan from the developer.
But on the other hand, if you are not working on R & D tasks, then your developers are production. The plant is also a production. Where did you see the factory manager approach the master on the machine and say “how many blanks do you do today?”. Production has a plan, you have to do so much per day.
The developers, too, just need to find the right indicators and put the correct and realistic plans.
And yet, we generally removed the priorities of the tasks. All tasks have one priority. Priority is now the order of tasks.
And then before (Redmine) was something like this:
Wage segmentation
But even this scheme got its sides in 6 months.
Example: a project consists of 120 tasks that need to be done. We have learned to predict when all 120 tasks will be ready. Managers have a deadline. But the developer suddenly does 118 tasks and doesn’t put on just 2 tasks in time, and it’s impossible to force him to “kick”. And “kick” is a violation of our rules, so that developers do not think about deadlines.
In reality, the developer does not put pressure on these 2 tasks, because he understands that he has done a lot of things, and he thinks that “well, two more tasks on the RFP will not have much influence”.
The scheme was fixed as follows: salary segmentation was done, and not linear.
For N completed tasks - X USD.
For 1.5N tasks - 2X USD
For 2N tasks - 3X USD
etc.
This scheme motivates to do more and more.
Quality
And her sides got on: developers do as many tasks as possible, and forget about the quality. A bug is also a task, so if I make a bug, and then they find it and I fix it, I will have a +1 task.
Immediately there was the thought “not to pay for the bugs and not to count the bugs”, but this is the wrong way:
- When we say that a bug fix is ​​counted, the subconscious thinks that “bugs are good.”
- When we say that fixing bugs is not counted - the subconscious thinks that “bugs are the norm”.
- Therefore, we had to say “bugs are bad and cannot be done”.
And we introduced the second KPI - quality .
Quality is the ratio of the number of completed tasks per month to the number of found bugs for this month.
For example, the developer made 100 tasks, and testers found 15 bugs - it means the percentage of the developer’s buggy = 15%.
And developers KPI - the percentage of bugs must be less than 15%, otherwise it is impossible to jump above the first bar of the RFP. In other words, always junior.
And at that moment it became at first bad (because 3 developers quit), and then just fine, because the bugs stopped appearing. One has only to start to monitor some indicator - and he immediately begins to change and adapt.
After 2 months, we stopped counting quality, because the percentage of bugs was less than 10% for all developers. All set up.
What did we get after these introductions?
- we stopped kicking the developers "do it, then do it"
- no one can change priorities just like that, only team lead has access to the calendars of their employees
- we have learned how to predict the time to complete tasks without asking questions “how much do you do it”
- really changing the order of tasks - we manage production
- we don’t have any priorities at all as in most business managers
- well, and when developers make a product whose tasks are in the same product, it blows the roof :)
What's next?
We guess that this is not the limit, something will break, and after a while it will again have to do the following scheme.
Be sure to share information.
Our company has existed since 2006 and we started off like everyone else, just like a regular web studio. When it all started, we still did not know anything about personnel management, we did not know anything about hiring and delegation of functional duties and responsibilities. Now we are obsessed with the efficiency of employees and the automation of all processes. We have 40 employees, we can train +20 developers in 4 weeks, but more on that in the next article.
Source: https://habr.com/ru/post/291308/
All Articles