About saving money in the project
Once I came across a study of what price our competitors offer for the same services and work that we do. And these data were unpleasant: we were noticeably more expensive. To save orders and hold positions, we needed change.
Looking ahead, I will say that in the end we restructured our work. Moreover, not only lowering costs, but also raising salaries for programmers. How - read under the cut.
First decided to understand the structure of labor costs in the project. All work in the project was divided into separate blocks. Each block is known for its assessment, est, which is put down by the leading developer, and the time spent by the programmer spent. We determined the "programmer's speed" as a ratio (est sum) / (sum spent), and calculated this figure for one team on one project. It turned out the table:
Scatters on speeds are evident. Where does he come from? Maybe the error of the experiment? At first I thought that different developers get tasks of varying complexity. Therefore, I brought a table for one project - where the works were similar to each other. Also, the sample is given for one team, where all the programmers had the same access to information about the project, the same opportunities for communication and assistance from technil, etc. Just in case, similar tables were built for other projects and other teams, and were convinced : scatter is present there.
')
As I later became convinced, such a large scatter is not a trivial fact for non-programmers. To back up the evidence base before the conversation with the management, I decided to read what software experts say in this regard. In the book of S. Archipenkov I found a mention about the variation in performance. A. Orlov spoke in a similar way in the book Secrets of Managing Programmers .
And in the book by Joel Spolsky, he found some interesting data about a study by Stanley Aizenshtat, a professor at Yale University. For several years, students were asked to report how much time they spent on homework in programming. Here are some of the results:
The examples given above are sufficient to state that the variation in speeds observed in our projects is not a feature, and even more so an error, of conducting projects in our company. This is an objective feature of the profession of the programmer, which must be considered.
So back to our task: reducing costs in the management of projects. From my very first tablet it follows that the spread in speeds was sixfold. And the scatter of wages within this team (the ratio of the maximum rate to the minimum) was about 2. Thus, if we issue a job to programmer N, we will pay for it 3 times more than if we issue the same job to programmer # 1.
The conclusion suggests itself: the greater the proportion of strong programmers in the project, the cheaper it will be made. So, we need to hire new strong developers, to keep the experienced guys already working. Moreover, this does not mean a complete rejection of junior level employees: first, there are always simple tasks that someone needs to do, and secondly, a promising junior will eventually grow into the middle.
However, one thing is to make a table and draw conclusions for yourself. Another thing is to bring the idea to the leadership and convince him that he is right.
As I said at the very beginning of the article, the action took place against the background of competition and cost reduction (savings). Usually, in such a situation in the office, there is no talk about raising salaries - total savings begin (well, is it necessary to somehow lower the price?!).
So, the idea of ​​raising rates + about raising the salary rate in a vacancy about hiring looked, to say the least, unexpectedly.
Let's see how the work is paid for, say, a bricklayer at a construction site. His salary is often proportionally dependent on output: he worked 2 times faster, received 2 times more money. Similarly, the situation with, say, a minibus driver: driving faster, picked up more passengers per unit of time, collected more money. Fair and fair (albeit insecure).
This approach by default sits in the minds of many people, not just managers. Therefore, when a PM-neaytishnik sees that the middle salary is K% higher than that of a virgin - he thinks that the middle works about K% faster. It means that the system is linear: 2 people for $ 1000 = 1 person for 2000. And it’s completely unclear why the emphasis should be on “strong employees”. Moreover, there are certain “inconveniences” in working with them.
According to my observations, the higher the level of a programmer, the more requirements he places on the quality of the product he is working on. If the green novice is satisfied with the fact that he created a working code fragment that got into the product, then his more experienced colleagues ask themselves: why do we use this technology, but not another one? What really cool is implemented in the product? How are we better than competitors? In practice, this translates into the fact that the developer asks to include him in the project more interesting and expresses dissatisfaction if he gets chronically primitive work. Or he refuses to build the code “quickly out of crutches”, but demands time for a normal development.
Sometimes by mistake this behavior is classified as "star disease". And with such a formulation it is really better to work with beginners than with experienced progers.
In the end, the information was conveyed to the leadership, and the proposed reforms were carried out: we work practically only with strong programmers. As a result, we got the following:
And the matter is not only in monetary indicators - as the situation was clarified by middle managers and top managers, their attitude towards developers and the programmer's profession changed.
Looking ahead, I will say that in the end we restructured our work. Moreover, not only lowering costs, but also raising salaries for programmers. How - read under the cut.
Study
Internal analysis
First decided to understand the structure of labor costs in the project. All work in the project was divided into separate blocks. Each block is known for its assessment, est, which is put down by the leading developer, and the time spent by the programmer spent. We determined the "programmer's speed" as a ratio (est sum) / (sum spent), and calculated this figure for one team on one project. It turned out the table:
| Developer | "Speed" |
|---|---|
| one | 1.61 |
| 2 | 1.55 |
| ... | ... |
| N-1 | 0.31 |
| N | 0.26 |
Scatters on speeds are evident. Where does he come from? Maybe the error of the experiment? At first I thought that different developers get tasks of varying complexity. Therefore, I brought a table for one project - where the works were similar to each other. Also, the sample is given for one team, where all the programmers had the same access to information about the project, the same opportunities for communication and assistance from technil, etc. Just in case, similar tables were built for other projects and other teams, and were convinced : scatter is present there.
')
Data from external sources
As I later became convinced, such a large scatter is not a trivial fact for non-programmers. To back up the evidence base before the conversation with the management, I decided to read what software experts say in this regard. In the book of S. Archipenkov I found a mention about the variation in performance. A. Orlov spoke in a similar way in the book Secrets of Managing Programmers .
And in the book by Joel Spolsky, he found some interesting data about a study by Stanley Aizenshtat, a professor at Yale University. For several years, students were asked to report how much time they spent on homework in programming. Here are some of the results:
| Project | The average | Minimum | Maximum | Deviation |
|---|---|---|---|---|
| COMPRESS00 | 33.83 | 11.58 | 77.00 | 14.51 |
| COMPRESS99 | 27.47 | 6.67 | 69.50 | 13.62 |
| TEX00 | 21.22 | 6.00 | 75.00 | 12.11 |
The examples given above are sufficient to state that the variation in speeds observed in our projects is not a feature, and even more so an error, of conducting projects in our company. This is an objective feature of the profession of the programmer, which must be considered.
Recipe
So back to our task: reducing costs in the management of projects. From my very first tablet it follows that the spread in speeds was sixfold. And the scatter of wages within this team (the ratio of the maximum rate to the minimum) was about 2. Thus, if we issue a job to programmer N, we will pay for it 3 times more than if we issue the same job to programmer # 1.
The conclusion suggests itself: the greater the proportion of strong programmers in the project, the cheaper it will be made. So, we need to hire new strong developers, to keep the experienced guys already working. Moreover, this does not mean a complete rejection of junior level employees: first, there are always simple tasks that someone needs to do, and secondly, a promising junior will eventually grow into the middle.
However, one thing is to make a table and draw conclusions for yourself. Another thing is to bring the idea to the leadership and convince him that he is right.
Why is it difficult to convince management to work with more expensive programmers?
Psychological barrier
As I said at the very beginning of the article, the action took place against the background of competition and cost reduction (savings). Usually, in such a situation in the office, there is no talk about raising salaries - total savings begin (well, is it necessary to somehow lower the price?!).
So, the idea of ​​raising rates + about raising the salary rate in a vacancy about hiring looked, to say the least, unexpectedly.
A superficial look at the problem
Let's see how the work is paid for, say, a bricklayer at a construction site. His salary is often proportionally dependent on output: he worked 2 times faster, received 2 times more money. Similarly, the situation with, say, a minibus driver: driving faster, picked up more passengers per unit of time, collected more money. Fair and fair (albeit insecure).
This approach by default sits in the minds of many people, not just managers. Therefore, when a PM-neaytishnik sees that the middle salary is K% higher than that of a virgin - he thinks that the middle works about K% faster. It means that the system is linear: 2 people for $ 1000 = 1 person for 2000. And it’s completely unclear why the emphasis should be on “strong employees”. Moreover, there are certain “inconveniences” in working with them.
"Star fever"
According to my observations, the higher the level of a programmer, the more requirements he places on the quality of the product he is working on. If the green novice is satisfied with the fact that he created a working code fragment that got into the product, then his more experienced colleagues ask themselves: why do we use this technology, but not another one? What really cool is implemented in the product? How are we better than competitors? In practice, this translates into the fact that the developer asks to include him in the project more interesting and expresses dissatisfaction if he gets chronically primitive work. Or he refuses to build the code “quickly out of crutches”, but demands time for a normal development.
Sometimes by mistake this behavior is classified as "star disease". And with such a formulation it is really better to work with beginners than with experienced progers.
What was the result?
In the end, the information was conveyed to the leadership, and the proposed reforms were carried out: we work practically only with strong programmers. As a result, we got the following:
- the average salary of strong programmers in a team has grown by more than 50%;
- average costs per block of work decreased by 50%.
And the matter is not only in monetary indicators - as the situation was clarified by middle managers and top managers, their attitude towards developers and the programmer's profession changed.
Source: https://habr.com/ru/post/107866/
All Articles