5、很关键的--质量

预计缺陷总数

实际缺陷总数

预计致命缺陷

实际致命缺陷

预计主要缺陷

实际主要缺陷

预计次要缺陷

实际次要缺陷

预计遗留缺陷数

实际遗留缺陷数

需求阶段预计发现缺陷

需求阶段实际发现缺陷

设计阶段预计发现缺陷

设计阶段实际发现缺陷

构建阶段预计发现缺陷

构建阶段实际发现缺陷

测试阶段预计发现缺陷

测试阶段实际发现缺陷

实施阶段预计发现缺陷

实施阶段实际发现缺陷

交付后1个月内发现总缺陷

交付后1个月内发现致命缺陷

交付后1个月内发现主要缺陷

交付后1个月内发现次要缺陷

需求活动预计引入缺陷

需求活动实际引入缺陷

需求活动实际引入缺陷(需求时发现)

需求活动实际引入缺陷(设计时发现)

需求活动实际引入缺陷(编码时发现)

需求活动实际引入缺陷(测试时发现)

需求活动实际引入缺陷(实施时发现)

需求活动预计清除缺陷

需求活动实际清除缺陷

设计活动预计引入缺陷

设计活动实际引入缺陷

设计活动实际引入缺陷(设计时发现)

设计活动实际引入缺陷(编码时发现)

设计活动实际引入缺陷(测试时发现)

设计活动实际引入缺陷(实施时发现)

设计活动预计清除缺陷

设计活动实际清除缺陷

编码活动预计引入缺陷

编码活动实际引入缺陷

编码活动实际引入缺陷(编码时发现)

编码活动实际引入缺陷(测试时发现)

编码活动实际引入缺陷(实施时发现)

编码活动预计清除缺陷

编码活动实际清除缺陷

测试活动预计引入缺陷

测试活动实际引入缺陷

测试活动预计清除缺陷

测试活动实际清除缺陷

实施活动预计引入缺陷

实施活动实际引入缺陷

实施活动预计清除缺陷

实施活动实际清除缺陷

项目在开发前应该预估会有多少bug，根据bug的修改时间知道要多少返工，以及测试轮次。这些数据也可以反映，因需求不清导致多少bug?引入bug的影响率?以及销售、交付后有多少bug?这些数据有了，考核都有了。

例如，交付后1个月返工的bug，考核测试与开发、项目经理、总监等。

再例如，你前面有规模估计，自然能预估会有多少bug。以代码行为例，标准如果是千行bug率在千分之3，那么你是10w行规模则会预计bug300个，测试1轮如果可以发现100个的话要3轮测试。开发测试计划中你制定2轮不合理了，1轮1周，那需要3周，你给2周也不合理了。

综上可见，度量是项目管理的灵魂。如何根据当前阶段能力，选择关键的度量点是qa、总监要很清醒的。不能不度量，也不能度量过度。以上5点做好了，这家公司基本是正规的公司了。其他的，一些其他高级度量点等再成熟了再度量