衡量开发者生产力

几乎从我开始致力于改善软件工程师生活的那天起，就不断有人问我如何衡量开发者的生产力。我们如何识别生产力问题？如何判断团队的表现是变好还是变差？经理如何向高级管理层解释开发者的生产力水平？诸如此类的问题层出不穷。

总的来说，我倾向于首先关注代码简洁性，而对衡量开发者的每一个具体行为赋予较低的优先级。几乎所有的软件问题都可以追溯到未能应用软件工程原则和实践的某种失败。因此，即使没有测量，如果你只是让良好的软件工程实践在整个公司得到应用，大多数生产力问题和开发问题就会消失。

话虽如此，衡量事物具有巨大的价值。它帮助你精确定位困难领域，允许你奖励那些生产力提高的人，在有需要时证明在开发者生产力工作上投入更多时间是合理的，并具有许多其他优势。

但编程不同于其他职业。你不能像衡量某些制造过程那样来衡量它，在制造过程中你可以只计算从装配线上滚下的合格物品数量。

那么，你将如何衡量程序员的产出呢？

“生产力”的定义

秘诀在于恰当地定义“生产力”这个词。许多人说他们想“衡量生产力”，但从未思考过生产力实际上是什么。如果你甚至没有定义某物，又如何衡量它呢？

理解生产力是什么的关键在于认识到它与产品有关。一个高效的人是定期且高效地生产产品的人。衡量开发者生产力的方法是衡量他们生产的产品。

然而，仅凭这一陈述可能不足以解决问题。因此，让我给你举一些你不会衡量的事情的例子，然后再举一些你会衡量的事情的例子，以给你一个总体的概念。

为什么不使用“代码行数”？

软件行业试图制定的最常见的指标可能都围绕着开发者编写了多少行代码（缩写为 LoC）。我理解人们为什么尝试这样做——这似乎是你可以衡量的东西，那么为什么不跟踪它呢？编写更多代码的程序员生产力更高，对吧？

嗯，不是的。这里的部分诀窍是：“计算机程序员”实际上并不是一个职位。

等等，什么？但我到处都看到“程序员”作为职位的招聘广告！嗯，是的，但你也到处看到“木匠”的广告。但是“木匠”生产什么？除非你更具体，否则很难说。你可能会说木匠制作“切割好的木块”，但那不是产品——没有人会雇你无意义地切割或塑造木块。那么，“木匠”可以做什么工作呢？嗯，工作可能是家具维修、建造房屋或制作桌子。在每种情况下，木匠的产品都不同。如果他是一名家具修理工（一个有效的职位），那么你会衡量他修好了多少家具。如果他在建造房屋，你可能会衡量他完成了多少个没有任何木工缺陷的房间。

这里的重点是，“计算机程序员”就像“木匠”一样，是一种技能，而不是一个职位。如果你想知道一个人生产了多少，你不会衡量技能的实践。你衡量该技能所生产产品的某些方面。为了把这个观点推到荒谬的程度——只是为了说明问题——如今计算机编程技能的一部分涉及在键盘上打字，但你会通过程序员每天在键盘上敲击了多少个键来衡量他们的生产力吗？显然不会。

衡量代码行数比衡量键盘敲击次数不那么荒谬，因为它确实似乎是程序员生产的东西之一——一行代码似乎像是一个可以交付的成品，即使它很小。但它本身真的是一种产品吗？如果我估计一项工作需要 1000 行代码，并且我打算为此收取 1000 美元，那么如果我只交付了一行代码，我的客户会付给我 1 美元吗？不，我的客户不会付给我任何钱，因为我根本没有交付任何产品。

那么，你将如何在现实世界中应用这一原则来正确衡量程序员的产出呢？

确定有效的指标

首先要弄清楚的是：程序产生的对其用户有价值的东西是什么？通常可以通过快速审视软件的目的来回答这个问题——确定你正在帮助哪类人群用你的软件做什么，并找出如何将这种帮助的结果描述为产品。例如，如果你有一个帮助个人报税的会计软件，你可能会衡量使用你软件的个人完全且正确提交的纳税申报表总数。是的，其他人（如销售人员）也对此有贡献，但程序员对实际工作完成的难易程度和成功程度负主要责任。人们可能希望选择那些紧密聚焦于只有程序员能控制的事情的指标，但不要在这方面过度——程序员不必是唯一可能影响指标的人，该指标才能成为对他们个人产出的有效衡量。

