很多文章都在探讨技术负责人和工程项目经理的角色，其中经常出现的一个共同问题就是如何提高团队的生产效率。在集中精力提高生产效率之前，首要任务则是打下一个良好的基础，这就需要考虑到是什么摧毁了生产效率。可惜的是，尽管《人件》发表了近30年的时间了，但还是有很多团队以不可思议地方式遭受着惊人的生产效率降低！（注：《人件》英文名Peopleware: Productive Projects and Teams， 发表于1987年，探讨如何通过有情商的人来创造高生产力的团队。）

众所周知，程序员们不能无电脑操作徒手写代码，但有很多公司却忽视了心境的重要性——两者缺任何一个都不现实。

接下来我们剖析一下，对开发者而言，哪12件事情会阻碍TA们的工作状态和延缓生产力。下面这个清单排序是从影响最大的开始。欢迎大家的评论～如果你还在怀疑这个问题是否值得你的投入，请想一想开发者的薪资。哪怕是提高他们10%的生产力，也会给你创造一笔不小的收入！

1、干扰和会议（Interruptions & Meetings）

在我看来，开发者首要的效率杀手就是受到干扰，因为TA们很难找回被打扰前的状态。首先，TA们需要找到工作的感觉，然后再慢慢摸索到刚才的进度，这个重启的过程轻而易举就是半个小时以上，而且被中断的次数越多，挫折感就越强，工作质量越低，bug也会出现地越频繁......

“在我想开始工作的时候，你给我使绊子的次数越多，我每次尝试找回感觉的间隔时间就越长。所以如果一早上我的工作不停地受到干扰，那么这一天我都生产力低下也不是什么怪事。" Reddit上的一位开发者

那开会呢？开会和干扰的唯一区别是，前者是有计划的干扰——其实这更糟糕了。如果开发者知道TA们在工作时会遇到一个中断点，那么TA们很难推进工作的进度。大多数程序任务都需要花较长的时间完成，如果一两个小时就开一次个会，程序员们任何工作的进展都会变得举步维艰。

正如保罗·格雷厄姆（Paul Graham，美国著名程序员）所写的那样：“仅仅一个会就可以把整个下午炸成两块，每一块时间都太短，无法完成任何有难度的工作。"

那么如何避免这种情况呢？管理人员们先不用急着找借口，这个问题是有据可查的，比如，完全可以在上班一开始或午饭前召开简短的会议，以避免如上所述的无必要的干扰。

2、微管理（Micro-magement）

在不同管理人员类型中，微管理者可能是开发者提高生产效率最大的拦路虎。毋庸置疑，微管理者往往会开更多的会，实施更多干扰计划。不仅如此，这些行为本身代表着缺乏信任，从开发者的角度来看，会觉得管理者在不断削弱TA们的技能和完成任务的能力，而且在被干扰间隔期间的任何动力都会随着这个想法消失殆尽。微管理不仅仅影响生产力，甚至可能是开发者换团队或者离职的首要原因。

3、模糊不清（Vagueness）

有很多方式阐述“模糊”一词。比如“坏了，修一修吧！”这样的bug报告是无法提供足够的信息供开发者参考的。对了，在这种情况下，使用bug报告模板可以有所帮助。

再举个例子：对某个功能的规范不明确。开发者往往会启动TA们觉得合适的功能，但一旦管理人员更详细地说明了预期的功能，TA们可能会逼不得已从头再看。

不清晰的工作优先级也属于这一类行为。其实很容易避免让开发者的时间浪费在纠结上面——纠结自己是否在做对的任务。如果有一天管理者突然问道，“为什么你在做这个啊？”（而任务的优先级并没有被定义）......好吧，你应该明白了：开发者会非常郁闷的。

4、海鸥式管理（Seagull Management）

这个有听说过吗？意思是管理者完全不参与工作，但是，TA们会像海鸥一样时不时“俯冲”下来遍地拉屎——“这个错了，还有那个也太难看了吧！”等等，然后又飞走了。老实说我很钟意这幅画面，但与我们的期望相悖：它在现实中发生地很频繁。这种管理会让开发者非常沮丧，在接下来的几个小时，甚至几天内，都很难找回状态。

5、被人抢功（Credit Greediness）

你有没有遇到过这样的情况：你的经理或其他开发者把你过去几周的工作全部归功到TA们自己身上？开发者最看重的是个人能力，把别人的功劳据为己有，就是把别人的能力从TA身上拔下据为己有。这个问题在我的清单上排序是相当高的，因为我觉得这会制造冲突的氛围，从而在相当长的一段时间内拉低开发者的生产力。

6、环境糟糕：噪音、动静、工位设计（Environment）

