今天看到了一个大团队的Bug跟踪报告。里面规定了每一天的Bug净降目标，以及阻塞类AB类BUG的净降目标。
这个目标会分解到每个团队，各个团队还会制定一个底线，比如每个开发每天必须改3个Bug。
这样持续运转，直到达到目标值。
这样看起来是以结果为导向，可以快速有效的达到目的。
但是，实际上会发生什么呢？我们来看一看。
作为一个开发，每天一醒来，就欠了3个Bug。来到公司，从剩余Bug列表里要先浏览一遍。首先看有没有和可能是自己引发的相关Bug，如果有，就再看看好不好改，如果可能好改，就挑三个。如果不好改，那再去列表里挑一些看起来好改的。
然后开始修改Bug，改来改去比较顺利都改完了。就再看看小组目标是否达到，再去挑选一些比较好改的。如果今天不太顺利，只改了一个，没有办法，只好主动加班。加到很晚了，也不能不休息，于是就把之前握在手里的比较容易修改的Bug拿出来改掉，凑个数，就可以早点回家了。如果非常不幸，连续几天都没有达到个人目标，就会遭受到不同层面的压力。而且也没有容易的Bug改了，怎么办？ 就只好差不多改完，凑个数量就可以回家了。之后验证的过程中如果发现没改好就reopen继续改，不过这就可以算作那天的修改目标了。
这是开发在这样的指标压力下可能会采取的对策。
如果开发会这么做，会有什么副作用呢？
第一、最高优先级的Bug可能不能及时得到修改
由于每天必须满足修改Bug的底线，所以大家会选一些不太重要的Bug进行修改，而那些难一些的BUG会被有意的忽略掉，一直推迟到发版的最后几天。而那时大家也不愿意进行大的改动，导致这样的Bug会被挪到下个版本再修复。
这样，敏捷里所倡导的总是工作在高优先级的事项上就无法得到保证，从而不能有效提交价值。
第二、由于净降指标的存在，导致修改Bug的质量不高
由于每天必须改三个，所以但凡有哪个bug占用了太多时间就意味着要加班到很晚。所以，每一个Bug修改完毕后都只会进行简单的自测或者不进行自测。很有可能会引入新的Bug，从而造成事实上的质量下降。曾经就有成员反映过，改得bug是达标了，但是会产生更多的Bug。
第三、由于整体的净降目标是在系统测试前制定出来的计划，整个系统测试期间按照这个计划执行。没有进行BUG分析，没有进行RCA分析来调整整体计划，就相当于开着跑车在土路上冲刺。最终导致整个团队只关注眼前任务而忽视了创造用户价值的长远使命。
第四、整个系统测试期间只关注了Bug净降，没有Case的执行进度与结果，没有能从整体上关注质量，会导致质量信息缺失，不能全面地把控质量。
问题是，在每天修改三个Bug的压力下，开发同学会采取什么策略呢？请考虑……
那么Bug跟踪，究竟跟踪的是什么呢？
是质量，产品的质量，影响客户价值的产品质量。
质量的跟踪等同于Bug的跟踪吗？
简单来说，在系统测试阶段，不仅要关注净降，还要关注每日新增和修改，不仅要关注Bug数量，还要关注Case的执行进度和结果。除此之外，要确保团队工作在最高优先级的Bug上面。不仅要关注Bug的修改数量，更应该关注验证关闭后的剩余Bug数量。不仅要按照计划执行，还需要根据Bug情况和根因分析结果，调整测试力度、测试计划以及修改的重点。除此之外，还要跟踪所有的质量活动，以便了解质量的全貌。
但是具体怎么做，还有两种方式：一种传统的传统管理方式，另一种敏捷方式。具体详情，请听后续分解……
不过多说一句，在敏捷的视角来看，这样的做法有两个问题：一、团队Backlog没有排序，大家随意。二、Bug修改没有明确的DOD，导致关注过程而不是价值。
