定义和度量程序员的工作效率是软件行业的一大难题。它是巨额投资的基础，是众多初创公司的价值主张，也是工程经理或CTO工作描述中最困难的部分之一。这也是所有经验级别的开发人员焦虑的来源:你如何知道你做得够不够，无论是在工作时间还是下班时间?当你所做的一切都是无形的，你该如何衡量它?它能被测量吗?在本文中，我将讨论生产率度量的最大陷阱和一些做好它的方法。

在软件开发中，就像在其他任何领域一样，许多人从输入和输出的角度来考虑生产力。在美国，全职开发者每周工作40个小时，平均年薪为107,510美元。工时和工资是可见的，容易量化的输入。然后，开发人员反复生成软件特性、文档、部署和/或bug修复。这些都是输出。如果开发人员和我们想象的他们正在编写的软件一样简单，那么提高他们的生产力就应该像要求他们工作更长时间或支付更高的薪水一样简单。当然，这只是一个童话故事。开发人员和软件都不是这样工作的。

输入衡量的问题

“工作时间”是用来衡量工作表现的几个错误指标之一。我首先提到它，是因为它是一种经常未经检查的违约，是一种阻力最小的路径。如果一家公司不是有意避免这样做，它迟早会恶化为一个小时的环境。在远程工作是常态的流行病之外，只工作一小时的环境的症状很容易识别。工作时间是没有商量余地的，出现在办公室被认为是有人在工作的证明。任何试图提前几个小时离开办公室的人都会遭遇敌意(有时是无声的，就像一些人扬起眉毛一样，有时是更肆无忌惮的)。任何工作到晚上很晚或周末上班的人都被视为高绩效员工。这种“最后离开健身房的人”文化的动机是不幸的:开发人员被迫在工作上花费越来越多的时间，没有任何其他方式来展示他们的价值，并被骗到只把次要注意力放在他们的工作产出上。随着时间的推移，工作场所变得越来越像一个人人都在工作却什么都没做的地方。

问题还不止于此。如果我们认为所有的工作都是“积极的工作”——也就是说，所有的工作都代表着朝着一个目标前进的过程——那么我们就错了。在筋疲力尽、心烦意乱或生病的情况下工作的开发人员往往熟悉“消极工作”的概念:工作做得很差，必须在以后完成或补偿，从而增加而不是减少剩余的工作量。软件开发是复杂、抽象、专注的工作，因此对开发人员的精神状态非常敏感。也就是说，有一些隐藏的因素在起作用:焦虑、抑郁、倦怠、工作中的毒性、悲伤、微侵犯，以及其他100种可能在任何一天降低或扭转个人生产力的因素。如果公司文化要求一周又一周的长时间工作，或者甚至只是每天工作8小时，没有弹性或假期，开发人员就会不可避免地花时间做一些消极的工作:他们加班完成的工作比他们早下班完成的工作要少。而且由于疲劳，他们第二天完成的工作也会更少。

另一方面，一个小时的环境并不是最坏的情况。它有一个关于公平的幽灵:如果两个开发者的工作时间相同，他们在一个维度上是相等的。双方似乎都没有懈怠，似乎都没有超出自己的份额。如果他们的产出低于预期，那么至少他们投入了时间。而“工作时间”指标并不能像某些指标那样明确地刺激糟糕的代码。所以，尽管这是一个糟糕的度量标准，在许多情况下甚至会影响生产率，但我们应该讨论更糟糕的度量标准。

考虑软件开发的另一个明显的投入:金钱。我曾经向我的经理开玩笑地建议过一两次，生产力应该用薪水来衡量，如果我的薪水翻倍，我的代码就会达到世界级的软件架构师的水平。当然，你直觉上知道这是荒谬的。给某人更多的钱并不能立即让他们更有效率(尽管在有限的范围内，这可能是间接的)。然而，在我看来，金钱和时间属于同一类别:不仅是投入，还是辅助的投入，只是微不足道地推动着生产力。一种是雇主提供的，另一种是雇员提供的，但这种交换是创造有用软件的附带条件。

长话短说，测量输入是一种有缺陷的技术，因为软件开发不是一个等式，代码不能通过装配线构建。我们来谈谈输出。