环境很重要——这对非技术人员来说可能有点奇怪。但工作环境对TA们所做的一切都有重要的影响。例如，一些无伤大雅的背景声音像空调啊、汽车和卡车驶过的声音啊，这些“白噪音”都可以帮助TA们集中注意力，这正是许多人喜欢戴耳机工作的原因！其实我也是刚刚种草了RainyMood（一款模拟下雨天音效的系列软件），强推!

同样，如果工作空间的设计造成了过杂的声音和动静，这可是不会帮助TA们集中注意力的！或者是让开发者的电脑屏幕的朝向管理者直视的方向......好吧，这不仅仅压力山大，而且会有更多被打扰的机会。

7、范围蠕变（Scope Creepiness）

项目管理中的范围蠕变（也叫焦点蠕变、需求蠕变、功能蠕变，有时也叫“厨房水槽综合症”）是指项目范围中不受控制的变化。当项目的范围没有被正确定义、记录或控制时，就会发生这种情况。

范围蠕变将相对简单的请求变成了可怕的、复杂的、耗时的怪兽！而大多数时候它都发生在研发的过程当中。举例说明下，假如有一个简单的功能：

第1版（实施前）：“显示位置地图”

第2版（第1版快完成时）：改为“显示位置的3D地图”

第3版（第2版快完成的时候）：再次改为“显示用户可以飞过的位置的3D地图”

8、无法参与产品设计过程（Production Definition Process）

这个乍一看很奇怪，但其实很容易理解。如果一个产品团队在定义工作的优先级时，从来没有验证过（通过客户反馈或其他任何方式）相应功能的优点，而最后一大堆功能都没有派上用场，这会让开发者会感到自己的苦劳百无一用，从而便失去工作的动力。人们都希望感受到自己的影响力，这对开发者来说更加重要！

9、缺乏对技术债务的考虑（Lack of Consideration of Technical Debt）

技术债务是为了更快地发布软件而故意实施非最优的解决方案或编写待改进的代码。承担一些技术债务是不可避免的，并且可以在短期内提高软件开发的速度。但是，从长远来看，它会造成系统的复杂性，从而延缓开发者的生产力。问题就来了：非程序员们往往容易低估生产力损失的重要性，只顾盲目推进度。但如果重构不是首要任务，它不仅会影响生产力，还会影响产品质量。

10、缺乏多样的工具或硬件设备（Tool Multiplicity & Hardware）

开发者每天都会使用很多工具来编程、推送和合并代码。自动化程度越高越好。不言而喻，如果你使用“古老”的工具，这必定会影响工作生产力。同样，用笔记本电脑工作相较于用一个大屏幕也会产生影响。考虑到硬件成本和开发者工资，只要有5%的生产力提升，在这上面的任何投资都绝对是值得的。请给你的开发团队喜欢的工具和硬件吧！而且相比单独使用的硬件，工具可以大家一起使用！

11、缺乏描述如何/为何的文档 （"How" Documentation）

在学习代码的时候，我们常常被教导要尽早并经常注释。这意味着注释太多胜过注释太少。可惜的是，许多程序员错误地把这句话理解为，TA们必须对每一行代码都进行注释，这就是为什么我们经常看到下面这样的代码（取自于美国著名程序员Jeff Atwood发表的“无注释编码”的博客文章）。

 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，而你偶然发现了这段代码，你将茫然不知从何下手。

12、不切实际的期限（Impossibly Tight Deadlines）

清单上的最后一项：管理者倾向于问开发者要时间估算，催促TA们尽可能缩短这些估算，然而又神奇地把它们当做完工的期限。管理者们甚至会认为，由于开发者自己“决定”了时间，承诺了最后期限，因此开发者说的应该被认为是有效的并可以汇报给上层管理人员。不足为奇的是，开发者们往往觉得那些期限不合理、武断、紧张，这就造成了冲突的氛围和精力的消散。

这些对开发者来说意义何在呢？

如果你回味下这12件事，其实它们在很多基于项目的工作中都是很常见的。然而开发者需要精力高度集中来推进任务，因此其中每一件事对开发者们来说意味着更深远的影响。

如果你发现自己的公司也存在上述现象，那么有必要与开发者一起解决这些问题。找TA们谈谈话、分析下这些现象是否造成了问题，以及如何解决。无论他们说什么，最重要的是要相信TA们的反馈和见解。虽然当下的技术与三十年前大相径庭，但经验教训却并行不悖。当考虑团队生产效率的时候，我们无法忽视人的因素。与团队一起改进流程、环境和工作习惯，让TA们来指导你如何获得最高的生产效率和影响力吧！