Let's talk about metrics as a way to evaluate a programmer’s work.
Metrics - they are like markers, each to their own taste. Without metrics, the existence of a profitable business as such is impossible, they surround us all the time, this is unpleasant, but an axiom. For some, the metric is a sales plan for the month, for someone it is the fulfillment of an order before the agreed deadline, and the other is the number of hours worked.
There is no suitable “Picture To Draw Attention” on this topic, so keep the cat
For some reason, the word “metrics” in the IT sphere is closely associated with such “excellent” in its stupidity practices such as counting written lines of code or closed tasks. It is safe to say that these are the most useless and toothless control tools in the management plan. In fact, adequate metrics are quite conditional, but still, only two types: metrics for the project and / or works, the result and time of execution of which are clear and predicted in time, and vice versa, metrics for the project and / or works, the result and the execution time of which is physically impossible to predict. For the first type, metrics of the result are set, and for the second type, distances, that is, the hours worked.
There is no universal recipe for setting metrics for any employee - this is always a situational phenomenon. Employee metrics are always formed from one simple answer to the following question: can we clearly predict the final result and, as a result, the time of work at a small or medium distance?
')
Let's take a look at freelancing. Most often, customers build relationships with performers on the basis of payment for the amount of work done. That is, there is a budget for the project, and under this budget, the redline and the deadline for its delivery are agreed during the negotiations. This is how designers, web designers, a number of developers work. Most often, the budget does not budge, that is, the moving part is “lead time”.
But it is always plus / minus predictable, that is, the customer clearly understands how much "approximately" time will be spent on the execution of his order. Based on this figure, a budget is allocated, after which a suitable cost performer is sought.
In general, in the freelance environment, the principle “we do not care how much time you spend on order fulfillment is clearly preached, just do it well and in terms that are acceptable to us” Thus, a lot of questions are removed on controlling the work of a hired freelancer or temporary employee; There is a prepayment tranche, there is a closing of the final, pre-specified account.
A similar approach has leaked into small and medium-sized businesses, where people seem to be working, and into full time, but the company lives in a state of tough competition and short distances, when the result is needed in specific terms. With "crazy effort" you can draw just such a rough-rough flowchart, which guided when making a decision:
Perhaps this question was born to you, the reader, at the beginning of the article, but we have just arrived at the answer to it. More precisely, to the answers, because there are several.
First: the hiring company is used to control, because the hourly rate implies a tracker in 50% of cases, and in 100% periodic reports with an audit of the work performed. That is, the customer shifts a part of managerial functions to the executor himself, who reports for himself.
Second, the company needs control over the development process, because it has only one attempt. If the project is stretched for more than a few weeks, the customer needs to understand the “light” of the work. Most often, for such massive orders, the budget is allocated once and there is only one attempt. In fact, there were once companies on the market that did not require such periodic and sometimes tough reporting from performers on large projects, but the same thing happened to them as with elephants with small ears - they became extinct (elephants from overheating, and companies - due to deadlines).
But everything becomes much, much more difficult if we start talking about a large project, the delivery dates of which vary in the range “from one to three” and to “this is an eternal development.” In the case of “eternal development” it is almost impossible to predict the time of the final result. the following reasons:
Under such conditions, it is easy to get lost and to hang around famous pears with a famous object. But since the business is not engaged in charity, we have to move from metrics "by result" to a more complex category of metrics "by time".
The simplest and most logical example of working “on time” is the usual office full time in companies of 30-50 people in the development department. Under these conditions, the “ashore” business agrees with a potential employee, that is, at the interview stage, not about the time of the project, but about the cost of an hour of work based on the 40-hour work week according to the TC. For us, it looks just like wages.
At the same time, it must be clearly understood that business is not fools. The size of the RFP (more precisely, in its reduction) includes personal crises, reels around the office, smoke breaks, an extra 20-30 minutes for lunch (that is, an hour and a half, instead of an hour) and just procrastination on YouTube. Some companies can afford these costs because the business is currently profitable and it can afford the “easy” version of control through the simple setting of short-term tasks with blurred deadlines, which are engaged in junior and middle management.
But if the business is low-margin or exists in a competitive legacy environment, then everything gets worse. And here begins shaped hell, for which developers do not like the word "metrics".
If a person is paid not for the result, but for the amount of time worked, then how to evaluate its effectiveness? This question is constantly asked business. There are several variables here:
In fact, a business is faced with a situation when it has moved, it seems, to a more than understandable “time buying” mechanism, but it is still necessary to control whether something was received for the payment of this time in return in the form of labor results. That is, our concept of “buying result” becomes a nested variable in the concept of “buying time”.
Most often it happens that management is not able to clearly trace the needs of business and workers at the same time, that is, to build a system and a policy of applying metrics in which both parties would be satisfied with what is happening. What is meant: metrics must simultaneously fulfill the interests of the business and be understandable and feasible by employees.
Here we are faced with another problem: if, when working “to order” at short distances, the task is often clear and understandable to all parties, then when developing a large product, the whole structure is in constant motion. Trite: competitors released a new product or a new toolbox appeared and all plans that were lovingly created by the management went to pieces.
At this point, a lot depends on management. Here you can simply describe inadequate and adequate approaches to setting metrics.
Inadequate metrics:
Here I described a typical “galley” when a developer turns from a person into a “code writing machine” and nobody cares how he handles short-term tasks / metrics that he descends from above. In this case, the developer loses any opportunity to influence the development, even if he sees "from the inside" problems. In this case, the complexity of the tasks is not taken into account and it all comes down to the monkey-job.
Adequate metrics:
Adequate metrics are those metrics that are not nailed to the floor and that can be moved. If a business is committed to maximum efficiency, then this efficiency should be at all levels. It has long been understood that the number of tasks or lines of code, in fact, does not mean very much, as some tasks can have a decisive impact on the product and cost hundreds of others.
In addition, the hard link to metric compliance is counter-productive: if a developer knows that he will have “problems” due to the fact that he closed 19 tasks for the week instead of 20, then the quality of the task goes into the background. And at least the last, 20 task, will be placed on the “back off”, with crutches and bicycles instead of truly solving the task once and for all.
In fact, a well-built development model, tied to the time of work, is much more complicated than it might seem at first glance. To work effectively on this model, qualitative feedback should be organized between the performers and the leaders, who must constantly adjust the "party policy" at all levels. After all, an inadequately set task, that is, a formulated metric is a problem far from being a developer, although we have decided to push this problem to the performers. An inadequately formulated metric is a problem, just the management who set this task for the performers, provided that the work of both parties is transparent.
It is the management that needs to organize the work in such a way that the time spent working efficiently, that is, the budgets are not “burned”, but at the same time the developers could cope with the tasks assigned to them without a total burnout in a few weeks. Because the human resource, though extensive, is not infinite, especially when it comes to qualified personnel.
It is the presence of feedback and responsibility for decisions made by the management that differs from the company, which keeps a detailed record of the hours worked, from the obvious “galleys”, where the developers fall into a meaningless meat grinder.
It is the feedback that allows businesses to find bottlenecks in the design. How often did you encounter a situation when employees of a department choked while working for wear, but did not receive “reinforcements” in the form of a pair of new specialists who would give a shoulder and take part of the workload on themselves? Such situations arise quite often due to the lack of high-quality feedback between development and management. Instead of accurately tracking the efficiency of the team and its workload, the manager picks his nose with his finger, and when someone “breaks down” without sustaining such a rhythm, he puts everything on the remaining developers. Do not do it this way.
The worst thing that can happen in the process of organizing a workflow is “distorting” the mechanisms inherent in one model to another. For example, when long-term projects are set to tight deadlines without a sound assessment of the complexity and capabilities of the team. Or when short-term self-sufficient projects and tasks are supplemented with such forms of control that can be used in the field of rocket production, but this is all about ordering freelancing.
A clear understanding of the relevance of certain methods of work in various companies in structure and size will help protect a huge chunk of health and nervous system when looking for work. And the more developers, managers and business owners understand these mechanisms - the better it will be for all participants in the IT segment.
There is no suitable “Picture To Draw Attention” on this topic, so keep the cat
For some reason, the word “metrics” in the IT sphere is closely associated with such “excellent” in its stupidity practices such as counting written lines of code or closed tasks. It is safe to say that these are the most useless and toothless control tools in the management plan. In fact, adequate metrics are quite conditional, but still, only two types: metrics for the project and / or works, the result and time of execution of which are clear and predicted in time, and vice versa, metrics for the project and / or works, the result and the execution time of which is physically impossible to predict. For the first type, metrics of the result are set, and for the second type, distances, that is, the hours worked.
The first type of metrics "by result"
There is no universal recipe for setting metrics for any employee - this is always a situational phenomenon. Employee metrics are always formed from one simple answer to the following question: can we clearly predict the final result and, as a result, the time of work at a small or medium distance?
')
Let's take a look at freelancing. Most often, customers build relationships with performers on the basis of payment for the amount of work done. That is, there is a budget for the project, and under this budget, the redline and the deadline for its delivery are agreed during the negotiations. This is how designers, web designers, a number of developers work. Most often, the budget does not budge, that is, the moving part is “lead time”.
But it is always plus / minus predictable, that is, the customer clearly understands how much "approximately" time will be spent on the execution of his order. Based on this figure, a budget is allocated, after which a suitable cost performer is sought.
In general, in the freelance environment, the principle “we do not care how much time you spend on order fulfillment is clearly preached, just do it well and in terms that are acceptable to us” Thus, a lot of questions are removed on controlling the work of a hired freelancer or temporary employee; There is a prepayment tranche, there is a closing of the final, pre-specified account.
A similar approach has leaked into small and medium-sized businesses, where people seem to be working, and into full time, but the company lives in a state of tough competition and short distances, when the result is needed in specific terms. With "crazy effort" you can draw just such a rough-rough flowchart, which guided when making a decision:
What about the hourly rates of UpWork and other freelancing models on time?
Perhaps this question was born to you, the reader, at the beginning of the article, but we have just arrived at the answer to it. More precisely, to the answers, because there are several.
First: the hiring company is used to control, because the hourly rate implies a tracker in 50% of cases, and in 100% periodic reports with an audit of the work performed. That is, the customer shifts a part of managerial functions to the executor himself, who reports for himself.
Second, the company needs control over the development process, because it has only one attempt. If the project is stretched for more than a few weeks, the customer needs to understand the “light” of the work. Most often, for such massive orders, the budget is allocated once and there is only one attempt. In fact, there were once companies on the market that did not require such periodic and sometimes tough reporting from performers on large projects, but the same thing happened to them as with elephants with small ears - they became extinct (elephants from overheating, and companies - due to deadlines).
The second type of metrics "in time"
But everything becomes much, much more difficult if we start talking about a large project, the delivery dates of which vary in the range “from one to three” and to “this is an eternal development.” In the case of “eternal development” it is almost impossible to predict the time of the final result. the following reasons:
- not a single person works on the project, but even several teams;
- each team "in directions" has from two to three, up to several dozen employees;
- when the work on the project is finished no one knows.
Under such conditions, it is easy to get lost and to hang around famous pears with a famous object. But since the business is not engaged in charity, we have to move from metrics "by result" to a more complex category of metrics "by time".
The simplest and most logical example of working “on time” is the usual office full time in companies of 30-50 people in the development department. Under these conditions, the “ashore” business agrees with a potential employee, that is, at the interview stage, not about the time of the project, but about the cost of an hour of work based on the 40-hour work week according to the TC. For us, it looks just like wages.
At the same time, it must be clearly understood that business is not fools. The size of the RFP (more precisely, in its reduction) includes personal crises, reels around the office, smoke breaks, an extra 20-30 minutes for lunch (that is, an hour and a half, instead of an hour) and just procrastination on YouTube. Some companies can afford these costs because the business is currently profitable and it can afford the “easy” version of control through the simple setting of short-term tasks with blurred deadlines, which are engaged in junior and middle management.
But if the business is low-margin or exists in a competitive legacy environment, then everything gets worse. And here begins shaped hell, for which developers do not like the word "metrics".
The real hard peg to the time worked is not an independent metric of efficiency, you need crutches
If a person is paid not for the result, but for the amount of time worked, then how to evaluate its effectiveness? This question is constantly asked business. There are several variables here:
- Binding team performance to the metric "result" at a short distance.
- Use of smaller metrics at the level of tasks and sprints.
- Building a clear structure of responsibility, deadlines and priorities, call it what you want, for example, “development policy”.
In fact, a business is faced with a situation when it has moved, it seems, to a more than understandable “time buying” mechanism, but it is still necessary to control whether something was received for the payment of this time in return in the form of labor results. That is, our concept of “buying result” becomes a nested variable in the concept of “buying time”.
Most often it happens that management is not able to clearly trace the needs of business and workers at the same time, that is, to build a system and a policy of applying metrics in which both parties would be satisfied with what is happening. What is meant: metrics must simultaneously fulfill the interests of the business and be understandable and feasible by employees.
Here we are faced with another problem: if, when working “to order” at short distances, the task is often clear and understandable to all parties, then when developing a large product, the whole structure is in constant motion. Trite: competitors released a new product or a new toolbox appeared and all plans that were lovingly created by the management went to pieces.
At this point, a lot depends on management. Here you can simply describe inadequate and adequate approaches to setting metrics.
Inadequate metrics:
- number of lines of code and commits;
- the number of closed tasks without taking into account the complexity;
- deprivation of the developer's right to vote;
- ignoring the dynamics and needs of development during the reporting period (metrics are above common sense);
- a long process of revising metrics, lack of flexibility, ignoring the views of the development.
Here I described a typical “galley” when a developer turns from a person into a “code writing machine” and nobody cares how he handles short-term tasks / metrics that he descends from above. In this case, the developer loses any opportunity to influence the development, even if he sees "from the inside" problems. In this case, the complexity of the tasks is not taken into account and it all comes down to the monkey-job.
Adequate metrics:
- Considering the complexity of the task;
- The possibility of revising the metrics after the fact if problems arise;
- Ability to comment on the task;
- The absence of a hard peg to quantitative indicators of lines of code / number of tasks;
- Ignoring partial noncompliance with metrics, if necessary.
Adequate metrics are those metrics that are not nailed to the floor and that can be moved. If a business is committed to maximum efficiency, then this efficiency should be at all levels. It has long been understood that the number of tasks or lines of code, in fact, does not mean very much, as some tasks can have a decisive impact on the product and cost hundreds of others.
In addition, the hard link to metric compliance is counter-productive: if a developer knows that he will have “problems” due to the fact that he closed 19 tasks for the week instead of 20, then the quality of the task goes into the background. And at least the last, 20 task, will be placed on the “back off”, with crutches and bicycles instead of truly solving the task once and for all.
Feedback as an integral part of the “time buying” model
In fact, a well-built development model, tied to the time of work, is much more complicated than it might seem at first glance. To work effectively on this model, qualitative feedback should be organized between the performers and the leaders, who must constantly adjust the "party policy" at all levels. After all, an inadequately set task, that is, a formulated metric is a problem far from being a developer, although we have decided to push this problem to the performers. An inadequately formulated metric is a problem, just the management who set this task for the performers, provided that the work of both parties is transparent.
It is the management that needs to organize the work in such a way that the time spent working efficiently, that is, the budgets are not “burned”, but at the same time the developers could cope with the tasks assigned to them without a total burnout in a few weeks. Because the human resource, though extensive, is not infinite, especially when it comes to qualified personnel.
It is the presence of feedback and responsibility for decisions made by the management that differs from the company, which keeps a detailed record of the hours worked, from the obvious “galleys”, where the developers fall into a meaningless meat grinder.
It is the feedback that allows businesses to find bottlenecks in the design. How often did you encounter a situation when employees of a department choked while working for wear, but did not receive “reinforcements” in the form of a pair of new specialists who would give a shoulder and take part of the workload on themselves? Such situations arise quite often due to the lack of high-quality feedback between development and management. Instead of accurately tracking the efficiency of the team and its workload, the manager picks his nose with his finger, and when someone “breaks down” without sustaining such a rhythm, he puts everything on the remaining developers. Do not do it this way.
Instead of output
The worst thing that can happen in the process of organizing a workflow is “distorting” the mechanisms inherent in one model to another. For example, when long-term projects are set to tight deadlines without a sound assessment of the complexity and capabilities of the team. Or when short-term self-sufficient projects and tasks are supplemented with such forms of control that can be used in the field of rocket production, but this is all about ordering freelancing.
A clear understanding of the relevance of certain methods of work in various companies in structure and size will help protect a huge chunk of health and nervous system when looking for work. And the more developers, managers and business owners understand these mechanisms - the better it will be for all participants in the IT segment.
Source: https://habr.com/ru/post/432138/
All Articles