What if the customer of the software project refuses to accept the application?

"We decided to carry out the acceptance in April 28th day of next month". The customer casually told me this sentence, which left me confused, the three-month acceptance date was finally settled. Looking back at the past three months, I have spent a lot of effort. Although the date has been set, it is three months later than the date specified in the contract.

The software development project I was in charge of was relatively smooth, and the test work was completed early. However, the customer was reluctant to accept the problem because the customer was stuck on a small problem and said that the problem was fixed before acceptance. This small problem does not occur in most cases, but only in special operations. As we have never been able to find a pattern to reproduce this bug, this small problem has not been completely solved, and the results have been put on hold again and again after project acceptance. I don't know how to explain this to my company.

Why is the customer reluctant to perform acceptance?

Generally, when the software development project has met the acceptance criteria, the development team starts to prepare for the acceptance stage. However, if the customer is unwilling to accept the request, it is a headache and common problem for the development team. The reasons are as follows:

(1) the development team is not right: Is this just a small problem?

After a software project is tested and corrected, the customer refuses to accept the project because it is stuck in a small problem. This is what we often say: "small questions, college questions ". Maybe many developers don't understand: Isn't it a small problem? Why are you making a fuss? In fact, this idea is because many development teams only stand first in their own interests. Therefore, when there is a small problem, consider that more than one thing is not less, the main needs and functions can be completed.

Therefore, as a development team, we need to correct our position and mentality, not to say that as long as we have completed the content stipulated in the contract, completed the work stipulated in the contract, and can be accepted after testing according to the contract. On the surface, the customer refused to accept the small bugs they discovered. In fact, when the customer does not agree to the acceptance at this time, their judgment is often not the bidding documents, contracts, technical agreements, Requirement Specification and other documents. Instead, the development team cannot give the customer sufficient confidence. The customer is not satisfied with the attitude of the development team to handle bugs. The customer thinks this is not a small problem and therefore refuses to accept the bug.

(2) Customer satisfaction is insufficient because the customer fails to grasp the intention of leadership.

We have learned a lot in the software development acceptance process. The most common problem is that we did not grasp the intention of the customer's key owner or important leaders during the development process, I don't know what customers are interested in. When the development team asks for acceptance, the customer will always feel that the customer is not satisfied with the acceptance. In short, the customer is unwilling to accept the acceptance. The main reason is that the relationship with the customer in the development process has not been improved, and the customer is not truly satisfied. For example, if the service is not in place when the customer reports a problem to the customer, the customer may be worried or lose the customer's trust if the customer finds that the problem has not been resolved in time after acceptance.

(3) the development process is not standardized and the acceptance criteria are not agreed

At the beginning of the project, the customer did not reach an agreement with the customer in the acceptance criteria, causing the customer to always talk about the small issues of the project. In fact, the acceptance criteria are very important. This requires detailed communication with the customer to clarify the work to be completed before acceptance. In the acceptance criteria, there must be not only work content and tasks to be completed, but also a relatively fixed period of time, so that both parties can work in this direction to prevent unlimited delays.

(4) No issue tracking records handled

Because many development contracts only provide a general framework, coupled with the fact that they have not been discussed with users before development, without a clear understanding of what the customer's products look like. The result is that both parties have different understandings of the requirements. For example, some requirements are not what the customer really wants, but many potential demands are not raised at the initial stage of the project. Since there was no written memorandum or issue tracking record during the development process, after a long time, the two sides forgot a lot of commitments and agreements, and may be rolled out again at the time of acceptance. This kind of thing is the most headache for the development team. It becomes necessary again when the content that can be done first is finally accepted. In this way, it is very easy for everyone to understand the differences.

(5) The customer delays acceptance due to financial reasons

Sometimes, the customer delays acceptance or deliberately delays acceptance. It is possible that the customer delays settlement and payment for the acceptance. For customers with this idea, the development team is most embarrassed. Use the law, and worry about undermining the long-term relationship. If you don't use the law, there are really so rude customers.