项目管理之质量检查点

在软件工程的理论中，没有“质量检查点”的说法，这只是我自己在项目管理中，为了应对项目的质量压力而采取的一个措施，现在在这里写出来，和大家分享，希望能够在这里和大家进行交流。

所谓“质量检查点”就是开发人员对需求的认识点。这个认识点将作为开发人员的开发依据和自我测试依据，也是在产品提交之后，客户发现bug之后，开发团队对bug的分析依据。

可能我对“质量检查点”的诠释不完全，毕竟“质量检查点”在我们项目组中的实施也不过两周。

首先我想说一下“质量检查点”的由来。我所在的项目组负责一个外包项目的开发，客户对提交的产品质量有着较高的要求。而我们项目组本身没有配备专门的测试人员，所以对产品质量的把握全靠开发人员的认真负责。虽然项目组成员都有着很高的工作热情，但是在提交的产品中，还是存在bug，并且有一部分bug是很低级的。这样的问题实在是让我有很大的压力，但是项目成员的工作态度都是没有什么可以挑剔的，面对bug，我能指着某某说“你提交的产品有问题，你要注意产品质量”吗？我曾经想这样去做，但是还是没有，因为我知道他们已经尽力了，这样的指责不但不能对事情有任何好处，而且还会打击他们的积极性和自信心。

我想一定是我们的工作方法存在问题。在我们的项目组中，有一个项目经理检查每一个任务的完成情况的过程，在这个过程中，我发现对于开发人员认为肯定不会出问题的地方出现问题了。这实际上就是灯下黑。例如，在一个记录添加的事件中改变某个标记值，这个标记值将会影响窗体退出时的行为。但是开发人员认为这是一个很简单的实现，所以在做完任务后没有去测试它。结果在我检查时，这里出问题了，一检查原因结果是记录添加时，记录添加的事件并没有被触发，因为要触发这个事件，则要执行数据绑定的更新，而开发人员忽略了这个过程，bug出现了。当然这只是其中的一个典型案例。

还有一个情况，就是这个任务本身很复杂，开发人员完成这个任务之后，全凭自己对需求的记忆来测试。而这里是存在过程的，我们且不谈“认为开发人员不愿意测出自己的代码中存在着bug的情节”，就算是假设开发人员开始记住了要测试的客观内容100%，然后通常是在测试的过程中，开发人员发现了问题，然后开发人员就会停止测试而转向bug的修改。而还有一个客观的事实是时间在一分钟一分钟的过去，随着任务提交时间的临近，开发人员的心理会发生很大的变化。其中一点可以肯定，他们会逐渐变得着急。在这样的情况下，可能会有80%的测试内容还留在开发人员的大脑中。假设在自我测试的过程中，发现bug的数量较多或是解决问题的时间比较长，留在开发人员大脑中的测试内容可能还要少。

以上两个问题其实也是思维过程中的盲区。从其它人的角度去看它是主观问题，因为他们提交的任务中存在bug，其实对于开发人员来说是一个客观问题，由于是思维的盲区，他们怎么可能发现提交任务中的bug呢（就像人的眼睛不能看见自己的后脑勺一样，所以当那个bug就在后脑勺，他也是看不见的）？

在这样的背景下，我想到了一个解决的办法，那就是开发人员自己写“质量检查点”。

质量检查点具体的内容是什么呢？我仅以工作实践中的一个案例作为例子。用户发过来一个新增需求，要求在原有的销售项目上增加相关销售项目。对于这个新增需求，我们开发人员目前的测试点为：

.....

需要给出租销售项目加上关联销售项目功能

需要给订餐项目加上关联销售项目功能

.....

添加关联销售项目，点击退出，系统提示是否不保存退出

......

如果从系统分析人员的角度看，它带有需求分析的色彩，但是不够系统；如果从测试人员的角度来看，它也像一个测试用例，但是不够详细。的确，测试点的本来就诞生在一个没有专职的系统分析师，没有专职的测试人员的开发团队中。但我相信，它还有其它价值。我总是鼓励开发人员能够在进入开发之前，尽量将它们想到的检查点写出来。我希望它能够成为一个方向，能够帮助开发人员在开发过程中操着正确的目标努力。而事实上，经过两周多的实践，它也确实起到了这方面的作用。我感觉开发人员在开发的过程中，思维变得更加严谨了。这是任务完成之前，当任务完成之后，进入测试阶段，我同样告诉开发人员能够根据它们的测试点去测试，但是他们似乎并不乐于这样做。

这实际上是很正常的事情，这是由于工作的惯性导致的，作为项目经理在这个阶段需要有所作为，让项目成员能够实施新的工作方式。我的方法是开会向大家分析这样做的好处，然后建议在一个人那里试点，然后在检查代码时，根据质量检查点来检查，在每周五的时候，开会讨论这周大家对质量检查点的认识以及实施的具体方法。这样三周后，大家都能够开始在项目之前写质量检查点。

开会讨论大家对某些观点的认识和具体的实践方法对于项目的管理来说是很重要的。它的作用不但在于能够让项目成员之间的思想能够互相传递，而且还能够加深大家对观点的认识，并且这种程度是单独谈话所不能达到的。

经过一段时间的实践，大家通过质量检查点提高了开发的质量，这是我所期望的，但是大家还发现了一些在系统中长期存在但是没有被发现的bug，这让我感到很意外。毕竟我们的程序是在交给客户之后，客户会派专业的测试人员来进行测试，难道测试点的效果有这么神奇？

后来经过思考，我发现这和质量检查点的存在周期有关系，质量检查点是开发人员在开始写代码之前和写代码之后以及写代码期间加上去的。这三个时间段实际上在一定程度上代码了三中角色。开发之前写质量检查点，是需求分析人员的角色，这个角色侧重于实现的功能应该有哪些；开发期间写质量检查点，是程序员的角色，这个角色侧重于功能执行的特性；开发之后写质量检查点，是测试人员的角色，这个角色侧重于功能是否实现正确。当这三种角色结合在质量检查点时，它的效应就出来了。我想，这是我应该继续思考的内容----分析出开发过程中的各种角色，然后创造出新的管理措施或是实施方案来对这些角色进行合并，来发挥出新的角色效应---就像一个化学家将分子拆开成原子，然后对这些原子进行从新组合，从而创找出新的分子。当然，我们并不能保证这些新的分子的特性比之前的那个好，但是我们总是会有机会来创造出比之前的那个分子更好的分子---这就要看管理者的本事了。

关于质量检查点的讨论就在这里告一段落。质量，这个关系到项目成败，企业存亡的话题，每一天都在被不同的人用不同的方式提及。希望能够和大家就这个话题进行长期的交流。



相关文章:再谈质量检查点



更多文章，请访问 我的Blog导读