Useless project summaries

Generally, the software development organization conducts a project summary meeting at the end of the software project, summarizes and analyzes the successes and failures of the project based on the statistical data of the project, and then develops an improvement plan, in the hope that the next project can do better. However, over the years, comparing the current data with the original data, we can come to the conclusion that there have been no improvement or even signs of regression over the years.

 

This occurs in many places. Why does this happen? I will analyze the causes of useless project summaries and useless process improvement suggestions and propose solutions.

 

The project kickoff was originally intended to comply with Dai Ming ring (P-D-C-A) for improvement. It summarizes the success or failure of the project and develops detailed action plans to improve the team's Capability Maturity.

 

The project summary will consist of the following elements:

Time, location, people, data, analysis process, analysis results, improvement suggestions, Action Plan, improvement process supervision, improvement effect evaluation, and conclusion.

 

Some organizations do not even have comprehensive elements. For example, there is no improvement plan after project summary.

For organizations with comprehensive elements, they still have the following problems:

1. Time incorrect

The project summary meeting time for most organizations is incorrect. They choose to convene a meeting after the project is completed and the data statistics are complete. This is a wrong time. Basically, software projects require more than half a year, and people cannot remember a large number of things, and the details can be completely restored, especially after such a long time. Therefore, project summaries often become project review meetings.

When words like the following frequently appear in expressions, this problem is basically explained.

"At that time, it seems like" I remember at that time "" This is probably the case"

How can we make accurate judgments based on such information?

 

Therefore, the project summary should be held frequently in a short period of time. The recommended cycle is 4-6 weeks.

In conclusion, we can remember what happened some time ago. In this case, we can correctly point out the problems and give reasonable suggestions for improvement.

However, opponents believe that the summary of the detailed design does not helpCodeImprovement in writing. In this regard, I will gradually elaborate on the basic mistakes in my opinion in the absurd process.

 

 

1. Incorrect candidate

Some organizations have SQA. Based on the requirements of the overall improvement of the organization, SQA is called during the project summary meeting, which helps to analyze the data. For example, the overall productivity of the Organization is 300 rows/person-month, however, if the productivity of a team is 1000 rows/person/month, SQA will propose that the data seriously exceeds the average level and conclude that the process is not standardized, therefore, an efficient team is required to reduce the development speed. This absurd conclusion is caused by reference to the absurd standards, and SQA's role is basically rewards and punishments, so it is a big mistake to call SQA to participate in the project summary. Specifically, why is SQA a penalty? I will explain it in detail in SQA.

 

For a team with hundreds of people, we didn't want everyone to attend the meeting, so we only called several "managers" to attend the meeting. So we started a discussion, the result is a set of irrelevant conclusions.

 

1. Data is of little significance

Currently, the team's statistical data is often not of reference value, even if the data is true and accurate, because the meaning of the statistical data itself is wrong. For details, refer to "Does your project collect such data?"

 

The conclusions made based on meaningless data are also meaningless, and the proposed improvement scheme is also irrelevant.

 

1. Analysis Process

Analyze the cause to analyze the root cause. Many cause analysis processes tend to stay on the surface and do not want to conduct in-depth analysis. For example, the cause of a bug is classified as a code writing error, which does not help improve code writing, the reason for incorrect code writing is that the design is incorrect, the understanding is incorrect, the technical strength is insufficient, or what is the other reason. When analyzing the cause, you should constantly ask why until you find the real cause and can formulate improvement measures. Otherwise, the analysis that stays on the surface cannot produce the correct improvement measures.

 

1. Insufficient knowledge, unable to analyze the real reasons

Although some organizations can constantly ask why and then develop improvement measures, due to their lack of knowledge, the routes for analyzing the reasons have produced errors and can only get wrong conclusions.

There is a very vivid example of an analysis process about error handling due to a lack of judgment conditions.

For the convenience of subsequent instructions, I added a letter number for each analysis step.

