联系到这两天项目组里发生的问题,我不得不再在这里谈一下质量检查点。
再谈质量检查点之前,有必要谈一下项目中经常发生的问题---提交项目失败。
在没有任何质量管理体系的项目组中,当提交的项目由于还存在bug被客户打回来的时候,我们通常会怎么去反省呢?是反省自己在工作中不够认真呢,还是该反省我们之前做的分析不够呢?其实,在这个时候做什么都晚了。那么我们该怎么弥补?是对自己说我以后再认真一点,还是我以后对任务的分析更深入呢?那我到底该做到什么程度才算是更认真一点呢?我到底该分析多少才算是更深入呢?如果我们只是这样的反省,那还是省了吧。因为这样的反省除了让我们感到郁闷之外,对项目本身是没有任何促进作用的。
而质量检查点在整个项目实践过程中,到底会起到什么样的作用呢?首先,我希望我们的程序员在开始被分配的任务之前,先将质量检查点写出来。将质量检查点写出来的过程实际上也是程序员梳理思路的过程,这个过程很重要。但是在这里通常会有不这样做的理由,我们的程序员通常会说:这个问题很简单,我已经想清楚了,把打写出来,是在浪费时间。在任务很紧的项目组中“浪费时间”可是一大罪状。其实从思维的角度来说,当我们自己认为将一件事情想清楚了,这只是我们自己主观的判断,而不是客观的描述。在之前谈质量检查点时,我提到了“盲区”就是指的这个问题。这个问题通常会导致我们在做项目或修改bug时出现偏差,并且很难被自己发现。要解决这个问题,就是要将自己对任务的认识写出来。
然而将自己的认识写出来真的可以解决这个问题吗?首先,写作的过程本身就是一个思考的过程,你每写一个逻辑单元,就意味着你可以在这个逻辑单元之上再继续思考下一个逻辑单元。其次,当你将你再次审视你写出来的资料之后,你的分析基础不再是原始的任务而是你刚才写出来的东西,这样你的思考才可能在这样的基础上扩展,从而最大限度的找之前分析的漏洞。其次,只有当你将你对任务的分析写出来之后,其他人才有可能帮助你检查你的分析是否存在漏洞。而这就是质量检查点产生的基础。
我在文章的开始强调“没有任何质量管理体系”,是因为我认为质量检查点是一种轻量级的质量管理手段,可以以很低的成本在项目管理中实施,它应该是小型开发团队进行质量管理的一种有效手段。
相关文章: 项目管理之质量检查点
更多文章,请参考我的Blog导读