结果【outcome】大于产出【output】

结果大于产出

著者 Martin Fowler

译者 尘世间一个迷途小码农

想象一下一个团队在编写购物网站的技术团队。如果我们在看这个团队的产出的时候，我们或许会考虑上个季度产出了多少个功能，或者一个跨功能模块的度量（如页面加载时间）。然而，一个对于结果的度量将应该考虑度量所增加的营收，或者所减少的产品支持电话数量。聚焦于结果而不是产出，将会使得团队倾向于构建那些有助于提升软件用户和客户效率的功能特性。

就好像任何专业活动一样，我们这些从事软件开发的人想要了解是什么使得我们更有效。事实上确实如此，正如一个开发人员尝试改善他的个人表现，或一个希望改进组织内团队的管理人员，或者像我这样试图提高整个行业水平的专家亦是如此。但是，使这变得困难的事情之一是没有明确的方法来度量软件团队的生产力。这个度量问题变得更加复杂的原因取决于我们将有效性测量建立在产出还是结果的基础上。

我总是认为结果应该是我们所关注的。如果一个团队交付了很多功能，不管我们是用代码行数、功能点数还是故事数来度量它，如果这些功能无法帮助用户改进他们的活动，那么这些功能就无关紧要了，许多未使用的特性都是浪费精力。实际上，更糟糕的是它们会使代码库膨胀，从而使将来添加新特性变得愈发困难。这样的软件开发团队需要关注新功能的有用性，这样它们就可以在交付更少但是更实用的功能的这个事情上得到改善（这里指的就是团队的结果【outcome】更高）。

我听到一个关于反对基于结果的观察的论点是，为结果而提出的可重复的度量要比为产出而提的要更困难。我发现这个观点挺难理解。度量软件的“纯”产出是出名的困难，代码行数是一个无用的度量，即使它们不那么容易被用于在产出多少方面进行造假。另外，功能点或者故事点的可复制性是很差的，不同的人会给同样的东西打不同的分数。与此相比，我们非常善于度量财务产出。诚然，考虑到客户满意度的话，许多的观察结果是更加棘手，但是我不认为它们任何一个比软件功能的评估更难。

当然，仅仅称某件事为“结果”并不能让你把注意力集中在正确的事情上，而选择观察正确的结果肯定是有方法技巧的。Seiden提出了一个很有用的观点，他认为结果应该是对组织有益的一些用户、员工或客户行为的改变。他区分了“结果”和“影响”，前者是更容易观察到的行为变化，后者则是对组织有着更广泛的影响。在《发展边缘》一书中，HighSmith、Luu和Robinson建议，基于客户价值的结果应该比基于业务价值的结果应该得到更多的重视（书中举例指一台洗碗机的可靠性要比保修维护成本更应该被重视）。

使用结果观察的一个重要问题是，很难将它们分摊给软件开发团队。考虑一个客户团队，他们使用软件来帮助他们跟踪供应链中的商品质量。如果我们通过最终消费者退回的不良品的多少评估它们的话，有多少是由软件引起的，有多少是由质量分析人员开发的质量控制程序引起的，有多少是由提高原材料质量的行动引起的？如果我们想要比较不同的软件团队，这种（责任）分摊的困难是一个巨大的障碍，也许如果是为了判断使用Clojure是否帮助团队会来得更有效一点。同样的情况是，开发人员工作得很好，并交付了优秀且有价值的软件来跟踪质量，但是质量控制流程并不好。因此，尽管开发人员在他们这方面做得很好，但不良品还是因此没有下降的话，整体项目（包含开发人员的软件交付也作为整体项目的一部分）还是被认为是失败的。

但是，这个分摊的问题不应该被当作观察错误事物的理由。俗话说“you get what you measure”，在这种情况下更应该是“you get what you try to measure”。如果你把成功的评价集中在产出上，那么每个人都在思考如何提高产出。因此，即使很难确定团队的工作如何影响结果，但人们转而考虑结果以及如何改善结果的事实，这个要比在团队中去比较谁在生产产品方面（不考虑结果，即不考虑客户价值的这种产品生产的方向是错误的）更加熟练的这一个方面上的努力来得更加有价值。

原文链接：

https://martinfowler.com/bliki/OutcomeOverOutput.html