您当前的位置: 故事六：质量管理
对每个定制项目来说，工作产品的质量的高低都是根据客户需求决定的，要求高，给钱多的，质量就高，要求低，给钱少的，质量就低，这个项目也不例外。做过对日外包项目的人都知道，日本人对质量的要求特别严，尤其是那些银行证劵类的软件，上线之后的bug数直接影响到能拿到多少回款，多出一个bug就会少拿一笔钱。因此试运行阶段，对全部项目组成员来说，都像顶了个避雷针似的，不定哪块云就能来个雷炸着自己，虽然不至于直接被罚款，但是加班和挨骂甚至半夜被从家里叫来都是很可能的，这段时间，要求全员24小时随传随到。为了避免后面的这些问题，项目的质量从开始时就要求的很严，下面详细说说都是怎么做的。
一、文档化
概要设计、详细设计、测试用例、概要设计的评审、详细设计的评审、测试用例的评审全部都有一一对应的文档，我相信能出这么多文档的项目没几个。详细设计到伪代码的程度，测试用例要求所有分支全覆盖。
当然，单纯有文档是提高不了质量的，但是文档的存在，降低了沟通难度，很大程度上消除了误解、理解上的差异并在形成了共同语言，比如说到“铭柄”这个词的时候，没人知道是什么意思，但是项目组中的人都知道这是一个功能模块。
二、评审
所有的工作产品都必须经过评审，评审采用会议评审和交叉评审两种方式。
最先产生的工作成果采用会议评审的方式，把大家都可能出错的地方找出来，统一改正，会议评审一两次之后，改成交叉评审，这样可以提高工作效率。
所有的评审问题都要记录下来，形成评审表，需要横向展开的问题，进行统一管理。
三、测试
单元测试，连接测试，系统测试，monkey测试，当然还有疏通测试，“V”模型里提到的所有测试，在这个项目里都存在，而且所有的测试都有文档化的测试用例，有测试过程记录，测试结果记录，所有的bug都被记录，被分析，bug中描述不清楚的用截图表示。
在评审和测试中，单纯因为手误或者马虎出现的bug是很难被原谅的，如果是多个人出现相同或类似的单纯错误的话，则认为是大家都可能出现的，要所有人把自己的代码都查一下。
四、限定代码行数
将每个模块的复杂度控制在一定范围内，超出范围时，进行拆分，以降低开发和查找bug的难度以及出错的概率。
五、变更记录
不管是代码也好，文档也好，凡是有修改的地方，都要有变更记录，而且原来的内容不能直接删掉，要保留。变更记录中要写明是谁在什么时间为什么做的修改。
六、工具
这个前面也已经提到过了，基本上都是项目组自己开发的小工具，用来提高工作效率和质量的。
这些管理质量的方法，不能算是这个项目经理的原创，只是这个项目中是这样做的，而且不仅这个项目，很多对日外包项目都是这样管理的。