背景
为了提升研发提测质量，我给研发定了一个BUG标准：5/5。按照职级不同，逐渐提升。
5/5：开发5人日，产生的P0&P1的BUG不能大于5个
公司也有自己的标准，就是P0&P1的数量占比不能超过30%，这个标准的问题就是没有对数量提出要求，就比如我开发了5天，产生了100个BUG，和另一个同学开发了5天，产生了10个BUG，但是P0&P1都是低于30%的，所以都是合理的。但是很明显这个对于QA来说，100个BUG测起来就很痛苦，就会认为质量比较差。
所以我才在这个基础上加了一个5/5标准，但是在落地的时候也产生了问题
问题
- 对BUG定级要求很高，如果QA之前没有要求对BUG进行定级，那这个逻辑在执行的时候就有问题。因为很多P2的BUG被定义为P1的，也会影响数据。
- 研发限制QA们提BUG了，因为有这个标准，那有一些跟当前需求没关系的问题，或者历史遗留的就会影响数据，所以研发就不让QA提BUG。
上面的问题在这个落地这个标准的半年内，会偶尔发生几例冲突。
思考
这个标准严苛么？
数据的来源是我待的2个团队的历史数据沉淀后，取最低一个标准，其中有基础架构团队的数据，也有纯业务团队的数据。最低是指，取质量最差的一个同学的平均数据然后再乘以一个1.几的系数得到的。所以从实际情况出发来看，数据是不严苛的，不然我待的第三个团队落地的时候早就有分歧了，但是实际是没有的。而且现在的团队也是偶发出现分歧，半年的时间里大约有个10例，但是半年内我们做的项目需求已经超过200多个，所以大多数研发提测质量都是满足要求的。
那是人的问题么？
是不是这些分歧都是个别几个人造成的，这些人沟通能力有问题，或者对于这个标准理解有问题。要么固定在几个QA身上，或者固定几个RD身上，如果是这样，那就针对性解决某个人的问题就行了。所以我们进行了一轮调查，首先让QA负责人沟通收集案例，让研发负责人收集研发案例，然后一起对一下。
最终结果是案例分布在不同的人身上，分布在不同的项目，有一些同学质量一直都很好，也会因为这个标准跟QA产生这样的分歧，那就说明是通用疑惑。
那是这个标准有问题？
我们几个负责人沟通的时候，QA负责人发表了一个观点。认为QA的工作就是发掘越来越多的BUG，你限制BUG数量，跟这个点是有冲突的，然后我们RD负责人和FE负责人也反馈说这个标准就像一把利剑悬在大家头上，所以大家都很紧张。
看这些反馈，你会觉得，是标准有问题么？这个问题回答起来很简单，就是去看看数据就行了。标准执行的半年来，目前项目提测BUG数量是越来越好的，反映到线上问题数量也是越来越少的。那就说明事情是对的，那就解决现在出现的问题就行，不用推翻这个标准。我理解问题的根本原因是执行过程中有一些信息没同步，造成大家的神经过于紧张，或者对于BUG标准也没有达成共识，才会有分歧产生。
解决办法
- 宣导这个标准执行的范围：在研发例会上，同步标准的范围，不包含历史问题、需求问题、优化问题、重复BUG。从根本上解决分歧发生的点
- 意识宣导：不可以阻止QA提BUG，只要商量好，把BUG归类好就行。
- 指定流程规范：根据目前发生的问题，给研发制定了面对不同场景如何处理的标准规范
总结
问题产生的根本原因是我在落地这个标准的过程，没有跟大家解释这个标准的范围。其实本来也不包含历史遗留问题，需求问题，重复BUG等，都是根据实际情况来定的，只要你能解释清楚原因，哪怕你10/5，也是没问题的。但是没想到大家过于关注了，超出了我的理解，这个事情才变得这么严重，也怪我平时可能对大家太严苛了吧，有些东西大家也不直接跟我反馈，就造成跟一线QA同学在那里battle。