衡量开发者生产力
作者：Max Kanat-Alexander
发布日期：2017年1月3日
自从我开始致力于改善软件工程师的生活以来，人们就一直问我如何衡量开发者的生产力。我们如何识别生产力问题？如何判断团队的表现是变好还是变差？管理者如何向高层解释开发者的生产力水平？诸如此类的问题层出不穷。
总的来说，我倾向于首先关注代码简洁性，而对衡量开发者每个具体行为的优先级较低。几乎所有的软件问题都可以追溯到未能应用软件工程原则和实践。因此，即使没有度量，只要在整个公司推行良好的软件工程实践，大多数生产力问题和开发难题都会消失。
尽管如此，度量事物仍有巨大价值。它帮助你精确定位困难领域，让你能够奖励那些生产力提高的人，为在必要时花更多时间处理开发者生产力工作提供理由，并具有许多其他优势。
但编程不同于其他职业。你不能像衡量制造过程那样衡量它——在制造过程中，你只需计算装配线上合格产品的数量。
那么，如何衡量程序员的产出呢？
“生产力"的定义
关键在于恰当定义"生产力"这个词。许多人说他们想"衡量生产力”，但从未思考过生产力究竟是什么。如果你连定义都没有，如何衡量某物？
理解生产力的关键是认识到它与产品有关。一个高效的人是一个定期且高效地生产产品的人。衡量开发者生产力的方法是衡量他们生产的产品。
仅凭这一陈述可能不足以解决问题。因此，让我给你一些你不会衡量的例子，然后再给你一些你会衡量的例子，以给你一个总体概念。
为什么不使用"代码行数"？
软件行业尝试开发的最常见指标可能集中在开发者编写的代码行数（缩写为LoC）上。我理解人们为什么尝试这样做——这似乎是你可以衡量的东西，那么为什么不跟踪它呢？编写更多代码的程序员生产力更高，对吧？
嗯，不对。这里的部分诀窍是：“计算机程序员"实际上并不是一份工作。
等等，什么？但我到处看到"程序员"作为工作的广告！嗯，是的，但你也到处看到"木匠"的广告。但"木匠"生产什么？除非你更具体，否则很难说。你可能会说木匠制作"切割的木块”，但那不是产品——没有人会雇你无意义地切割或塑造木块。那么"木匠"可以做什么工作呢？嗯，工作可能是家具维修、建造房屋或制作桌子。在每种情况下，木匠的产品都不同。如果他是家具修理工（一份有效的工作），那么你会衡量他修好了多少家具。如果他在建造房屋，你可能会衡量他完成了多少个没有木工缺陷的房间。
这里的重点是，“计算机程序员"就像"木匠"一样，是一种技能，而不是一份工作。如果你想知道一个人生产了多少，你不会衡量技能的实践。你衡量该技能产生的产品的某些方面。为了说明这一点，将其推向荒谬的程度——如今计算机编程技能的一部分涉及在键盘上打字，但你会通过程序员每天敲击键盘的次数来衡量他们的生产力吗？显然不会。
衡量代码行数比衡量键盘敲击次数不那么荒谬，因为它似乎是程序员生产的东西之一——一行代码似乎是一个可以交付的成品，即使它很小。但它本身真的是产品吗？如果我估计一项工作需要1000行代码，并且我要收取1000美元，如果我只交付一行代码，我的客户会付我1美元吗？不，我的客户不会付我任何钱，因为我根本没有交付任何产品。
那么，如何在现实世界中应用这一原则来正确衡量程序员的产出呢？
确定有效指标
首先要弄清楚的是：程序产生什么对其用户有价值？通常通过快速查看软件的目的来回答这个问题——确定你正在帮助哪群人用你的软件做什么，并弄清楚如何将这种帮助的结果描述为产品。例如，如果你有帮助个人报税的会计软件，你可能会衡量使用你软件的个人完全正确提交的纳税申报表总数。是的，其他人也为此做出了贡献（比如销售人员），但程序员主要负责实际工作的轻松和成功完成。人们可能希望选择密切关注只有程序员能控制的事情的指标，但不要过分——程序员不必是唯一可能影响指标的人，以便它成为他们个人产出的有效衡量标准。
一个系统可能有多项需要衡量的内容。假设你正在开发一个购物网站。该网站的后端开发人员可能会衡量成功处理的数据请求数量，而网站购物车的前端开发人员可能会衡量成功放入购物车的商品数量，每天成功完成结账流程的人数等。
当然，人们还会确保任何提议的指标也与整个系统的整体指标一致。例如，如果后端开发人员只衡量"后端接收的数据请求数量”，但不关心它们是否正确处理、处理速度如何或其他什么，他们可能会设计一个需要太多调用的糟糕API，这实际上会损害整体用户体验。因此，你必须确保你正在查看的任何指标，都要与帮助实际用户的现实进行比较。在这种特定情况下，更好的解决方案可能是计算，比如，正确处理了多少"提交支付"请求，因为那是最终结果。（顺便说一句，我不会将其作为购物网站后端的唯一可能指标——那只是一个可能的想法。）
当你的产品是代码时怎么办？
有些人交付代码作为他们的产品。例如，库开发者的产品是代码。但它很少是单行代码——更像是整个函数、类或一组类。对于库开发者，你可能会衡量诸如"为程序员使用发布的完全测试的公共API函数数量"之类的东西。在这种情况下，你可能还需要做一些事情来计算现有函数的新功能，比如将每个改进其API的函数的新功能计算为一个全新的交付"函数"。当然，由于原始指标说"完全测试"，任何新功能也必须完全测试才能计入。但无论你选择如何衡量，这里的重点是，即使对于产品是代码的少数人，你也在衡量产品。
从事开发者生产力工作的人怎么办？
这确实留下了最后一类人，即从事提高开发者生产力工作的人。如果你的工作是帮助其他开发者更快地移动，你如何衡量这一点？
嗯，首先，大多数从事开发者生产力工作的人都有一些特定的产品。要么他们致力于测试框架（你会以类似于衡量库的方式衡量），要么他们致力于开发者使用的某些工具，在这种情况下，你会衡量该工具的成功或使用情况。例如，错误跟踪系统的开发者可能想衡量成功快速解决的错误数量。当然，你会修改这一点以考虑工具在公司中的使用方式——也许错误跟踪器中的某些条目 intended 长期存在，因此你会以其他方式衡量这些条目。总的来说，你会问：通过致力于这个工具，我们在世界上带来了什么产品或结果？那就是你要衡量的。
但如果你不从事某些特定框架或工具的工作呢？在这种情况下，也许你的产品与软件工程师本身有关。也许你会衡量工程师因你的工作而获得帮助的次数。或者你的更改节省的工程时间量，如果你能可靠地衡量的话（这很少可能）。但总的来说，这项工作可能比其他类型的编程更难衡量。
我过去提出过的一件事（虽然尚未实际尝试）是，如果你有一个帮助特定团队提高生产力的人，衡量这些团队随时间经历的生产力改进。或者也许衡量团队指标改进的速度。
例如，假设我们纯粹根据产品带来多少收入来衡量一个产品。（注意：纯粹通过这个指标来衡量产品是罕见的——这是一个人工示例，用于演示这一切如何运作。）假设第一周产品带来了100美元。下周101美元，再下周102美元。这是一个增长，所以还不错，但并不令人兴奋。然后玛丽来帮助团队提高生产力。那一周产品赚了150美元，然后200美元，然后350美元，玛丽继续致力于此。它从每周增加1美元变为每周增加50美元，然后100美元，然后150美元。这对玛丽来说似乎是一个有效的衡量标准。当然，可能还有其他因素有助于该指标的改进，所以它并不完美，但如果你真的有一个"纯粹"的生产力开发者，它总比没有好。
结论
关于如何衡量员工、团队和公司的产出，还有很多其他需要了解的内容。上述观点仅旨在讨论如何对待程序员并找出你应该衡量的一般事物。关于正确进行测量的方法、如何解释这些测量以及如何选择不糟糕的指标，还有更多需要了解的内容。但希望上述内容能让你开始解决如何衡量个体程序员、团队和整个软件组织的产出的巨大谜团。
-Max
评论
Shailesh 说：2017年1月5日晚上10:20
这是一篇不错的博客，作为软件开发人员，我可以跟踪自己的日常发展，以变得更有生产力。感谢撰写。
divp 说：2017年3月22日凌晨1:11
很棒的博客……我会定义更多方式：给定一段程序员理解的编程语言中的未知代码和一个错误报告，他们能多快理解错误来源并修复它。一个人能多快调试问题以及程序员能否以专注的方式完成任务，通过这些我们可以判断开发者生产力……虽然是一篇好文章，感谢分享。
Kyle 说：2017年6月3日上午11:16
好文章！你在文章中回避了一个关键点，即生产力只有在最终结果产生价值时才重要。换句话说，如果构建的东西没有用并且没有为目标受众提供价值，那么某人的生产力如何并不重要。我创建了https://www.codemonkey.ai 来通过连接整个软件开发工具链并基于他们通过提交（源代码控制）完成的工作项（问题跟踪系统中的功能和错误）以及这些更改对用户的影响（应用程序性能管理/日志记录）来衡量开发者的生产力。
Max Kanat-Alexander 说：2017年7月26日晚上9:43
是的，关于价值的观点实际上在我的书中。
-Max
Cara 说：2017年6月12日上午8:18
真正的好文章。确定有效指标一直是我们公司最困难的部分，因为我们从事许多不同类型的项目（并且通常与可能影响某些指标的各种合作伙伴合作）。
10 Extraordinary Time Management and Productivity Articles, 8/1/16 - TimeCamp 说：2017年6月15日晚上9:06
[…] Code Simplicity – Measuring Developer Productivity – by Max […]
Tom Hombergs 说：2017年6月22日上午10:53
好文章。让我开始思考……我知道你描述的指标只是例子，但当你查看成功放入购物车的商品数量或有多少人无误地完成结账流程时，你真的在衡量生产力吗？这更像是衡量产品的质量或成功，而不是团队定期高效生产产品（或产品增量）的方式。不要误会：我完全同意团队应该通过这样的成功指标来衡量！团队甚至可能通过提供游戏化机制或直接奖金等激励措施来激励实现良好的成功指标。但为了衡量生产力，我宁愿回退到"每周投入生产的功能数量"或"每周修复的错误数量"等指标。为了激励团队使这些功能和错误修复高质量（而不是仅仅快速而肮脏只是为了提高生产力），我会将它们与"低错误率"或"成功完成的业务交易"（如那些结账）等成功指标结合起来。然而，我还不知道如何在特定项目中实现生产力和成功指标的这种组合。我会再思考一下……:)。有人有想法吗？
Max Kanat-Alexander 说：2017年7月26日晚上9:49
“每周投入生产的功能数量"和"每周修复的错误数量"都是传统指标，已经尝试了几十年，并因各种原因失败。如果你查找"功能点”，你会发现为试图量化"功能"而设计的最复杂系统。它如此复杂，以至于没有人能可靠地实际执行，使其成为一个糟糕的指标。不太复杂的系统失败是因为"功能"不是一个明确定义的对象，并且"功能"都有不同的大小。衡量修复的错误数量是有问题的，因为人们跟踪不好，不同的错误有不同的大小，有些错误修复对用户比其他人更有价值，有时做功能工作更有价值，人们会博弈指标等。可能有理由跟踪未解决问题的数量和处理速度，但不应该用于衡量开发者的生产力。如果你真的想知道生产力，你必须定义这个词本身并衡量它，经过多年的广泛搜索，你最终会得到我上面写的博客文章。我猜，在我和其他人之间，我已经参与了数百人年致力于这个问题，而我上面写的是我所知道的最佳解决方案。
-Max
Steven Gordon 说：2017年8月4日上午8:47
你会用这样的指标做什么？从任何目标开始，我相信我能找到比虚假生产力指标更接近实现该目标的东西。
Saim Aksr 说：2017年10月19日下午5:33
感谢撰写如此好的信息性文章，我是Web开发人员，最大生产力是我的日常目标
Federal Cyberattacks, Dropbox Security, & More… - Intertech Blog 说：2018年7月12日上午7:57
[…] 衡量开发者生产力是出了名的困难。关于 thoughtful measurement 的一些想法。[…]
Enola Labs 说：2018年10月3日下午12:17
非常有见地和跳出框框的思考生产力的方式。
Measuring Productivity – Fall 2018 Software Discoveries 说：2018年10月19日下午12:40
[…] 为了进一步研究答案，我阅读了经验丰富的开发者 Max Kanat-Alexander 的"Measuring Developer Productivity"。在这篇博客文章中，他从什么是[…]的根源开始
The value of code - SoatDev IT Consulting 说：2023年7月13日上午11:14
[…] 尽管LOC和贡献测量周期性地流行，但依赖代码贡献的风险通常是众所周知的。它可能导致：[…]