输出衡量的陷阱

在这里，也许与直觉相反，我们发现了软件开发世界中许多最糟糕的度量标准。有些人陷入了一个著名的陷阱，认为软件开发的工作输出是代码行或版本控制中的提交。当然，这些都是过程的一部分，但它们更像是副产品而不是结果。严格地说，一行代码不能解决问题比没有代码更糟糕。因此，用开发者贡献多少代码来衡量他们的生产力，就像用发电厂产生多少垃圾来衡量它，或者用国会通过多少法案来衡量它一样;它与实际价值相去甚远。

更糟糕的是，玩弄这些测量方法非常简单。一个开发人员只要一行代码就能赚到一整年的薪水，而不需要创造任何业务价值。大多数开发人员将采用一种更微妙的方法，但不管怎样，您应该小心自己的愿望。

当一个措施成为一个目标，它就不再是一个好的措施--古德哈特定律。

总的来说，开发人员理解这一点——然而，令人尴尬的是，我们仍然倾向于使用提交和代码行作为众所周知的工作量的衡量标准。当我们读到谷歌(指截至2015年的所有谷歌品牌产品)超过20亿行代码，或者Windows团队每天完成超过8400个代码推送时，我们的眼睛都睁大了，尽管我们知道谷歌和Windows的用处都不是这些。有时社区甚至会产生这样的废话:

是什么阻止了你编写这样的代码?pic.twitter.com/ZBi5NIISUn

(顺便说一句，我要祝贺那些为养成每天编程的习惯做出贡献的人，也祝贺他时不时地休息一天。在我看来，这都是积极的迹象。不过，如果不深入了解这个人的贡献历史，我不会说他是一个富有成效的人。)

在任何情况下，我们都可以将这些度量添加到无效代理列表中。根据修正的漏洞、完成的任务或发布的功能来衡量生产率同样是徒劳的。如果目标是修复更多的错误，开发人员可以故意编写有错误的软件，然后编写大量的修复程序;或者，为了达到相反的目标，他们可以通过尽可能慢地编写特性来减少bug数量。如果目标是发布特性，他们可以快速而天真地编写，导致软件运行缓慢且几乎无法运行;如果目标是完成任务，那么整个团队就会陷入政治之中，因为每个开发人员都在为最容易(或最高估)的任务而奋斗。一个优秀的团队可能会忽略您的度量方法并继续工作，但即使在最好的情况下，一个糟糕的度量方法也是一个难以忽视的障碍。

有些组织，表现出极度的偏执，在员工的电脑上安装监控软件来追踪他们每时每刻的工作细节，比如鼠标移动、按键和屏幕截图。我不清楚员工在这种审查下怎么能做有创意的工作。我认为大多数开发者会立即退出。但是与上面讨论的度量方法一样，这个方法最明显的失败是它没有捕获任何对业务或其客户真正有意义的东西。你会因为一个高效的开发人员在Reddit上花了很多时间或者没有足够的移动鼠标而惩罚他吗?你会因为一个开发人员花了很多时间在Visual Studio中打字而提拔他吗?有些经理显然知道，但希望我们大多数人都能聪明些。

测量工作量的正确方式

现在，你已经被警告不要使用你可能会被诱惑使用的最糟糕的方法，让我们来谈谈一些好的方法。不幸的是，除了“这个团队成员贡献了什么”或“这个团队成员没有贡献”这样的二进制状态之外，个人的性能很少能被度量。“它不能从远处测量。

软件开发团队不是一组独立工作的个体;每个团队成员的工作输出是他们所有团队成员的工作输出的函数，更不用说一天中几个有意义的不可测量的交互作用了。个体工作的相互依赖性和细微差别太过复杂，无法由外部观察者来衡量。例如，一些团队成员是团队其他成员的力量倍增器——他们可能无法独自完成很多事情，但如果没有他们的帮助和影响，他们的团队成员的效率会显著降低。像这样的人是有效工程组织的秘密武器，但是他们的生产力不能以个人的规模来衡量。其他的团队成员可能不会产生很多特性，但是会扮演“代码看门人”的角色，无论他们走到哪里，都要仔细地测试、清理和重构代码，这样他们的团队成员就可以更快、更轻松地开发特性。他们作为个人的生产力也是不可能测量的，但是他们对团队生产力的影响是指数级的。即使是定期发布新特性的程序员，工作效率也会在短期内发生很大的变化，从而使追踪新特性的工作变得困难。由于这样的原因，个人表现最好留给个人贡献者来衡量自己和彼此。

