本节书摘来自异步社区《嵌入式系统开发之道——菜鸟成长日志与项目经理的私房菜》一书中的第2章，第02-07节，作者 邱毅凌,更多章节内容可以访问云栖社区“异步社区”公众号查看。
02-07项目质量（Quality）管理
把项目在预算内准时完成，并不代表就可以顺利结项。如果质量不符合要求，在改善之前，客户是不会愿意当冤大头验收的。
嵌入式系统包含软件与硬件，硬件的质量比较容易理解，例如：结构接缝是否密合、各零件的功能是否正确运行。但软件是逻辑实体，不容易描述其质量等级，软件问题基本上是由人为差错所引起，且问题隐藏在千变万化的逻辑组合中，若等到开发告一段落后才想要去一一找出所有问题，困难度会非常高。软件质量管理的关键是预防重于治疗，尽可能在规划阶段就要做好‘质量计划’，不能全靠事后检查。
一般以研发为主的公司，虽然都知道质量对产品的重要性，但在实际运行时，往往又无视质量单位应发挥的作用。PMI注意到了这件事情，因而在项目管理知识体系中特别提到：在项目运行的过程中，质量单位应该全程参与，不只具有发言权，面对攸关项目的决策，甚至应该具有否决权。
在软件开发项目里更是如此。道理很简单，研发单位根据流程执行产品开发，但最终产品的质量（甚至可上推到项目的成败）却应该是质量单位的责任1。唯有如此，才能避免研发单位陷入‘球员兼裁判’的盲点。
投影片中列举了不少项目质量的思想，无论你是项目经理、工程师或测试人员，只要身为项目的一员，都请务必了解质量的精髓。质量管理必须贯穿整个项目，没有质量观念的团队，将会在项目后期付出沉重的代价。
质量系统是门大学问，市面上有不少体系复杂的质量系统，但我一向认为只需要弄清质量系统的基本概念即可，实际上则必须根据项目的实际状况来制定该项目的质量策略。
一般公司或项目团队总是弄不清楚QA、QC、Testing-Team这些名词的定义，所以老是会把团队冠上名不副实的名字。最常见的就是称呼只负责测试的团队为QA，但实际上，公司内部根本没有任何单位负责执行真正QA该做的事。
质量保证（QA）主要目的就是确保产品在既定进度与预算下，能圆满达成预期质量水平与可靠度目标。QA单位的工具就是稽核（Audit），任何项目流程中的工作，从计划拟定、模块设计、Code Review、测试计划、测试涵盖率、生产流程、备料计划等，QA单位都可以进行稽核。特别是项目团队完成了某个里程碑、提出了某项变更请求，或是项目即将进入下一个阶段时，QA单位都应该主动介入稽核，避免问题被拖延到项目后期，将会变得更棘手。
我们知道工程师都是很爱面子的，所以QA单位在执行稽核时一定要注意态度，不能自以为是RD的上级单位，造成团队彼此的冲突。PM更必须注意RD与QA间的关系，并尽可能参加所有Audit Meeting。
很可惜，本公司中并没有‘真正’的QA，但项目里不能没有QA，所以我的项目就只能由PM及其他主管包办代替。因为由主管来执行Audit（请注意，Audit和Review是不同的概念，前者主要关注的是流程与结果，而Review则较为技术性，关注的是detail），工程人员也较容易配合。本公司因人力资源不足，项目执行者也只能从权。
PMP提到了许多QA的工具，基本上和软件工程提到的SQA概念一致，各位有兴趣可以找来看一看。
QC和QA的职责完全不同，QA是专注在流程的正确性，而QC则必须确定项目结果与质量标准是否相符，同时确定消除不符的原因和方法。以软件开发来说，QC就是根据质量标准，设法找出某软件版本的所有bug，并持续追踪每个bug被处理的状态。
软件测试有其方法论，QC必须有系统、有方法、有计划地执行测试工作，绝对不是乱枪打鸟。当找到bug后，必须利用bug管理工具妥善管理，每个bug的处理流程都必须记录下来。此外，bug管理软件也能自动产生报表，让项目经理可以判断各个版本间质量水平的趋势。
最后再强调一次，项目团队不能过度依赖QC的测试，如同RD无法写出没有bug的程序，测试团队也无法找出所有的 bug。质量工作一定要在项目前面执行，如果等到后期才来做，势必得付出相当可观的成本。
并非所有公司都能言行一致，虽然口头上说质量第一，但组织中却无法落实质量系统。我们在业界工作，还是要让自己的项目尽量可以站在质量的保护伞下，以下是我的经验和建议。
- 质量活动必须经过规划，同时符合项目需求，并明文公布
- 推广‘提高质量，就是尊重客户’的理念
- 质量活动必须尽早启动
- 质量小组尽量可以独立存在
- 质量人员必须经过培训
- 工程人员必须能够理解，质量人员也是为了项目成功而努力着，并非存心挑剔或找麻烦
