结果胜于产出

想象一个团队为一个购物网站编写软件。如果我们查看团队的产出，我们可能会考虑他们在上个季度产生了多少新功能，或者一个跨职能的指标，比如页面加载时间的减少。然而，结果指标会考虑衡量销售收入的增加，或者产品支持电话数量的减少。专注于结果而不是产出，有利于构建更多功能来提高软件用户和客户的有效性。

与任何专业活动一样，我们这些参与软件开发的人想要了解是什么让我们更有效率。这对试图提高自身表现的个人开发者来说是正确的，对试图提高组织内团队的经理来说也是正确的，对像我这样的专家试图提高整个行业的水平来说也是正确的。使这变得困难的一点是，没有明确的方法来衡量软件团队的生产力。而这个衡量问题会进一步复杂化，取决于我们是基于产出还是结果来衡量有效性。

我一直认为我们应该专注于结果。如果一个团队交付了很多功能——无论我们用代码行、功能点还是故事来衡量——这些功能如果不能帮助用户改进他们的活动，就没有意义。很多未使用的功能都是浪费的精力，实际上比这更糟糕，它们会膨胀代码库，使将来添加新功能变得更加困难。这样的软件开发团队需要关心新功能的实用性，他们通过交付更少但更有用的功能来提高效率。

我听到过一个反对使用基于结果的观察的论点，即为结果想出可重复的度量比为产出想出可重复的度量更难。我发现这个观点难以理解。众所周知，衡量软件的纯粹产出非常困难。代码行是一个无用的度量，即使它们没有那么容易被操纵。功能点或故事点缺乏良好的可重复性——不同的人会对相同的事物给出不同的分数。相比之下，我们非常擅长衡量财务结果。当然，许多结果观察更难进行——比如客户满意度——但我认为它们并不比软件功能更难。

当然，仅仅称某事为“结果”，并不能使它成为应该关注的正确事物，并且选择正确的结果进行观察确实需要技巧。一个方便的概念是Seiden，他认为结果应该是用户、员工或客户行为的变化，这种变化会为组织带来好事。他区分了“结果”，即更容易观察的行为变化，和“影响”，即对组织的更广泛影响。在开发EDGE时，Highsmith、Luu和Robinson建议，关于客户价值（洗碗机的可靠性）的结果应该比关于商业价值（保修维修成本）的结果更重要。

关于使用结果观察的一个重要问题是，更难将它们分配给软件开发团队。考虑一个客户团队，他们使用软件来帮助他们跟踪供应链中商品的质量。如果我们根据最终消费者有多少次拒收来评估他们，其中有多少是由于软件造成的，有多少是由于质量分析师制定的质量控制程序造成的，以及有多少是由于一项单独的提高原材料质量的计划造成的？这种分配的困难是一个巨大的障碍，如果我们想比较不同的软件团队，也许是为了判断使用Clojure是否帮助团队更有效率。同样，开发人员工作出色，交付了优秀且有价值的软件来跟踪质量，但质量控制程序却不好。因此，拒收率没有下降，该计划被视为失败，尽管开发人员在他们方面做得很好。

但是，分配问题不应该被视为观察错误事物的理由。常见的短语说“你得到你所衡量的”，在这种情况下，更像是“你得到你试图衡量的”。如果你将成功评估的重点放在产出上，那么每个人都在考虑如何提高产出。因此，即使很难确定团队的工作如何影响结果，但人们反而在思考结果以及如何改进它们，这比任何努力去比较团队在生产错误事物方面的熟练程度都更有价值。