《QUML：量化需求分析与建模》节选之五：一个量化管理项目的一生（4）

本书由本人编写，于2014-09-09在百度阅读首发，博客将转载试读部分的20%内容，以及非试读章节的某些片断。

电子版链接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6### 

第三个月​

结项度量

第三个月月底，项目成功交付。

看惯了文山会海，高层领导希望这个小项目做一个简短的总结。

结果他看到了下面的表格：

功能点耗时率是指完成每个功能点需要5.16小时，P40指只有40%的项目更快；功能点缺陷率是指每个功能点被发现包含0.9个缺陷，P55指55%的项目比这个项目好。

所以这个项目在这家企业中，是一个比较中庸的项目，工作量略好而质量略差。

行业比较

上面这些数据如果放在在行业中已经是很好的了。中国政府OA项目的功能点耗时率中值是7.17小时/功能点；质量数据国内暂缺，引用美国的一则数据则是1.2/功能点左右。

功能点还能做很多事情，比如“进度”这样东西上面的表格里边还没有提，以后相应的章节中还会提到。

小结

可能初次接触量化管理的读者会觉得数字太多了，难以掌握。但熟练之后，会发现其实量化管理的成本最低，效果最明显。

比如在“第二个月”中提到的测试。当测试经理面对空白的Word要编写《测试计划》时，最关键的内容就是“这是一个多大的软件？应该用多少测试用例？投入多少人力？会测试出多少缺陷？”如果这些信息没有，那么不管这个测试计划后来写了多少页，写得多详细，都不令人放心。

作为一个高层经理，如果一个团队在全程中能持续提供上述数字，而不是写出厚厚的文字报告，管理会显得更轻松一些。

在接下来的章节里边，将会介绍如何轻松——不，甚至说是“顺便”——获得这些数字。

由于隐含了国际标准功能点的规则，使用本书中所说的需求分析与建模、代码设计等方法，工作产品会形成天然的颗粒度，不需要额外做太多量化管理的活动。