编者按:12件影响程序员效率的事情,看看你身边存在吗?本文作者John Lafleur,原文标题Top 12 Things That Destroy Developer Productivity。
身为技术主管和工程经理,我们经常遇到的问题是如何提高团队的效率。但是在你集中精力提高他们的工作效率之前,你可能首先要考虑是什么在破坏他们的工作效率,并建立起良好的基础。
程序员想要完成什么工作,根本离不开电脑,但确实还有很多公司希望程序员不使用电脑就能完成工作(你敢信)。
因此,我们列出了12件阻碍程序员提高效率的事情。下面给出的顺序是按最重要到不重要的排序的(从我的视角),请大家斧正。
其实吧,给程序员们加薪也是个好办法,哪怕加薪10%,也能起到相当不错的激励作用。
在我看来,随意打断是程序员的工作最影响他们效率的事情。开发人员无法轻松回到被打断之前的状态。他们需要再次找到感觉,然后继续上手原来的工作。干扰越多,挫折越大,质量越低,bug就越多——而且还在继续。
我越被干扰,效率就越低。每次被打断了工作流程,我就得重新开始找感觉,所以如果我一天被多次打断,这一天想要又什么成果基本就不可能了。
——一位程序员如是说道
那开会呢?开会和干扰的唯一区别是,会议是有计划的干扰,会让事情变得更糟。如果程序员知道自己会在工作时可能会出现干扰,那么他们就无法在工作中取得进展。因此,如果他们在一两个小时内得去开会的话,几乎无法在工作上取得进展,因为大多数工程任务需要足够多的时间。
正如Paul Graham所说的,“一次会议可能会毁掉整个下午,因为它导致了大块的时间碎片化,无法集中精力完成任何艰难的事情。”
如何才能避免这种情况?其实也不难,例如,在一天开始的时候或者午饭前开个短会,以避免给程序员们不必要的打扰。
在不同类型的管理人员中,那些微观管理人员可能最招程序员嫌弃。因为微观管理人员往往手伸得太长,喜欢组织更多的会议,或者有计划外的干扰——而且不仅仅如此,他们还对程序员缺乏信任,这样一来,程序员会觉得他们在不断地削弱自己的技能和完成工作的能力。这时候,程序员所有的工作尽头就都没了,这就不单单是效率的问题了。微观管理人员可能是程序员离职的最主要原因,或者至少是更换团队的原因。
语焉不详也是导致程序员效率低下的原因。如果一份Bug报告里面写着“它坏了,把它修好”,这份报告里没有为程序员提供足够的信息。顺便说一下,在这种情况下,如果你专门设置了报告模板能解决很多问题。
如果有什么东西的含义非常模糊,然后程序员又错误地理解了意思,最终他们的努力就都打了水漂,一切就又得推倒了重来。
工作的优先程度也要弄清楚,你需要为程序员省下思考该干什么的时间。这样一来他们可以全方位地投入到工作中,给你交一份满意的答卷。
你听说过“运动式管理”吗?最怕的就是领导们一般什么都不管,然后突然哪天心血来潮,唰地“俯冲”下来横插一杠,把所有的事情就都搞砸了。他们会口里嚷嚷着“这样不对,这是错的,不行这样不好”之类的话,然后拍屁股走人。更不幸的是,这种事情发生的频率比我们以为的要高得多。这种行为让程序员深感沮丧,然后在接下来的几个小时里,他们的工作被迫停止,有时甚至会耽搁好几天的时间。
还有一些经理或其他程序员把你过去几周所做的工作全部归功于自己。程序员最看重的是能力。把别人的功劳揽在自己身上,就是把别人的能力从他或她身上强行夺走。这种行为实在太过恶劣,因为我觉得这种行为在团队之中制造了太多的紧张,在相当长的一段时间内它只会破坏整个程序员群体的效率,有百害而无一利
这对非程序员来说可能有些奇怪,但是程序员身处的工作环境对他们的工作效率有重要的影响。例如,有一些白噪音——交流电声,车声驶过——可以帮助他们更好地集中注意力。这就是为什么我们很多人都戴着耳机的原因了。而且我刚刚发现雨声也很棒。
同样地,如果工作场所的设计乏善可陈,而且人来人往噪音很大,那简直就要了程序员们的命了!或者从经理的办公室可以直接看到程序员的电脑,这个会带来额外的压力,也会有更大的几率使得程序员的工作被打断。
在某个项目范围内出现不受控制的变化也是让程序员痛苦的地方之一。当某个项目的范围没有正确定义时,这种情况很容易出现。
这种情况会导致相对简单的请求变成非常复杂和耗时的行为。大多数情况下,它发生在开发过程中,这对程序员来说不啻为巨大的噩梦。
这个乍一看可能有点奇怪,但其实很容易理解。如果某个产品团队在没有验证(通过客户反馈或任何其他方法)相应特性的情况下定义了其团队的优先级,然后程序员又发现大多数特性最终都没有被采用时,他们会觉得自己的努力是无用的,更糟糕的情况下会失去动力。我们或多或少都想有点影响力,这对程序员来说可能更重要。
技术引进是个比较复杂的问题,需要深思熟虑,从更长的周期来考量。如果说当前任务紧迫,或者一定要迅速将产品投入市场,那么适当地引进一些技术是不可避免同样也是合情合理的,并且可以在短期内提高软件开发的速度。但是,从长远来看,一味地引进技术可能会增加系统的复杂性,从而减慢开发速度。非程序员常常低估了效率的损失,并且总是倾向于突飞猛进,这就导致了重重问题。
但是,如果从来都没有把自行开发列入考虑事项,那么它不仅会影响效率,还会影响将来的产品质量。
程序员们每天都会使用各种各样的工具来编程。自动化程度越高越好。不用说,如果哪个程序员使用了比较“古老”的工具,那可能会影响自己的工作效率。同样,大屏幕与笔记本电脑的对比也会产生影响。考虑到硬件成本和程序员的薪水,如果效率能提高5%,那就值得投资!身为经理,完全应该为开发团队提供他们喜欢的工具和硬件(硬件单独提供,工具就没必要了)。
在学习如何编写代码时,老师们教育我们要尽早和经常地讨论。老师的出发点在于,多讨论起码可以增加思想的碰撞,比自己一个闭门造车要好得多。但不幸的是,许多程序员将其错误地理解为自己必须注释每一行代码,这就是为什么我们经常看到这样的代码了:
r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}
你知道这段代码是做什么的吗?我反正不知道。问题是,虽然有很多注释描述了代码是做什么的,但是没有一个注释说明为什么要这样做。如果程序中有一个bug,而你在浏览时无意中发现了这个bug,你甚至不知道从哪里改起。
最后一个与管理人员要求程序员进行评估的倾向有关,管理人员会要求程序员尽可能降低这些评估,然后神奇地将它们视为最后期限!管理人员甚至会认为,正如程序员自己根据估算“决定”的那样,他们承诺在最后期限内完成工作,因此最后期限完全可以视为是足够有效。
作为程序员肯定觉得这些最后期限不合理,然后他们就会因为紧张无法集中注意力。
这12件事,它们对大多数其他项目工作来说都很普遍。对于程序员来说,每一种情况可能更甚,因为他们需要集中精力来完成任务。
如果你在日常工作中发现有上述影响存在,可以与程序员们谈谈,看看这些问题如何解决,最重要的是要相信他们的反馈和见解。尽管今天的科技与30年前大不相同,但教训仍然是一样的。当你考虑团队效率时,不能忽视人为因素。与你的团队一起改善工作流程、环境和习惯,以提升整个团队的工作效率。
编译组出品,编辑:郝鹏程