一、什么是质量
项目的质量需要把“符合要求”（产出预定的结果）和“好用”结合起来，达到让客户满意的目标。
符合要求：承诺做什么，做出来就是什么，不偷工减料。
好用：包含了“能用”，“有用”的意思。
- 产品能正常运行，不出错；
- 产品功能满足客户需要，能解决实际问题；
- 容易学习，不用客户费心思考；
- 方便快捷，提升工作效率；
- 美观精致，赏心悦目
二、低质量的恶果
1、 团队内部协作成本高；会增加很多额外的工作，比如：
- 开发人员多花10分钟自测就能避免的bug，测试人员除了花10分钟测试，还要填写JIRA数据；
- 然后项目经理指派给开发人员；
- 开发人员反过来理解测试人员的描述，复现Bug，如果不清楚的还得沟通；
- 修复bug时，可能还会遇到重新拉取git分支，重新配置环境等额外工作；
- 修复之后还得验收。
整个增加的工作量可能远远超出最初的10 分钟。
2、 因为不断的返工，测试可能会抱怨开发不负责任，开发又会抱怨测试没把问题描述清楚，引起团队内部冲突；
3、 因为质量问题，无法估计什么时候能得到一个稳定的版本，无法给客户明确的承诺；
4、 因为额外的工作增加，进度变慢，无法在约定的日期发布版本；合同违约；
5、 提交给客户后，客户迟迟不能验收通过，无法结项，回款慢，奖金发放同步滞后；
6、 客户满意度、忠诚度下降，影响合作关系，丢失继续合作的可能，甚至赔款；
很多项目的结果可能一开始就注定了，只是当时我们还不知道。所以我们要从源头上防范问题发生，避免类似这首童谣的糟糕结局：
失了一颗铁钉，丢了一只马蹄铁；丢了一只马蹄铁，折了一匹战马；折了一匹战马，损了一位将军；损了一位将军，输了一场战争；输了一场战争，亡了一个国家。
三、提高质量的几个要点
项目中，时间、成本和质量是相辅相成的，比如：工期很紧、预算有限的时候，质量通常很难得到保证。
如何平衡这3者的关系，非常考验项目经理的管理能力和团队的配合，这需要大家了解这几个概念。
3.1 质量与成本
要创造高质量，必然需要投入时间和成本，但质量和成本并不是相互排斥的。
质量专家W. 爱德华兹·戴明（W. Edwards Deming）认为这个道理很简单。
他认为随便哪个工厂，如果你去问一线的工人“为什么提升质量反而能降低成本”，得到的回答总是“返工少了”。
削减成本是高风险的动作，有时候这边的成本削减了，但是不经意间却增加了另一边的成本。想想这种情况，一位客户必须打多次电话，和多个人交流，才能做到一件事。想想受伤的客户最后放弃然后另找别的企业。想想如果你因为服务差而丢掉了一个客户，要花多少成本才能再找到一个客户。所以说，一家真正把客户服务好的企业所需的营销成本和客户获取成本非常低。满意的客户可以抵得上世界上最好的营销部门。
所有这些成本都非常重要，但是却不容易计算。很多企业把精力放在那些在财务报表的成本上，希望削减这些成本，但这只是拆东墙补西墙而已。成本没有降低，只是转移了。而且在削减成本的同时，把未来也减没了，因为今天的成本虽然降低了，但却损害了长期客户关系和客户的忠诚度。一旦有机会，受伤的客户就会另寻别家。
3.2 预防剩于检查 and "一次就做对"
从下图可以看出，在预防问题上投入更多成本，可以降低因缺陷导致的成本，但这个减少不是线性相关的，有一个拐点，这个拐点的投入回报是最大的“最佳质量点”。
而我们目前在预防上的投入，远远没有达到最佳质量点，还应该投入更多的预防成本，保证“一次就做对”。
3.3 半成品与工期
半成品这个概念来自于制造行业，它的标准定义是“半成品，是指经过一定生产过程并已检验合格交付半成品仓库保管，但尚未制造完工成为产成品，仍需进一步加工的中间产品”，理解半成品的关键就在于“尚未完工”。
软件开发中，最容易理解的半成品状态就是JIRA看板中的几个中间状态，比如“开发中”，“待测试”，如果“待测试”任务出现积压，说明很多任务没有通过验收，也意味着进度和质量可能失控。
有时候，因为工期紧张等原因，经常出现直接把半成品当做成品提交的情况，比如：
• 开发人员把未经自测、很多明显问题的功能直接提交给测试人员测试；
• 项目团队把未经过内部验收的产品直接提交给客户；
这些情况，表面看起来是按时完成了任务，但是事实上，3.2节列举的“低质量的恶果”，绝大部分是因为提交半成品导致的，因此需要进行控制。
可采取的措施：
• 在前期需求确认阶段多花时间，弄清楚要做成什么样（生成原型、需求说明），更有可能一次性做对；
• 尽早加入测试人员，逐渐验收；
• 分迭代提交，每个迭代都有可以用的功能，而不是每个功能做一点，但都没做完；
• 改Bug（以保证成品）的优先级高于开发新功能；
对半成品的补充说明：
不同客户，不同项目对产成品的定义是不同的，我们可以提前约定。
比如:
• 通常我们买房子，开发商交付的是毛坯房，毛坯房就算是成品；但如果这次签订的是精装修房的合同，那毛坯房就只能算半成品。
• 有的客户很看重代码质量，即使功能实现了，但代码不遵守规范，可维护性、代码复用性差，在客户眼里它仍然只是半成品。
• 产品推出一个新功能，相比市面上成熟的产品显得比较简陋，但只要能解决客户的实际问题，我们也算它是成品。
标准流程中，是把经过测试验收当成生产过程的终点。但我们可以拓展我们的思维，把终点外延，对很多问题就有全新的认识。
• 如果我们把经过客户验收当成终点，那就更能好理解要求客户确认需求、确认原型、确认中途提交也是在减少半成品。
• 如果我们把客户购买产品、客户真正使用当成终点，那就不会做出一大堆没人用的新功能，就清楚精益的平衡度在哪里。
3.4 持续改进（PDCA）
没有一开始就完美的项目，我们需要在做的过程中，不断识别过程中的问题，计划-实施-检查-行动，达到阶梯式进步。
我们的周报、迭代回顾会等，就是为了达到这个目的。
3.5 管理层责任
项目成功需要项目团队全体成员的参与。然而，管理层在其质量职责内，肩负着为项目提供具有足够能力资源的责任。
比如：
- 在公司范围内，如果大部分项目都有质量问题，那么PMO是有极大责任的，可能没有严格的执行质量标准、没有提供足够的支持等等；
- 在项目范围内，出现质量问题，项目经理也是承担最大的责任，可能没有投入足够的质量成本、没有按照规范执行、没有提供足够支持，等等；
当出现问题时，所有人都应该提出来，管理层应该使用立即暂停机制，即“安灯系统”，避免产生更坏的结果。
3.6 安灯系统
在我们的项目出现质量问题时，可能是因为对相关的技术不熟悉，或者质量意识差，或者开发流程混乱，我们的应对之策通常是提醒相关人员做出改进，甚至以这是客观原因导致所以不采取任何行动，总之仍然是带病上岗。实际上，我们可以更积极地应对，以从根本上解决问题的态度来应对，确保“不欠新债”。
应对方法取材于丰田生产方式之安灯系统，具体就是，暂停工作，问题解决之后再恢复。比如工具使用不熟，那就先培训，确保对工作没有影响之后再开发；质量意识差，那就教会清单的工作方法，声明工作纪律。
摘录两段丰田工作人员解释：
摘录一：大野先生曾经说过，暂停生产线运转而找出的任何问题，都必须在第二天早上以前解决，因为当你每分钟造出一辆车时，今天未解决的问题，明天必定会再发生。----张富士夫
摘录二：当张富士夫向史克菲德表示，他注意到组装线一整月都没有停止过时，史克菲德非常骄傲的说，“是的，我们这一个月表现极佳，我想您应该会很高兴再看好几个月这种佳绩。”可是，张富士夫接下来的这番话却另史克菲德震惊不已：“若组装长没有暂停，代表没有任何问题，但是，任何一家工厂一定有问题，因此，工厂一直在运转，表示问题被隐藏起来了。请减少存货，让问题浮现出来吧，这会造成组装厂停工，但却能继续解决问题，并以更高效率制造品质更加的引擎。”
四、具体怎么做？
项目经理
- 质量意识
o 项目经理重视质量，团队才有可能提交质量高的产出物；
o 对团队成员的质量，奖惩分明；
o 遇到问题及时“拉灯”，不欠新账，还清旧账； - 控制半成品
o 尽早让测试人员加入项目组中，提前预防问题，及时验收，减少半成品；
o 确保迭代划分合理，每次提交都有可使用的成品；
o 如果进度确实很紧，可协商增量提交，保证逐步提交经过验收的、可用的成品，而不是半成品； - 提高质量成本投入
o 多花时间在前期需求分析，输出原型和确切的需求，而不是在做的过程中再确认，这样可以在源头上避免问题，提高一次性做对的概率。
o 强调开发阶段的自测，避免明显的Bug流入测试阶段；（Bug越早发现，修改成本越低） - 客户满意度的维持
o 除了努力完成功能清单中的功能外，还需要思考我们工作对客户产生的价值，不仅强调“符合要求”，还要强调“好用”；
o 已知的问题，一定要提前告诉客户，而不是等客户测出来了再说，这样会浪费客户时间，引起客户不满；
o 每个发布给客户的版本，一定要经过内部验收，不能把客户当做测试人员；
测试人员
- 对质量的坚持
o 对于质量极差的版本，可拒绝测试，责令整改后再提交测试；
o 确保每一个发布给客户的版本，都严格把关，即使有问题，也已经罗列出已知问题，告知客户； - 对过程改进的监控
o 通过QA清单等工具，监控项目过程，推动从根本解决问题以及预防问题，有问题及时“拉灯”：
o 如果项目一直没有提交可测试的产出物，说明半成品堆积，需要“拉灯”；
o 提交的功能相对功能清单，有很多遗漏，需要“拉灯”；
o 如果项目总是很多低级的Bug，说明管理流程出问题了，需要“拉灯”；
o 如果遇到无法推动的问题，需及时抛出，“拉灯”
开发人员
- 认识误区
因为时间很紧，匆忙提交未经自测的半成品，以为这样是按时完成了任务，但实际是不负责任的态度，后期的返工成本非常大。
o 如果任务时间不够，可以申请投入更多的时间来保证质量（及时沟通）； - 问题到我为止
o 拿到任务，首先判断任务是否明确，不明确的任务，做的过程中极可能导致返工，应申请推迟处理（及时沟通）；
o 开始编码之前，应该先熟悉、分解需求，理清思路，而不是做一步看一步；（不理解的一定要及时沟通）
o 编码完成后，必须自测，把自己力所能及可发现的Bug及时的解决，而不是等着测试反馈；
o 修改Bug时，写明Bug产生的原因，避免自己再犯类似错误，还能对测试人员有所帮助。
