Today, a friend asked me how programmers should assess the situation. I thought about it and summarized the performance appraisal of General developers in my understanding.
Significance of assessment
The first premise is that,Assessment is a means rather than an aim. I have always felt that for a team, there are two basic goals: one is to complete their own tasks, and the other is to improve the capabilities of the entire team. These two goals promote each other to achieve a spiraling upward development. The assessment is onlyBetter understanding of work conditions and team conditions, clearer and more accurate understanding of self-analysis, and technical means for improvement and Improvement.
Therefore, the evaluation of developers has two meanings for the team: it is not only a data support for the performance bonus honors of team members, but also the basis for further development of the overall team building.
For individuals, there are also two meanings: horizontal comparison with other members in the team to see the gap and continue to work hard, vertical comparison with their own different time periods to see the progress footprint.
In terms of design,The assessment should be linked to the company's rank-level job sequence and performance bonus systemsDifferent Levels and positions should have different requirements and assessment methods, and the assessment results should be implemented through some rewards and punishments. There is no rewards and punishments assessment, just an empty form of discussion on paper.
Assessment Principles
The programmer's assessment can generally be composed of the R & D management process, project and department benefits, the company's attendance system, and subjective assessment and evaluation indicators. Because programmers often work overtime without charge (no way, isn't it true ?), The company's attendance and other systems should not be very useful to programmers, and the rest is mainly about the process, benefits and evaluation.
I think there are several assessment principles:
1. Combination of subjective and objective elements
In general, we want reliability to be more objective and better. However, developing indicators to collect objective data, analyze and sort out is complex for it R & D. In particular, R & D itself is not standardized, technical capabilities are poor, immature teams, large variables, and non-standard processes, making it difficult to measure many things. Subjective things are inevitable. However, subjective assessments should be as few as possible to avoid any influence on the entire team, such as those in the team.
2. Reasonable quantification
Quantifiable data during R & D should be quantified as far as possible. The measurement is too rough, and the results are not obvious. The measurement is too small and the requirement for collecting indicator data is relatively high, which may even have a certain impact on R & D. Therefore, quantitative indicators should be combined with the actual R & D process to make economic choices.
3. Bidirectional and multi-direction Evaluation
For behaviors that a superior can directly evaluate a lower-level employee, the lower-level employee should be able to score the lower-level employee collectively. For the subjective evaluation part, the evaluation should be 360 degrees. For a developer, the developer can first score the subjective evaluation part, review the evaluation by the supervisor and colleagues in the team to determine the final evaluation.
4. Should we develop the process or business results?
The evaluation programmer should focus on the process rather than the business results.The business result should be the responsibility of the business management personnel. Simply put, who is responsible for making decisions (or who is benefiting from the responsibility ). Therefore, I have always felt that hard-pressed programmers should be responsible for their own work. A programmer is a good programmer who can do a good job, write code well, change bugs quickly, produce more data, and have high quality. Of course, the requirements for technical leader and effecect should be higher. Of course, the quality of the business is generally related to the performance of the company and Department. This is the source of bonus and performance. It is naturally related to programmers, but it should not be the core of the assessment. For a good Malone (generally a programmer, not up to some so-called height,R & D is the core value of a programmer.. This is exactly what we mentioned above. Different job sequences should have different requirements and assessment methods.
5. development stage and focus
Of course, the development phase of the Company or team also determines the different emphasis on the programmer's assessment.
For a team with lower-level capabilities, frequent delays, poor accumulation, and non-standard requirements, the focus of the assessment should be to improve the team's R & D capabilities and complete the task on time.
For a team that completes tasks on time, but is not standardized, has no cooperation spirit, and has no motivation, the focus of the assessment should be to guide its behavior and standardize it to achieve overall improvement of team collaboration.
For a team that has accumulated a certain amount of experience and has good relative competence and can complete the work well, the focus of the assessment should be on how to further improve the level and quality of R & D, achieve Standardization and process .......
Indicator formulation
For details about how to develop assessment indicators, let me just talk about the ideas.
1. R & D process
How many projects are involved, how much code and documentation are written, how much test code is performed, how many modules and use cases are completed, how many problems are solved, how much bug rate is, and how much reopen bug rate is, how many work delivery delays, how many work mistakes, and how many technical exchanges were made internally... And so on.
2. Business Results
How much benefit the involved project brings to the company? The Personal Work proportion is the total task volume, and the amount of income the individual brings to the company is calculated... Refer to the performance of the Department and the average performance level of each person.
3. System Attendance
Late, leave early, leave for work, and so on
4. Subjective Evaluation
Colleagues at the same level evaluate the team, the superiors, their work attitude, team spirit, technical level, innovation spirit, initiative, and sense of responsibility.
Similar data can be used as an Evaluation Indicator Based on your actual situation. And then quantize them to a certain granularity. Then, determine the proportion of each indicator and how to collect statistics. Finally, we will provide an assessment system document.
Assessment execution
With the assessment criteria and methods, the execution is left.The intensity of implementation determines whether the assessment system can play a role.. If the execution is good, you can execute and collect data while improving the assessment method. Without a strong impetus, the continuous collection of data, check & Review, the assessment will only flow in the form.