破坏程序员生产力的 12 件事

原文转载自 John Lafleur ： goo.gl/fqfN8h

不少文章都提到如何当好一个技术组组长或者技术部经理。常见的话题通常都是如何提升团队的效率。但当你试图提升程序员的效率时，首先要搞清楚效率是怎么变慢的，清楚缘由后再来提团队效率。虽然 Peopleware 在 30 年前就发表了，但不少团队依旧会出现精力浪费和效率低下的问题。

没人会期待程序员不用电脑就能编好程序，但却有不少公司在不了解程序员的思惟方式下就期待他们能把程序编好，这确定是不现实的。

我总结了拖慢程序员创造力和效率的 12 件事，从影响最大到影响最小进行排序。若是有疑问欢迎给我留言！

若是你在想是否应该继续看下去的话，想一想付给程序员的高工资，因此哪怕提升 10% 的效率也是值得的！

1.打断&会议

我认为「打断」能够排在破坏程序员创造力的第一位。程序员在被打断后通常不能作到马上从新开始编程。被打断以后继续编程的话，一般程序员须要从新看一遍代码，再次逐渐进入到编程的思惟环境中，才能想起来被打断以前的思惟逻辑，再从被打断的点从新开始。这个过程大概要花 30 分钟以上。「打断」越多，烦心越多，工做质量也会下降，Bug 也会随之增长—成为恶性循环。

「若是你在我准备开始编程的时候打断我，次数越多- 我从新进入状态耗费的时间就越长。若是你在早晨就安排了一堆会打断我工做的会议，就别怪我这一天什么程序也没编出来」出自 Reddit 上的一个程序员。

那么「会议」呢？「会议」和「打断」的惟一区别在于会议是计划好的打断，这比非计划的打断还闹心。程序员没法在被打断的时候还能专心作其余任务。好比你跟程序员开 1-2 小时的会议，基本上不会有什么进展，由于通常技术性的任务 1-2 小时之内是没法完成的。

保尔·格雷厄姆(Paul Graham)说过，「一个下午若是被分红两个小会议是最糟糕的状况，由于这两个会议都过短了，什么都作不了。」

那么，如何避免这两种状况呢？

如下请记笔记：工做会议能够安排在一天开始的时候或者午餐前，并尽可能简短，避免没必要要的「打断」。

2.微管理

在全部管理者类型里面，微管理经理对程序员的效率影响最大。这很容易理解，由于微管理经理的会议和临时打断会更多一些，而这些会议和打断会显示出来他们对程序员不信任，程序员也会以为他们的能力被低估。致使程序员编程的动力在每次被打断的时候就跟浇了冷水同样。这样的影响不止效率，还会使程序员离职或者更换团队。

3.编程要求模糊

编程要求很模糊有不少种表现方式。好比，故障报告（Bug report）中像「这个不运行，重作！」并不能有效告诉开发人员如何解决问题。用统一的故障报告模版就能解决不少问题。

若是某项功能要求很模糊，在这个状况下，开发人员只能靠本身的感受来编程。最好是可以把某项功能的要求细节化，再递交给开发人员。

再有，不清楚的优先级也算需求模糊。这些没必要要的时间原本是能够避免的，程序员却要花时间搞清楚本身是否在完成正确的任务。想象一下若是经理来问程序员为何在作这个任务（在任务优先级没有细节化以前）。你能想象以后的各类解释和误解…

4.海鸥管理

你据说过「海鸥管理」么？「海鸥管理」是指管理者彻底无论工做，像海鸥同样在高空飞，但….他们时不时的会跳出来捣乱。「这个作的不对，这个，这个还有这个作的不行」等，而后再继续飞走。我必须得说，这个场景虽然听起来很好笑，但却很常见。这种状况对开发人员来讲很是的烦心，他们可能在以后的几个小时，甚至几天都没法专心。

5.被「占便宜」

你有过上层或者其余的程序员把你工做成果拿去当成本身成果的状况吗？在程序员心中，能力被承认是摆在第一位的。别人把本身的成果拿去当成是他们的成果，等于剥夺了其余人对本身承认的机会。这一点很是很是重要，若是这种状况发生了，程序员在很长一段时间以内都不会有动力工做。

6.环境-噪音，走动，工做环境等等

这些对非程序员来讲可能比较奇怪，但对程序员工做的效率影响却很是大。好比一些白噪音，像空调噪音，汽车卡车行驶的这些声音，反而能够帮助他们更好的集中注意力。这就是为何咱们老是戴着耳机的缘由。顺便推荐最近刚发现的 RainyMood 。