1. The cause of the bug is that the Code is written incorrectly.
2. The code is incorrectly written because the design is incorrect.
3. The design error is caused by insufficient conditional analysis.
4. The reason for insufficient conditional analysis is that the week is not taken into consideration.
5. The reason for the lack of weeks is that the checklist for secondary analysis is missing.
6. The improvement measure is to establish an analysis auxiliary tool-condition disagreement Checklist

 

This process seems impeccable. However, the fundamental problem in this analysis process lies in the lack of a knowledge system. We asked another expert to analyze the cause of the problem. He analyzed it in this way. To distinguish the above process, I added the number 1 to the letter.

A1. the cause of the bug is the code writing error.

B1. the reason for incorrect code writing is that it violates the single responsibility principle.

C1. the reason for violating the single responsibility principle is that developers lack relevant knowledge.

D1. the improvement measure is to conduct object-oriented technical training.

 

Why are the two analysis processes starting from the same point but reaching different paths. Because the former lacks relevant knowledge, he believes that the problem can be solved by adding relevant checklists to the design process. However, the complexity of each case is different. How can I use a checklist to cover all the branches?

 

In fact, the IF-else nesting of the original code can be replaced by an object-oriented call and several overloading, which can fundamentally avoid the problem of missing conditions, this avoids the direct cause of the problem: there are too many variables that affect the logic. However, the first analyst did not understand that object-oriented technology can solve the problem well, so he came to a wrong conclusion along his own ideas.

 

1. Improvement measures cannot be implemented

 

The improvement plans of some organizations are general, such as improving design capabilities and enhancing communication.

Some are a little specific, but still unable to guide the action, for example: Increase the code review time.

Some are very specific, but cannot be implemented;

Some can be implemented but there is no owner;

Some have owners, but no completion time is set;

Some have time to complete, but there is no way to test the improvement effect;

 

The improvement measures should be specific and feasible, and the improvement effect should be tracked.

First, you must be specific.

Avoid using: to use words that are vague, such as reinforcement, improvement, and elevation, use specific actions such as addition, reduction, replacement, crossover, and establishment.

 

Second, feasible.

If the set improvement plan cannot be executed, the analysis cannot be improved.

 

There must be a time limit again.

Improvement measures cannot be extended indefinitely. Clear execution time restrictions are required, and milestones and phased improvements are also required if necessary. Some tasks are not achieved overnight.

 

Then there must be a person in charge.

If the person in charge is not arranged for improvement measures, they are often shelved and ignored. Finally, there is no real improvement action.

 

Finally, you must check the results.

If the improvement measures are implemented but the improvement effect is not checked, it is impossible to know whether the improvement measures are effective.

 

1. Invalid Improvement Measures

Ineffective improvement measures are often caused by one or more of the preceding reasons. For example, "demand changes lead to an increase in working hours in the later stage, resulting in project delays ." The proposed improvement measures are to freeze project requirements as soon as possible. However, the customer cannot freeze project requirements because the requirement is a guess work. This improvement measure cannot be implemented at all, so it will be ineffective.

 

 

1. Misleading management personnel

 

A. The error of absolute expression

A common question raised by managers is: "If XXX is the cause of the problem, can the problem be solved if this problem is solved ?" This sentence is an absolute rhetorical question. No one will answer yes. The cause of the problem is often caused by many factors. Not unilaterally. Therefore, no one can solve this problem. Therefore, a corrective measure is rejected.

 

B. unwilling to make changes to inherent but fundamental things

For many projects, the root cause is a process error, but this conclusion can be drawn when there is little analysis. On the one hand, there are some reasons for lack of knowledge. On the other hand, even if some people raise problems in the process, managers tend to raise objections to them in order to maintain their dignity and do not want to admit such problems, let's talk about him and shirk responsibility. Sometimes there are also personal attacks.

 

C. reluctant to admit that tools are lagging behind

Managers like to cover up the problem of tool backwardness in one sentence: "understanding the principle is more important than using tools ". This sentence is correct.

 

 

The above are the Analysis and Improvement Measures for the summary meeting of useless projects. What opinions do you have?