How to compress time?
The traditional way to measure tasks in our industry is watches. Let's calculate how many metrics in the clock we use.
The first, most important hours - those that we expose the client. Depending on the situation, we either agree on the clock in advance, or put in fact - how much the programmer has spent.
The second clock is the one 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 it is these watches that we set for sale. If the payment goes after the fact, then we ask the evaluation of the programmer for planning purposes.
')
The third hours - how much the programmer has spent on solving the problem after the fact. With that planned figure, which he called himself, this watch coincides extremely rarely, and this is normal - no one knows how to precisely plan their time, because a lot of forces work on the programmer’s work from the environment - he gets distracted, he is not in the mood, he comes across with unforeseen difficulties, etc.
There are also fourth hours - when we set a sum for the client that is different from the amount agreed in advance. Of course, if the conditions of our cooperation allow us to do so.
And now attention, the question is: where is it possible to work on efficiency? Or in a different way: what effectiveness will we increase?
You can answer vaguely: the effectiveness of the programmer. Well, how, and what will we measure? In our presence, I recall, three or four kinds of watches.
Try telling the programmer: 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 per day. And it will tell you boldly about this - I cannot work more than 24 hours a day, fear God.
Another theory of relativity will remember. Let it not be in the details, but it will definitely mention the impossibility of time compression - we are not moving at speeds close to the light one?
If the clock does not shrink, then how to increase efficiency? How can we talk about it at all? How can you even calculate it? How many hours per hour of work did the programmer spend? Spend on the hour of work for half an hour? How to make a formula? Without a formula, after all, there will be no calculations, and you will not set a goal.
Let's go on the other side. Imagine not a programmer, but a worker in a factory. Here he stands, poor fellow, the whole shift at the machine and produces parts. How is his work planned? Suppose a hundred parts in a shift. The shift lasts eight hours, it turns out 4.8 minutes per detail.
Now imagine: we, with our approaches to the measurement of work, have come to lead this worker. We no longer say “make 100 details” to him, we like to measure in hours, so the new plan of the worker will sound like “make 8 hours per shift”.
He, of course, at first considers us idiots. Ask - and how many details to do? No matter, we will answer. The main thing is the clock. We understand that there are variations, you go there for a smoke, chat with friends, but imagine the average check - 4.8 minutes for detail. So make us 100 times for 4.8 minutes of your work.
At first, he, of course, will try to follow the old plan, but when he sees his calculation, his life values ​​will change - there will be written “accrued so much in 20 shifts of 8 hours”. What is the point now for him to do the details if only the time spent at the machine is paid?
If we are not expelled from the factory by then, we will change the sales system. We will not sell parts to customers - the invoices will be hours spent by our workers. The client asks for 100 details, we leave to think, then we send the invoice - 8 hours of work by a specialist. The client is surprised, but agrees, and the bill pays. And after a couple of days, he gets another “boost” - a couple of hours. Well, that happened. Could not work out at 8 o'clock.
Customers are beginning to resent - what the hell, what time is it? We need the details! In pieces, boxes, pallets, cars - it does not matter. We do not care how many hours to produce them!
Here, I think we will definitely kicked out. Return the account in pieces - both internal and external for customers. And they will be engaged in efficiency.
Where is the efficiency here, what is its formula? The answer is obvious: the more detail a unit of time is produced by a worker, or a workshop, or an entire plant, the better. Of course, with the observance of technology, decent quality and without packing a warehouse.
But the formula for efficiency is obvious - things per hour. And the directions for the application of management efforts are obvious, to increase efficiency.
We, dejected, return to our programmers. And we also want a simple and clear formula for calculating efficiency. And what about us? Hours, hours, around - hours.
Now you already understand what is wrong with the clock. Hours measure time - a physical phenomenon that is not subject to you, which has happened, is happening and will always happen. It doesn’t matter whether you work or not, your company exists or is closed, you have clients or not - time will go and it will be measured in hours.
All that you can do is to dispose of your activities during the hours given 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? How to measure our tasks, except for hours?
The first thing that comes to mind is things. 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 a scram. The method is called "Poker Planning."
In what units are tasks in planning poker measured? The answer is unusual - in any. Call them whatever you want. Dogs, parrots, stools, points, glasses - it does not matter. The most common name is story points (story points, story points). Personally, I like the simpler and laconic points. I will use it in the course of the further presentation. You can of course choose any other.
The key feature of points is their relativity. This is not a unit of measurement from some classifier, but a unique scale for each company, or even a team. The same task, in two different teams, can be assessed differently. Somewhere - five points, somewhere - thirteen, etc.
The number of points is the actual size of the task. That same assessment, which we lacked.
Methodology poker planning recommends using estimates from the Fibonacci series: 1, 2, 3, 5, 8, 13, 21, 34, etc. points, where each successive element is equal to the sum of the two previous ones. The reason is simple: it is necessary that there be a significant difference between the estimates. It is rather difficult to choose a grade between, for example, 5 and 6 points. Much easier - between 5 and 8, or 8 and 13.
Evaluate in a team methodology recommends as follows. All team members must distribute cards with scores written on them (from the Fibonacci series). You can buy special cards for planning poker, if you want some kind of beauty, but for simplicity, it is enough to take ordinary small pieces of paper for notes, like stickers, only without an adhesive strip.
So, the team has gathered, everyone has cards on their hands. 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 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 more than one element from the Fibonacci series from each other.
For example, grades 5 and 8 are normal, and 3 and 8 are no good. Too much run-up in assessments suggests that someone did not understand something. The one who put a low mark, either knows too much (for example, has already solved such a task), or did not understand anything and is too optimistic.
Similarly, a high score may indicate a lack of understanding of the problem. For example, the programmer simply never solved such problems, or they are associated with unknown mechanisms of the platform, and he, in any case, as a reserve, puts a high mark.
In any case, if the assessments are very different, you need to re-discuss - clarify the details, discuss the details, give maximum information. When the discussion is held, the assessment is repeated. If necessary, again and again, until the assessments are no more than one element apart from each other.
Sometimes it is useful to exclude someone from 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, if not explain - he will not understand what the complexity is or, on the contrary, the simplicity of the task. In the end, he simply agrees, and will put the desired assessment, so as not to delay the team.
This result does not carry any value, because it turns planning poker into a mere formality. Therefore, I recommend a simple rule: only people who understand something in a task participate in the assessment of a task. Do not understand - just sit and listen.
Of course, sometimes it happens that the task understands only one person. For example, if it belongs to some very specific, rarely used area of ​​knowledge. It's okay, let it be one assessment.
It happens and the extreme case - no one understands how to solve the problem. It's also okay - we put what happened, then we'll figure it out.
When grades are set, the arithmetic average is considered - this will be the final grade of the problem. In flexible methodologies, it is written down on a sticker and hung on a board, but I recommend simply inserting it into your information system, where you write down the tasks. Of course, you must first add the appropriate field.
Another evaluation algorithm is without the use of a command. For example, points can be put down by a manager, or a leader, or the most intelligent programmer. Usually, this algorithm is taken after several weeks or months of playing poker with the whole team.
The reason is simple: it is necessary that all team members are accustomed to the evaluation system. They penetrated it, learned how to quickly evaluate tasks, and did not look at the points, like a ram at a new gate. When the habit has developed, you can give a rating to one person. Of course, leaving the team the right to express their opinion - no one is perfect, and the manager may be wrong in the estimates.
Sometimes teams have difficulty starting work with points - no one knows what to choose as a point of reference. I recommend choosing several anchors - typical tasks that you periodically solve.
The first anchor is the easiest task. Usually, as far as I know, the work time of programmers is charged in multiples of 15 minutes. What tasks do you usually solve in 15 minutes? Simple report? Adding a user to the database? Filling address classifier?
This task is worth giving 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 frills with design, without a code in the form and module - let it be 3 points. Add a requisite to the document and display it on the form, without processing input and checks - let it be 2 points. Etc.
It is important that the team itself chose these anchors, agreed with them and used 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 fulfilled in a week, month, year, etc. We know how many points each programmer produces. We clearly see how many points the unsolved problems weigh.
But the main thing - we know efficiency, 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 time - 80, which means 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 beyond our control, but the number of points decided is still how. Actually, this is what we will study further.
Points are the key coordinate system that will be used in the following presentation. This is a required section that should not be missed. There is not much point in introducing any other methods until points are calculated. Do you understand why?
Because you can not evaluate the effectiveness of the applied methods. How to understand, it became better or worse, not having numbers? No, only dreaming remains. Management based on fantasies and illusions is, of course, very widespread, but it is not suitable for increasing efficiency.
I will reveal a small secret: having introduced a system for evaluating tasks in points, you can already improve the efficiency of the work of a team of programmers. Sometimes even twice, I tested this hypothesis several times.
The reason is simple - there is real transparency. Illusions disappear, bare figures remain. Together with the hours paid by the client, you get a fairly powerful performance accounting system. When people see their numbers, they themselves will start working better, because they will no longer be able to hide behind the clock.
Therefore, not postponing, make in your system the accounting of tasks in points. This is not difficult, especially if you use a system on the 1C platform - just add a numeric field to the metadata object that stores your tasks. Well, write a few reports on the point system - how many tasks are solved, by whom, when, how many have not yet been taken into work, how many are waiting for acceptance by the customer, etc.
The first, most important hours - those that we expose the client. Depending on the situation, we either agree on the clock in advance, or put in fact - how much the programmer has spent.
The second clock is the one 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 it is these watches that we set for sale. If the payment goes after the fact, then we ask the evaluation of the programmer for planning purposes.
')
The third hours - how much the programmer has spent on solving the problem after the fact. With that planned figure, which he called himself, this watch coincides extremely rarely, and this is normal - no one knows how to precisely plan their time, because a lot of forces work on the programmer’s work from the environment - he gets distracted, he is not in the mood, he comes across with unforeseen difficulties, etc.
There are also fourth hours - when we set a sum for the client that is different from the amount agreed in advance. Of course, if the conditions of our cooperation allow us to do so.
And now attention, the question is: where is it possible to work on efficiency? Or in a different way: what effectiveness will we increase?
You can answer vaguely: the effectiveness of the programmer. Well, how, and what will we measure? In our presence, I recall, three or four kinds of watches.
Try telling the programmer: 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 per day. And it will tell you boldly about this - I cannot work more than 24 hours a day, fear God.
Another theory of relativity will remember. Let it not be in the details, but it will definitely mention the impossibility of time compression - we are not moving at speeds close to the light one?
If the clock does not shrink, then how to increase efficiency? How can we talk about it at all? How can you even calculate it? How many hours per hour of work did the programmer spend? Spend on the hour of work for half an hour? How to make a formula? Without a formula, after all, there will be no calculations, and you will not set a goal.
Let's go on the other side. Imagine not a programmer, but a worker in a factory. Here he stands, poor fellow, the whole shift at the machine and produces parts. How is his work planned? Suppose a hundred parts in a shift. The shift lasts eight hours, it turns out 4.8 minutes per detail.
Now imagine: we, with our approaches to the measurement of work, have come to lead this worker. We no longer say “make 100 details” to him, we like to measure in hours, so the new plan of the worker will sound like “make 8 hours per shift”.
He, of course, at first considers us idiots. Ask - and how many details to do? No matter, we will answer. The main thing is the clock. We understand that there are variations, you go there for a smoke, chat with friends, but imagine the average check - 4.8 minutes for detail. So make us 100 times for 4.8 minutes of your work.
At first, he, of course, will try to follow the old plan, but when he sees his calculation, his life values ​​will change - there will be written “accrued so much in 20 shifts of 8 hours”. What is the point now for him to do the details if only the time spent at the machine is paid?
If we are not expelled from the factory by then, we will change the sales system. We will not sell parts to customers - the invoices will be hours spent by our workers. The client asks for 100 details, we leave to think, then we send the invoice - 8 hours of work by a specialist. The client is surprised, but agrees, and the bill pays. And after a couple of days, he gets another “boost” - a couple of hours. Well, that happened. Could not work out at 8 o'clock.
Customers are beginning to resent - what the hell, what time is it? We need the details! In pieces, boxes, pallets, cars - it does not matter. We do not care how many hours to produce them!
Here, I think we will definitely kicked out. Return the account in pieces - both internal and external for customers. And they will be engaged in efficiency.
Where is the efficiency here, what is its formula? The answer is obvious: the more detail a unit of time is produced by a worker, or a workshop, or an entire plant, the better. Of course, with the observance of technology, decent quality and without packing a warehouse.
But the formula for efficiency is obvious - things per hour. And the directions for the application of management efforts are obvious, to increase efficiency.
We, dejected, return to our programmers. And we also want a simple and clear formula for calculating efficiency. And what about us? Hours, hours, around - hours.
Now you already understand what is wrong with the clock. Hours measure time - a physical phenomenon that is not subject to you, which has happened, is happening and will always happen. It doesn’t matter whether you work or not, your company exists or is closed, you have clients or not - time will go and it will be measured in hours.
All that you can do is to dispose of your activities during the hours given 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? How to measure our tasks, except for hours?
The first thing that comes to mind is things. 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 a scram. The method is called "Poker Planning."
In what units are tasks in planning poker measured? The answer is unusual - in any. Call them whatever you want. Dogs, parrots, stools, points, glasses - it does not matter. The most common name is story points (story points, story points). Personally, I like the simpler and laconic points. I will use it in the course of the further presentation. You can of course choose any other.
The key feature of points is their relativity. This is not a unit of measurement from some classifier, but a unique scale for each company, or even a team. The same task, in two different teams, can be assessed differently. Somewhere - five points, somewhere - thirteen, etc.
The number of points is the actual size of the task. That same assessment, which we lacked.
Methodology poker planning recommends using estimates from the Fibonacci series: 1, 2, 3, 5, 8, 13, 21, 34, etc. points, where each successive element is equal to the sum of the two previous ones. The reason is simple: it is necessary that there be a significant difference between the estimates. It is rather difficult to choose a grade between, for example, 5 and 6 points. Much easier - between 5 and 8, or 8 and 13.
Evaluate in a team methodology recommends as follows. All team members must distribute cards with scores written on them (from the Fibonacci series). You can buy special cards for planning poker, if you want some kind of beauty, but for simplicity, it is enough to take ordinary small pieces of paper for notes, like stickers, only without an adhesive strip.
So, the team has gathered, everyone has cards on their hands. 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 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 more than one element from the Fibonacci series from each other.
For example, grades 5 and 8 are normal, and 3 and 8 are no good. Too much run-up in assessments suggests that someone did not understand something. The one who put a low mark, either knows too much (for example, has already solved such a task), or did not understand anything and is too optimistic.
Similarly, a high score may indicate a lack of understanding of the problem. For example, the programmer simply never solved such problems, or they are associated with unknown mechanisms of the platform, and he, in any case, as a reserve, puts a high mark.
In any case, if the assessments are very different, you need to re-discuss - clarify the details, discuss the details, give maximum information. When the discussion is held, the assessment is repeated. If necessary, again and again, until the assessments are no more than one element apart from each other.
Sometimes it is useful to exclude someone from 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, if not explain - he will not understand what the complexity is or, on the contrary, the simplicity of the task. In the end, he simply agrees, and will put the desired assessment, so as not to delay the team.
This result does not carry any value, because it turns planning poker into a mere formality. Therefore, I recommend a simple rule: only people who understand something in a task participate in the assessment of a task. Do not understand - just sit and listen.
Of course, sometimes it happens that the task understands only one person. For example, if it belongs to some very specific, rarely used area of ​​knowledge. It's okay, let it be one assessment.
It happens and the extreme case - no one understands how to solve the problem. It's also okay - we put what happened, then we'll figure it out.
When grades are set, the arithmetic average is considered - this will be the final grade of the problem. In flexible methodologies, it is written down on a sticker and hung on a board, but I recommend simply inserting it into your information system, where you write down the tasks. Of course, you must first add the appropriate field.
Another evaluation algorithm is without the use of a command. For example, points can be put down by a manager, or a leader, or the most intelligent programmer. Usually, this algorithm is taken after several weeks or months of playing poker with the whole team.
The reason is simple: it is necessary that all team members are accustomed to the evaluation system. They penetrated it, learned how to quickly evaluate tasks, and did not look at the points, like a ram at a new gate. When the habit has developed, you can give a rating to one person. Of course, leaving the team the right to express their opinion - no one is perfect, and the manager may be wrong in the estimates.
Sometimes teams have difficulty starting work with points - no one knows what to choose as a point of reference. I recommend choosing several anchors - typical tasks that you periodically solve.
The first anchor is the easiest task. Usually, as far as I know, the work time of programmers is charged in multiples of 15 minutes. What tasks do you usually solve in 15 minutes? Simple report? Adding a user to the database? Filling address classifier?
This task is worth giving 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 frills with design, without a code in the form and module - let it be 3 points. Add a requisite to the document and display it on the form, without processing input and checks - let it be 2 points. Etc.
It is important that the team itself chose these anchors, agreed with them and used 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 fulfilled in a week, month, year, etc. We know how many points each programmer produces. We clearly see how many points the unsolved problems weigh.
But the main thing - we know efficiency, 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 time - 80, which means 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 beyond our control, but the number of points decided is still how. Actually, this is what we will study further.
Points are the key coordinate system that will be used in the following presentation. This is a required section that should not be missed. There is not much point in introducing any other methods until points are calculated. Do you understand why?
Because you can not evaluate the effectiveness of the applied methods. How to understand, it became better or worse, not having numbers? No, only dreaming remains. Management based on fantasies and illusions is, of course, very widespread, but it is not suitable for increasing efficiency.
I will reveal a small secret: having introduced a system for evaluating tasks in points, you can already improve the efficiency of the work of a team of programmers. Sometimes even twice, I tested this hypothesis several times.
The reason is simple - there is real transparency. Illusions disappear, bare figures remain. Together with the hours paid by the client, you get a fairly powerful performance accounting system. When people see their numbers, they themselves will start working better, because they will no longer be able to hide behind the clock.
Therefore, not postponing, make in your system the accounting of tasks in points. This is not difficult, especially if you use a system on the 1C platform - just add a numeric field to the metadata object that stores your tasks. Well, write a few reports on the point system - how many tasks are solved, by whom, when, how many have not yet been taken into work, how many are waiting for acceptance by the customer, etc.
Summary
- Measuring tasks in hours only makes it impossible for you to increase efficiency;
- It is better to measure tasks in physical units - points;
- Starting the introduction of points is better with team planning poker;
- When the rating system becomes clear to the team, you can give a rating to one person;
- Scoring gives an understanding of effectiveness;
- Accounting of points must be automated.
Source: https://habr.com/ru/post/450498/
All Articles