衡量开发者生产力

几乎从我开始致力于改善软件工程师生活的那天起，就不断有人问我如何衡量开发者生产力。我们如何识别生产力问题？如何判断团队随时间推移是进步还是退步？管理者如何向高层解释开发人员的工作效率？诸如此类的问题层出不穷。

总体而言，我倾向于首先关注代码简洁性，而对衡量开发者的每个具体行为赋予较低优先级。几乎所有的软件问题都可追溯至未能遵循软件工程原则和实践。因此，即使没有度量，只要在公司范围内推行良好的软件工程实践，大多数生产力问题和开发难题都会迎刃而解。

尽管如此，度量本身具有巨大价值。它能帮助你精准定位困难领域，奖励生产力提升者，在必要时为生产力工作争取更多时间，并带来诸多其他好处。

但编程不同于其他职业。你不能像衡量制造业流程那样，简单计算流水线上合格产品的数量。

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

“生产力”的定义

关键在于恰当定义“生产力”一词。许多人声称要“衡量生产力”，却从未思考过生产力的实质。如果连定义都没有，又如何进行衡量？

理解生产力的关键是认识到它与产品（product）相关。一个高效的人就是能够持续且高效地生产产品的人。衡量开发者生产力的方法就是衡量他们生产的产品。

不过，仅此一句话可能不足以解决问题。因此，我将先举例说明哪些不应衡量，再介绍哪些应该衡量，以帮助你建立基本概念。

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

软件行业尝试制定的最常见指标莫过于开发者编写的代码行数（LoC）。我理解人们为何尝试这样做——这似乎是可衡量的东西，为何不跟踪呢？编写更多代码的程序员效率更高，对吧？

其实不然。这里的诀窍在于：“计算机程序员”本身并非一个具体职位。

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

这里的重点是，“计算机程序员”如同“木匠”，是一种技能，而非职位。如果你想了解一个人的产出量，不应衡量技能本身，而应衡量该技能所产出的产品。为了更形象地说明这一点——如今计算机编程技能的一部分涉及键盘打字，但你会通过程序员每天敲击多少键来衡量其生产力吗？显然不会。

衡量代码行数比衡量键盘敲击数稍好，因为它看起来像是程序员产出的东西——一行代码似乎是一个可交付的成品，即使很小。但它本身真的是产品吗？如果我估计一项工作需要1000行代码，并打算收费1000美元，而我只交付了一行代码，客户会付我1美元吗？不，客户一分钱都不会付，因为我根本没有交付任何产品。

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

确定有效指标

首先要弄清楚：程序为用户创造的价值是什么？通常通过快速审视软件目的来回答——确定你帮助哪类人群通过软件做什么，并思考如何将这种帮助的结果描述为产品。例如，如果你有一款帮助个人报税的会计软件，你可能会衡量使用你软件完全且正确提交的纳税申报表总数。当然，其他人（如销售人员）也对此有贡献，但程序员对实际工作的便捷性和成功率负主要责任。有人可能想选择只由程序员控制的指标，但不要过度——一个指标不必只有程序员能影响才算是其个人产出的有效衡量。

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

当然，还需确保任何提议的指标与整个系统的总体指标一致。例如，如果后端开发者只衡量“后端接收的数据请求数”，而不关心是否正确处理、处理速度等，他们可能设计出需要过多调用的劣质API，从而损害整体用户体验。因此，你必须确保所关注的任何指标都与帮助真实用户的实际情况相比较。在这种特定情况下，更好的解决方案可能是计算正确处理的“提交支付”请求数，因为这是最终结果。（顺便说一句，我不会将其作为购物网站后端的唯一可能指标——这只是一个思路。）

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

有些人交付代码作为产品。例如，库开发者的产品就是代码。但这很少是单行代码——更像是整个函数、类或类集。对于库开发者，你可能会衡量“为程序员发布的全测试公共API函数数量”。在这种情况下，可能还需要计算现有函数的新功能，例如将每个改进API的函数新功能视为一个全新的已交付“函数”。当然，由于原始指标要求“全测试”，任何新功能也必须经过全面测试才能计入。但无论你如何衡量，重点在于即使对于少数以代码为产品的人，你也是在衡量产品。

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

这还剩下最后一类人，即致力于提升开发者生产力的人。如果你的工作是帮助其他开发者更快地工作，如何衡量？

首先，大多数从事开发者生产力工作的人都有具体产品。他们要么开发测试框架（可类似库的方式衡量），要么开发开发者使用的工具，此时你会衡量该工具的成功或使用情况。例如，缺陷跟踪系统的开发者可能想衡量成功快速解决的缺陷数量。当然，你需要根据工具在公司中的使用情况调整——也许缺陷跟踪器中的某些条目需要长期存在，你会用其他方式衡量这些条目。总的来说，你会问：我们开发这个工具为世界带来了什么产品或结果？那就是你要衡量的。

但如果你不开发特定框架或工具呢？这种情况下，你的产品可能与软件工程师本身有关。你可能会衡量工程师受你工作帮助的次数。或者如果你的变更节省了工程时间，且能可靠衡量（这很少可能），则衡量节省的时间量。但总体而言，这类工作比其他编程类型更难衡量。

我过去曾提议（但尚未尝试）的是，如果有人帮助特定团队提升生产力，衡量这些团队随时间经历的生产力改进。或者衡量团队指标改善的速度。

结论

关于如何衡量员工、团队和公司的产出，还有很多其他知识。以上观点仅旨在讨论如何针对程序员确定应衡量的一般内容。关于正确进行度量、解读度量结果以及选择不糟糕的指标，还有更多需要了解。但希望上述内容能帮助你开始解决如何衡量个体程序员、团队及整个软件组织产出的重大谜题。

-Max