Control development costs

In the afternoon, I heard Xu Yanchang say, "I have just finished the report I Want To Make (and changed it n times). Today, I suddenly picked up the print board sample and told me to redo it. The customer also called and said, 'The report you made yesterday is complete? Don't do it if you don't do it. Don't use '". Xu is really crying.
Similarly, the project manager immediately shouted when he saw what was not pleasing to the eye. Program Personnel to modify it, and then change it. In addition, the customer's needs are not clearly understood, and the amount of time it takes to modify the software is countless.
In our company, "diligence" and "patience" are the virtues of being promoted. If a person makes changes to a bug, he can work overtime every weekend. He is a good employee (if not, he can be promoted ). In fact, everyone ignores this point. Doing the right thing is more important than doing the right thing. A programmer who does the right thing is a programmer who does the right thing with half the effort.
Of course, to control the cost of software, the source is the leader, and the leader should do the following:
1. Perform their respective duties. It is best not to ask programmers to input data, test data, and answer customer complaints. Because dedicated people will do faster and have lower costs. This is an opportunity cost issue. During my work period, our leaders often asked me to input data and run the process to see if there were any such errors. Chen Jianming was often asked by employees of the Implementation Department: "What are you doing today? What is your arrangement? Why haven't I changed the bug ?" (This should be the focus of Chen's pm)
2. Understanding perfection is not our goal (but to make the right software at the right cost ). Before asking programmers to modify bugs, they must take into account the cost-effectiveness of changes (especially the change to what it looks like), rather than losing their brains to programmers. Similarly, when the project manager receives complaints from customers or implementers, it should first consider whether the bug should be resolved, how to solve it, and how to solve it.
3. Requirement! Yes! This seems to be a dead point of our company. Taking the XX logistics management software I am working on as an example, this project has already been installed for the customer. As a result, the customer found several problems: the business object is incorrect: not only bonded parts, but also non-bonded parts; one of the three types of accounts Algorithm No. After some documents are approved, the change function needs to be added; some one-to-one relationships need to be changed to one-to-many. These are almost some of the changes in principle demand, meaning almost all the reports and many front-end program modifications. The famous saying goes, "fixing a problem in the later stage of the software requires 4-5 or more energy than the early stage ". Although our company has a dedicated implementation team, there are also project requirements and design documents. That is, the project manager always requires employees to write code within one week of the project, rather than doing analysis. Is this really fast?
[Author] xxpyeippx [author]