May 4, 2019 at 14:07How to squeeze time?
The traditional way to measure tasks in our industry is the watch. Let's calculate how many metrics in the clock we use.
The first, most important hours are those that we put on the client. Depending on the situation, we either agree on the clock in advance, or set the fact - how much the programmer spent.
The second hours are those that the programmer called, answering the question “how much time do you need to solve the problem?”. If we agree with the client in advance, then these watches are put up for sale. If payment is made after the fact, then we ask the programmer for evaluation for planning purposes.
The third hours - how much the programmer spent on solving the problem in fact. This watch coincides extremely rarely with the planned number, which he himself called, and this is normal - no one knows how to plan his time precisely, because a lot of forces from the environment act on the work of the programmer - he is distracted, he is not in the mood, he is faced with unforeseen difficulties, etc.
There are also the fourth hours - when we set the client an amount different from the one previously agreed upon. Of course, if the conditions of our cooperation allow us to do so.
And now attention, the question is: where can you work on efficiency? Or in another way: the effectiveness of what we will increase?
One can answer vaguely: the efficiency of the programmer. Well, how, and what will we measure? In our presence, I remind you, three or four kinds of watches.
Try telling the programmer: we want you to produce more hours. What will he answer? The programmer is an intelligent guy, he studied at the institute, and he immediately remembers the fifth metric - the number of hours in a day. And boldly tell you about it - I can’t work more than 24 hours a day, fear God.
He will also remember the theory of relativity. Even if it’s not in details, it’s definitely mentioning the impossibility of compressing time — are we not moving at speeds close to light?
If the watch does not shrink, then how to increase efficiency? How can you talk about it at all? How can you even count it? How many hours per hour did the programmer spend? Spend half an hour on an hour of work? How to make a formula? Without a formula, you won’t make any calculations, and you won’t set a goal.
Let's go on the other side. Imagine not a programmer, but a factory worker. Here he is, poor fellow, a whole shift at the machine and produces parts. How is his work planned? Suppose a hundred parts per shift. The change lasts eight hours, it turns out 4.8 minutes for one part.
Now imagine: we, with our approaches to measuring work, have come to lead this worker. We no longer tell him “do 100 parts”, we love to measure in hours, so the new work plan will sound like “do 8 hours per shift”.
He, of course, at first will consider us idiots. He asks - but how many details should be done? It doesn’t matter, we will answer. The main thing is the watch. We understand that there are variations, you go there for a smoke, chat with friends, but we imagine the average bill - 4.8 minutes per detail. Therefore, do us 100 times for 4.8 minutes of your work.
At first, of course, he will try to follow the old plan, but when he sees his calculation, his life values will change - it will say "so much has been calculated in 20 shifts of 8 hours." What is the point to him now in general to do the details, if only time spent at the machine is paid?
If by that time they had not yet driven us out of the factory, then we will change the sales system. We will not sell parts to customers - the invoices will show the hours spent by our workers. The client asks for 100 parts, we leave to think, then we send an invoice - 8 hours of specialist work. The client is surprised, but agrees, and pays the bill. And after a couple of days he gets another “increase” - a couple of hours. Well, what happened. The worker could not keep within 8 hours.
Customers are starting to resent - what the hell, what kind of watch? We need the details! In pieces, boxes, pallets, wagons - it does not matter. It makes no difference to us how many hours are needed to produce them!
Here, I think, they will definitely kick us out. Return accounting in pieces - both internal and external, for customers. And will be engaged in efficiency.
Where is the efficiency here, what is its formula? The answer is obvious: the more parts per unit of time the worker, or the workshop, or the entire plant produces, the better. Of course, subject to technology, decent quality and no stocking.
But the formula for efficiency is obvious - pieces per hour. And the directions for the application of management efforts are obvious, to improve efficiency.
We, dejected, return to our programmers. And we also want a simple and understandable formula for calculating effectiveness. What do we have there? Watches, watches, around - watches.
Now you already understand what is wrong with the clock. A clock measures time - a physical phenomenon beyond your control that has occurred, is happening and will always happen. It doesn’t matter whether you work or not, whether your company exists or has closed, whether you have clients or not - time will go, and it will be measured in hours.
All you can do is manage your activities during the hours allotted to you by the Labor Code, i.e. produce something, and somehow measure what you produce.
In the case of the plant, everything is clear - there is a measurement in physical units. Pieces, liters, linear, square or cubic meters. And with us, programmers, what to do? In what to measure our tasks, except for hours?
The first thing that comes to mind is the pieces. But such a thought is not viable - the variation between tasks is too high.
In fact, the answer has long been found in the so-called. flexible development methodologies, like scrum. The method is called "Poker Planning."
In what units are poker planning tasks measured? The answer is unusual - in any. Call them what you want. Dogs, parrots, stools, points, glasses - it doesn’t matter. The most common name is story points (story points, story points). Personally, I like the simpler and more concise - points. I will use it in the course of further exposition. You, of course, can choose any other.
A key feature of points is their relativity. This is not a unit of measure from some classifier, but a unique scale for each company, or even team. The same task, in two different teams, can be evaluated differently. Somewhere - five points, somewhere - thirteen, etc.
The number of points - this is the actual size of the task. The very assessment that we lacked.
The poker planning technique recommends using estimates from the Fibonacci series: 1, 2, 3, 5, 8, 13, 21, 34, etc. points, where each subsequent element is equal to the sum of the previous two. The reason is simple: there must be a significant difference between the ratings. It is rather difficult to choose a rating between, for example, 5 and 6 points. Much easier - between 5 and 8, or 8 and 13.
The methodology recommends evaluating the team as follows. All team members must be dealt cards with marks written on them (from the Fibonacci series). You can buy special cards for poker planning, if you want some beauty, but for simplicity it’s enough to take ordinary small pieces of paper for notes, like stickers, only without an adhesive strip.
So, the team gathered, each holding a card. A task is announced, its features and details are listed so that everyone understands what needs to be done. After that, each participant makes his own assessment - selects one of the cards - and puts it face down on the table (so that the assessment is not visible).
When everyone has evaluated, the cards are turned over, and a key check is performed - there should not be estimates that are separated from each other by more than one element of the Fibonacci series.
For example, grades 5 and 8 are normal, and grades 3 and 8 are not good. Too much overshoot in the estimates suggests that someone did not understand something. Those who give a low rating either know too much (for example, have already solved such a problem), or have not understood anything and are too optimistic.
Likewise, a high score may indicate a misunderstanding of the task. For example, a programmer simply never solved such problems, or they are connected with platform mechanisms unknown to him, and he, just in case, in reserve, gives a high mark.
In any case, if the estimates have diverged greatly, a second discussion is needed - to clarify the details, discuss the subtleties, and give maximum information. When the discussion is held, the evaluation is repeated. If necessary, again and again, until the estimates are separated from each other by no more than one element of the series.
Sometimes it’s useful to exclude one of the team members from the assessment of a specific task. For example, if there is an intern in the team, then at least explain to him, at least do not explain to him - he will not understand what is the difficulty or, conversely, the simplicity of the task. In the end, he simply agrees and puts the desired rating so as not to delay the team.
Such a result does not carry any value, because it turns poker planning into an empty formality. Therefore, I recommend a simple rule: only people who understand something in the task participate in the assessment of the task. You don’t understand - just sit and listen.
Of course, sometimes it happens that only one person understands the task. For example, if it belongs to some very specific, rarely used field of knowledge. It's okay, let there be one assessment.
There is an extreme case - no one understands how to solve the problem. It's also okay - we set what happened, then we'll figure it out.
When the grades are set, the arithmetic average is considered - this will be the final grade of the task. In flexible methodologies, they write it down on a sticker and hang it on a whiteboard, but I recommend just adding it to your information system, where you write down tasks. Of course, you must first add the appropriate field.
Another evaluation algorithm is without using a command. For example, points may be given by a leader, or a leader, or the most intelligent programmer. Usually, they move on to this algorithm after playing the poker team for several weeks or months.
The reason is simple: it is necessary that all team members are accustomed to the assessment system. They penetrated it, learned how to quickly evaluate tasks, and did not look at points, like a ram at a new gate. When a habit has developed, one person can be evaluated. Of course, leaving the team the right to express their opinions - no one is perfect, and the leader may be wrong in the estimates.
Sometimes teams have difficulties at the beginning of work with points - no one knows what to choose for a reference point. I recommend choosing several anchors - typical tasks that you periodically solve.
The first anchor is the easiest task. As a rule, as far as I know, the time spent by programmers is charged in multiples of 15 minutes. What tasks do you usually solve in 15 minutes? A simple report? Adding a user to the database? Filling an address classifier?
This task should be given a score of 1 point. In the future, you will be guided by it.
You can add a few more anchors, depending on your specifics. For example, a simple external report on one residual register, without bells and whistles, without code in the form and module - let it be 3 points. Add the requisites to the document and display on the form, without processing input and checks - let it be 2 points. Etc.
It is important that the team itself choose these anchors, agree with them and use them in the future. Estimates are relative, and anchors will play the role of starting points.
Now all our tasks are measured in physical units - points. We know how many points were completed in a week, month, year, etc. We know how many points each programmer produces. We clearly see how many points "weigh" unresolved tasks.
But most importantly, we know effectiveness as the ratio of points to hours. It’s easier, of course, to count points per day.
One programmer produces 4 points a day, another - 8, the third - 2. Last week we made 50 points, this week - 80, which means that our efficiency has increased.
The goal of increasing efficiency also becomes obvious: we must learn to produce more points per unit of time. Time, as we know, is not subject to our influence, but the number of points resolved is still how. Actually, this is what we will continue to study.
Points is a key coordinate system that will be used in the further presentation. This is a must-have section that cannot be skipped. It makes little sense to introduce some other methods until the points are calculated. Do you understand why?
Because you cannot evaluate the effectiveness of the applied methods. How to understand, it’s better or worse, not having numbers? No way, just a fantasy remains. Management based on fantasies and illusions is, of course, very widespread, but it is not suitable for increasing efficiency.
I’ll tell you a little secret: by implementing a system for assessing tasks in points, you can already increase the efficiency of the team of programmers. Sometimes even twice, I tested this hypothesis several times.
The reason is simple - there is real transparency. Illusions disappear, bare numbers remain. Together with the hours paid by the client, you get a fairly powerful system for tracking performance. People, having seen their numbers, themselves will start to work better, because they will no longer be able to hide behind the clock.
Therefore, without delay, make a record of tasks in your system in points. This is not difficult at all, especially if you use a system on the 1C platform - just add a number field to the metadata object that stores your tasks. Well, write a few reports on a point system - how many problems have been solved, by whom, when, how many have not been accepted into the work, how many are waiting for acceptance by the customer, etc.
The first, most important hours are those that we put on the client. Depending on the situation, we either agree on the clock in advance, or set the fact - how much the programmer spent.
The second hours are those that the programmer called, answering the question “how much time do you need to solve the problem?”. If we agree with the client in advance, then these watches are put up for sale. If payment is made after the fact, then we ask the programmer for evaluation for planning purposes.
The third hours - how much the programmer spent on solving the problem in fact. This watch coincides extremely rarely with the planned number, which he himself called, and this is normal - no one knows how to plan his time precisely, because a lot of forces from the environment act on the work of the programmer - he is distracted, he is not in the mood, he is faced with unforeseen difficulties, etc.
There are also the fourth hours - when we set the client an amount different from the one previously agreed upon. Of course, if the conditions of our cooperation allow us to do so.
And now attention, the question is: where can you work on efficiency? Or in another way: the effectiveness of what we will increase?
One can answer vaguely: the efficiency of the programmer. Well, how, and what will we measure? In our presence, I remind you, three or four kinds of watches.
Try telling the programmer: we want you to produce more hours. What will he answer? The programmer is an intelligent guy, he studied at the institute, and he immediately remembers the fifth metric - the number of hours in a day. And boldly tell you about it - I can’t work more than 24 hours a day, fear God.
He will also remember the theory of relativity. Even if it’s not in details, it’s definitely mentioning the impossibility of compressing time — are we not moving at speeds close to light?
If the watch does not shrink, then how to increase efficiency? How can you talk about it at all? How can you even count it? How many hours per hour did the programmer spend? Spend half an hour on an hour of work? How to make a formula? Without a formula, you won’t make any calculations, and you won’t set a goal.
Let's go on the other side. Imagine not a programmer, but a factory worker. Here he is, poor fellow, a whole shift at the machine and produces parts. How is his work planned? Suppose a hundred parts per shift. The change lasts eight hours, it turns out 4.8 minutes for one part.
Now imagine: we, with our approaches to measuring work, have come to lead this worker. We no longer tell him “do 100 parts”, we love to measure in hours, so the new work plan will sound like “do 8 hours per shift”.
He, of course, at first will consider us idiots. He asks - but how many details should be done? It doesn’t matter, we will answer. The main thing is the watch. We understand that there are variations, you go there for a smoke, chat with friends, but we imagine the average bill - 4.8 minutes per detail. Therefore, do us 100 times for 4.8 minutes of your work.
At first, of course, he will try to follow the old plan, but when he sees his calculation, his life values will change - it will say "so much has been calculated in 20 shifts of 8 hours." What is the point to him now in general to do the details, if only time spent at the machine is paid?
If by that time they had not yet driven us out of the factory, then we will change the sales system. We will not sell parts to customers - the invoices will show the hours spent by our workers. The client asks for 100 parts, we leave to think, then we send an invoice - 8 hours of specialist work. The client is surprised, but agrees, and pays the bill. And after a couple of days he gets another “increase” - a couple of hours. Well, what happened. The worker could not keep within 8 hours.
Customers are starting to resent - what the hell, what kind of watch? We need the details! In pieces, boxes, pallets, wagons - it does not matter. It makes no difference to us how many hours are needed to produce them!
Here, I think, they will definitely kick us out. Return accounting in pieces - both internal and external, for customers. And will be engaged in efficiency.
Where is the efficiency here, what is its formula? The answer is obvious: the more parts per unit of time the worker, or the workshop, or the entire plant produces, the better. Of course, subject to technology, decent quality and no stocking.
But the formula for efficiency is obvious - pieces per hour. And the directions for the application of management efforts are obvious, to improve efficiency.
We, dejected, return to our programmers. And we also want a simple and understandable formula for calculating effectiveness. What do we have there? Watches, watches, around - watches.
Now you already understand what is wrong with the clock. A clock measures time - a physical phenomenon beyond your control that has occurred, is happening and will always happen. It doesn’t matter whether you work or not, whether your company exists or has closed, whether you have clients or not - time will go, and it will be measured in hours.
All you can do is manage your activities during the hours allotted to you by the Labor Code, i.e. produce something, and somehow measure what you produce.
In the case of the plant, everything is clear - there is a measurement in physical units. Pieces, liters, linear, square or cubic meters. And with us, programmers, what to do? In what to measure our tasks, except for hours?
The first thing that comes to mind is the pieces. But such a thought is not viable - the variation between tasks is too high.
In fact, the answer has long been found in the so-called. flexible development methodologies, like scrum. The method is called "Poker Planning."
In what units are poker planning tasks measured? The answer is unusual - in any. Call them what you want. Dogs, parrots, stools, points, glasses - it doesn’t matter. The most common name is story points (story points, story points). Personally, I like the simpler and more concise - points. I will use it in the course of further exposition. You, of course, can choose any other.
A key feature of points is their relativity. This is not a unit of measure from some classifier, but a unique scale for each company, or even team. The same task, in two different teams, can be evaluated differently. Somewhere - five points, somewhere - thirteen, etc.
The number of points - this is the actual size of the task. The very assessment that we lacked.
The poker planning technique recommends using estimates from the Fibonacci series: 1, 2, 3, 5, 8, 13, 21, 34, etc. points, where each subsequent element is equal to the sum of the previous two. The reason is simple: there must be a significant difference between the ratings. It is rather difficult to choose a rating between, for example, 5 and 6 points. Much easier - between 5 and 8, or 8 and 13.
The methodology recommends evaluating the team as follows. All team members must be dealt cards with marks written on them (from the Fibonacci series). You can buy special cards for poker planning, if you want some beauty, but for simplicity it’s enough to take ordinary small pieces of paper for notes, like stickers, only without an adhesive strip.
So, the team gathered, each holding a card. A task is announced, its features and details are listed so that everyone understands what needs to be done. After that, each participant makes his own assessment - selects one of the cards - and puts it face down on the table (so that the assessment is not visible).
When everyone has evaluated, the cards are turned over, and a key check is performed - there should not be estimates that are separated from each other by more than one element of the Fibonacci series.
For example, grades 5 and 8 are normal, and grades 3 and 8 are not good. Too much overshoot in the estimates suggests that someone did not understand something. Those who give a low rating either know too much (for example, have already solved such a problem), or have not understood anything and are too optimistic.
Likewise, a high score may indicate a misunderstanding of the task. For example, a programmer simply never solved such problems, or they are connected with platform mechanisms unknown to him, and he, just in case, in reserve, gives a high mark.
In any case, if the estimates have diverged greatly, a second discussion is needed - to clarify the details, discuss the subtleties, and give maximum information. When the discussion is held, the evaluation is repeated. If necessary, again and again, until the estimates are separated from each other by no more than one element of the series.
Sometimes it’s useful to exclude one of the team members from the assessment of a specific task. For example, if there is an intern in the team, then at least explain to him, at least do not explain to him - he will not understand what is the difficulty or, conversely, the simplicity of the task. In the end, he simply agrees and puts the desired rating so as not to delay the team.
Such a result does not carry any value, because it turns poker planning into an empty formality. Therefore, I recommend a simple rule: only people who understand something in the task participate in the assessment of the task. You don’t understand - just sit and listen.
Of course, sometimes it happens that only one person understands the task. For example, if it belongs to some very specific, rarely used field of knowledge. It's okay, let there be one assessment.
There is an extreme case - no one understands how to solve the problem. It's also okay - we set what happened, then we'll figure it out.
When the grades are set, the arithmetic average is considered - this will be the final grade of the task. In flexible methodologies, they write it down on a sticker and hang it on a whiteboard, but I recommend just adding it to your information system, where you write down tasks. Of course, you must first add the appropriate field.
Another evaluation algorithm is without using a command. For example, points may be given by a leader, or a leader, or the most intelligent programmer. Usually, they move on to this algorithm after playing the poker team for several weeks or months.
The reason is simple: it is necessary that all team members are accustomed to the assessment system. They penetrated it, learned how to quickly evaluate tasks, and did not look at points, like a ram at a new gate. When a habit has developed, one person can be evaluated. Of course, leaving the team the right to express their opinions - no one is perfect, and the leader may be wrong in the estimates.
Sometimes teams have difficulties at the beginning of work with points - no one knows what to choose for a reference point. I recommend choosing several anchors - typical tasks that you periodically solve.
The first anchor is the easiest task. As a rule, as far as I know, the time spent by programmers is charged in multiples of 15 minutes. What tasks do you usually solve in 15 minutes? A simple report? Adding a user to the database? Filling an address classifier?
This task should be given a score of 1 point. In the future, you will be guided by it.
You can add a few more anchors, depending on your specifics. For example, a simple external report on one residual register, without bells and whistles, without code in the form and module - let it be 3 points. Add the requisites to the document and display on the form, without processing input and checks - let it be 2 points. Etc.
It is important that the team itself choose these anchors, agree with them and use them in the future. Estimates are relative, and anchors will play the role of starting points.
Now all our tasks are measured in physical units - points. We know how many points were completed in a week, month, year, etc. We know how many points each programmer produces. We clearly see how many points "weigh" unresolved tasks.
But most importantly, we know effectiveness as the ratio of points to hours. It’s easier, of course, to count points per day.
One programmer produces 4 points a day, another - 8, the third - 2. Last week we made 50 points, this week - 80, which means that our efficiency has increased.
The goal of increasing efficiency also becomes obvious: we must learn to produce more points per unit of time. Time, as we know, is not subject to our influence, but the number of points resolved is still how. Actually, this is what we will continue to study.
Points is a key coordinate system that will be used in the further presentation. This is a must-have section that cannot be skipped. It makes little sense to introduce some other methods until the points are calculated. Do you understand why?
Because you cannot evaluate the effectiveness of the applied methods. How to understand, it’s better or worse, not having numbers? No way, just a fantasy remains. Management based on fantasies and illusions is, of course, very widespread, but it is not suitable for increasing efficiency.
I’ll tell you a little secret: by implementing a system for assessing tasks in points, you can already increase the efficiency of the team of programmers. Sometimes even twice, I tested this hypothesis several times.
The reason is simple - there is real transparency. Illusions disappear, bare numbers remain. Together with the hours paid by the client, you get a fairly powerful system for tracking performance. People, having seen their numbers, themselves will start to work better, because they will no longer be able to hide behind the clock.
Therefore, without delay, make a record of tasks in your system in points. This is not difficult at all, especially if you use a system on the 1C platform - just add a number field to the metadata object that stores your tasks. Well, write a few reports on a point system - how many problems have been solved, by whom, when, how many have not been accepted into the work, how many are waiting for acceptance by the customer, etc.
Summary
- Measuring tasks only in hours deprives you of the opportunity to increase efficiency;
- It is better to measure tasks in physical units - points;
- It’s better to start implementing points with team poker planning;
- When the rating system becomes clear to the team, you can give an assessment to one person;
- Scoring provides an understanding of effectiveness;
- Points must be automated.