Nova Software has always attached great importance to project quality management. The following article combines the company's thinking and methods of quality management. Hope that every colleague will read it carefully, check whether his work is in place, what problems he has, and what improvements can be made.

1. Introduction to quality

In order to satisfy customers, the quality of the project needs to combine "meet the requirements" (produce the expected results) with "easy to use".

Meet the requirements: promise what to do, what is done, no compromise.

Easy to use: contains the word "useful" and "usable":

• The product can run normally without error.
• Product functions meet customer needs and solve practical problems.
• Easy to learn, no need for customers to think hard.
• Convenient and efficient, improve work efficiency;
• Beautiful and exquisite, pleasing to the eye;

2. Consequences of poor quality

The cost of teamwork is very high and will add a lot of extra work, such as:

• Developers spend 10 minutes to self-test to avoid bugs, testers spend additional10 minutes to test, and they also need to fill in JIRA data;
• Then the project manager assigned the bug to the developer.
• Developers conversely understand the testers' descriptions, reproduce Bug, and communicate if they are not clear.
• When repairing bug, you may also encounter additional tasks such as re pulling git branches, reconfiguring the environment, etc.
• After repair, we have to recheck.

The whole increased time may be far beyond the first 10 minutes.

• Because of continuous rework, testing may complain that developer is irresponsible, and developer will complain that testing does not clearly describe the problem, causing intra-team conflict.
• Because of the quality problems, it is impossible to estimate when a stable version will be available and to give customers a clear commitment.
• Because the extra work is increasing, the progress slows down, the version can not be released on the appointed date; the contract breaks the contract;
• After submitting to clients, clients delay acceptance and approval, unable to settle accounts, slow repayment, and lagging in the synchronization of bonus payment.
• Customer satisfaction and loyalty decline, affecting the cooperative relationship, losing the possibility of continuing cooperation, and even compensation;

The results of many projects may have been doomed from the beginning, but we did not know that at the time. So we need to prevent the problem from the source and avoid the bad ending like this nursery rhyme: Lost a nail, lost a horseshoe; lost a horseshoe, broken a horse; broken a horse, damaged a general; damaged a general, lost a war; lost a war, lost a country.

3. Several keys to improve quality

In projects, time, cost and quality are mutually affected. For example, when the time limit is tight and the budget is limited, quality is usually difficult to guarantee.

How to balance these three relationships is a test stone for project manager's management ability and team cooperation, which requires you to understand these concepts.

3.1. Quality and cost

To create high quality, it is necessary to invest time and cost, but quality and cost are not mutually exclusive. Quality expert W. Edwards Deming (W. Edwards Deming) thinks this reason is very simple. He thinks that in any factory, if you ask the front-line workers why they can reduce costs by improving quality, the answer is always "less rework".

Reducing cost is a risky action. Sometimes the cost on one side is reduced, but it accidentally increases the cost on the other side. Think about this situation, a customer must make many phone calls and communicate with many people in order to achieve one thing. Think of the injured client and give up another company. Think about how much it would cost to find another customer if you lost a customer because of poor service. So the marketing cost and customer acquisition cost of a company that really serves its customers well are very low. Satisfied customers are worth the best marketing department in the world.

All these costs are very important, but they are not easy to calculate. Many companies focus on the cost of financial statements, hoping to reduce these costs, but this is just to break down the East Wall to make up the West Wall. The cost has not been reduced, but it has been transferred. And while cutting costs, it also reduces the future, because today's costs are reduced, but it undermines long-term customer relationships and customer loyalty. Once there is a chance, the injured customer will find another home.

3.2. Prevention over inspection and "get it right in one time"

As can be seen from the figure below, investing more cost in prevention can reduce the cost caused by defects, but this reduction is not linearly related. There is a turning point, and the investment return of this turning point is the biggest "best quality point".

However, our current investment in prevention is far from the best quality point, and we should invest more in prevention costs to ensure that " get it right in one time ".

3.3. Semi product and time-line

The concept of semi-finished product comes from the manufacturing industry. Its standard definition is "semi-finished product", which refers to the intermediate product that has passed a certain production process and passed the inspection and delivered to the semi-finished product warehouse for storage, but has not yet been manufactured into the finished product and still needs further processing. The key to understand the semi-finished product lies in "not yet completed".

In software development, the most easily understood semi-finished state is several intermediate states in JIRA Kanban, such as "in development" and "to be tested". If there is a backlog of "to be tested" tasks, it means that many tasks have not passed the acceptance test, which also means that the progress and quality may be out of control.

Sometimes, due to time constraints and other reasons, it often occurs that semi-finished products are submitted directly as finished products, such as:

• The developers submitted the functions that were not self-test and many obvious problems to the testers directly.
• The project team submits products that are not internally accepted to customers directly.

These situations appear to have been completed on time, but in fact, the "bad consequences of low quality" listed in Section 3.2 are mostly due to the submission of semi-finished products and therefore need to be controlled.

Measures to be taken:

• Spend more time in the early stage of requirement validation to figure out what to do (prototype generation, requirement description), and it is more likely to do it right once.
• Add the tester as soon as possible and gradually accept the test.
• Submitted iteratively, each iteration has available functions, rather than each function to do a little, but did not complete;
• The priority of changing Bug is to exceed the development of new functions.

Side note to semi finished products

Different customers and different items have different definitions of finished products. We can make an appointment in advance.

For example, usually we buy a house, the developer delivers the blank house, even if the blank house is finished products; but if the contract signed this time is fine decoration house, then the blank house can only be regarded as semi-finished products.

• Some customers attach great importance to code quality, even if the function is realized, but the code does not comply with the specifications, maintainability, code reusability is poor, in the eyes of customers, it is still a semi-finished product.
• The product launches a new function. Compared with the mature products on the market, it is simpler, but as long as it can solve the actual problems of customers, we also consider it as a finished product.

