重读PMBOK《项目质量管理》之自问自答（三）

by Pei Qing

第一篇写了质量不可妥协、质量不同于等级、什么是质量政策。第二篇讲到质量管理的目标是缩小偏差而非提高上限，产品符合要求并不等价于适合使用，质量管理的大部分责任在管理层。这篇继续。

以下提及的页码，均为《项目管理知识体系指南》（PMBOK指南）中文第6版的页码。

对上篇缩小偏差的案例补充

图：Who's the Better Shot?[1]

一篇1990年的HBR文章用了上图。作者的答案是

Sam’s shooting is consistent and virtually predictable. He probably knows why he missed the circle completely. An adjustment to his sights will give many perfect bull’s-eyes during the next round. John has a much more difficult problem. To reduce the dispersion of his shots, he must expose virtually all the factors under his control and find a way to change them in some felicitous combination. He may decide to change the position of his arms, the tightness of his sling, or the sequence of his firing: breathe, aim, slack, and squeeze. He will have little confidence that he will get all his shots in the bull’s-eye circle next time around.
...
Robustness derives from consistency. Where deviation is consistent, adjustment to the target is possible.**

小偏差意味着更容易管理和提高。

事业环境因素的影响

PMBOK 280页罗列了一些能够影响规划质量管理过程的事业环境因素:

  • 政府法规
  • 特定应用领域的相关规则、标准和指南
  • 地理分布
  • 组织结构
  • 市场条件
  • 项目或可交付成果的工作条件或运行条件
  • 文化观念

初读的时候，略过就完事了，反正看起来都是常识，不过脑子也知道这些都会影响规划质量过程——识别项目及其可交付成果的质量要求和（或）标准，并书面描述项目将如何证明符合质量要求和（或）标准的过程。

现在再读，就该慢下来想想这些因素是怎么样影响的了。

政府法规。

密码法出台之后，对整个toB，尤其是toGov的软件项目，都是个绕不过去的新规则，大家原来闭着眼睛选择AES、RSA的，现在可能突然发现不改过不了验收。

大企业的组织过程资产相对齐全，新立项目时，很容易参考过去类似的项目所遵循的法律法规，然后只需要了解一下最近有什么新法律颁布生效，就解决了。甚至这个过程常常由法务部门代劳了，项目经理只要使用专家判断就高枕无忧。而中小企业里，一来没有以前的完善项目档案作参考（就算有，其中的法律法规使用情况要求大概率是空着的），二来也没有充足的律师团队帮着分析这部分要求，绝大部分的压力都落在项目经理身上，得自己去检索信息、整理信息、判断对项目的影响。这在做出海项目时，尤其痛苦，当地的法律法规有哪些适用于自己项目的可交付成果？

特定应用领域的相关规则、标准和指南

最典型的就是国标、行标。这项如果不和政府法规结合在一起，只不过是各个组织、协会、集团的公关竞技场，但一旦像汽车排放标准那样由政府确立为入市门槛，游戏规则就变了。

跨界做项目的时候此处存在质量风险。比如原来做安卓平板的厂商，想做车载中控系统，而没有识别到汽车行业的特殊要求，PM的结局就呵呵了。哪怕一样的技术难度，但是从硬件器件选型到软件开发、测试标准，都是完全不同的要求。这些会极大地影响成本、周期，从而决定了项目成败。

组织结构

有的公司，BA、Dev、QA、QC是独立团队（职能型）；还有一些公司，三人甚至一人小组就完整扮演了全部角色（项目型）。这两类组织结构下，规划质量的责任人可能不同，对可交付成果进行检验的执行人可能不同，这都会相应地改变我们如何去执行质量相关活动。

市场条件

面向不同市场的项目，自然会有不同的质量要求。做民用产品，按ISO、GB做往往就充分了，但是做军用产品，GJB一堆额外要求等着PM去识别和满足。

不管是PM还是质量管理人员，都需要清醒地针对目标市场设定质量目标。错位的后果要么是卖不了，要么是买不起。国内很常见的情形是出口产品的质量标准比内销的高，如果不做区分，一刀切，就是在浪费钱（低标准，货躺在海关或退回）和浪费钱（高标准，国内没竞争力没利润没份额）之间做选择。

项目或可交付成果的工作条件或运行条件

前文关于车载系统的开发，除了行业标准以外，也是这个因素的例子。

另外一个想到的例子是，曾经使用的诺基亚和黑莓手机，在北京的冬天都没有明显感觉到电池续航的明显缩短，但是苹果在零下户外肉眼可见的电量百分比下降近些年都不能称为新闻了。一种猜想是加拿大和芬兰维度都不低，于是默认的工作温度下限就比较低。

最近各位读者没少被测体温吧？那些红外体温计表现如何？有没有被众人唾弃？它们大多标称工作温度是10~40℃，原本是设计给（有空调、暖气的）室内用的。没想到这次被大批量用在冬季室外，结果我被测出过多次不到30℃的体温，最低一次22℃，当场就凉凉了。

