Memorial to the lost youth-a summary of the failure of the YY Project

 

Memorial to the lost youth-a summary of the failure of the YY Project

Luo Weifeng 2011-5-21

 

It's almost half a year since the previous project was launched. It's time to summarize the lessons learned.

 

First, introduce the background. Harbin Institute of Technology (Weihai) is not a very famous school. Even though it seems to us that the name is inappropriate, however, it has not been widely recognized and recognized. However, the school is still very competitive. Although the three-party joint construction is basically equal to no funding source, the school still places itself in the so-called good university position. The course schedule is still relatively tight, especially for soft schools. It is hard to imagine that the course schedule is tight. It seems that there has never been a holiday since May 1 or October 1.

 

Let's get started with the above discussion. In the first semester of my junior year (that is, the last semester), I was honored to transfer to the XX lab, and the XX lab cooperated with the company YY, so I started a project of the company yy, this is the beginning of the story.
The project is very big, but it seems like an opportunity to fall in front of our group of children. The project is divided into four groups, three front-ends and one backend. I have the honor to participate in the background and act as the team lead.
As you expected, the three front ends were successful and they did a great job. In our background, you can imagine the embarrassing situation of ibm360. Unlike failure, there is no such thing as success. Next, I will make a personal review, which is also some of the reasons for the project failure we have recognized so far. I will only draw some references for later users and draw a full stop for my half year.

 

Failure factor 1:The interface standard is frequently changed, or there is no standard.This problem can be said to be the most prominent problem in the project progress. One is our client-server communication protocol. The communication protocols of our client server appeared in 11 versions in just one month. And many are not compatible with the previous version. When the Protocol is specified, only the Protocol itself is optimized. Even if a field has no impact on the business, it is immediately replaced by the following protocol. The consequences can be imagined. The four teams are constantly changing the code to adapt to new standards, resulting in a lot of waste of people and months. The same is true in the background. The database design has been changing from scratch, from the first version to many later versions. from beginning to end, there is no set of standards that can be used for making decisions. In this regard, I personally apologize for my team and project.

Experience 1:Always ensure that there is a standard (Interface) that everyone agrees and complies with. All changes to the standard are maintained in a separate standard (Interface) without compromising the project's success or failure) development tree.All project departments are implemented in accordance with this established standard, which must be recognized by everyone. All standard objections and unexpected ideas during the development process are loaded into the standard (Interface) Tree of the Development edition without affecting the normal progress of the project.

 

Failure factor 2:Schedule by month.Man-month is an old problem and one of the most challenging aspects of team leader, and I have followed suit here. I am also embarrassed about the monthly schedule for the project team. We have a clear division of labor for the development of four people in the background team. In the early stage of development, I invested too much in the discussion of client-server communication interfaces, so that after half a month, Our backend is still not started, the database design follows the old path of frequent standard changes. What's even more fatal is that my team leader is not very familiar with the capabilities of the team members I depend on. Sometimes, they mistakenly estimate their production capabilities. This question is like: Can we guess that humans can win 100 million records in 100 9 s 58 based on the bolt's-meter records. Another problem is that we can correctly estimate the available time, because we mentioned in the background that the junior year is very busy.

 

Experience 2:Team
The leader should be able to clearly understand the abilities and project complexity of each member, and make appropriate monthly staffing arrangements.After the project is over, I tried to use management software like a project. However, the real problems are not as simple as the Project software. When I was in the ZZ lab, the project diagram was standard and regular enough. But when I did it, I found that the actual problem was sometimes several times or even dozens of times more complex than this one. For example, you have not considered the days when a comrade or a few people caught a cold, pregnant women, and friends who came here.
This is a test of team leader and has no experience to learn from. In this regard, I have failed to do so and I apologize to my team members.

 

Failure Factor 3:Serious lack of communication.A successful project requires a lot of communication, but the dream of communication errors in our project is replaced by "detailed documents. It is true that this can be replaced. However, there is a high risk because you cannot guarantee the availability and authority of the document. In addition, communication can detect early project route errors. For example, when I talked to a buddy during the project summary, he clearly told me that the standard (Interface) if the problem is a problem with the project, it may be possible to avoid such a low-level problem if I can communicate in the first place.

 

Experience 3:Always think about integrating with the team.Team
Leader cannot live proudly. The first step of communication is the relationship between Members. If you have no relationship with Members who want to communicate with you, all the rest will be nonsense.

 

Failure factor 4:The pursuit of perfection is premature optimization.I borrowed a sentence from someone on csdn to "bring the gift of God to the extreme ". This sentence is very good, but it is fatal to put it in software engineering. Because of the pursuit of perfection, premature optimization, regardless of documents or procedures, is disastrous.

 

Experience 4:Always prepare for the development of the second version, and do not optimize or add features in advance without affecting the project's success or failure.Do not add any secondary things of the project to the project at one time. The smaller the things, the more disastrous the last, this is the so-called scope control of software projects. For this project, the things we do on this side are indeed fucking formal, the documents are complete, and the projects are all very standard, but we still cannot run the deadline. The BB team developed code in parallel with us. Their code is really bad, there are very few documents, and there are not as many functions as we can, but they can run it, maybe in a certain sense, the Development on our side is like a bloated big fat man. It is very difficult to take a step forward, so many team members will not come to the lab at all.

 

Failure FactorsV:Team
Leader's excessive interference with team members.
This may be mostly my reason, because I will review a lot of code, and it is a perfect person. For example, the design status should be tested through logical operations, but some of them are enumerated directly, and I am not calm enough to follow my ideas. It's really naive to think about it now. It can be a metaphor: Do you think the success or failure of a project is important to the implementation method?

 

Failure Factor 6:Too much emphasis on the document itself.One thing you need to know is, why documentation?
This is critical to the document. We have hand-written documents of nearly 10 MB throughout the project development process. We mistakenly put the document above, but ignored communication. The document is a standard. On the one hand, it is a substitute for some exchanges, and on the other hand, it is a reference for future generations. We have documented simple problems, but these simple problems can be easily solved during the development process. We attempted to use documents to reduce communication in the same way as ibm360. The so-called software engineering authority is not applicable in many cases.

 

Experience 5:Agile development.First, declare that agile development is not without documentation. Also, I am not an expert in Agile development. I will make a special trip to learn this thing if I have time.
We all know that the software industry has suddenly arrived in the world for nearly half a century. Before that, engineering theories in automotive engineering, electronic engineering, and other fields were perfected, most of the coders who initially engaged in software came from these fields. As a result, people began to use the existing Engineering Control Theory for software engineering. They are clearly divided into parts and stages, such as the requirement analysis, design, and coding that we are familiar. However, "no silver bullet" seems to be telling us that this road cannot be achieved. Although the intention of "no silver bullet" is not like this, with the development of the software industry, people are increasingly aware that software engineering is different from traditional engineering control, so agility is born. I will not elaborate on it here, because I have not studied it carefully, but it gives me hope.

 

I wrote so many things in one breath. As a result, I am very sorry to my team. Secondly, I will provide some reference for people like me. At the same time, I will stay here to comfort those years.