Project summary from the 401 Flight Accident Investigation

Most of the time, a project is over, whether it is successful, failed, or unsatisfactory, and lessons should be summarized. However, I always think that in the software development process, most of the summary after the end of the project is regarded as a dispensable stage. Even if the project is summarized in a decent way, there will also be a lot of ideas. The good aspects of the summary also need to be improved by writing the documents according to the template. But at last, these activities still point to the past project, so the results of the documents can only be shelved, and no one cares. Then, the next project repeats the same issues and risks.

When I was bored today, I looked at the 401 Flight Accident Investigation in Miami more than 30 years ago. This made me feel that we have a lot to learn from. Let's talk about the cause and effect of the 401 crash. When the flight was about to land, when the landing gear was put down, the indicator lights were broken. Then the captain, co-pilot, and mechanic were all playing tricks, the height of an airplane's self-driving flight dropped from 20000 feet to 900 feet. It was too late for the crew to respond. The management department has only one reason to investigate the cause of the crash. Below are the results and Countermeasures of the survey.

• At that time, both the host and other pilots put their energy on the Several dollar light bulbs. No one paid attention to the instruments and reported off-earth alarms.
  Countermeasure:Develop a CRI system to ensure that the captain, Pilot, and other personnel are responsible for each other and avoid human errors to the maximum extent.
• The ground Tower controller found that the plane height was abnormal, but suspected that it was a radar data error. His role was only to ensure a safe distance between planes.
  Countermeasure:After changing the rules, the ground conductor is also responsible for monitoring the data of the incoming planes, and can detect any exceptions in time.
• Self-driving on the plane at that timeProgramIf someone touches the rudder, the automatic drive will exit. It is this situation that caused the plane to fall in height and eventually crash. All the flight attendants did not know about this and did not have any training.
  Countermeasure: The aircraft manufacturer makes adjustments to the aircraft program to avoid program modifications caused by unintentional touch and to train flight personnel in related handling measures.
• At that time, the captain was always confused about the landing gear. He was very nervous and had a bad temper. This also infected other people and caused misoperations.
  Countermeasure: Training pilots to ensure operation consistency and remain calm without being infected by other people's emotions.

What can we see from this? These measures seem useless for us to improve software development. Except for the last one, if someone in our team makes a mistake, we need to know that this is inevitable, and people will make mistakes. However, we need to grasp two points. First, we need to clarify our responsibilities and we cannot expand our responsibilities without reason. The second is to fully understand and ensure that the owner is truly aware of the mistakes. In fact, I am talking about the fact that all of these causes have very practical and feasible rectification measures to avoid the recurrence of the same problem, therefore, these rectification measures are easily implemented.

On the contrary, if a problem occurs in a project, the common solution is to call all the personnel to hold an emergency meeting by a senior leader who seldom asks questions about the team. At the meeting, we made a burst of air and asked everyone to discuss and find out the problem and solution. Then there was a bitter conference where developers had long complained about it, it was time-consuming, heavy-duty, insufficient resources, and no external support. Then there was a big discussion about specific technical details, you know that it is easy for technicians to get stuck with technical details too early. At this time, senior leaders have been blinded and know that senior leaders generally know little about technology. In the end, you can either leave it alone, or emphasize the implementation of the company's development process and the like, and finally warn you that it will not be used as an example.

We can see that we can learn a lot from other industries and industries. In fact, the concept involves organizational improvement and self-improvement of development processes. Cmme attaches great importance to process improvement. In particular, it collects quantitative data during development to compare with the benchmark data, takes corrective measures, and enriches our benchmark data. In this way, we can make our process more reasonable, more convincing, and more feasible. For more information, see.