地理分布和文化观念，我一时想不到什么好例子，正好作为思考题留给读者。（不会做的题留给学生和读者算不算传统艺能？）

最优项目质量成本

PMBOK 282页写道

最优 COQ 能够在预防成本和评估成本之间找到恰当的投资平衡点，以规避失败成本。有关模型表明，最优项目质量成本，指在投资额外的预防/评估成本时，既无益处又不具备成本效益。

只要看过PMBOK的参考文献就知道这个机构是不肯给其他书籍和文章任何露脸机会的。

图：PMBOK参考文献

如果不去探究有关部门到底是哪个部门，事办不成。这里不去探究有关模型是什么模型，理解不了什么是最优项目质量成本。

传统观点（可能太朴素了，我没发现这个模型被冠名）认为，随着预防成本增加，缺陷率下降，质量损失下降，在某个缺陷率下，总质量成本最低，这个最优缺陷率>0。

图：Total Cost of Quality — Traditional View[2]

而零缺陷模型（菲利浦・克劳斯比（Philip B. Crosby）在20世纪60年代初提出，核心观点是第一次就把正确的事情做正确）认为，随着缺陷率降低，总质量成本降低，最优缺陷率=0。

图：Total Cost of Quality — Zero Defects View[2:1]

最近的一些观点给出了新的COQ函数：

图：现代质量观下的总质量成本函数曲线[3]

该观点认为

当产品质量接近于稳健的零缺陷状态时，企业预防和鉴定成本并不会无限制地增加；总质量成本最优点是不存在的，存在总质量成本极小值点E*，进行持续质量改进才是最优的；质量水平不断改进，总质量成本不断下降。企业实现“零缺陷”质量水平有一定难度，因此在接近6σ质量水平时总质量成本上升到极大值。当技术取得突破、企业能够实现“零缺陷”质量水平时，企业的总质量成本停止增加，开始下降并维持在一个稳定的水平。

我认为，该图对技术取得突破的诠释是不充分的。技术突破可能带来不同方面的改善：

  • 鉴定成本下降。也就是上图展示的过程。通过将人工检验替换为自动化检验，有可能实现鉴定成本的大幅降低。
  • 预防成本下降。现在不少技术管理者选择Java的原因是相比其他语言，写Java想犯错比较难。Java和现在一系列成熟框架的出现，使得预防软件工程师写bug的成本下降了。

审计的首要目标是找亮点而非找不足

PMBOK 294页

质量审计目标可能包括(但不限于):
  • 识别全部正在实施的良好及最佳实践;
  • 识别所有违规做法、差距及不足;
  • 分享所在组织和/或行业中类似项目的良好实践;
  • 积极、主动地提供协助，以改进过程的执行，从而帮助团队提高生产效率;
  • 强调每次审计都应对组织经验教训知识库的积累做出贡献。

按PMI的性格，遇到举例时，虽然书里用的是unordered list，但其实大多是重要性递减的ordered list。

其他组织的质量审计做得如何我并不清楚，但我所经历过的几乎全部内部/外部质量审计，都在做第二项——识别违规做法、差距及不足。有少量外审老师在看到问题之后，偶尔花时间分享一下他了解到的行业良好实践供我们改进参考。我至今没见到审计报告强调我们正在实施的良好及最佳实践，建议管理层坚定推行至其他职能部门的。

以我自己为例，直到不久前，对别人提交的各种代码、文档，我几乎不去肯定其中做得好的地方，只会在回复中提出一些不足和改进建议。对别人的工作“无语”竟然成了最高评价。现在看来，这是大错。

PDCA循环要通过标准化巩固

我曾在2019年8月的工作报告中用了PMBOK的一张图来帮助阐述现在团队状态通过一系列活动的比几年前好。

到2019年终工作报告时，我补充了下图。并说明它比左侧图更有价值的地方，就是明确地展示了通过标准化，把组织工作质量下限不断抬高的过程。解决了具体问题之后，我们需要监控一段时间的相关指标，当验证方法有效，就更新标准，让后来者无需在这个问题上徘徊。

具体到软件开发的过程，我们所采用的框架代码、以前项目用过且表现稳定的库、逐渐完善的开发过程评审项、测试用例库、代码检查工具都是这个楔子的组成部分。这一整套标准，有助于提高开发项目的质量下限。

团队水平在一段时间内是很少发生突变的，这意味着质量上限是短期稳定的，而控制了下限，就是缩小了偏差，这就是更高的质量管理水平。

这个系列告一段落了。如果您对项目质量管理，尤其是软件项目的质量管理有见解、问题想与我交流，请通过 edwardtoday@gmail.com 和我联系。

  1. Robust Quality, https://hbr.org/1990/01/robust-quality ↩︎

2. Managing Quality, https://slideplayer.com/slide/5099687/ ↩︎ ↩︎

3. 张利，王雨时，闻泉。现代质量观下质量成本数学模型研究 [EB/OL]. 北京：中国科技论文在线 [2011-03-14]. http://www.paper.edu.cn/releasepaper/content/201103-623. ↩︎