老板要在每个bug报告上加上“谁的责任”项

来源:外刊IT评论

看到这样标题,我的第一反应就是反对老板这样做。作为开发人员,我最讨厌有人指着我的鼻子说:这是你的责任,你写的代码出了问题。我通常会争辩,有时会恼羞成怒。但如何能用充分的论据来证明这样做法是不合适的呢?我还真没有系统的考虑过。所以,当看到有这样的一个讨论时,我马上就被吸引住了,群众的力量是巨大的,群众的思想放光芒,我从讨论中学到了不少知识,有了这些论据,当日后不可避免的遇到指责时,至少心里能找到不少安慰。下面先看看这个伟大讨论的发起人对自己遇到的问题的描述吧:

在最近的制度改革中,老板要在我们的bug跟踪单模板中加入“谁的责任”项,他认为这样能提高程序员的责任感(跟踪单上已经有地方指明bug是属于哪个功能/用例的)。我认为这样会打击程序员的士气,导致人们相互指责,而且对于一些由于需求问题而被当成bug的情况无法填写。

有没有其它的能反驳这种做法的有效方法?有谁知道哪里有关于这方面问题的文章可参考的?我希望能拿这些给团队的同事和老板看。我认为这种文化是不可接受的,希望能在实施前阻止它。任何建议我都十分感激。

老板要在每个bug报告上加上“谁的责任”项

有网友一针见血的指出这样做的弊端,就是:

如果有人认为“谁的责任”项要填的是自己的名字,他就不会报告这个bug。这个会导致团队的bug数减少。

对这样一个问题,我最欣赏的回答是下面一条:

对于这样的做法,我首先要做的是问你的老板他这样做究竟想解决什么问题。有很多显然更好的方法能解决他想解决的问题。

对于一个事情,真的需要有一个人站出来承担责任吗?如果是这样,那你的老板可能在其它什么地方出了问题。一个好的工作流程是需要多人共同参与的,在软件正式发布前,它需要经过分析人员,开发人员,代码审查人员,测试人员。如果你们没有经过所有的这些步骤,那么严格按照这些步骤开发将是解决你的老板的问题的最好方案。如果你们已经是按照这个流程去做了,那么,哪个个人应该为此承担责任呢?也许谁都不应该,也许应该谴责的是这些历史遗留的代码。

让人们背后议论、相互指责会引起很不好的后果,千万不要随意给人涂黑点,一旦做了就很难挽回。这样做解决不了任何问题。很少有人会故意的大意犯错误。你的老板应该自我反思,看看问题究竟是出在什么方面,看看如何能让这种错误不再发生。

这样做了后,你就能清楚的看出,如果有人在不断的犯错,这很可能是完全不同另外一个问题。

但是指stackexchange网站上最受欢迎的回答却是下面一个:

告诉他,这外行人对内行人所说的问题根源的外行叫法(如果没有专门的项来描述这个,一般会使用注释来替代)。

你可以在网上搜一下软件bug根源分析等内容,你能搜到丰富的资料来证明你的观点1234, …

… 一个软件bug的根源通常不是在某个单个的开发人员身上(填写此项时特别要注意这点)…

这清楚的说明了为什么“问题根源”是专业的,而“谁的责任”是外行的。能说明个人责任当然很好,但有时候问题的根源会产生在开发团队“外部”。

告诉你的老板,如果需要指明一个承担责任的人,“问题根源”项应该写成这样:“编码错误由鲍勃提交,版本号是1234,吉姆在代码审查中疏漏了此错误,审查号是567”。“问题根源”项的目的就是要记录这样的内容,包括一些在开发团队之外的原因。

例如,如果一个bug是由于硬件引起的(受到谴责的应该是开发团队外的购买/测试硬件的那个人),用“问题根源”就能很好的描述这个问题,而“谁的责任”就会导致问题跟踪线索中断。

对于其它的开发团队之外的人导致的错误也能这样记录 —— 测试错误,需求变更,管理决策问题等。比如,如果管理部门决定不投入资金制备灾难应急硬件设备,在数据中心停电宕机事件上填写“哪个程序员的责任”将毫无意义。

你遇到过这样的事情吗?你对此有何见解?

1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部