影响开发者生产力的因素有哪些？

作者 | Jeremy Mikkola       译者 | 弯月

责编 | 夏萌

出品 | CSDN（ID：CSDNnews）

影响开发人员生产力的因素有很多，有些非常明显，而且测量也很方便（比如构建时间）。但我认为我们往往会忽略一些重要的因素，也许是因为这些因素很难直接测量。举个例子，没有任何系统会收集一个数字来显示每位开发人员对他们所使用的系统的理解程度。直接测量开发人员的头脑内部状况是不可能的。而直接测量输出（他们的生产力），也无法通过数据了解你缺少什么（比如文档）。

对于下文提到的一些因素，你可能很难找到明确的衡量标准，但我们应该确保这些领域内不会出现影响生产力的问题。虽然有些因素之间互相有重叠，但由于出发点不同，因此应该分开考虑。

知道要做什么

如果构建的是错误的功能，那么即便速度再快，也是无用功。重点在于了解客户需要什么，其他团队会接受什么（数据库表可以有多少个索引？某个功能会共享我们无法合法共享的信息吗？）以及之前尝试过哪些方法被证明无效。

有时，在构建时你就会意识到错误，但你还是会为了积累经验而构建下去。你可以通过原型了解为什么某种方法行不通，或者通过最小化可行产品了解客户的实际需求。尽管如此，你仍然需要了解哪些想法值得尝试。

越少越好

能够快速完成任务固然好，但不战而胜则更好。公司的流程可能会平白增加一些无用功，如果没有这些繁琐的流程，你的工作效率会更高。有时，只需要调整流程就能找到更简单的方法，减少工作量，同时还能提供相同的价值。

此外，为了确保公司正常运营，我们需要付出一定的努力。这种工作需要不间断地完成（例如回复票据），但无助于推动项目向前发展。虽然从许多指标来看，这项工作十分高效（票务关闭、提交合并），但无益于公司的发展。

快速的工具

开发人员需要使用很多工具，通过编辑器高亮显示代码并自动补齐方法名称，通过 git 提交代码，通过构建系统运行测试。鉴于这些工具的运行频率之高，它们多占据一秒，就有可能导致成本上升。除了浪费大量时间之外，工具的速度过慢还会导致开发人员的注意力分散。由于工具缓慢而导致工作陷入停滞十分打击士气，特别是对于那些背负着沉重的时间压力的人来说。

开发人员拥有的知识

这是一个很难测量的因素！

在其他条件相同的情况下，开发人员拥有的相关知识越多，生产力就越高。他们无需深入挖掘代码，因为他们知道代码的基本运作机制。他们知道如何使用工具以及避免哪些陷阱。他们可以提出正确的问题。10倍速的开发人员真的存在，他们是真正了解代码库的人。

这意味着，团队拥有的产品数量不应超出集体的头脑容量总和。这也意味着，我们应该最大限度地减少所有权易手的频率，毕竟这个世界上没有人比创建者更了解产品本身。理想情况下，刚接触某个系统的人应该与已熟悉该系统的人一起工作并向他们学习。

另外，系统之间需要建立明确的界限。具有简单语义、整洁的接口意味着，你只需思考该接口的属性，而不必了解其背后的整个系统。

文档是传播知识的好方法。当开发人员需要完成他们不熟悉的特定任务时，尤其需要文档的帮助。缺乏文档可能会导致开发人员的速度下降，因为他们必须研究如何完成任务，他们会犯错误并重做某些工作，而且他们还需要等待其他团队答疑。如此下来，一小时的任务很容易就会拖延到两天。如果 100 名开发人员都需要完成这项任务，那么缺少一页文档的成本大致相当于一名开发人员的年薪。

这也证明我们需要加强专业化。要求每位开发人员承担广泛的工作实际上很低效。花费一个小时学习某些安全系统或容量规划流程的细节，那么相应的花费在了解自己的系统或需要解决的问题领域的时间就会减少。

基础设施

基础设施应该辅助开发人员的工作，而不应该成为一种障碍。这意味着，基础设施必须与开发人员的工作紧密结合。每个基础设施在设计时都会考虑一些用例，但实际项目的需求可能并不属于这些用例。“你必须使用我们的基础设施”、“没有我们的基础设施，你就无法实现”，听到这类的话会让人很沮丧。结果是，你必须浪费时间处理基础设施，或者在会议上说服基础设施的所有者满足你的需求。

减少技术债务

现有的代码永远无法完美地满足你的需要，原作者无法通过水晶球来预知你需要什么样的改变。但有些代码的修改难度会远低于其他代码。在考虑如何完成某个功能时，我希望答案不是“我们必须重构整个系统”。随着技术债务的增加，即便是很小的功能改动也会涉及大范围的系统变动。减少技术负债可以最大限度地减少（a）你需要理解（b）你需要修改的代码库规模。

我们需要偿还技术债务。中途放弃或降低这些工作的优先级可能会导致系统每况愈下。

降低故障率

如果工具无法运行、构建失败、部署失败，或者代码变更导致生产错误，则必须花费时间来处理这些故障。降低这些故障的概率可以提高生产力。

除了遭遇故障的工程师外，出现问题的系统的负责团队也需要花费大量时间来诊断和修复故障。

切合实际的生产实践

学习如何解决特定问题的最佳方法是编写原型。如果环境不允许设计原型，那么就有可能阻碍开发人员发现最有效的方法。如果监控工具使用起来很痛苦，那么开发人员就不会制作太多的仪表板，测量的指标也会减少，因此决策将很难由数据驱动。另一方面，如果可以将一次大变更拆分为多个较小的代码审查，就可以降低代码审查的难度，并提高部署的安全性。

集中注意力

工程师需要按照制造商的时间计划推进工作。他们需要集中注意力。但他们的注意力可能会被会议和干扰打断，其中包括缓慢的 CLI 命令、缓慢的测试以及遇到不知道如何完成但需要研究的任务。

有太多需要操心的事情会导致工程师无法集中注意力。迫在眉睫的最后期限或经理提出的需要回答的问题会占据你的大脑，导致你无法专注于其他工作。

完成任务

完成 50% 的构建并不意味着生产力为 50%，也许是 0%。推翻一切从头再来，何来效率？

在某些情况下，中途放弃项目是正确的选择。与沉没成本谬论作斗争有时是正确的做法。但在项目完成之前，我们不应该随意改变优先级。这可能会导致团队的生产力降至零。

总结

你不一定需要构建一个仪表板来测量上述因素，但我认为任何开发人员都可以告诉你其中哪些因素正在影响他们的生产力。解决这些问题可以大大增加完成的工作量。有些问题可能非常容易解决，有时花几个小时编写一页文档就有可能为公司节省数千个小时。工欲善其事必先利其器。