中文版前言
本文是 GERGELY OROSZ 和 KENT BECK 发表的文章《Measuring developer productivity? A response to McKinsey》 的中文翻译版本，英文原版见下面链接：
https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity
https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity-part-2
文章针对软件开发团队生产力的衡量问题，反驳了麦肯锡公司提出的衡量框架，并提出了作者的观点和建议。作者认为，衡量生产力不应过分侧重于努力和产出，而应更注重团队的整体结果和影响。文章通过销售和招聘的实例，揭示了只关注个人绩效可能导致团队合作的缺失和业务目标的偏离。
文章还通过足球和冰球的例子，强调了团队绩效相对于个人绩效的重要性。在软件工程领域，团队的协作和整体表现比个人的技能和经验更能决定项目的成功。作者建议，衡量软件工程投资的价值应采取类似于石油公司的策略，通过小规模但不昂贵的投资探索可能的成功，然后在有希望的项目上加大投资。
在衡量开发者生产力方面，作者建议重新定义问题，关注团队的影响和结果，而不是个人的努力和产出。他们强调，任何衡量都会影响团队的行为和文化，因此需要谨慎选择衡量指标，并保持对工作的亲自参与和监督。
总之，文章强调了一个平衡和全面的生产力衡量方法的重要性，这种方法应注重团队的整体结果和影响，而不仅仅是个人的努力和产出。
注：版权归原作者所有，仅为方便中文软件技术人员阅读，翻译为中文版，如有侵权请通知本人删除，Hayppy Coding!
第一部分
1. 软件工程周期的思维模型
在我们探讨解决方案之前，先来建立一些背景知识。软件工程是如何创造价值的？我们可以通过一个典型的例子来理解：开发一个功能，推送给用户，然后不断改进。这个过程是怎样的呢？假设我们有一个在创业公司工作的自主、有能力的软件工程团队，他们能够很好地理解客户的需求。
我们可以这样看待一个典型的开发周期：首先，我们决定下一步要做什么，然后付诸实施。这包括计划、编码等各种工作。通过这些努力，我们得到了具体的产品，比如功能本身、代码、设计文档等，这就是我们的产出。因为有了这些产出，客户的行为也会发生改变，这就是我们的成果。例如，有了这个新功能，客户在使用产品的过程中可能会遇到更少的困扰。由于客户行为的改变，我们会收到反馈、增加收入、获得推荐等，这就是我们产生的影响。
所以，我们可以用以下术语来更新我们的思维模型：
这个模型描述了软件工程的整个过程，无论是对小任务还是对复杂项目的开发，都同样适用。
我们会在整篇文章中反复引用这个模型。
2. 为什么我们需要衡量生产力？
在探讨“如何衡量”之前，我们先回答一个更根本的问题：
是谁想要衡量生产力，原因又是什么？
这个问题至关重要。不同的人对这个问题的回答可能截然不同，这取决于提问者是谁，以及他们提这个问题的目的是什么。以下是一些常见的情况：
#1：CTO想要识别并解雇表现不佳的工程师
“我如何衡量组织中工程师的生产力，找出表现最差的10%，然后解雇他们？” 鉴于科技行业最近的裁员潮，这个问题变得尤为重要。有几种可能的回答：
- 根据最近的绩效评审分数找出表现最差的员工。这种方法依赖可能已经过时的历史数据。
- 基于员工的工龄进行裁员，采用“后进先出”的原则。这种方法并不考虑绩效数据，只是假设最新入职的员工离职对生产力的影响较小。
- 选择一些容易衡量的指标，如拉取请求的数量、已关闭的工单数量等，基本上是根据工作量和产出来做决定。
- 让经理确定要裁掉的工程师数量。这种方法可以利用团队动态和无法量化的信息，例如经理可能知道哪些工程师即将辞职，这是量化指标无法捕捉到的。
裁员会影响团队的动态，任何未能考虑到这一点的方法都可能导致不理想的结果。同时，裁员常常受到限制，例如高层领导不想让一线经理参与决策，因此决策常常基于被认为是错误的指标。
#2：为了比较两个投资机会
“我如何衡量团队的生产力，并将额外的人员分配给能更有效利用这些人员的团队？”
要回答这个问题，你需要比较投资的回报。这不是一个关于生产力的问题，而是关于将更多人员分配给一个团队或另一个团队的影响。
#3：为了管理绩效。
“我如何衡量工程师的生产力，以奖励表现最好的10%，并识别表现最差的25%，以便改进他们的绩效？”
有很多方法可以衡量绩效，虽然用指标来衡量可能会出错。一个亲身参与的经理可以立刻列出表现最好和最差的员工，然后检查和调整产出，更仔细地观察工程师是如何工作的。绩效校准是这样做的标准方式。
#4：软件工程师想要提升能力：
“我如何衡量自己的生产力，有哪些指标我可以改进，以成为一个更好的工程师？”这是更多工程师应该自我提问的问题！以下是两种有帮助的方法：
- 在使用测试驱动开发（TDD）时，一次只有一个红色测试。这种方法衡量了努力和产出。你需要达到有意识、有计划地保持一个红色测试的水平。
- 设定每天合并一个拉取请求的目标，并在一周内跟踪这个目标。这个目标迫使你做更小的提交，这样更容易审查和得到批准。它也推动你编写正确的、符合团队标准的代码。
只要你继续跟踪这些“分数”并努力提高它们，你就会提高自己作为软件工程师的效率。
但是，如果你把这些指标展示给你的经理，然后你的绩效就是根据它们来评判的，那会怎样呢？这将是一场灾难：你将不是根据成果或影响来衡量，而是根据产出。当你尝试不同的方法 - 例如，学习一种新语言来帮助一个有需要的团队 - 那么你的产出可能会下降，即使你正在帮助团队取得更好的成果！
3. 为什么销售和招聘团队能准确衡量生产力？
作为软件工程行业，我们应该承认，与其他职能团队相比，我们在衡量个人生产力方面做得不够好。以销售为例，以下是 Kent 在他过去的一家公司的销售和工程领导层会议上，关于销售运营的责任水平的描述：
“我清晰地记得这次会议，工程和销售领导层在报告进展。销售团队的每个人都发言并给出了类似这样的更新：
‘我团队本季度的目标是60万美元，我们实现了52万美元。我为未达标负责。这里是发生这种情况的原因，以及我为实现下个季度65万美元的目标所做的改变。另外，我正在实施一个为期两个季度的计划，我预计完成后每个季度将增加10万美元的收入。有任何问题吗？’
如果有人有问题，销售领导会深入到个人层面——哪些销售代表超额完成，哪些未达标，超或低多少——并以房间里的每个人都能理解的方式进行说明。
然后，轮到工程团队。天哪，对比真是鲜明。典型的工程更新大概是这样的：
‘所以，这个季度我们发布了功能A，我们在一些技术债务迁移方面稍微落后，下个季度我们将发布功能B并赶上迁移。有任何问题吗？’
如果有人对某些延迟有问题，答案从不涉及个人——就像销售那样——通常包括不可预见的困难、技术债务、APIs；所有这些非工程师在房间里都不太理解。”
销售和客户支持的责任水平与 CEO 从工程观察到的完全不在一个层面上。但当 CEO 检查整个部门的成本时，工程可能比销售成本更高！
不仅销售展示了更高的责任水平。招聘团队有“要填补的头数”目标。招聘团队可以毫不犹豫地回答他们达成目标的百分比是多少，为了达到激进的招聘目标他们还需要多少招聘者，以及根据纯粹的指标识别顶级和底级的招聘者。
让我们站在 CEO 的角度思考。销售有明确的生产力衡量方法，招聘也是如此。那么工程呢？
让我们回到我们的努力-产出-成果-影响的软件工程工作思维模型。我们可以将这个模型应用到销售和招聘。销售团队通过成交的交易来衡量自己，那么这个指标在模型中属于哪里呢？它属于“成果”或“影响”：
那么招聘团队的主要指标：需要招聘人员数量的完成度，它也可以被归类为“影响”：
我们可以对其他具有高责任感的职能重复这个练习。例如，客户支持可以通过关闭的工单数量（一种成果）、关闭工单所需的时间（也是一种成果）和客户满意度分数（影响）来衡量。
Kent 和我都没有看到技术公司内部有责任感的团队不是通过成果和影响来衡量的。为了使软件工程更具有责任感，我们需要探讨如何做到这一点。
4. 软件工程中的测量权衡
一个流行的衡量软件工程团队效率的框架是 DORA 框架。让我们梳理一下这个框架的测量重点：
所有 DORA 指标都衡量成果或影响。
让我们看另一种衡量开发者生产力的方式：SPACE 框架。它试图捕捉满意度、性能、活动、沟通和效率（SPACE）。它不仅仅是 DORA 那样的成果和影响。SPACE 框架没有列出明确的指标 - 但给出了示例指标。其中几个指标带有警告，比如衡量代码行数。带有 SPACE 框架作者警告的指标 - 例如‘代码行数’指标 - 倾向于衡量努力或产出。
我们对麦肯锡的系统的一个批评是，几乎每一个与 DORA 和 SPACE 指标不同的自定义指标，都衡量努力或产出：
这种方法有什么问题呢？首先，关心这些指标的只有收集它们的人。客户不在乎。高管不在乎。投资者不在乎。其次，最关键的是，收集和评估这些指标阻碍了下游人员真正关心的测量，比如盈利能力。
为什么麦肯锡要增加衡量努力的方式呢？一个原因是这是最容易衡量的！但麦肯锡的方法忽略了一个重要的事实：测量的行为改变了开发者的工作方式，因为他们试图“操纵”系统。
你在周期的早期测量，就越容易测量。也更有可能引入意外后果。让我们考虑只衡量利润的极端情况。好消息是，公司内的每个人都是一致的！坏消息是：几乎不可能归因谁对利润贡献了多少！你可以通过衡量产出或努力来‘修复’归因问题。但代价是你改变了人们的行为，因为它激励他们操纵系统以在这些指标上‘得分’更高：
让我们考虑一个公司的情况，该公司相当盈利，在行业的上四分之一。公司的领导层不喜欢无法归因个人在盈利方面的表现。
你会被诱惑去通过引入微观测量来破坏你公司的业务吗？当然不！
我们敦促工程领导者看向成果和影响的测量，来确定要测量什么。衡量努力确实很有诱惑力。但销售和招聘团队不是根据他们准时上班或发送的电子邮件数量（这都是努力或产出）来评价他们的表现的原因是有道理的。
那么工程团队可以衡量哪些成果和影响呢？DORA 和 SPACE 提供了一些指引，我们还提供了另外两个：
- 每个团队每周至少生产一个面向客户的东西。这个产出可能听起来不那么令人印象深刻，但实践中很难实现。最生产力高的团队 - 和灵活的公司 - 能做到这一点。如果你考虑为什么一个创业公司能如此迅速和出色地执行，那是因为他们必须这样做，即使他们没有衡量这一点。
- 交付团队承诺的业务影响。像 Meta、Uber 和其他快速发展的科技公司一样，“影响”之所以如此普遍，有一个很好的原因。通过奖励影响，企业激励软件工程师了解业务，并优先帮助实现其目标。通过配置更改实现每年节省200万美元的成本，是否比花费5个工程月实现每年节省50万美元的成本更有价值？不！你不想仅关注影响，但不关注实现商业价值的最终目标是一个糟糕的选择。
结论
毫无疑问，商业界对量化软件开发团队的生产力的需求日益增加。像麦肯锡这样的公司通过提供框架来满足这一明确的需求，这些框架承诺能够做到这一点。
我们不认为衡量努力和产出就是答案：因为这些都带有会对工程文化产生负面影响的权衡。作为工程领袖：一定要考虑这种权衡，以及它如何改变开发者的激励。
文章的第二部分中我们将探讨只衡量成果和影响的危险；并提供我们对如何衡量开发者生产力的问题的答案。Kent Beck 将对这个话题给出他坦率的看法。
回顾 Uber 如何衡量工程生产力是有趣的：鉴于这个共享出行巨头已经建立了一个仪表板来可视化衡量产出的统计数据，比如 diff 计数、软件工程师的审查次数。这些指标衡量的是产出。同时，该公司还衡量了诸如从创建到关闭的时间、软件工程师的专注时间等事物。
Uber 在推出这些指标后认识到其对行为改变的影响：工程师创建更小的 diff，目标是更快地关闭这些 diff，并为自己腾出更多的专注时间。
我四处询问了工程师，Eng Metrics 仪表板的引入是如何改变文化的。我听说大多数团队使用仪表板来调试问题 - 尽管有些团队和小组的经理或主管为每月的 diff 数量设定了目标（这些指标很容易达到：因为你只需创建更小的 diff）。在引入仪表板一年后，这种情况似乎已经改变，这只是另一个常规的指标。
Uber 的一个有趣的轶事是：在引入 Eng Metrics 仪表板后：代码行数并没有显著改变，但 CI 系统的利用率明显增加。基本上，人们开始创建更多的 diff，这给持续集成（CI）系统带来了更大的负载，并增加了 CI 成本。所以，在衡量产出之后，为了改善这些被衡量的指标，跟着的是更多的努力来改变行为。
文章在第二部分结束，我们讨论了只衡量成果和影响的危险；团队与个人表现；以及回答如何衡量开发者。
第二部分
这是 Gergely Orosz 和 Kent Beck 对麦肯锡文章《Yes, you can measure software developer productivity》的回应的第二部分，也是最后一部分。
我们认为，引入麦肯锡所提议的那种框架是错误的，肯定会适得其反。这样的框架很可能会对组织和公司的工程文化造成更多的伤害而非益处，修复这种损害可能需要数年的时间。
在这篇两部分的文章的第一部分中，我们涵盖了：
- 软件工程周期的心智模型
- 衡量生产力的需求从何而来？
- 销售和招聘是如何如此准确地衡量生产力的？
- 软件工程中的衡量权衡
现在我们将总结这个话题，包括：
- 仅衡量成果和影响的危险
- 团队与个人绩效
- 为什么工程成本如此之高？
- 你如何决定投资多少在工程上？
- 你如何衡量开发者？
1. 仅衡量成果和影响的危险
到目前为止，销售和招聘一直处于一种责任的基准上，因为他们都用无可争议的指标捕捉团队和个人的表现。然而，我们看到了只关注衡量和奖励结果和影响的阴暗面：人们为了自己的利益操纵系统，这样做违背了衡量的初衷，并最终通过产生垃圾数据损害了企业。
下面，Kent 分享了他看到的当唯一重要的事情是销售配额时会发生的情况：
“个人目标阻碍了人们的合作，因为每个人都在追求自己的配额。这可能导致错失机会。
例如，有机会完成一个跨越几个地区的大销售。为此，需要多个销售代表共同努力，销售将归功于发现机会的代表。但其他销售人员没有动力去帮助。公司在不知情的情况下失去了一个有吸引力的前景。个人激励可能会损害公司的长期盈利目标。
我亲眼看到一个‘明星’销售人员是如何操作的。他们总是达到他们的配额，并收集丰厚的奖金。他们是怎么做到的呢？嗯，他们知道销售随时可能落空，所以他们总是有几个潜在客户‘在口袋里’，他们可以随时转化，所以把他们推迟到每个季度的末尾。他们只有在需要达到他们的配额时才会转化他们。为了最大化个人收益，他们没有最大化公司的收益。”
在招聘领域，Gergely 经历了如何通过奖励招聘人员关闭候选人，后来会产生反效果：
“我曾与一个招聘人员一起工作，其他招聘经理对他大加赞赏。这个招聘人员有 100% 的关闭率。关闭意味着当一个候选人得到一份工作提议时，我们让他们签字。当时，我的组织部分非常紧张，招聘人员进行了大部分的关闭对话并处理细节。大多数招聘人员最多关闭 70-80%。我被告知这个招聘人员是他们同行中的‘摇滚明星’。 我用痛苦的方式发现了他们是如何做到的。大约在这个招聘人员离职 6 个月后，绩效评估和奖金时间到了。我们小组的几名工程师抱怨他们的奖金金额，说他们被‘保证’的金额是他们实际得到的 10 倍。经过一番挖掘，所有迹象都指向了摇滚明星招聘人员；他们在私人场合对工程师做出了荒谬的口头承诺。 这个招聘人员专注于结果，并忽视了几条不成文的规则，以及书面规则。我们经理花了几个月的时间来整理混乱，让工程师感到受骗，对公司的信任下降。”
衡量结果和影响是重要的，但必须有检查和平衡机制，确保以正确的方式实现结果。最终，这正是一个健康的公司文化所关注的。相反，在一个“割喉”或有毒的文化中，只有容易衡量的结果和影响是重要的——目的总是为手段辩护。一个更健康的文化会考虑到结果和影响，并会限制以不专业的方式，或者不考虑合作或更大局的方式实现的结果的奖励。
2. 团队与个人绩效：哪个更重要？
在衡量团队和个人绩效的重要性方面，体育行业提供了一些启示，因为在这个行业中，个人绩效可以被相当准确地衡量。
以足球为例。有很多例子证明团队绩效胜过个人绩效。一个拥有技术较差球员的球队，通过团队合作，有时能击败拥有更多才华球员的对手。2004年欧洲杯足球赛上，希腊队就以排名第15的身份赢得了冠军，这一事实就充分证明了这一点。这背后的秘密是什么呢？纪录片《国王奥托》揭示了答案——团队合作、发挥球员的长处，以及一位出色的德国教练奥托·雷赫格尔。
拥有众多明星球员的球队，尽管拥有客观上更优秀的技能，但往往难以获得成功。西班牙俱乐部皇家马德里在21世纪初的“银河战舰”招聘政策就证明了这一点，他们签下了超级球星，但球队经常无法赢得奖杯。
我们在软件工程中也看到了类似的动态：通过团队合作，士气高昂，以及拥有正确直觉的经理，一些技能和经验不足的团队也能表现出色。我也见过一些由高级工程师组成的团队，他们难以实现预期的成果，士气低落，方向混乱，管理和领导能力差。
再看另一项运动，冰球。这项运动使用了一个有趣的统计数据，“正负值”，用来衡量一个球员的进球差，即当该球员在场时，球队进球多、失球少的情况。这是一种“对团队成功的贡献”指标，用于识别能让团队更高效的球员。
我们能为软件工程师找到类似的“正负值”指标吗？如果存在这样的指标，衡量它可能是有价值的。但是，五对五的冰球比赛和由5-10名工程师、设计师、测试人员和产品专家组成的软件工程项目有很大的不同。冰球队每周都有比赛，有严格的时间限制；胜利的条件非常明确：进更多的球。相反，软件项目往往持续时间更长，可能没有时间限制，也没有简单的计分系统。
个人绩效并不能直接预测团队绩效。如果在像体育这样容易衡量的领域里，都不可能从个人绩效中推断出团队绩效，那么在软件工程中，我们可以预期的成功更少。
团队绩效比个人绩效更容易衡量。工程团队通过已发布的项目、商业影响（例如收入、利润、减少的流失率等）和其他指标来跟踪绩效，就像体育团队通过胜负和其他统计数据来跟踪绩效一样。
3. 为什么工程成本这么高？
“为什么工程成本这么高”是一个会频繁出现的问题。以下是一个建议，说明如何处理这个特定问题：
想象一个公司在工程上花费0%的预算的世界。我知道，这听起来很荒谬。但请这样想一想。这对公司意味着什么？客户会有什么体验？业务趋势会是怎样？
现在，再想象一个公司将100%的预算花在工程上，其他一切都不投入的情况。会发生什么？
既然我们知道了这两个极端：公司在工程上花费的预算占总预算的百分之多少呢？有了这个数字，问题就变成了，如果我们将这个数字降低或提高几个百分点，会发生什么？哪种做法更有利于业务，为什么？
这个练习将“为什么工程成本这么高”这个问题转变成一个比较练习，决策是将工程支出减少或增加X美元，还是将这笔投资（或减少）用在其他领域。
4. 如何决定投资多少在工程上？
高层管理人员想要衡量工程的生产力的另一个常见原因是，他们想要了解在工程上进一步投资的价值——相对于将计划投资分配给销售或市场营销等。
然而，一位高管真正要问的问题并不是关于生产力。问题是：“我们应该投资多少到工程上？”
为了回答这个问题，需要考虑到软件工程的结果是不可预测的，特别是在小规模上衡量时。当然，有些行业你确切地知道你想要建造什么，工程只是一个执行游戏。但在工程创新的公司里，投资决策更像是石油公司决定在哪里和投资什么。
石油公司无法确切知道一个石油钻探操作将带来多少利润。所以他们做出明智的投资。不可能告诉任何单一的探索性钻探是否会发现一个新的、有利可图的油田：所以他们一次资助几个这样的钻探；期望其中一些最终会带来有希望的结果。有了更多的数据，然后做出更大的投资决策。
对工程领袖和高管来说，以类似的方式将软件工程作为研究和开发活动进行投资是一种务实的方法。做出小而不昂贵的赌注：并加倍投资那些显示出有形希望的赌注。
5. 如何衡量开发人员的表现 （Gergely的答案）？
这一部分是Gergely 与 Kent 意见分歧的地方。以下是 Gergely 对这个问题的看法。
那么，如何衡量开发人员的生产力呢？我建议使用以下框架。
了解真正的需求
当有人问如何衡量开发人员的生产力时，这永远不是真正的问题。为了弄清楚真正的问题，考虑以下几点：是谁在问，他们的真正目标是什么？真正的话题可能是：
- “我需要决定在哪些领域投入更多的人力。哪种分配会为企业带来最好的回报？”
- “我想进行绩效管理，识别低效和高效的表现者。”
- “我想找出问题团队，进行调试和修复。”
- “我们的投资者希望我们削减成本，我需要弄清楚我可以削减多少，而不会对业务产生重大影响。”
- “我需要向认为我们太贵的CEO证明工程的成本。”
重新定义问题
作为一名工程领袖，你经常会收到“我们想衡量你的团队的生产力”的请求。与其顺从，不如退后一步。
Abi Noda — DX的联合创始人，Engineering Enablement通讯的作者，以及《一种新的衡量开发人员生产力的方法》论文的合著者（免责声明：我是DX的投资者和顾问）建议这样做：
“我对这种情况下的工程领袖的建议是：重新定义问题。CEO想知道的是你是否在他们对工程的投资上做了一个好的管理者。你可以通过提供工程的全貌来展示强烈的管理能力，包括：
- 业务影响
- 系统性能（我们的系统是否快速、可靠等）
- 开发人员的效率（速度、便利、质量、满意度）。”
知道人们会优化被衡量的内容
员工足够聪明，知道如果一个衡量标准被用来评估他们，那么他们应该优化那个标准。这被Goodhart的法则所捕捉：“当一个衡量变成一个目标时，它就不再是一个好的衡量。”
例如，我记得当一个使用Scrum的团队开始衡量他们是否实现了冲刺目标时，用速度点来衡量。我们的PM和EM开始将实现冲刺目标的团队称为‘完成了冲刺’，而没有做到这一点的团队为‘冲刺失败’。我们用故事点来定义冲刺目标，而不是承诺的工作。
接下来我知道的是，一个明显为了晋升而努力工作的开发人员开始夸大任务的估计，并且也将估计为高故事点的易于完成的任务“偷偷摸摸”地加入到冲刺中。在纸上，我们做了更多的故事点。
我问这个开发人员为什么这样做，他回答说他不想冲刺失败，因为这可能会让他看起来不好。最终的结果是，作为一个团队，我们的工作重心减少了，感觉人们关心的是故事点，而不是构建我们的客户想要的东西。
当你的衡量标准对团队公开时，衡量的目标应该是成果和影响，而不是努力和产出
人们会弄清楚如何“玩弄”你衡量的东西，并为此优化。当你衡量每个领域时，会发生以下情况：
- 衡量努力：创造有问题的高努力工作
- 衡量产出：通过最容易做的事情增加产出的数量。这可能对成果或影响没有帮助。
- 衡量成果：目标是达成指标，即使这意味着走捷径
- 衡量影响：用更少的努力和产出来创造性地达到这一点
不过，不要忽视人和团队付出的努力和产出！不是衡量它们，而是用这些来调试与成果或影响有关的问题。
例如，如果你衡量产生的代码行数，并将绩效激励与之挂钩，工程师会优化这个数字并增加技术债务。但如果你衡量的是成果，然后注意到一个工程师几乎没有发布功能，你会想要看看他们产生的代码、其质量、他们如何花费时间等等。
注意衡量努力和产出的框架会改变行为——并不总是以明显的方式
如果你衡量拉取请求的数量：人们会创建更小的拉取请求，而不会改变其他任何东西。这是一种可取的事情吗？也许是：如果是这样，那么引入这个衡量将使工程文化朝着那个方向发展。
然而，要警惕意想不到的行为变化。例如，如果人们现在开始将拉取请求分割为代码更改和测试更改：只是为了增加他们的PR计数：因为这种方法是适得其反的。
一个关注努力和产出的衡量的问题是，它们将工程文化转变为一个‘松散时间’——两项工作之间的空闲时间——是不受欢迎的。在像工厂一样运作的公司，这可能不是问题。但对于工程是利润中心的公司，同事之间在停机时间的自发互动可能导致原型和新想法的出货，那么衡量努力和成果的框架将压制文化。
知道衡量会干扰系统
你开始衡量的每一件新事物都会导致工程师优化以使该衡量看起来更好。你衡量的越多，你塑造文化和人们工作的方式就越多。
很容易看出，当领导层开始衡量事物时，一个高生产力的工程团队变得不那么生产力，特别是如果它是努力和产出。
谨记每个衡量的风险。当顾问声称可以在不影响人们工作的情况下进行衡量时要保持怀疑态度。永远不会。你能做的最好的事情是引入实际上是可取的变化。
运行一个高绩效团队是一种亲自动手的方法。
希望通过指标获得显示团队高绩效的数字是一种一厢情愿的想法。实际上，你能知道你有一个高绩效团队的方式是：
- 团队的影响与预期一致，或者超出预期。看看像收入生成、对利润的贡献、成本削减或其他与盈利能力、增长或其他关键业务指标挂钩的影响衡量
- 团队的工程师正在有效地工作——以这个团队有意义的方式
- 团队的领导者（或领导者）足够亲自动手，能够及时发现执行中的问题，并迅速解决
我会选择一个明确传达其影响的团队；和团队中的一位亲自动手的领导者，而不是任何有花哨指标和不亲自动手的领导者的团队。相关阅读：
是的，你可以衡量开发人员的生产力，但代价是什么？
McKinsey在声明开发人员生产力可以被衡量时并没有错。然而，他们回避了衡量的成本是什么的问题。
衡量一个工程团队和工程组织的影响是可能的。如果你还没有这样做，你应该这样做！例如，当我在Uber时，我的团队有一个wiki页面，我们列出了我们当前和已完成的项目，以及它们的影响，按季度划分。这就是它的样子（🔒文档有更多的例子）
捕捉工程团队的影响——我的方法。 更多的例子
我发现奇怪的是，相对较少的团队以我团队所做的格式捕捉他们的影响：并且有“硬影响数据”使关于一切的讨论变得更容易：优先事项、重组、人头分配等等。
将这种影响归因于个别工程师也是可能的，但是你使归因更细化，就越干扰激励，就越有可能创建一个激励繁忙工作的组织。
我的建议是，如果你要衡量，那么从影响开始。不是个人影响：而是团队影响。
当然，作为一名工程领袖：靠近工作：在你能的时候亲自动手，绝对保持技术性。
如果影响有问题，卷起袖子调试问题——这涉及查看努力和产出。但不要默认衡量努力和产出，“以防万一”成果或影响可能有问题。
6. 如何衡量开发人员的表现 （Kent的答案）？
- 要清楚你为什么要问这个问题，以及你与被衡量的人或人群之间的权力关系是什么。当有权力的人衡量没有权力的人时，你会得到扭曲的结果。
- 自我衡量以实现自我提升是非常好的！我的测试驱动开发书中包含了一个分析，分析了我为书中开发样本代码时，测试运行之间的延迟。我发现这种经历是有启发性的。
- 通过在与收集数据相同的层面上分析数据，避免不正当的激励。我可以分析我自己的数据。我的团队可以分析其自己的汇总数据。
- 如果你选择围绕衡量创建激励（广义上定义为—金钱、地位、晋升、自主权），要知道你将再也无法收到准确的数据。
- 红队任何激励。一个聪明（你雇佣他们，他们当然聪明）、有动机的人会怎样让数字看起来更好。他们在这个过程中可能会造成多大的损害。
- 对自己的判断感到舒适。过分依赖“数据”的执行者似乎在逃避责任。抓住这个难题。要求得到对你有意义的解释。然后坚持你自己的结论。
- 衡量开发者的生产力？不可能。有太多的混淆因素、网络效应、方差、观察效应和反馈循环，无法得出像“Joan比Harry创造了多少倍的利润？”或“Harry这个季度比上个季度做得好（或差）多少？”这样的问题的明确答案。你可以衡量活动，但不是在不将活动从你关心的目标、你的客户和你的投资者那里引开的情况下。
- 对任何声称能衡量开发者生产力的人持怀疑态度。询问是谁在问这个问题，为什么要问。问他们用什么单位进行衡量，以及这些单位是如何与利润相联系的。
- 我百分之百支持问责制。每周交付客户赏识的价值是最好的问责方式，最一致，也是最少扭曲的。