一个系统也可能有多个方面需要衡量。假设你正在开发一个购物网站。该网站的后端开发人员可能会衡量成功处理的数据请求数量之类的东西，而网站购物车的前端开发人员可能会衡量成功放入购物车的商品数量、每天成功完成结账流程的人数等等。

当然，人们还会确保任何提议的指标也与整个系统的整体指标保持一致。例如，如果后端开发人员只衡量“在后端接收到的数据请求数量”，而不关心它们是否被正确填充、填充速度如何等等，他们可能会设计一个需要过多调用的糟糕 API，这实际上会损害整体用户体验。因此，你必须确保你正在查看的任何指标，都要与帮助实际用户的实际情况进行比较。在这种特定情况下，更好的解决方案可能是计算，比如说，有多少“提交付款”请求被正确处理，因为那是最终结果。（顺便说一句，我不会将其视为购物网站后端的唯一可能指标——那只是一个可能的想法。）

当你的产品是代码时怎么办？

有些人交付代码作为他们的产品。例如，库开发者的产品就是代码。但它很少是单行代码——更像是整个函数、类或一组类。对于库开发者，你可能会衡量诸如“发布的、供程序员使用的、经过全面测试的公共 API 函数的数量”之类的东西。在这种情况下，你可能还需要做一些事情来计算现有函数的新特性，比如将每个改进其 API 的函数的新特性算作一个全新的已交付“函数”。当然，由于原始指标说的是“全面测试”，任何新特性也必须经过全面测试才能计入。但无论你选择如何衡量，这里的重点是，即使是对于那些产品是代码的少数人，你也是在衡量产品。

那些从事开发者生产力工作的人怎么办？

这确实留下了最后一类人，即那些致力于提高开发者生产力的人。如果你的工作是帮助其他开发者更快地前进，你如何衡量这一点？

嗯，首先，大多数从事开发者生产力工作的人确实有某种特定的产品。他们要么从事测试框架的工作（你可以用类似于衡量库的方式来衡量），要么从事开发者使用的某些工具的工作，在这种情况下，你会衡量该工具的成功或使用情况。例如，bug 跟踪系统的开发者可能想衡量的一件事是成功且快速解决的 bug 数量。当然，你会根据该工具在公司中的使用情况来修改这一点——也许 bug 跟踪器中的某些条目 intended 存在很长时间，因此你会以其他方式衡量这些条目。总的来说，你会问：我们通过开发这个工具在世界上带来了什么产品或结果？那就是你要衡量的东西。

但如果你不从事某些特定的框架或工具工作呢？在那种情况下，也许你的产品与软件工程师本身有关。也许你会衡量工程师因你的工作而获得帮助的次数。或者，如果你能可靠地衡量的话（这很少可能），你的更改所节省的工程时间量。但总的来说，这类工作可能比其他类型的编程工作更难衡量。

我过去曾提出过一件事（尽管尚未实际尝试），即，如果你有一个帮助特定团队提高生产力的人，衡量这些团队随时间推移所经历的生产力改进。或者也许衡量团队指标改善的速度。

例如，假设我们纯粹根据产品带来多少收入来衡量一个产品。（注意：纯粹用这个指标来衡量产品是很罕见的——这是一个为了演示这一切如何运作的人为例子。）假设第一周产品带来了 100 美元。下周 101 美元，再下周 102 美元。这是增长，所以不算太糟，但也不那么令人兴奋。然后玛丽来了，帮助团队提高生产力。那一周产品赚了 150 美元，然后是 200 美元，接着是 350 美元，因为玛丽继续致力于此。它从每周增加 1 美元变为每周增加 50 美元，然后 100 美元，然后 150 美元。这对玛丽来说似乎是一个有效的衡量标准。当然，可能还有其他因素促成该指标的改善，所以它并不完美，但如果你真的有一个“纯粹”的生产力开发者，这总比没有好。

结论

关于如何衡量员工、团队和公司整体的产出，还有很多其他需要了解的地方。以上观点仅旨在讨论如何针对程序员找出你应该衡量的一般性事物。关于进行测量的正确方法、如何解释这些测量结果以及如何选择不糟糕的指标，还有更多需要了解的知识。但希望以上内容能让你开始解决如何衡量个体程序员、团队乃至整个软件组织产出的巨大谜团。

-马克斯