Five major causes of death assessed by programmers (I)

Programmers, as the core assets of the enterprise's development strength, undoubtedly won the company's consistent attention from top to bottom. Development is an intellectual-intensive industry. The feature of program development is that, at the same time, the production capacity of two developers may be dozens or even dozens of times different. Software developers have always been known for being "not easy to assess and work is not easy to quantify. In this issue, we will focus on analyzing the "Cause of death" and Countermeasures of the programmer's assessment. Before analyzing the cause of death, let's take a look at how it was born. One day, my boss suddenly thought of something-I don't understand R & D, and R & D is so important to my company. What should I do? After reading this, the boss was a little nervous. He immediately called HR to hold a meeting and arranged the focus of this month's human resources work, that is, the "R & D personnel assessment", which must be put in place and executed immediately. Well versed in the boss's intention of HR, back to the station immediately online to sell books, from how to assess, KPI practice to a stable scorecard strategy is all available, after the book hand overnight "book copy" to the system of assessment, sort out the "assessment methods for R & D personnel ". The next day, HR handed over the assessment method to the R & D Director and told him that "the boss wants to assess you. This is an assessment method. The specific indicators and KPIs should be set by the department. They should be reported to the human resources department before this week. We will report it to the president ." The R & D Director found the project manager with a "solution" that the person who even wrote the system did not understand: "the boss wants to assess us. This is an assessment method. You can set specific metrics and KPIs for your team members and summarize them to me before coming off work tomorrow ." The project manager found the programmer: "the boss wants to evaluate you. This is an assessment method. You can set your own metrics and KPIs and give them to me before noon today ." Programmers are confused and ask: "isn't the goal set by the company ?" A lot of assessments have just begun ...... Soon the assessment turned into a monthly score for the programmers in the group by the Project Manager. As a result, the boss was very satisfied: "I can finally relax. In the future, we will rely on the assessment system to manage R & D personnel. We have now moved away from the era of 'governance of The People !" HR is also very satisfied: "I don't need to understand what R & D is, or programs. As long as they know, I can deduct their money, or use their own indicators ." Others are not satisfied ...... Soon after, the company will see a rise in the programmer's resignation rate. Those who have been assessed, such as programmers, project managers, and R & D directors, are all gone, so the assessment is so dead! Next, let's talk about the five causes of death and Countermeasures for programmers. The assessment only takes the event as the core company and cannot survive without profit. The progress of R & D projects often determines the company's profit. Therefore, many assessments involve the unlimited division of projects to the programmer level. Such assessments focus only on events and focus on whether events are made, rather than on the development of people and people. Only the event-centered assessment regards programmers as machines on the production line, and there is an investment (high salary) to produce (high quality code). Programmers are treated as standard parts, that is to say, there is no need to grow too much (because all jobs are relatively repetitive), nor can there be frequent failures (often working overtime or asking for leave ). Some programmers "It migrant workers" have a lot to do with the existence of such an assessment system. This assessment system can maintain high efficiency in the short term, and long-term implementation will lead to the overall system crash. A lot of company staff are constantly changing and there is no stability at all. Part of the reason is that they have performed or actually performed an assessment with only the event as the core. Expert tips: Leo Zhang: Admit that programmers are also people, and respecting individual personality is the basis of assessment. Focusing on training, focusing on results when the project is under great pressure, and increasing programmer skills and personal development in the case of buffer is the core solution to this similar problem. In the different stages of the project cycle, the adjustment of the assessment method is a combination of assessment methods, more enable enterprises to move forward to the goal, but also to maintain the enthusiasm of programmers. Hu zhenghui: from another perspective, the most common example is that four people work together to plant trees, a dig holes, B trees, c soil, and D watering. If the assessment only takes the event as the core, when B does not plant trees, C is still filled and D is still watered. From the perspective of assessment, A, C, and D all scored full marks. Even if B scored 0 points, the average score would be 75%, exceeding 60% in passing pass, but the task of planting trees was not completed. Therefore, for an assessment that only takes events as the core, not only do programmers not feel the team, but programmers do not consider it for the team. In this case, the assessment should be adjusted to include both the events to be completed by the individual and the overall understanding of the team.