Why do software projects always fail? Please tell me.

The technical route is wrong and technical problems are encountered.

Project management error, software out of control.

Due to some personnel changes, the project failed. Up to now, it is generally summarized as "due to the low level of software engineering", and then the prescription is "developing by software engineering mode". But specifically, there are many schools, models and methods in software engineering, and these methods are contradictory and contradictory. What do we do? So developers are stuck in the quagmire of software development. The bigger the project, the longer the time, the more people and the more situations. I think the essence of the problem is not the above reasons, but the relationship between people is artificially distorted in the process of software development. This is the root cause of the failure of many software projects. The following details how the relationship between people is distorted step by step. First, the relationship between developers and customers is the relationship between providers and users of software products. One sells things and the other buys things. The relationship between them is equal, fair trade and childlike innocence. This is a normal and reasonable relationship between them, but now? At present, the relationship between developers and users is seriously unequal. In order to get orders, developers often compromise, give up the principles they should adhere to, bargain with each other in bidding, and even use some aboveboard means to get orders, putting themselves in a passive position. Many developers have such a slogan "customer-centric", which is not only said but also done. The problem is an unequal relationship. I can see on the Internet that a developer's tender for a project has a big box. Do you need two people to carry it to the meeting? Excuse me, who will read this tender? Don't developers even have this minimum common sense? Why write when no one is reading it? Does the developer really think that the customer will be stupid enough not to know that you are lying to him? So who is cheating in writing such a tender? I'm afraid I'm deceiving myself! Investigate the causes of this abnormal situation, both developers and users. On the one hand, the reason for developers is the influence of the economic environment. Everyone does this, just following the crowd. On the other hand, I want to please customers in this way, leave a good influence on customers and get orders. On the other hand, customers' reasons are often out of ignorance and fear of computers, lest they should be responsible for the losses. Therefore, they are inherently distrustful of developers, hostile, and psychologically inclined to find faults and problems. The result is fear at both ends. When they first came into contact, they were cautious for fear of problems. Once there is a conflict, developers will retreat blindly, customers will push their luck, and finally things will be a mess. Developers are afraid of offending customers, but they don't realize that sometimes conflicts with customers are inevitable. Customers are afraid that developers will deceive themselves, so they try again and again. The more concessions developers make, the more they feel cheated. Developers' concessions are often not trusted by customers, but they gain greater distrust. Because developers don't believe in themselves and deceive themselves, they can't win the trust of customers in the end. After all, software development is done by developers, so they should and must decide the progress and content of the project, but now they often compromise because of customer pressure. Failure is inevitable, success is a fluke. The conclusion is that in software development, the developer should be the center, not the customer. The customer's opinion is only reference and reference, not the golden rule. We should not be afraid of conflicts with customers, but should analyze the causes of conflicts and treat conflicts as symptoms of problems instead of simply eliminating conflicts themselves. For example, developers are like doctors, and customers are like patients. When they are sick, they come to see a doctor. If the patient has doubts about the doctor's medical skills and refuses to cooperate with the doctor, the condition will only deepen, not heal. The relationship between developers and customers is a good cooperative relationship, and it should not be competitive in the field of cheating business. The goals of both sides are the same, not the opposite. The contradiction between the two sides is based on the same interests, not irreconcilable contradictions between the enemy and ourselves, so we should go away quickly. The software can't succeed. What we usually call "frequent changes in requirements" is often because the relationship between developers and customers is incorrect and the requirements have not changed, but developers accept the wrong requirements put forward by customers, but dare not raise objections. Only after doing it did we find that there was a problem with the understanding between the two sides. 2. The relationship between salespeople and technicians As the saying goes, the ass decides the brain, and one person plays different roles. He will naturally think more about his own immediate interests when considering problems. As for the trouble that this may bring to his colleagues, he can't care so much. Within the developer, the relationship between sales staff and technicians is also very strange. In order to improve the enthusiasm of sales staff, many companies reward sales staff with commission, and the basic salary is set at a very low level. In this way, in order to get the order of the project, we often succumb to the pressure of customers, make many promises that are difficult to keep, or casually agree to the requirements of customers because we don't know the technology. When the contract is signed and the project is in the development stage, the customer will use these promises to ask the developer to honor it. As a result, the developer was very passive and angry with the sales staff, and told the customer that these requirements could not be met, and the customer was furious. How can you people change your face as soon as you get the money The problem is, because the sales staff made too high a commitment without considering the future realization of the technicians, the result may be to get the order. However, because the salesmen and technicians have different caliber, the customers finally feel at a loss, feel cheated, and then get angry with the technicians. The relationship between cooperation and trust has gradually become the relationship between confrontation and deception. One day, someone told me a joke. It is said that one-third of computer companies are part-time, one-third are muddling along and one-third are liars. The last third refers to sales. Excuse me, when the company's sales are regarded as liars by others, doesn't it mean that the whole company is a liar? Is it possible to succeed in doing business with swindlers? Isn't it normal for a project to fail? Salespeople and technicians should be two wheels of a bicycle, and their relationship must be mutual cooperation and support, not mutual demolition and confrontation. Once they confront each other, it will bring disastrous consequences to the reputation of the whole company. Third, the relationship between the project manager and the developer should have been mutual solidarity and mutual help. * * * Faced with the relationship between problems, many project managers distort this relationship into a mandatory relationship between management and being managed, force developers to accept it with various rules and regulations and various management methods, put themselves on the opposite side of developers, alienate them from their virtues, and even call it "quantitative management and scientific management". In this poor management, developers have no choice but to passively accept poor management. Either resign and protest. Once this happens to a project, it is difficult to succeed. The problem was not obvious at first. Nowadays, with the proliferation of various specious theories such as MBA, Indian experience and software factory, many people, especially many managers who don't understand software development at all, change books and add calendars, strengthen the management of developers by almost harsh means, and put forward various ridiculous quantitative indicators to measure developers. Coupled with the theoretical basis, developers who dare to resist their practices are fired in order to solve problems, resulting in a very absurd reality, that is, many companies would rather use students who have just graduated without any experience than engineers with work experience, which is euphemistically called: easy to manage, ha, easy to be deceived. Excuse me, under the influence of the relationship between managers and developers, is it possible for a software project to succeed?