Estimated time to complete the task
While working on a large, constantly developing project, I deal with various forms of task approval almost daily: from “Very urgent, correct here. In an hour you will be laid down? "To" Estimate, on how many weeks this task will pull ". As a performer, I myself estimate the time and complexity of performing each task, and I consider this the only correct approach to assessing the front of upcoming work in software development.
But, watching many projects - third-party, about which they write in articles and blogs, as well as projects of neighboring departments of the company, I see that different project managers apply different approaches to estimating deadlines for completing tasks. And they do not always coincide with my attitude to this matter.
Summarizing the accumulated information on the timing of the assessment of the dates, I received the following principles for assessing the timing of work:
Observing these principles, the light becomes visible at the end of the tunnel, even before the first line of code. The direct executor (or executors, in the case of group development), himself breaks down the general task into subtasks for a more accurate assessment and indicates the risks for each of the subtasks. Thus, adding the time for each of the subtasks, you can get very optimistic deadlines for the implementation of the entire volume of work. These terms are multiplied by the risks and get the approximate time required for the entire work as a whole. The main thing is that these principles should be understood not only by the performer, but also by the customer, otherwise he will want to play with the performer in a “guessing game”.
')
In the process of performing the task, circumstances may arise that require additional time to be solved. For example, it turns out that the system architecture does not allow solving the problem “quickly and beautifully”, and the development team has to choose: to do hacks and a lot of other unnecessary work aggravating the state of the system as a whole, or to suggest the project leader to refactor the necessary modules.
Both solutions are obvious, as well as the fact that the second is more acceptable in the long run. The complexity of the situation lies in the fact that some decision makers think that everyone in the company is playing a “guessing game”: once a programmer has called a term, he has to meet it. And he does not care about the changed circumstances, it is more important for him to "shove" responsibility for the deadlines on the performer, than to try to find the optimal solution to a common problem.
Almost every project has its own architecture and its own legacy (usually “heavy”), therefore, when evaluating a task, it is reasonable to make allowances for the specificity of a project. It's one thing when the project is young, thoughtful, and the code is written with meticulous observance of all the rules and regulations of design and coding, and quite another when the project has been in continuous development for about 5 years, for which dozens of developers have changed, who have written hundreds of thousands of lines of code just to make it work. ”
The trickier the architecture and the more sloppy the existing code, the greater the risk of not meeting the deadlines for the task. In such cases, I see a solution in entering the special coefficients, by which the preliminary estimate of time for the task is multiplied.
No matter how much experience a person sets a task to a developer, he can only “figure out” the time for its implementation, too many nuances need to be taken into account in each specific case: new functionality or refinement of the existing one, flexibility of the system architecture and quality of the existing code, specificity of the approach to problem solving in a specific project.
And if the task director does not have a technical education, he can only guess the timing of the task. And he can do it, perhaps out of curiosity - guessing or not, because such an assessment has no practical value.
The fact is that some project managers are trying to personally set the deadlines for the programmer to perform a specific task, which is absurd in principle. The roots of this ignorance come from a lack of understanding of the specifics of work in the IT sphere: only the system administrator can estimate the time for which he will set up the server, and only the programmer can tell the time that will be spent on the task. The job of a manager is to manage tasks, but the processes within a task are no longer in his competence.
There are a number of tasks that should provide for the possibility of transferring functionality to other projects. If a company has several projects and the estimated task must be completed within each of them, it is time to reconsider the assessment of the timing and complexity of this task.
First, the requirement of "universality" should be stated immediately, and not after the task has already entered the implementation stage. If the customer wants to make the functionality universal at one of the later stages of development, this will lead to a rewriting of a considerable part of the code and, consequently, to a revision of the terms.
In my practice, there was a case when, after the completion of a complex mechanism for one of the projects, the customer wanted to apply it on another project and, having received an answer about the specificity of the task, complained that the functionality was not made universal. But this is a difficult case ...
Separately, I would like to mention the cases where the task designer (the customer) considers himself a professional, although in fact he does not even claim to do so. Such a customer does not believe in anything outlined in this article and believes that he is able to estimate the deadlines for completing the task to the minute, even without having a sufficient amount of technical knowledge.
It is better to refuse to deal with such tyranny. This is the best way for everyone: the performer gets rid of unrealistic deadlines, the customer, after numerous attempts, will still moderate his “professionalism”.
In my memory there was a case when the management wanted to “freeze” one sluggish and absolutely unprofitable project, after some refinement of the functionality. The programmers were asked to evaluate the problem, they rated it without risks - they gave out a very optimistic, minimum period. When they began to "dig" they realized that they had fallen for serious refactoring. After sleepless nights in the office and work on Saturdays and Sundays, the deadlines were eventually met, but with minor deficiencies. For these deficiencies from the authorities came the verdict: the programmers frustrated the terms they named themselves. There is a game of "guessing", no one wanted to hear about any risks.
The programmers themselves set themselves up, and in the end they were additionally also accused of unprofitability of the project and carelessness, and the management itself, however, looked good at the meeting with the investor, blaming the unprofitableness of the project on the disorder of the development team.
But, watching many projects - third-party, about which they write in articles and blogs, as well as projects of neighboring departments of the company, I see that different project managers apply different approaches to estimating deadlines for completing tasks. And they do not always coincide with my attitude to this matter.
Principles
Summarizing the accumulated information on the timing of the assessment of the dates, I received the following principles for assessing the timing of work:
- The final assessment of the task can only give a direct performer;
- Time estimates are always too optimistic;
- It is impossible to estimate the whole time for a task that requires crushing into subtasks.
Observing these principles, the light becomes visible at the end of the tunnel, even before the first line of code. The direct executor (or executors, in the case of group development), himself breaks down the general task into subtasks for a more accurate assessment and indicates the risks for each of the subtasks. Thus, adding the time for each of the subtasks, you can get very optimistic deadlines for the implementation of the entire volume of work. These terms are multiplied by the risks and get the approximate time required for the entire work as a whole. The main thing is that these principles should be understood not only by the performer, but also by the customer, otherwise he will want to play with the performer in a “guessing game”.
')
Guessing game
In the process of performing the task, circumstances may arise that require additional time to be solved. For example, it turns out that the system architecture does not allow solving the problem “quickly and beautifully”, and the development team has to choose: to do hacks and a lot of other unnecessary work aggravating the state of the system as a whole, or to suggest the project leader to refactor the necessary modules.
Both solutions are obvious, as well as the fact that the second is more acceptable in the long run. The complexity of the situation lies in the fact that some decision makers think that everyone in the company is playing a “guessing game”: once a programmer has called a term, he has to meet it. And he does not care about the changed circumstances, it is more important for him to "shove" responsibility for the deadlines on the performer, than to try to find the optimal solution to a common problem.
Individual approach
Almost every project has its own architecture and its own legacy (usually “heavy”), therefore, when evaluating a task, it is reasonable to make allowances for the specificity of a project. It's one thing when the project is young, thoughtful, and the code is written with meticulous observance of all the rules and regulations of design and coding, and quite another when the project has been in continuous development for about 5 years, for which dozens of developers have changed, who have written hundreds of thousands of lines of code just to make it work. ”
The trickier the architecture and the more sloppy the existing code, the greater the risk of not meeting the deadlines for the task. In such cases, I see a solution in entering the special coefficients, by which the preliminary estimate of time for the task is multiplied.
Mind games
No matter how much experience a person sets a task to a developer, he can only “figure out” the time for its implementation, too many nuances need to be taken into account in each specific case: new functionality or refinement of the existing one, flexibility of the system architecture and quality of the existing code, specificity of the approach to problem solving in a specific project.
And if the task director does not have a technical education, he can only guess the timing of the task. And he can do it, perhaps out of curiosity - guessing or not, because such an assessment has no practical value.
The fact is that some project managers are trying to personally set the deadlines for the programmer to perform a specific task, which is absurd in principle. The roots of this ignorance come from a lack of understanding of the specifics of work in the IT sphere: only the system administrator can estimate the time for which he will set up the server, and only the programmer can tell the time that will be spent on the task. The job of a manager is to manage tasks, but the processes within a task are no longer in his competence.
Versatility
There are a number of tasks that should provide for the possibility of transferring functionality to other projects. If a company has several projects and the estimated task must be completed within each of them, it is time to reconsider the assessment of the timing and complexity of this task.
First, the requirement of "universality" should be stated immediately, and not after the task has already entered the implementation stage. If the customer wants to make the functionality universal at one of the later stages of development, this will lead to a rewriting of a considerable part of the code and, consequently, to a revision of the terms.
In my practice, there was a case when, after the completion of a complex mechanism for one of the projects, the customer wanted to apply it on another project and, having received an answer about the specificity of the task, complained that the functionality was not made universal. But this is a difficult case ...
Hard case
Separately, I would like to mention the cases where the task designer (the customer) considers himself a professional, although in fact he does not even claim to do so. Such a customer does not believe in anything outlined in this article and believes that he is able to estimate the deadlines for completing the task to the minute, even without having a sufficient amount of technical knowledge.
It is better to refuse to deal with such tyranny. This is the best way for everyone: the performer gets rid of unrealistic deadlines, the customer, after numerous attempts, will still moderate his “professionalism”.
Story
In my memory there was a case when the management wanted to “freeze” one sluggish and absolutely unprofitable project, after some refinement of the functionality. The programmers were asked to evaluate the problem, they rated it without risks - they gave out a very optimistic, minimum period. When they began to "dig" they realized that they had fallen for serious refactoring. After sleepless nights in the office and work on Saturdays and Sundays, the deadlines were eventually met, but with minor deficiencies. For these deficiencies from the authorities came the verdict: the programmers frustrated the terms they named themselves. There is a game of "guessing", no one wanted to hear about any risks.
The programmers themselves set themselves up, and in the end they were additionally also accused of unprofitability of the project and carelessness, and the management itself, however, looked good at the meeting with the investor, blaming the unprofitableness of the project on the disorder of the development team.
Source: https://habr.com/ru/post/52472/
All Articles