另一方面，团队表现则要明显得多。也许最好的跟踪方法是问，这个团队是否始终如一地在几周到几个月的时间范围内生产出有用的软件?这呼应了敏捷的第三条原则:“频繁地交付可工作的软件，从几周到几个月，优先于较短的时间范围。”“一个定期生产有用软件的团队是富有生产力的。如果团队不这么做，就应该问为什么。缺乏生产力通常有正当的理由;大多数没有生产力的团队想要提高生产力，而大多数有生产力的团队想要提高生产力。

团队生产力可以通过简单、全面的观察在组织范围内进行测量。由于团队成员往往很清楚彼此的贡献(无论是可衡量的还是不可衡量的)，个人生产力的任何严重缺陷都可以通过良好的组织习惯来发现，例如管理者和他们的直接下属之间经常进行一对一的面谈;定期收集诚实的、匿名的反馈;并鼓励每个团队成员通过报告他们的成就和对他们的失败负责来履行个人责任。

这里的很多东西都取决于人，而不是趋势图和原始数据。这是软件不可避免的事实:它更多的是关于人类，而不是1和0，而且一直都是这样。生产力追踪工具和激励计划永远不会像工作场所的积极文化那样产生巨大的影响。当问责制和健康的沟通融入到这种文化中时，效率的关键时刻很快就会被最有能力解决这些问题的人看到。

许多组织使用速度作为团队生产力的首选度量标准，如果做得好，这可以成为理解软件开发过程的有用工具。速度是团队在一段时间内完成的任务的总和度量，通常考虑到开发人员自己对每个任务的相对复杂性的估计。它回答了这样的问题:“这个团队在未来两周能做多少工作?”最基本的答案是“差不多和他们在过去两周做的一样多”，而速度是这句话的背景。它是一种计划度量，而不是追溯度量，任何试图给它附加激励的人都会发现它的准确性在压力下消失了(有关这方面的更多信息，参见Ron Jeffries的《软件开发的本质》)。了解一个团队、部门或公司的发展速度，对于您确定功能开发的优先级、与客户设定期望以及规划产品的未来都是基础性的。

没有比“任务乘以复杂性”更有效的度量方法了。“像一些工具那样，度量提交、代码行数或编码时间，在团队规模上并不比在个人规模上更有用。一个团队产生的代码工件的数量，或者他们在这些代码工件上花费的时间，以及他们贡献的价值之间根本没有关系。

许多组织在没有任何硬性的度量标准的情况下也能蓬勃发展。在组织中，有用的软件被很好地理解为开发工作的目标和主要(尽管难以量化)测量的结果，并且相应地优先考虑开发工作和输入，这有深刻而深远的影响。无论何时何地，开发人员都可以自由地做他们最好的工作。这可能看起来像朝九晚五，也可能不像。有些人会出于偏好或需要，在清晨和深夜完成大部分工作。其他人则会以不同的时间段工作:在这里工作一个小时，在那里再工作几个小时。有些人在家工作，有些人在办公室工作，还有一些人在路上工作。这是一个特性，而不是一个bug。它强调的是真正的生产力，而不是试图把它硬塞进一种可观察的启发式，它让工作场所变得可行，可以容纳更深层的人才库，例如，包括在职父母和残疾人。关于只注重结果的工作环境(ROWE)、远程工作、减少花在会议上的时间和灵活的工作时间的好处，已经有很多人写过和说过;这些都是精明的生产力衡量标准的体现。

有人说你得到你所测量的东西。因此，你应该只测量你真正想要的东西——不管它是否可以用折线图画出来。对一些人来说，做或管理不能简化为数字的工作可能会令人沮丧。但是随着工作像软件开发一样微妙和抽象，我们在细节上越深地巩固自己，我们就越挫败我们自己的目标。有用的软件是我们的目标，我们不应该满足于(或度量)任何不足的东西