类似的，若是工做空间的设计会有不少人走来走去，这也会让程序员没法专心。或者他们坐的位置很容易被管理者看到等等，这些因素都会让程序员压力增大而没法专心。

7. 范畴蠕动

范畴蠕动（也称为焦点蠕动，需求蠕动，功能蠕动，有时候也称为厨房水槽现象）在项目管理中意思为没法控制的变数。这种状况在项目范畴没有被肯定以前会发生。

范畴蠕动会让简单的请求变成复杂，超级花费时间的怪兽。通常都在开发过程当中发生。好比，一个简单的功能：

版本 1（发布前）：功能是在地图中显示一个定位。

版本 2 （当版本 1 几乎开发完毕时）：功能变为「在 3D 地图上展现一个坐标」。

版本 3 （当版本 2 几乎开发完毕时）：功能又变成「在 3D 地图上展现一个用户能在上空飞过的坐标」。

8.产品定义过程

这一点可能第一眼看上去有点怪，可是其实很是好理解。若是一个产品团队在没有仔细考察功能是否有需求就定义了产品优先级（经过客户反馈或者其余渠道），程序员极可能会开发出不少用不到的功能。这会让他们以为本身作的东西没有利用价值，开发的热情也会大大下降。咱们都想创造更多的影响力，开发人员更是如此。

9.没有考虑技术负债

技术负债是为了更快上线产品而使用非最佳解决方案或编写不是最好的代码。这些决定有时候是不可避免的，由于能够在短时间内提升软件开发的速度。可是，长远来看，这会让系统复杂程度提升，而且会下降开发速度。非程序员老是想尽快推动项目而低估了生产力的浪费，这就成了一个问题。若是代码重构永远排不上优先级，这不只会影响效率，还会影响产品质量。

10. 工具多样性和硬件

开发人员可能会用不少工具来编程，天天都要运行和合并代码不少次。自动化越多越好。这就比如用很是老的没有任何自动化工具来编程确定会拖慢编程效率同样。大显示屏和笔记本等硬件的区别也是如此。所以，在开发人员的软件工具和硬件上投资是确定不会错的！让你的开发团队选择他们喜欢的工具和硬件（为单人买硬件，为整个团队买软件工具）。

11.如何注释

当咱们学习编程的时候，知道要尽早开始为代码写注释，越多注释越好。不幸的是，不少程序员把这概念理解错了，致使他们在每一行代码都有注释，如如下这种常见的代码（摘自杰夫安特乌茨（Jeff Atwood）的「不写注释的代码」）：

r = n / 2; // 赋值 r 给 n 除以 2
// 迭代直到 r – (n/r) 大于 t
while ( abs( r – (n/r) ) > t ) {
  r = 0.5 * ( r + (n/r) ); // 赋值 r 给(r + (n/r))/2
}

你知道这段代码想干吗么？我也不知道。这就是注释太多会带来的问题，虽然有注释，但这并无解释为何要这么写这段代码。若是你在程序调试的时候看到这段代码，对排除报错（debug）并无帮助。

12.不可能实现的项目截止日期

管理者老是要求开发人员预估项目完成时间，而后再推进他们缩短预估时间，并以此为截止日期。不少管理者甚至认为，既然这是开发人员本身估计的时间，他们就应该在这个截止日期以前完成，因此这个截止日期是能够正式向上级汇报的。然而，开发人员会认为这个截止日是没有办法完成的，这就致使了开发人员与管理者之间紧张的关系。

以上这些事情为何只针对程序员？

若是你看完这 12 件事，你会发现，这 12 件事其实在项目管理过程当中常常发生。只是这些事情对程序员的影响更多一些，他们在工做中更须要全神贯注。

若是你在公司里看到了以上所提的 12 件事，不妨和你们探讨一下。沟通后，搞清楚这些问题是否真实存在而且如何解决。无论他们怎么说，关键是在于信任他们的反馈和意见。现今的科技和 30 年前比已经很不同了，但即便如此，人性并无变。你在考虑公司生产效率的同时必需要考虑人的因素。反复推敲你团队的工做流程，工做环境和工做习惯，让你的团队来指引你达到你想要的最高效率。

LeanCloud，领先的 BaaS 提供商，为移动开发提供强有力的后端支持。 了解更多： www.leancloud.cn