1. 降低外界干扰，减少打断

被「打断」是破坏程序员生产力的罪魁祸首。程序员在被打断后一般不能做到立刻重新开始编程。被打断之后继续编程通常程序员需要重新看一遍代码，才能进入到编程的思维环境中，才能想起来被打断之前的思维逻辑，再从被打断的点重新开始。这个过程大概要花 30 分钟以上。「打断」越多，烦心越多，工作质量也会降低，Bug 也会随之增加—成为恶性循环。

如果从我刚开始编程，就这个事那个事不断打断我，那次数越多，我重新进入状态耗时越长。如果你一直打断我，就别怪我一天没写出来啥东西。

所以降低外界干扰，减少打断能够显著提高程序员生产力。

2. 减少没必要的会议

「会议」和「打断」的唯一区别在于会议是计划好的打断。程序员无法在被打断的时候还能专心做其他任务。比如你跟程序员开 1-2 小时的会议，基本上不会有什么进展，因为一般技术性的任务 1-2 小时以内是无法完成的。一个下午如果被分成两个小会议是最糟糕的情况，因为这两个会议都太短了，什么都做不了。

那么，如何避免呢：工作会议可以安排在一天开始的时候或者午饭前，并尽量简短，避免不必要的「打断」。

3. 在管理上放开，程序员知道如何完成目标

有些公司会让你些不懂编程的人来“管理”程序员的日常工作，在旁边指手画脚。而一个好程序员只要知道目标需求是什么，他会知道如何安排工作，如何达成目标。

4. 明确编程要求，有详细需求文档

如果某项功能要求很模糊，在这个情况下，开发人员只能靠自己的感觉来编程。最好是能够把某项功能的要求细节化，再递交给开发人员。

5. 降低环境噪音，走动等

这些对非程序员来说可能比较奇怪，但对程序员工作的效率影响却非常大。比如一些白噪音，像空调噪音，汽车卡车行驶的这些声音，反而可以帮助他们更好的集中注意力。这就是为什么程序员总是戴着耳机。同样，如果工作空间的设计会有很多人走来走去，这也会让程序员无法专心。或者他们坐的位置很容易被管理者看到等等，这些因素都会让程序员压力增大而无法专心。

6. 降低需求变数

比如，一个简单的功能：

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

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

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

这种需求上的变数，和需求安排的不合理，会极大降低程序员工作效率。

7. 做有意义的产品

如果一个产品团队在没有仔细考察功能是否有需求就定义了产品优先级（通过客户反馈或者其他渠道），程序员很可能会开发出很多用不到的功能。这会让他们觉得自己做的东西没有利用价值，开发的热情也会大大降低。所以我们要明确产品定义，做有意义的产品。

8. 没有考虑技术负债

技术负债是为了更快上线产品而使用非最佳解决方案或编写不是最好的代码。这些决定有时候是不可避免的，因为可以在短期内提高软件开发的速度。但是，长远来看，这会让系统复杂程度提高，并且会降低开发速度。

非程序员总是想尽快推进项目而低估了生产力的浪费，这就成了一个问题。如果代码重构永远排不上优先级，这不仅会影响效率，还会影响产品质量。

9. 好用的工具，高性能硬件

SSD！大显示屏！高性能电脑！好用的软件！

在开发人员的软件工具和硬件上投资是肯定不会错的！让你的开发团队选择他们喜欢的工具和硬件（为单人买硬件，为整个团队买软件工具）。

10. 代码注释规范

规范的注释可以避免很多不必要的麻烦，有些人只有被坑到的时候才感觉出规范注释的重要性。

11. 合理的任务排期

项目排期很重要，需要给出合理的排期，如果你给一个完全无法完成的排期，那程序员可能就不做了，这会影响员工和谐。