The choice is evil
I will begin with the main thing: if your programmers choose their own task, then you have big problems.
We used to look at the choice as a conditional operator in a programming language or algorithm scheme. Well, remember, such a diamond is drawn, it has the condition of choice, and two branches - yes and no. When the algorithm is executed, the condition is checked instantly, so its performance is usually not taken into account.
And what is the choice made by man? This is not an instantaneous algorithm, but a process. This process has a beginning, an end (God forbid), and, most importantly, duration. How much do you think the task selection can last?
')
You can guess, but better to measure. I watched this process many times, and the conclusion is disappointing: the programmer can choose a task for several days.
The selection process is bad because it is hidden from our sight. If a man loafed around the office, tossed from side to side, looked up in a draw, we would understand that he has a problem. But it is different.
Programmers have long invented such an algorithm as reconnaissance in force. Applied to tasks, it means: not just read the condition, but go in and see. Look at the code, forms, links, metadata, examples of reproduction and analytical reports.
It is necessary to look in order to evaluate the problem “as it should be”, not by eye. If you catch a programmer doing this, he will say: I am a professional, and I cannot take on the task without knowing all the subtleties. It would seem, what is wrong with that? That's right, man does?
Of course, right. But only if he, according to the results of his research, makes the final decision - to take on the task or not. As an option - to take the task with reservations, such as the need to explore additional mechanisms.
If the programmer decided to take the task, and sat down to do it, then everything is fine. If he refused the task, then everything is bad. The time spent on research will be wasted.
There are two options. The first is that the programmer will refuse flatly, and the task will be watched by someone else. In principle, it is possible that the first programmer will simply retell the results of his research, the discovered pitfalls and related difficulties to the second. But in practice, programmers prefer independence from each other, including from the opinion of colleagues. Some even experience some excitement, understanding the task, for which the colleague did not undertake.
The second option - the programmer did not refuse, but postponed the task for later. When this “later” comes is not known, but most likely - after a rather long time. What will happen during the second iteration of reconnaissance in force? Will start from the place where he stopped in the research? Of course not - he will go the same way, from beginning to end. And, with a high probability, stalled in the same place as the first time.
And that's what happens. There is a time that programmers spend on solving problems. Normal, correct, useful time. As a rule, time to solve the problem is spent once.
And there is a time that programmers spend on multiple exploration. There is no special benefit in this time - neither for the programmer, nor for the client, nor for your company. Time for reconnaissance in force - almost a net loss.
But the problem is not only in intelligence. It could be worse.
For example, a programmer understands all the tasks in his list, but simply cannot choose what to do. The problem is aggravated by the fact that the choice is made, as God puts it at heart - without a specific algorithm, criteria and priorities. And here is someone in that much.
One chooses what is more interesting. Another chooses something that is easier. The third one selects tasks according to the mechanisms that are familiar to him. The fourth chooses the tasks of his favorite client, because the result is easier to pass. The fifth selects the most ambitious task to show themselves.
At the same time, what is important, almost every one of them suffers from serious mental agony due to the uncertainty of the criteria. He roughly understands what tasks he wants to solve, but, either consciously or unknowingly he feels that he is doing something wrong. It seems to him that it is necessary to choose a completely different task, based on the strategy of the company, the state of the project, the plan for the development of its own competencies, etc. But I want to choose something that is not necessary, but something that I like.
Such mental agony aggravates the selection process even more. A man plunges into dark reflections, weighing his choice on the scales of conscience. And so can pass hours and days.
From the point of view of the manager, who stood aside, this whole process resembles a groundhog from one famous film that crawls out of a hole and “chooses the weather for the next six weeks”. What is he guided there, sees his shadow or not, and why does the groundhog do it at all? True, if a manager often looks at this process from the outside, then the question is more likely to him than to programmers.
Also, in the context of choice, a holiday is of great importance. A programmer is a human being, first of all, and not a robot. What does a person want after doing a difficult job? A holiday, of course!
The completed task should be noted. Go for a smoke, drink tea or coffee, chat with friends, boast a solved problem, sit on social networks, read the news - in general, there are many options. Unfortunately, this holiday is sometimes delayed.
Especially bad if the task was completed in an hour, or even two before the end of the working day. Well, who, in his right mind, will choose a new task for himself, if he will soon go home?
How easy it is to get out of the state of the holiday, every Russian knows - we all rest in the New Year holidays. In our case, it is even more difficult. the programmer must return not to the solution of the problem, but to the choice of the next one. How painful the choice, we have already discussed.
To summarize the losses from the choice, they are always there. The only question is their number. In order for you to penetrate, I’ll call this figure: the choice of the task takes up to 50% of the time. Just think about this figure.
But, in the context of our material, this figure is simply beautiful. By eliminating losses due to choice, you can double the efficiency.
How to get rid of the choice? There is nothing easier. Actually, you yourself know how to do it. I will state my proposals, and you will combine them with your own methods, and you will get a decent increase in efficiency.
The first and most important thing to start with is controlling. No matter how you come up with a system of priorities and distribution of tasks, it will not work until the programmers are “not listening” to you.
Controlling, in a nutshell, is digit-based management. In this case, the figure will not be the profit or the amount of sales, but the sequence number of the task in the queue. It is necessary to manage the choice of the task based on this number, and to be sure that the tasks are solved in a given order.
Controlling is also necessary if you manage a team, and even when you control yourself. With a deal is easier to negotiate than with the head? "Yes, now, for the last time, and then for sure!"
In general, about controlling, we will talk more thoroughly, here I ran ahead, but it's worth it. If you come up with the rules for choosing a task, but no one executes them, then nothing happens.
So, all that needs to be done is to line up the tasks in the queue and ensure that this queue follows. In some sources, it is recommended to hide the queue from programmers, leaving only two tasks in sight: the current and the next. If you show the programmer all the tasks at once, then he, no matter how hard you try, will still “pry” and study what lies ahead.
The first way is the distribution of tasks by the boss, without using automation. You simply say who does what and in what sequence. You can make simple plans - for example, in the form of small pieces of paper, such as work orders, or production tasks. You can simply dictate the numbers of tasks under the notepad entry.
You can make a board, the type of scrum, and hang there stickers for the day. The method of scrams involves hanging many tasks, for example - for a week or a month, but this does not suit us, because the choice appears again.
Manual distribution of tasks is very simple to start, and just as easy to stop, because they get tired quickly. You need to have significant willpower, or good regular management skills, to force yourself to distribute tasks daily. If this is about you, you can start today.
For the lazy, suitable automation. In your information system, where tasks are stored, you need to lay out a mechanism for sorting them. How to you closer? Sort by production date? According to the date of performance? Any way is suitable. The main thing is that it be deterministic and equally understood by programmers. Personally, I recommend not to limit the sorting, but to store the numbers in the queue as a separate field. Modern systems are too user friendly and allow them to customize the sorting themselves. So you decided that you need to perform the tasks in the order of receipt (FIFO), and the programmer accidentally, or intentionally, changed the sorting to the reverse, and got a LIFO.
If the number in the queue is saved, then sort, do not sort, it is difficult to make a mistake.
You can not attach to sorting, and put the numbers manually. It is also good if you have enough willpower to arrange these numbers.
The principle, I think, is clear. Any queuing system that is understandable to programmers, and monitoring its compliance. This will be the first step to depriving the choice that takes efficiency.
The second step we will look further. It will allow us to extract much more benefit from the queues - not only to simplify the selection, but also to make it right.
Summary
We used to look at the choice as a conditional operator in a programming language or algorithm scheme. Well, remember, such a diamond is drawn, it has the condition of choice, and two branches - yes and no. When the algorithm is executed, the condition is checked instantly, so its performance is usually not taken into account.
And what is the choice made by man? This is not an instantaneous algorithm, but a process. This process has a beginning, an end (God forbid), and, most importantly, duration. How much do you think the task selection can last?
')
You can guess, but better to measure. I watched this process many times, and the conclusion is disappointing: the programmer can choose a task for several days.
The selection process is bad because it is hidden from our sight. If a man loafed around the office, tossed from side to side, looked up in a draw, we would understand that he has a problem. But it is different.
Programmers have long invented such an algorithm as reconnaissance in force. Applied to tasks, it means: not just read the condition, but go in and see. Look at the code, forms, links, metadata, examples of reproduction and analytical reports.
It is necessary to look in order to evaluate the problem “as it should be”, not by eye. If you catch a programmer doing this, he will say: I am a professional, and I cannot take on the task without knowing all the subtleties. It would seem, what is wrong with that? That's right, man does?
Of course, right. But only if he, according to the results of his research, makes the final decision - to take on the task or not. As an option - to take the task with reservations, such as the need to explore additional mechanisms.
If the programmer decided to take the task, and sat down to do it, then everything is fine. If he refused the task, then everything is bad. The time spent on research will be wasted.
There are two options. The first is that the programmer will refuse flatly, and the task will be watched by someone else. In principle, it is possible that the first programmer will simply retell the results of his research, the discovered pitfalls and related difficulties to the second. But in practice, programmers prefer independence from each other, including from the opinion of colleagues. Some even experience some excitement, understanding the task, for which the colleague did not undertake.
The second option - the programmer did not refuse, but postponed the task for later. When this “later” comes is not known, but most likely - after a rather long time. What will happen during the second iteration of reconnaissance in force? Will start from the place where he stopped in the research? Of course not - he will go the same way, from beginning to end. And, with a high probability, stalled in the same place as the first time.
And that's what happens. There is a time that programmers spend on solving problems. Normal, correct, useful time. As a rule, time to solve the problem is spent once.
And there is a time that programmers spend on multiple exploration. There is no special benefit in this time - neither for the programmer, nor for the client, nor for your company. Time for reconnaissance in force - almost a net loss.
But the problem is not only in intelligence. It could be worse.
For example, a programmer understands all the tasks in his list, but simply cannot choose what to do. The problem is aggravated by the fact that the choice is made, as God puts it at heart - without a specific algorithm, criteria and priorities. And here is someone in that much.
One chooses what is more interesting. Another chooses something that is easier. The third one selects tasks according to the mechanisms that are familiar to him. The fourth chooses the tasks of his favorite client, because the result is easier to pass. The fifth selects the most ambitious task to show themselves.
At the same time, what is important, almost every one of them suffers from serious mental agony due to the uncertainty of the criteria. He roughly understands what tasks he wants to solve, but, either consciously or unknowingly he feels that he is doing something wrong. It seems to him that it is necessary to choose a completely different task, based on the strategy of the company, the state of the project, the plan for the development of its own competencies, etc. But I want to choose something that is not necessary, but something that I like.
Such mental agony aggravates the selection process even more. A man plunges into dark reflections, weighing his choice on the scales of conscience. And so can pass hours and days.
From the point of view of the manager, who stood aside, this whole process resembles a groundhog from one famous film that crawls out of a hole and “chooses the weather for the next six weeks”. What is he guided there, sees his shadow or not, and why does the groundhog do it at all? True, if a manager often looks at this process from the outside, then the question is more likely to him than to programmers.
Also, in the context of choice, a holiday is of great importance. A programmer is a human being, first of all, and not a robot. What does a person want after doing a difficult job? A holiday, of course!
The completed task should be noted. Go for a smoke, drink tea or coffee, chat with friends, boast a solved problem, sit on social networks, read the news - in general, there are many options. Unfortunately, this holiday is sometimes delayed.
Especially bad if the task was completed in an hour, or even two before the end of the working day. Well, who, in his right mind, will choose a new task for himself, if he will soon go home?
How easy it is to get out of the state of the holiday, every Russian knows - we all rest in the New Year holidays. In our case, it is even more difficult. the programmer must return not to the solution of the problem, but to the choice of the next one. How painful the choice, we have already discussed.
To summarize the losses from the choice, they are always there. The only question is their number. In order for you to penetrate, I’ll call this figure: the choice of the task takes up to 50% of the time. Just think about this figure.
But, in the context of our material, this figure is simply beautiful. By eliminating losses due to choice, you can double the efficiency.
How to get rid of the choice? There is nothing easier. Actually, you yourself know how to do it. I will state my proposals, and you will combine them with your own methods, and you will get a decent increase in efficiency.
The first and most important thing to start with is controlling. No matter how you come up with a system of priorities and distribution of tasks, it will not work until the programmers are “not listening” to you.
Controlling, in a nutshell, is digit-based management. In this case, the figure will not be the profit or the amount of sales, but the sequence number of the task in the queue. It is necessary to manage the choice of the task based on this number, and to be sure that the tasks are solved in a given order.
Controlling is also necessary if you manage a team, and even when you control yourself. With a deal is easier to negotiate than with the head? "Yes, now, for the last time, and then for sure!"
In general, about controlling, we will talk more thoroughly, here I ran ahead, but it's worth it. If you come up with the rules for choosing a task, but no one executes them, then nothing happens.
So, all that needs to be done is to line up the tasks in the queue and ensure that this queue follows. In some sources, it is recommended to hide the queue from programmers, leaving only two tasks in sight: the current and the next. If you show the programmer all the tasks at once, then he, no matter how hard you try, will still “pry” and study what lies ahead.
The first way is the distribution of tasks by the boss, without using automation. You simply say who does what and in what sequence. You can make simple plans - for example, in the form of small pieces of paper, such as work orders, or production tasks. You can simply dictate the numbers of tasks under the notepad entry.
You can make a board, the type of scrum, and hang there stickers for the day. The method of scrams involves hanging many tasks, for example - for a week or a month, but this does not suit us, because the choice appears again.
Manual distribution of tasks is very simple to start, and just as easy to stop, because they get tired quickly. You need to have significant willpower, or good regular management skills, to force yourself to distribute tasks daily. If this is about you, you can start today.
For the lazy, suitable automation. In your information system, where tasks are stored, you need to lay out a mechanism for sorting them. How to you closer? Sort by production date? According to the date of performance? Any way is suitable. The main thing is that it be deterministic and equally understood by programmers. Personally, I recommend not to limit the sorting, but to store the numbers in the queue as a separate field. Modern systems are too user friendly and allow them to customize the sorting themselves. So you decided that you need to perform the tasks in the order of receipt (FIFO), and the programmer accidentally, or intentionally, changed the sorting to the reverse, and got a LIFO.
If the number in the queue is saved, then sort, do not sort, it is difficult to make a mistake.
You can not attach to sorting, and put the numbers manually. It is also good if you have enough willpower to arrange these numbers.
The principle, I think, is clear. Any queuing system that is understandable to programmers, and monitoring its compliance. This will be the first step to depriving the choice that takes efficiency.
The second step we will look further. It will allow us to extract much more benefit from the queues - not only to simplify the selection, but also to make it right.
Summary
- Choosing a task is not an instant, but a long process;
- The programmer chooses a task based on his own ideas;
- The choice is spent a huge amount of time;
- The selection process brings neither benefit nor pleasure;
- Choice must be deprived;
- You can distribute tasks manually, like a foreman;
- Automation can assist in queuing.
Source: https://habr.com/ru/post/450794/
All Articles