软件评估--->Bug的价值(产品市场角度分析)

最新推荐文章于 2025-08-20 21:46:48 发布

原创最新推荐文章于 2025-08-20 21:46:48 发布 · 1.3k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#产品 #cmm #工作 #平台

本文探讨了如何从产品市场的角度评估Bug的价值，根据Bug的严重等级（P10, P20, P30, P40）进行分析。P40 Bug的价值几乎等同于受影响模块的价值，而P30 Bug的价值则取决于其在模块中所占比例。P20及以下级别的Bug在产品价值中影响较小。通过统计项目中P40和P30 Bug的价值，可以估算出QA在产品开发中创造的增值。" 114476194,10543113,哈夫曼树的WPL值计算,"['数据结构', '算法', '树', '哈夫曼编码']

  总是在考虑，谁是公司直接财富的创造者，谁又是公司财富间接创造者，他们在各个岗位上的价值是怎么评估出来的。而公司的品牌价值又是怎么评估出来的？可是显然问题的范围太广，完全超出我的理解范围了。所以呢就从工作中的最小单位来评估，可能比较容易得出结果！评估Bug的价值这个思考过程应该很有创造性的！

  评估的第一个切入点问题：Bug的等级和每个等级Bug的价值是多少？

  公司内部对Bug分成P10,P20,P30,P40来分的。这个公司在接受CMM评估时，肯定会有明确定义的，可惜偶看不到。
从一个bug对产品质量的危害的严重程度，这个角度来看，我们可以大概衡量出这个bug在产品中的比重。显然这个和等级有相关性，P40的bug在产品中占的比例要比P30大的多，P30的又比P20的大的多。

//-------P40Bug的价值评估！-------
   这是一个角度衡量。P40的是最严重的，它危害是可能是整个产品不能用，或产品的一个模块的所有功能都不能使用，或者产品在某个支持的主流平台上不能工作。这种bug的价值应该几乎相当与这个模块的价值了。P40Bug和模块价值等价，从产品价值方面考虑，这种一种评估方法！这样的话P40Bug的价值就会依赖于模块功能在市场上的市价。结论：P40的bug就是模块价值的100%的比例。

//-------P30Bug的价值评估！-------
   这个P30的Bug，它主要应当是模块中的某一个功能不能用，出了问题。这个功能在模块中占的百分比，需要看具体的问题而定，具有一定的滑动性。模块有10个功能，其中有2个功能出了问题的，就是20%的比例吧！结论：P30的Bug是模块的价值*bug在模块中占的比例。

//-------P20Bug的价值评估！-------
   由于现在在项目CF的时候，只要求对P30以上的bug缴觅干净，所以P20的bug的价值在产品中几乎算不计了！

一个项目做完的时候，我们的统计一下，所有P40和P30的bug的价值，再将它折算成市价，哈哈，这样QA就能算出，这个项目中我们创造了多少的产品价值。一个产品在CC的时候的价值到Release的时候的价值，应该是在不断上升的，因为Bug的数量在上升嘛！QA在里面付出劳动了。

下期，会从产品生产线的内部角度分析Bug的价值。它还应该是QA发现Bug付出的代价 + DEV修改Bug付出的代价。