衡量开发人员工作效率的最大好处是，你可以很快找出那些糟糕的程序员。我想给大家讲讲我认识的最差的程序员，以及我为什么要把他留在团队里。
几年前，我在 Twitter/X 上写过一篇关于我认识的最好的程序员的文章，我应该把它写成一篇博文。现在，我也应该向大家介绍一下我认识的最差的程序员。他的名字叫蒂姆-麦金农（Tim Mackinnon），我想让全世界都知道他的工作效率有多低。
我们当时在一家大银行为一家知名软件咨询公司工作，这家银行决定引入个人绩效指标，"用于考核和个人发展目的"。这在组织中层层传达，并在我们团队中以故事点的交付量为标准。这是部门经理经过深思熟虑讨论后做出的决定，他知道你不应该衡量代码行数或发现的错误等指标，因为人们很容易在这些指标上做手脚。
相反，我们会衡量已交付的故事，也可能是故事点（事实证明这并不重要），因为这些故事代表了业务价值。我们当时使用的是 Jira 这样的工具，人们会把自己的名字写在故事上，这样就能非常容易地生成这些生产率指标。
这让我想到了蒂姆。
蒂姆的得分一直是零。
零分！不仅仅是低，也不仅仅是呈下降趋势，而是实实在在的零。一周又一周，迭代又迭代。蒂姆得了零分。
显然，蒂姆必须离开。这就是经理的结论，他要求我做出必要的安排，把蒂姆调走，换上一个真正能讲故事的人。
我断然拒绝了。对我来说，这甚至不是一个艰难的决定，我只是拒绝了。
你看，蒂姆的工作效率之所以是零分，是因为他从来没有参加过任何故事。相反，他每天都会和不同的队友配对。对于经验较少的开发人员，他会耐心地让他们开动脑筋，同时引导他们找到解决方案。他不会挤兑他们，也不会训斥他们，而是让他们花时间学习，同时精心设计洞察和学习的时机，通常是苏格拉底式的问题、"如果"、"怎么办"。
与前辈们在一起更像是共同创造或切磋；将不同的世界观应用到问题中，创造出比我们自己想出来的更好的东西。蒂姆是个了不起的程序员，和他在一起总能学到一些东西。
蒂姆交付的不是软件，而是一个能够交付软件的团队。因为蒂姆的加入，整个团队变得更有效率、更有生产力、更团结、更习惯化、更有趣。
我向经理解释了这一切，并邀请他不时来观察我们的工作。每当他路过时，都会看到蒂姆和另一个人坐在一起，做着 "他们 "的事情，可以肯定的是，这件事情的质量会比蒂姆不和别人配对时好很多，价值实现的时间也会大大缩短--是的，你可以做得更好、更快、更便宜，只是需要遵守纪律。
最终，我们留住了蒂姆，并悄悄放弃了个人生产力指标，转而采用团队问责制，我们跟踪并庆祝我们作为一个高绩效团队为组织带来的业务影响。
总结
通过各种方式衡量生产率--我支持问责制--最好是以节省、产生或保护的美元来表示有形的业务影响。这通常很难做到，所以代用业务指标也可以。
只是不要试图衡量一个单位在复杂适应系统中的个人贡献，因为这个问题的前提是有缺陷的。
例如，DORA 指标是关于工作系统如何运作的，无论是作为韦斯特鲁姆文化指标，还是作为生产中的技术变革流程。它们衡量的是引擎，而不是单个活塞的贡献，因为这毫无意义。
另外，如果你有机会与蒂姆-麦金农（Tim Mackinnon）共事，一定要去。
网友评论：
1、这让我想起了贝尔实验室的一件轶事。有人计算了谁是最有生产力的员工（根据获得的专利等信息），发现他们中的许多人会和同一个人共进午餐。这个人的工作效率不是很高，但他总是会提出深思熟虑的、令人信服的问题，这反过来又使他的同事们的工作效率大大提高。
2、如今，我是一家有200人（大多数是开发人员）的公司的前端负责人，成为一个力量倍增器的想法是正确的。我在那里不是为了成为最好的开发者或最博学的人;我在那里引导谈话，并放大那些说好话的人。对这项技术有一个相当深入的了解是有用的，这样我就可以告诉那些好东西是什么。我绝对不是来公司炫耀或为我的团队所做的事情邀功的。
3、这就是为什么软件工艺很少被认可的原因。当您以精湛的工艺构建时，可以轻松快速地在构建的基础上添加功能，因为您在合理范围内考虑了当前需求的最可能后果
4、篮球运动中一个常见的问题是人们忘记了它是一项团队运动。如果你的球队很烂，你个人有多好都无关紧要（看看1988年的迈克尔·乔丹或勒布朗职业生涯的大部分时间）。同样，编程是一项团队运动。个人的成功并不等同于团队的成功。