衡量开发者生产力最棒的一点是，你能快速识别出差劲的程序员。今天我要和你讲讲我所认识的最差程序员，以及为什么我拼了命也要把他留在团队中。

几年前，我在 Twitter/X 上写过一篇关于我认识的最好程序员的帖子（也许我该把那写成一篇博客文章）。既然提到了最好的程序员，现在再说说最差的，也算公平。他的名字叫蒂姆·麦金农（Tim Mackinnon），我想让你知道他的生产力指标到底有多差。

当时我们在一家著名的软件咨询公司，为一家大型银行工作。这家银行决定引入个人绩效指标，美其名曰“用于绩效评估和个人发展”。经过管理层慎重讨论，他们知道不能简单地用代码行数或发现bug数量来衡量，因为这些指标太容易被投机取巧。

我们选择的衡量方式是统计每个人交付的用户故事数量（或者故事点数，具体已经记不清了，也不重要），因为它们代表了业务价值。当时用类似 Jira 的工具，每个开发者都会在自己的故事上签名，这让生成生产力指标变得极其方便。

接下来我们说说蒂姆。蒂姆的分数始终是零。没错，就是零！不是分数低，也不是下降趋势，而是彻彻底底的零分。每周都是这样，每个迭代都是这样，零分。

很明显，蒂姆必须走人了。经理迅速得出这个结论，并且让我去安排开除蒂姆，换一个真正能交付故事的人。

而我明确拒绝了这个要求。这甚至不是个艰难的决定，我只是很坚定地说了“不”。

原因很简单，蒂姆的生产力分数为零，是因为他从来没签过任何一个故事。他每天都在做另一件事：与不同的队友进行结对编程。

跟经验少的程序员搭档时，他会耐心地让他们主导，并通过启发式的方式引导他们找到解决方案。他不会强行灌输自己的想法，而是巧妙地通过苏格拉底式的提问，比如“如果这样做会怎样？”“还能怎样做得更好？”等等，引导他们逐渐获得洞察并真正学到东西。

与资深开发者搭档时，则更像是一场思想的碰撞、共同创造——每个人带着不同的视角来看待问题，最终得出比单独工作更优秀的方案。蒂姆本身就是个厉害的程序员，每次和他结对，你都会学到新东西。

其实，蒂姆交付的并不是软件，他交付的是一支能够持续交付高质量软件的团队。正因为有他存在，整个团队变得更加高效、更有生产力、更统一、更专业，也更有趣。

我向经理解释了这一切，并邀请他偶尔过来亲眼看看我们的工作。当经理来到我们团队时，总能看到蒂姆和不同的人坐在一起，专注于其他人的任务。你可以确信，只要蒂姆参与了，这个任务的质量就会显著提升，交付的周期明显缩短——是的，只要有足够的纪律，你完全能做到质量更高、速度更快且成本更低。

最终，我们把蒂姆留了下来。同时，我们悄悄放弃了个人生产力指标，改用团队责任制，关注并庆祝团队作为整体带给组织的业务成果。

总结一下（tl;dr）：

你当然可以衡量生产力，我完全支持对工作成果负责的态度。最理想的方式是直接衡量以美元为单位的业务影响，比如创造了多少价值、节省了多少成本、保护了多少收益。但这通常不容易做到，因此用一些间接的业务指标也是可以的。

但是，千万别试图在一个复杂的、适应性的系统里衡量个体的贡献，因为这个问题的前提本身就是错的。

例如，DORA 指标的核心在于衡量工作系统本身，比如组织文化或技术变更流入生产的效率。它衡量的是整个引擎，而不是单独的某个活塞，因为单独评估毫无意义。

最后提醒一下，如果你有机会和蒂姆·麦金农一起共事，一定不要错过。