再谈质量检查点

联系到这两天项目组里发生的问题，我不得不再在这里谈一下质量检查点。

再谈质量检查点之前，有必要谈一下项目中经常发生的问题---提交项目失败。

在没有任何质量管理体系的项目组中，当提交的项目由于还存在bug被客户打回来的时候，我们通常会怎么去反省呢？是反省自己在工作中不够认真呢，还是该反省我们之前做的分析不够呢？其实，在这个时候做什么都晚了。那么我们该怎么弥补？是对自己说我以后再认真一点，还是我以后对任务的分析更深入呢？那我到底该做到什么程度才算是更认真一点呢？我到底该分析多少才算是更深入呢？如果我们只是这样的反省，那还是省了吧。因为这样的反省除了让我们感到郁闷之外，对项目本身是没有任何促进作用的。

而质量检查点在整个项目实践过程中，到底会起到什么样的作用呢？首先，我希望我们的程序员在开始被分配的任务之前，先将质量检查点写出来。将质量检查点写出来的过程实际上也是程序员梳理思路的过程，这个过程很重要。但是在这里通常会有不这样做的理由，我们的程序员通常会说：这个问题很简单，我已经想清楚了，把打写出来，是在浪费时间。在任务很紧的项目组中“浪费时间”可是一大罪状。其实从思维的角度来说，当我们自己认为将一件事情想清楚了，这只是我们自己主观的判断，而不是客观的描述。在之前谈质量检查点时，我提到了“盲区”就是指的这个问题。这个问题通常会导致我们在做项目或修改bug时出现偏差，并且很难被自己发现。要解决这个问题，就是要将自己对任务的认识写出来。

然而将自己的认识写出来真的可以解决这个问题吗？首先，写作的过程本身就是一个思考的过程，你每写一个逻辑单元，就意味着你可以在这个逻辑单元之上再继续思考下一个逻辑单元。其次，当你将你再次审视你写出来的资料之后，你的分析基础不再是原始的任务而是你刚才写出来的东西，这样你的思考才可能在这样的基础上扩展，从而最大限度的找之前分析的漏洞。其次，只有当你将你对任务的分析写出来之后，其他人才有可能帮助你检查你的分析是否存在漏洞。而这就是质量检查点产生的基础。

我在文章的开始强调“没有任何质量管理体系”，是因为我认为质量检查点是一种轻量级的质量管理手段，可以以很低的成本在项目管理中实施，它应该是小型开发团队进行质量管理的一种有效手段。

 

 

相关文章:  项目管理之质量检查点

 

更多文章，请参考我的Blog导读