A great way to learn how to evaluate project work.
It's no secret that the best way to learn how to do something well is to practice all the time. The same is true of project performance evaluations. But it is not enough just to evaluate. It is necessary then to track the real result, analyze it and draw conclusions so that your assessment methodology is constantly improved. Without this important component, you will never learn how to evaluate cool. But what if you find some way to train in the ratings "on cats"? Moreover, as often as possible and more intense. This method will be discussed in the article ...
Some time ago I wrote an article about how you can significantly improve your assessment skills using the proper organization of your working time and Pomodoro techniques. Now we will talk more about the completely non-development-related area of ​​life of most of us — movement around the city. We all do it one way or another, someone on public transport, someone on a car. And at least a couple of times a day. Why not use your trips to train grades?
Every time when you are going to go somewhere, you ask yourself the question: “in what time will I be there?”. To answer this question, assessment mechanisms are included: you remember your past trips, look at traffic jams on the map, analyze the condition of the car and other factors. As a result, you have a certain assessment. Is she accurate? Unfortunately, people are divided into punctual and not very. In punctual, this assessment will be more accurate, perhaps additionally a buffer is placed on various risks. Therefore, they most often arrive on time and it is pleasant to deal with them.
')
So, the method is very simple:
I saw a lot of similarities in the process of getting around the city and developing software.
Firstly, it seems that the purpose and scope of work is clear and transparent - you know the exact address and you have a map. But how exactly the traffic situation will look like and what problems you will not be able to predict. It is the same in the development - everything seems to be clear, but as the work is done a lot of things can happen, which is not easy to predict.
Secondly, a lot depends on external factors - other drivers, traffic accidents, traffic lights, etc. The development also has testers, analysts, customer, manager and other roles that can significantly affect the timing of work. And then there is the technical side of the issue - new tools and frameworks, defects in someone else's code, hardware ... Everything that depends on you very little, but the impact on your work is very large.
Thirdly, a large share of success depends on the skill and knowledge of the driver. Which route to choose, in which lane to reorganize, where to cheat and go around the traffic jam. In the development of individual qualities of the performers are no less important - experienced developers are able to vary the solution and look for workarounds.
What does such a method of evaluation give? After all, its results and experience gained are not applicable to the field of development.
First of all, you learn to be much more realistic and kill in yourself the optimism of the developer, about whom you have already written . Failed estimates force you to work on errors and take into account various factors, lay temporary buffers for all sorts of risks. The second advantage is working with these very risks . You analyze them and assess the impact on your estimates. This forces you to ask yourself questions when evaluating other work: “What can go wrong? What are the risks and how will they affect the execution time? What can I do to protect myself? ” This is a very useful quality for the developer, which allows him to work more predictably and reliably. Finally, you begin to understand that it is not the plan itself that is important, but the planning process . When you try to give an assessment, you ask yourself many useful questions, think through the main strategy, alternative scenarios. And this is the most important. After all, with so many external factors, any plan is a very fragile design. But the readiness and ability to adapt to the current conditions without disrupting ratings is a very competitive advantage for the developer.
Despite the fact that software development is a very difficult and difficult to predict area, find similar models in other areas and practice them. Learn from your mistakes and do not repeat them in the future! Well, good luck on the road ...
Some time ago I wrote an article about how you can significantly improve your assessment skills using the proper organization of your working time and Pomodoro techniques. Now we will talk more about the completely non-development-related area of ​​life of most of us — movement around the city. We all do it one way or another, someone on public transport, someone on a car. And at least a couple of times a day. Why not use your trips to train grades?
Every time when you are going to go somewhere, you ask yourself the question: “in what time will I be there?”. To answer this question, assessment mechanisms are included: you remember your past trips, look at traffic jams on the map, analyze the condition of the car and other factors. As a result, you have a certain assessment. Is she accurate? Unfortunately, people are divided into punctual and not very. In punctual, this assessment will be more accurate, perhaps additionally a buffer is placed on various risks. Therefore, they most often arrive on time and it is pleasant to deal with them.
')
So, the method is very simple:
- before the next trip, give a temporary assessment;
- as you go, compare it with realities and try to change the plan on the fly to invest in this assessment;
- remember the circumstances that prevented you and how exactly they affected your assessment;
- on arrival, summarize and draw conclusions.
I saw a lot of similarities in the process of getting around the city and developing software.
Firstly, it seems that the purpose and scope of work is clear and transparent - you know the exact address and you have a map. But how exactly the traffic situation will look like and what problems you will not be able to predict. It is the same in the development - everything seems to be clear, but as the work is done a lot of things can happen, which is not easy to predict.
Secondly, a lot depends on external factors - other drivers, traffic accidents, traffic lights, etc. The development also has testers, analysts, customer, manager and other roles that can significantly affect the timing of work. And then there is the technical side of the issue - new tools and frameworks, defects in someone else's code, hardware ... Everything that depends on you very little, but the impact on your work is very large.
Thirdly, a large share of success depends on the skill and knowledge of the driver. Which route to choose, in which lane to reorganize, where to cheat and go around the traffic jam. In the development of individual qualities of the performers are no less important - experienced developers are able to vary the solution and look for workarounds.
What does such a method of evaluation give? After all, its results and experience gained are not applicable to the field of development.
First of all, you learn to be much more realistic and kill in yourself the optimism of the developer, about whom you have already written . Failed estimates force you to work on errors and take into account various factors, lay temporary buffers for all sorts of risks. The second advantage is working with these very risks . You analyze them and assess the impact on your estimates. This forces you to ask yourself questions when evaluating other work: “What can go wrong? What are the risks and how will they affect the execution time? What can I do to protect myself? ” This is a very useful quality for the developer, which allows him to work more predictably and reliably. Finally, you begin to understand that it is not the plan itself that is important, but the planning process . When you try to give an assessment, you ask yourself many useful questions, think through the main strategy, alternative scenarios. And this is the most important. After all, with so many external factors, any plan is a very fragile design. But the readiness and ability to adapt to the current conditions without disrupting ratings is a very competitive advantage for the developer.
Despite the fact that software development is a very difficult and difficult to predict area, find similar models in other areas and practice them. Learn from your mistakes and do not repeat them in the future! Well, good luck on the road ...
Source: https://habr.com/ru/post/179281/
All Articles