bug驱动。

实验室试行bug驱动开发的管理办法，严格指定每天测试人员抓bug和开发人员改bug的数量， 并以此作为员工业绩的重要考核指标。
领导的意思很明白，想比较精确地量化员工的工作力度，能够督促懈怠者，并且易于管理控制。
个人认为bug驱动开发的思路是好的，许多开源项目就是被社区内用户的新功能请求和bug提交来推动发展的。但这种严格量化的方法值得商榷：一、用一种简单的计数方法来比对各种不同类型的开发任务是不太科学的，比如界面表现的修修补补、针对用户体验的调整这类任务和新功能模块的添加以及性能的调优这类任务基本上是没有比对意义的；二、严格量化确实能够敦促懈怠者，但对于积极工作的员工来讲反而会影响他们的积极性，是一种负累，因为除了努力工作外，还要考虑将自身工作整理成定量的条目展示给领导者；三、严格量化本身就出于管理者对员工的不信任，这种方法在某种程度上会影响员工在工作上的积极创新的兴趣。
bug驱动不是错，但严格量化的方法是管理上的倒退，这是属于古老的“科学管理方法”体系中的东西，不适用于新兴IT从业者，因为和制造业工人比起来，他们更需要轻松的环境和自由发挥的工作空间。