The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
九年前（正好是该网站刚刚推出的时候），在StackExchange上提出了这个问题：“如果不是通过代码行数来衡量，那么有什么好的指标可以用来衡量远程程序员的有效性。”答案毫不意外地都是这样的：程序员不应该被衡量！我敢打赌那些回答的人自己就是程序员。的确，为什么一个程序员会对被衡量并被简单地归纳为一个数字感兴趣呢？
首先，让我们看看为什么给程序员设定一个指标可能被认为是不好的做法（我的观点是：这仅仅是过度支付的程序员/经理们为了保住自己的工作而找的借口，他们只是在做他们想做的事情，浪费雇主的钱而已）。
“如果不加以控制，英雄主义思维会破坏团队精神，” Quovantis 的产品经理 Bhuwan Jain 在这里说道。
“绩效评估破坏士气，破坏团队合作。” Samuel A. Culbert，加州大学洛杉矶分校安德森管理学院的管理学教授说道。
“个人奖励在一个合作至关重要的环境中培养竞争意识。”Avienaash Shiralige，一位在AgileBuddha担任敏捷教练的人士说道。
“个别指标会阻碍团队合作，” Sean McHugh——Axosoft 的Scrum Master说道。
“绩效评估是有害且完全不必要的，” Kane Mar，Scrumology 的联合创始人兼首席顾问指出。
“绩效指标会抑制主动性、创新和冒险精神，” 《指标暴政》的作者杰瑞·穆勒表示。
“人类本质上无法被简单归结为一个数字。”，一位认证敏捷教练 Jimi Fosdick 表示。
你觉得这样怎么样？“继续给我钱，但别指望我会给你任何回报！而且你敢检查我的表现！”——这就是我听到的，我并不惊讶。所发生的事被称为绩效管理革命，其要点是：现代管理太弱了，我们迫切需要一个官方名称来避免混乱。敏捷（Agile）就是这个名称。
现在不再有经理人，而是程序员。这很令人悲哀。
然而，并不是每个人都相信这种混乱。一些专家认为指标实际上是有帮助的。布拉德利·柯克曼等人声称：“认可一个团队成员似乎对团队中的其他成员产生了积极且有感染力的影响”，并且2001年由杰克·韦尔奇提出的著名的活力曲线至今仍然存在。
我认为对指标的所有负面评价都是由于它们的错误使用造成的。确实，如果对软件工程师的唯一绩效指标是他们在办公室待的时间，那将只会对所有指标产生负面影响。这样的指标确实会伤害，毫无疑问。但缺乏好的指标会更加伤害。如何选择它们——这才是真正的问题。让我建议几个，而不是著名且不正确的代码行数（LoC）。理想情况下，你可以从这个列表中选择组合，甚至同时使用它们：
合并的拉取请求。每个拉取请求都需要同行评审，以确保其合理并符合项目的质量标准。太小或太大的拉取请求必须被拒绝。
已修复的错误。错误与功能的工作方式相同，但通常较小。程序员关闭的错误越多，越好。当然，关闭工作必须由产品经理或其他报告了错误的程序员完成。
已报告的错误。一旦错误被报告并被项目接受，报告者将获得额外的积分。这是项目质量的提升方式：通过鼓励每个人报告错误。
发布版本。在一个有纪律的项目中，每天发布新版本；在其他项目中，每周或每几个月发布一次（或者根本不发布）。每次发布都是一项充满压力的操作，因此奖励程序员似乎是合理的。
正常运行时间。有一组DevOps指标可用于展示生产环境中的服务质量，包括MTBF（平均故障间隔时间）、MTTF（平均故障时间）、故障率等等。正常运行时间越长，程序员和他们的产品就越好。
拉取请求的成本。我相信，一个程序员提交的拉取请求合并所需的时间越短，他们就越优秀。他们的拉取请求能够快速通过同行评审和质量控制，这是最好的情况。初级程序员通常会提交过大或过于复杂的拉取请求，在同行评审过程中引发了很多麻烦。他们还会引发合并冲突，有时甚至导致无效的分支和无法合并的拉取请求。
已发布的文档页面。常见问题解答页面、Javadoc块、维基页面、博客文章等等——它们通过提高可维护性，帮助项目与用户和未来开发者更加接近。当然，在发布之前，每一段文字都必须经过验证。
学员成果。高级程序员可以担任初级程序员的导师，并且可以根据他们的学员所获得的奖励而获得回报。上述所有指标都可以按照这种方式运作，当学员表现更好或更差时，奖励或惩罚导师。
我无法强调这一点：每个指标都必须有一个质量控制机制。仅仅测量报告的错误而不检查其质量将导致作弊：程序员会报告他们喜欢的任何错误，只是为了提高数字。每个错误都必须由架构师进行验证：重复或质量低劣的错误报告将被拒绝。对于每个指标都是如此：没有控制的信任会导致作弊。
还值得一提的是，功能、错误、拉取请求和文档页面可能具有不同的“复杂性”、“紧急性”和“严重性”，这也应该考虑在内，增加或减少每个指标的数字。
这些指标中的大多数可以自动收集，不需要任何人工干预，例如通过GitHub API。
在理想的理想管理世界中，项目根据收集到的指标补偿程序员的工作。程序员不再领取薪水，而是根据功能、错误、文档页面等获得报酬。你的项目离这个乌托邦有多远，就是你作为项目经理的专业水平的指标。糟糕的经理不测量任何东西，通过保持工资高而控制低来让每个人“满意”…直到项目资金耗尽。另一方面，非常优秀的经理让指标控制每个人，使得最好的人满意，最差的人迅速找到出路。
Is there a metric to measure programmers' performance objectively?
— Yegor Bugayenko (@yegor256) July 19, 2020
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 14:12
