衡量开发者的生产力的一大优势在于可以迅速识别出糟糕的程序员。我想向你介绍我所知道的最糟糕的程序员，并解释为什么我努力保留他在团队中。 几年前，我在Twitter/X上写了一篇关于我认识的最优秀程序员的帖子，我应该将其整理成一篇博客文章。公平起见，我觉得也应该告诉你关于最糟糕的程序员。他叫Tim Mackinnon，我想让你知道他的生产力是可以明显量化的。 当时，我们为一家著名的软件咨询公司在一家大型银行工作。该银行决定引入个体绩效指标，以进行“评估和个人发展目的”。这个决定在整个组织中推广开来，最终在我们的团队中以交付的故事点数的形式体现。在部门经理经过一番深思熟虑的讨论后，这一决定被定为衡量标准，因为他知道不应该衡量诸如代码行数或发现的错误之类的事物，因为人们很容易通过各种手段来操纵这些指标。
相反，我们将衡量的重点放在交付的故事或故事点数上（实际上这并不重要），因为这些代表了业务价值。我们使用类似Jira的工具，人们会在故事旁边标上自己的名字，这使得生成这些生产力指标变得非常容易。
这就引出了Tim的情况。Tim的得分一直是零。零！不是低分，也不是趋向下降，而是真的零。周复一周，迭代复一迭代，Tim的得分一直是零。
显然，Tim必须离开。这是经理的结论，他让我采取必要的措施，让Tim离开，并由一个真正能交付故事的人取代他。
而我果断的拒绝了。这对我来说甚至不是一个难以做出的决定，我直接说不。
你知道，Tim的生产力得分为零的原因是，他从不报名参与任何故事。相反，他会花一整天的时间与不同的团队成员搭档。与经验较少的开发人员一起，他会耐心地指导他们，同时引导他们朝着解决方案的方向思考。他不会挤占他们的空间，也不会强行推动，而是让他们花时间学习，同时巧妙地制造洞察和学习的时刻，通常是通过苏格拉底式的问题、假设、以及其他方式。
与资深开发人员一起，更像是共同创造或切磋；将不同的世界观应用于问题，以产生比我们任何一个人都能想到的更好的东西。Tim是一个了不起的程序员，与他搭档总是能学到一些东西。
Tim不是在交付软件；Tim正在交付一个团队，而这个团队正在交付软件。整个团队变得更加高效、更有生产力、更加协调、更具特色、更有趣，因为Tim在团队中。
我向经理解释了所有这些，并邀请他不时过来观察我们的工作。每当他经过时，他会看到Tim与不同的人一起工作，致力于“他们的”事情，而且你可以肯定，那件事的质量会显著提高，价值产出的时间会显著降低——是的，你可以在质量更好、更快、更便宜的同时完成——而在Tim不与人合作时，情况会截然不同。
最终，我们保留了Tim，并悄悄地放弃了个体生产力指标，转而采用团队问责制，我们追踪并庆祝作为一个高效团队为组织带来的业务影响。
尽管我完全赞成追求问责制，最好以在节省、创造或保护有形业务影响为指标。这通常很难，所以用替代性的业务指标也是可以的。
只是不要试图测量复杂自适应系统中单位的个体贡献，因为这个问题的前提是错误的。
比如，DORA指标关注的是工作系统的运作方式，无论是Westrum文化指标还是技术变化流向生产的情况。它们测量的是引擎，而不是个体活塞的贡献，因为那是没有意义的。
而且，如果你有机会与Tim Mackinnon一起工作，你应该抓住这个机会。