In the standard process, acceptance is regarded as the end of the production process. But we can expand our thinking, extend the end point, and have a completely new understanding of many problems.

• If we regard customer acceptance as the end point, we can better understand that requiring customers to confirm requirements, confirm prototypes, and confirm midway submission is also reducing semi-finished products.
• If we take customers' purchasing products and their real use as the end point, we will not make a lot of new functions that nobody uses, and we will know where the balance of lean is.

3.4. Continuous improvement (PDCA)

There is no perfect project from the beginning. We need to identify problems in the process of doing it, plan - implement - check - action, and achieve step-by-step progress.

Our weekly report, iteration review meeting and so on, is to achieve this goal.

3.5. Management responsibility

The success of the project requires the participation of all the members of the project team. However, in its quality responsibilities, management shoulders the responsibility of providing sufficient capacity resources for the project.

For example:

• On company level, if most projects have quality problems, PMO has great responsibility, may not strictly implement quality standards, do not provide adequate support and so on.
• Within the scope of the project, the project manager is also responsible for the quality problems. He may not have invested enough quality cost, not implemented in accordance with the specifications, not providing enough support, and so on.
• When problems arise, everyone should mention that management should use the immediate suspension mechanism, the "light system", to avoid worse outcomes.

3.6. Safety lamp system

When quality problems arise in our projects, they may be due to unfamiliarity with relevant technologies, poor quality awareness or confused development process. Our response is usually to remind relevant personnel to make improvements, or even to take no action because of this objective reason. In short, it is still to take sick job. In fact, we can deal with it more actively, with a fundamentally problem-solving attitude, and ensure that we do not owe new debts.

The response method is based on the Toyota production mode of the Anden system, specifically, suspend work, and then resume after the problem has been solved. For example, if you are not familiar with the tools, you should train first to ensure that there is no impact on the work before you develop them; if you have poor quality awareness, you should teach the working methods of the checklist and declare the work discipline.

Two excerpts from TOYOTA staff:

• 1Mr. Ono once said that any problems found by suspending the production line must be solved by the next morning, because when you build a car every minute, the unsolved problems today will certainly happen again tomorrow. --- Zhangtomi Shio
• 2When Fuji Zhang told Skyfield that he noticed that the assembly line had not stopped outdated for a whole month, Skyfield was very proud to say, "Yes, we have done very well this month. I think you should be happy to see this performance for several more months." However, Zhang Fuji's next remark shocked Skyfield: "If the assembly leader did not suspend, there would be no problem, but there must be a problem in any factory, so the factory has been running, indicating that the problem has been hidden. Please reduce inventory and let problems arise. This will cause the assembly plant to shut down, but it will continue to solve the problem and make more quality engines with higher efficiency.

4. What to do

4.1 For project manager

Quality sense

• Project managers attach importance to quality and teams are likely to submit high quality outputs.
• The quality of team members is rewarding and punishments are clear.
• In the face of problems, timely "pull lights", do not owe new accounts, pay off the old accounts.
• Control semi-finished products
• Let test personnel join the project team as early as possible, prevent problems in advance, check in time, and reduce semi-finished products.
• Ensure that the iteration is reasonable, and every submission has a finished product.
• If the schedule is really tight, incremental submission can be negotiated to ensure the gradual submission of acceptable and available products, rather than semi-finished products;

Improve quality cost input

• Spend more time in pre-requirement analysis, output prototypes and exact requirements, rather than confirming them in the process of doing so, which can avoid problems at the source and improve the probability of one-time corrections.
• Emphasis is placed on self-testing in the development phase to avoid obvious Bugs flowing into the testing phase; (The sooner Bugs are discovered, the lower the cost of modification)

Maintenance of customer satisfaction

• In addition to trying to complete the functions in the function list, we also need to think about the value of our work to our customers, not only emphasizing "meeting the requirements", but also emphasizing "good use";
• Known problems must be told to customers in advance, rather than waiting for customers to detect, which will waste customer time and cause customer dissatisfaction;
• Each version issued to the customer must undergo internal acceptance and cannot be regarded as a tester.

4.2 For tester

Insistence on quality

• For a very poor quality version, the test can be refused and ordered to be submitted for testing after rectification.
• Make sure that every version released to customers is strictly checked, even if there is a problem, it has listed the known problems, inform customers;

Monitoring of process improvement

Through QA list and other tools to monitor the project process, promote the fundamental problem solving and prevention of problems, problems and timely "pull the light":

• If the project has not submitted the tested output, it is necessary to "pull the lamp" when the semi-finished product is stacked.
• There are many omissions in the relative function list submitted.
• If the project is always a lot of low-level Bug, it shows that the management process is out of order and needs to be "pulled up".
• If we encounter problems that can not be pushed forward, we need to throw them out in a timely manner.

4.3 For developer

One misconception

Because of the time constraints, developers rushed to submit the semi-finished products without self-testing, thinking that this is to complete the task on time, but this attitude is quite irresponsible, and the cost of rework in the later period is very high. If the task time is not enough, you can apply for more time to ensure quality (timely communication).

Let the problem stop in front of me:

• To get the task, first of all, to judge whether the task is clear and unclear, the process of doing may lead to rework, should apply for postponement of processing (timely communication);
• Before start coding, you should be familiar with, analyze the requirements, clear up the ideas, rather than take a step by step; (If you do not understand, you must communicate in time.)
• After the coding is completed, you must test yourself and solve the discoverable Bug as soon as you can, instead of waiting for feedback from the test.
• When modifying Bug, it is helpful for testers to specify the causes of Bug and avoid making similar mistakes.