衡量程序员生产力的美妙之处在于，你很快就能识别出差劲的程序员。
今天我想讲讲我认识的最差程序员，以及我为何力排众议将他留在团队。
几年前我曾在推上发过一个关于"我认识的最佳程序员"的帖子，现在讲讲最差的似乎才算公平。他叫 Tim Mackinnon，我要让你看看他的效率数据有多糟糕。
当时我们在一家知名软件咨询公司工作，客户是某大银行。
他们决定引入个人绩效指标（美其名曰“用于评估和个人发展”）。
这个政策层层传达，最终落实到我们团队时变成了“交付的用户故事数量”。
部门经理还算明智，没有选择代码行数或 bug 数量，比较这类指标太容易造假了。
注：User Story（用户故事），这是敏捷开发的核心概念之一，用于以简洁、用户友好的方式描述软件需求。
用户故事通常以第一人称视角撰写，
例如：
"作为一个用户，我希望能够在线预订酒店，以便快速安排行程。
"
它强调功能的价值和用户视角，而非技术细节。
我们改用 Jira 之类的工具追踪用户故事，大家在任务上标注自己的名字，这样就很容易生成效率报表了。
问题就出在 Tim 身上。他的得分始终为零！不是低，不是下滑，是真真切切的零分。周复一周，迭代复迭代，Tim 的得分始终是零。
经理：开除他，换个能做事的人
显然 Tim 必须走人。经理得出这个结论后，让我立马解雇他，换个真正能做事的人。
但我断然拒绝了。这对我来说甚至不是个艰难的决定，我直接说不。
Tim 效率为零的原因在于，他从不认领任何任务。他的日常就是和不同的队友结对编程：
Tim 没有直接交付软件，但他培养了能交付软件的团队。因为有 Tim 在，整个团队变得更高效、更默契、更有乐趣，代码质量也显著提升。
我向经理解释了这一切，并邀请他随时来观察我们的工作。每次他来，都会看到 Tim 和不同的同事坐在一起，共同打磨“他们的”任务。而这些任务的质量和交付速度（没错，高质量和高速度可以兼得），总是比 Tim 不参与时要好得多。
最终我们留下了 Tim ，悄悄放弃了个人效率指标，转而追踪团队整体的业务影响。我们开始追踪并庆祝作为高效团队为组织创造的实际价值。
简而言之：
-
我完全支持问责制，可以衡量效率，但应聚焦于可量化的业务影响（节省/创造/保护的资金）
-
如果难以直接衡量，使用业务替代指标也可以
-
但绝不要试图在复杂适应系统中衡量个体贡献，因为这种做法本身就有逻辑错误
-
像 DORA 指标这样的体系，衡量的是工作系统的效能（如 Westrum 文化指标或技术变更的生产流程），关注的是引擎而非单个活塞，这才是合理的
另外，如果你有机会和 Tim 共事，一定要珍惜。
网友留言
上面这个故事在 Hacker News 上引发了热议。
伯小乐摘译部分热评：
morsecodist：
对我来说，衡量开发者个人生产力的想法本身就很荒谬。这倒不是说我们在搞魔法，而是影响因素实在太多了。
采用用户故事或代码行数来衡量生产力，其实是在鼓励开发者做尽可能多的无意义工作。我更希望开发者能简化任务或复用现有工具，这样反而减少了实际编码时间。他们通过经验节省下来的工作量价值极高，但却很难量化。
我们真正需要的是衡量业务成果，但这些成果很难直接归功于某个开发者。
很遗憾，我们最终只能依赖主观判断。与其假装我们有某种科学依据，不如坦然承认这个事实会更好。
JohnMakin：
我曾被类似问题困扰，直到我发现了 Tim 和本文作者显然没意识到的简单解决办法——管理层只需把 Tim 参与过的任何工单都附上他的名字即可。他可以让队友这么做（队友们会很乐意），或者好心的同事通常会在工单里注明“在@Tim 的帮助下解决”。这种方法能有效帮助团队保留像 Tim 这样的成员，抵御这类僵化的进度指标。
生产力指标并非一无是处。比如，当我加入一个团队时，如果发现他们平均每个 Jira 工单对应 1 个 PR，而一个三人团队中某位成员一年提交了 70%的 PR，这并非毫无意义的信息——他很可能是技术负责人。虽然不绝对，且可能存在数据操控，但这至少是个值得注意的参考点。
NalNezumi：
很高兴听到 Tim 留了下来，作者也成功将整个评估体系引向了正确方向——这需要一位愿意倾听的管理者。
我曾经历过这种生产力指标层层传导的"悲剧结局"：OKR。那家初创公司不仅要求团队制定季度 OKR（目标与关键成果），还要求个人 OKR，并将股票期权与之绑定。这是一家机器人公司，拥有高度跨领域的团队（软件、硬件、嵌入式、DevOps、硬件设计、硬件测试、硬件维护等等）。
结果如何？开发者们变成了一座座孤岛。团队里再没有" Tim "这样的人。当我（软件集成工程师）遇到一个百思不得其解但直觉是深层问题的技术故障时，去向控制/运动学专家求助，得到的回答却是："抱歉，我很想帮你，但我的 OKR 截止日期快到了，实在没时间。" 这个问题他本可以在一天内甚至更短时间解决，但最终耗费了两周。
问题的根源异常复杂：在层层嵌套的 C++大型单体仓库中，我发现 Boost 库和自定义运动学库存在隐式结构体复制，而多个库（不止两个）使用了完全不同的平移/旋转表示顺序（xyz、rpy、欧拉角、四元数），且每个分量的排列方式都不一样。令人匪夷所思的是，在两年多的运营中从未有人发现这个问题，直到我们新团队接手时才暴露出来。
据我所知，我向软件团队报告了这个问题，但同样因为 OKR 的存在，最终无人采取行动。
crazygringo：
这种让一个程序员完全不做个人工作、只负责帮助他人的模式很奇怪。
在我看来，更健康的状态应该是：Tim 像其他人一样处理用户故事，当有人需要帮助时，团队成员根据专长或贡献频率互相支援。对于最需要帮助的同事，可以分配更简单的任务，而 Tim 应该独自承担最困难的用户故事。如果团队真的极端失衡（比如全员都是刚毕业的新手，只有一个超级资深开发者），那这位资深开发者难道不应该被明确为专职导师，不参与普通绩效评估吗？
原文的例子并不能说明 "指标无法衡量工作价值"，反而暴露了两个关键问题：要么是 Tim 的职位与指标完全不匹配，要么是 Tim 未能贡献最难的代码，且团队没有合理分配 "帮助" 的工作量。在这两种情况下，指标都在正常发挥作用，揭示了需要解决的重要问题（记住，"解雇 Tim " 不是面对指标结果时唯一的选择）。
最后
如果本文主角 Tim 是在国内大厂任职，他能留下来的概率有多大？
![]()
你们身边有这种程序员么？
- EOF -
