今天被提了几个bug,让我心情十分烦闷,冷静下来后也引发了一些我的思考.统计bug率固然是一种量化的指标管理方法,但是他真的是一种好的评价指标吗,我认为并不是的,他可能引发一些系统性的问题
1. bug像是子弹一样,引发员工互相射击
如果使用bug率的高低来评价一个员工的工作是否称职,那么就会造成一个现象,就是大家都会想方设法的降低自己的bug率,前端后端产品之间会相互甩锅,前端说是原型设计问题,后端说是前端交互问题,产品说是开发代码问题
大多数项目管理软件在每一条bug中都会有一个特殊的列,指派人/负责人.这是一个值得我们特殊关注的列,他会将这个bug绑定到个人的头上, 就如同射击瞄准一样,将子弹打到别人的身上,被击打者会非常的不爽,因为这会影响到他的绩效,或者是项目中排名.所以这个时候,被指派人的心态已经转变,也就是从让项目变得更好转变到,如何自己不被射击,他们会穿上防弹衣或者直接逃离战场,也就是职场中的甩锅和混, 他们会应激性的将错误推给自己的同事,并且尽可能的少承担一些需要负责任的开发需求.这直接导致了职场关系紧张和项目开发困难
2. 有些问题就像流弹一样,误伤了无关之人
我的同事被调去其他项目组或是我的同事直接离职了,而我接手了他的相关代码
这个时候问题显然比前面还要严重,前面是这个问题或多或少和你有关,但是现在,你面对着刚接手的代码,突然被bug子弹击中了, 你甚至连这个bug在讲什么都懵懵懂懂
误伤还不是最恐怖的,有一个东西把他的效果放大了无数倍,那就是统计口径 --- 千行bug率
这太恐怖了,因为你的代码行数是0, 但是你的bug可能不止一个
这些他人遗留的问题,变成了拖垮你绩效的武器
这会让员工觉得别人的代码是毒药,因为你一旦沾染上,就逃脱不掉他的诅咒,而且他还是一个不可控制的毒药,以为那些代码根本不是你写的,甚至代码风格都有差别
3. 需求和bug之间的模糊界限,可能引发更大的后果
在我的公司里, 需求需要遵守严格的提测上线流程,而bug则只要通过简单的回归验证测试就可以跟随版本发布到线上
我想你已经猜到结果了, 你猜对了, 有人会把应该是需求的问题当成bug提给你
例如: 我需要修改一个当前版本已经不合时宜的文案, 或是整体切换一个图标等需求
这种事情的大麻烦是,他把你开发任务,变成了fixbug任务, 本来是你的工作成果,却变成了你对“自己错误” 的修复和补救,这些东西如果都被统计到,会让大多数开发肝疼
所以说,一旦开始统计bug率,同事之间关系会变的紧张,项目开发人员会避重就轻逃避责任,项目管理者使用自以为的鞭子督促项目进展,反而适得其反
写前文的过程中,我也在不停的思考,是否有一个合适的办法,来解决这个问题呢,那么怎么将坏事变成好事呢,我想到了
将bug拆分!
第一类是需求引发的bug,也就是开发人员在日常开发中产生的bug,这种bug只要没有上线,不会产生任何损失,所以在规定时间内改掉这个bug,就完全可以当他不存在,毕竟测试的工作就是保证这些问题被发现和及时解除
第二类是其他bug,包括你接手的bug和以前未被发现的bug,甚至还有修改文案等小问题,将这些进行量化,首先想清楚,这些对于bug的修改人来说,不应当被算作是工作的失职,相反,应该是非常称职的表现,修改这些非人为bug明显会让项目朝着好的方向发展,所以修改这一类bug应该是积极的,甚至可以统计这些bug,每个季度颁发“救火急先锋”奖金(哪怕只是聚餐时单独和他喝一杯酒,口头表扬一下),这样大家会抢着修改这些bug.
不是指派人,而是相关人
将问题绑定到某人的做法是保留的,但是并不代表这个问题是非他不可, 相关人在可能在忙一个更重要的事情,所以这个问题可以交给不忙的同事协助解决,他可以询问原本的负责人这个问题的相关信息
这样有两个好处,一个是原负责人不用从复杂工作中抽离出来处理这个bug,而是讲述一下大概的修改方向就把这个问题交给同事,而这个同事也可以在自己的项目贡献中加上一笔,这会成为他竞争高绩效的筹码,也有助于同事之间和睦相处
如果按照我的主意来修改项目管理软件的话,我能预想到有几个好处
- 大家会抢着修改项目问题,提高项目bug的修改率,缩短项目中问题的存在时间
- 同事之间不会相互埋怨,而是真的相互帮助
- 面对不合理的bug时, 不会首先急火攻心,或者是上头红温,而是开心的去修改
这应该比拿着统计表威胁员工拿差绩效丢失年终奖要好多了, 起码项目不会越来越糟糕
