本节书摘来自华章计算机《需求设计：构建用户想要和需要的产品》一书中的第3章，第3.7节,作者： [英] 克里斯·布里顿（Chris Britton） 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
3.7 品质
品质，谈的是一致性与改进的问题。这两方面总是需要同时考虑，因为我们必须以一致性为基础，才能据此做出改进。
在很多人的印象中，质量管理总是与繁复而庞大的文档相联系。笔者对此表示遗憾，我认为产生这种状况的根本原因，还在于管理者对程序员及设计者的技能水平缺乏信任，因此想通过质量管控计划来加以弥补。为了使大家理解其中的误会，我现在做个比喻。一位优秀的厨师本身是知道怎样制作蛋奶酥的，然而品质管控计划却不是告诉厨师应该怎样去做这个蛋奶酥，它甚至连烹制配方都不会提供。它所要确保的，是每一枚蛋奶酥都能做得一样好。
有迹象表明，品质管控计划可以较好地运用于IT开发工作。在Evaluating Agile and Scrum with Other Software Methodologies这篇文章[17]中，Capers Jones对各种软件开发方法的有效性进行了衡量。在效果比较好的开发方法里面，有一种方法叫做TSP，也就是Team Software Process（团队软件过程）。这个结果对笔者来说是有些意外的，因为我原来在网上看到很多人以负面的口气评论过TSP。TSP是由一个组织所引领的，该组织长久以来一直在品质管控过程方面提供领先的思想，这个组织就是卡内基梅隆大学（Carnegie Mellon University）的软件工程学院（Software Engineering Institute）。
通过研究TSP，笔者有三项体会。
首先，品质是从上到下得以贯彻的。TSP构建在PSP之上，PSP指的是Personal Soft-ware Process（个体软件过程），它要求程序员与设计者必须监测自己所做的事情、寻找自身的弱点，并努力提高工作水平。TSP是把一套与PSP相似的流程，运用在整个团队上面。
第二，品质建立于测量之上。如果你无法测量功能点的实现速度、bug的探查速度以及这些bug的性质，那么你就很难想到应该如何更好地完成工作。PSP或许把这种想法推向了极致。编程者总是抱怨他们必须把每天的实际编程时长记录下来，而且要精确到分钟，不仅如此，而且还必须记录编译器所给出的错误数量与错误类型。笔者觉得这样做有些过头，要是开发工具本身可以把这些指标记录下来，那还显得好一些。有了这些指标做基础，我们可以很好地发现并改正自身的缺点。
第三，品质不是靠烦琐的规章制度来保证的，而是应该在一个学习型的组织之中培养而成。学习型的组织，不单单会送员工去参加培训并定期开会以讨论相关的流程，而且还可以保证员工在无需担心打击报复的前提下，能够直接表达出自己的不满，并且使员工乐意尝试新的东西。笔者在第2章中曾经简要地讨论了DevOps，这在某种程度上是为了反制运维部门（operations department）中那些所谓的品质系统。笔者对品质衡量指标及学习型组织的看法，同样适用于运维部门。
笔者从品质管控之中所得到的第三项体会，就是明白了应该怎样检验软件产品。3.8节就来谈这个话题。
