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 tightly 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 of two types: metrics for the project and / or works, the result and the execution time of which are clear and predictable in time, and vice versa, the metrics for the project and / or works, the result and the time of execution 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 look at the situation in 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, and 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 cost-effective performer is sought.

    In general, in the freelance environment, the principle of "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, the need to pay him three, four, ten times the “salary” and so on is removed. There is a prepayment tranche, and there is a closing of the final, previously agreed 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 that guides when making a decision:

    And 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:

    • working on the project is not that one person, 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.

    In 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, it is necessary to move from metrics “by result” to a more complex category of metrics “by time”.

    The simplest and most logical example of work “on time” is the usual office full time in companies of 30-50 people in the development department. Under these conditions, a business “on the bank” 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 should be clearly understood that business is not fools. The size of the RFP (more precisely, in its reduction) includes personal crises, vacillation 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 that the junior and middle managers do.

    But if a business is low-margin or exists in a competitive legacy environment, then everything gets worse. And here begins shaped hell, for which the 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:

    1. Binding team performance to the metric of "result" at a short distance.
    2. Use of smaller metrics at the level of tasks and sprints.
    3. 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 mechanism of “buying time”, but it is still necessary to control whether something was received for paying 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 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 achievable 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 regard to 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 a 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 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, since some tasks can have a decisive impact on the product and cost hundreds of others.

    In addition, the strict binding to compliance with metrics 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 model of development, 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 by no means developers, 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 must organize the work in such a way that the work time is spent 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 skilled 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 didn’t 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 “juggling” 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 applied 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 terms of 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 will understand these mechanisms - the better it will be for all participants in the IT segment.

    Only registered users can participate in the survey. Sign in , please.

    What model of work do you personally prefer?

    Also popular now: