Jeff Patton谈结果导向

Jeff Patton在2019年敏捷希腊峰会的闭幕主题演讲中说，我们需要关注结果，调整我们的思维方式和流程，从而不断发布产品和服务的小更改。

Patton表示，我们应该付费学习，而不是仅仅构建“潜在的可交付软件”。他认为，我们必须承认我们经常会失败——我们必须让谦逊成为流程的一部分。然后，我们可以把学习纳入流程：

如果我们不了解客户的问题，那么我们可以研究。如果我们不知道他们真正想要什么，我们可以花时间构建原型，如果我们不知道他们是否会继续使用它，我们可以花时间构建软件，然后发布给有限数量的客户，并观察他们的行为。这些都不会带来投资回报。不过，它们会帮助我们做出更好的决定，决定我们应该大规模地构建什么。

Patton说，“当我们开始可视化结果时，团队的思维模式就会开始关注结果。”

Patton建议多谈结果。他说，即使是使用“项目”这个词也会破坏我们的思考。要记住，我们希望项目结束，但理想情况下，我们希望产品尽可能长时间地存续。他认为，我们所关注的结果只有在我们交付产品并投入使用之后才能被衡量；这就是为什么它被称为“结果”。

在2019年敏捷希腊峰会上演讲结束后，InfoQ采访了产品设计顾问、《用户故事映射》一书的作者Jeff Patton。

InfoQ：21世纪的软件开发实践对软件行业中许多人持有的流程假设提出了怎样的挑战？

Jeff Patton：事实上，我们生活的世界已经变了。我们的流程即工作方式正在适应这种变化。 最好的软件开发流程和实践是对我们的业务需求以及我们构建和销售的产品和服务的响应。想想你每天使用的产品和服务的类型；它们中有多少依赖于数字体验？你的手机，你的手表，你的车，你的流媒体，你玩的游戏。想想银行、购买机票或酒店房间等服务。想想你是如何找到一家新餐馆的，或者是如何点外卖的。现在，想想你每天使用的所有这些数字体验，想想你看到的大版本和大更新的速度。我猜你不会看到很多。相反，你看到的是持续的小变化。 这是新常态。一切都是数字化的——需要软件和技术。我们不再试图在一个发行版中打包尽可能多的内容——相反，我们正在尝试对我们的产品和服务进行持续的小改进。 不管你怎么称呼你遵循的流程，它都不能再根植于20世纪的大设计模式以及接下来的大交付。这种思维方式挑战了企业赖以构建的许多假设。 例如，许多企业投资的技术开发都是使用时间和范围固定的项目，其目标是在固定的时间内获得尽可能多的成果。项目往往是长期的，以季度或年为单位。相比之下，当代以产品为中心的组织为一个产品领域融资数月或数年，却不了解他们将获得的特性。相反，其关注点是可观察到的市场成果——如客户获取和保留。那个产品领域的团队会使用这些资金来持续地改进这个产品领域，关注的还是相同的业务成果。

InfoQ：我们在设计和构建软件时应该怎么做？

Jeff Patton：许多敏捷流程中缺失的价值观是谦逊；承认我们不完美，承认我们经常会失败。 我们无法预测在一次冲刺或一次发布中能完成多少工作。但是，更常见的情况是，我们无法预测客户是否会喜欢和使用我们的产品，以及是否有足够多的客户，让我们可以真正获得投资回报。如果这很简单的话，所有的创业者都会成为亿万富翁。 一旦我们把谦逊纳入流程，我们就可以在流程中建立起学习文化。我们需要比十年前更快地学习这些东西，因为请记住，当今世界发展得更快。这就是为什么像精益创业、设计、思考、精益用户体验和设计冲刺这样的过程方法蓬勃发展的原因。它们是“付费学习流程”。将这些流程与更传统的敏捷方法相结合，就形成了所谓的双轨开发；一个同时包含持续学习轨道和大规模构建轨道的流程。

InfoQ：成功的项目注重结果，而不是产出。我们如何调整我们的心态和做法，以推动结果导向？

Jeff Patton： 更多地谈论结果。这是项目思维方式和语言的问题。 我们用时间、成本和范围定义项目。在像Scrum这样的敏捷过程中，我们关注的是同样的事情。我们定了为期两周的冲刺。我们通过调整团队规模来降低成本。因为Scrum可能有点残酷，我们强迫团队自己确定范围——承诺在冲刺结束时能完成什么。在冲刺审查中，我们会检查我们所做的事情的质量——但是我们不会通常也无法谈论结果，因为通常在发布几周或几个月之后我们才能了解结果。和项目思维一样，Scrum也促使团队关注时间、成本和范围。 我试图通过提醒人们这些现实来改变他们的思维方式。我会问团队，“我们如何衡量成功的结果？”遗憾的是，这样做的结果是更多的工作——尤其是监测产品，以便知道人们是否真的使用它们，以及使用了哪些功能。 我还会要求团队构建一个简单的可视化。左右轴是实际的工作；上下轴是实际的结果。对于他们提供的每个特性或功能，都放到这个简单的图表中。当将特性放到工作轴上时，我会要求他们把花费时间比预期长的标记出来。他们很快就会知道，大事耗费的时间往往比预期的长。对于实际结果，我将要求他们使用不同的桶。第一个是“不知道”——什么都是从这个状态开始的，因为直到产品上市，用户开始使用它们，我们才知道。但除此之外，还有从“糟糕”到“棒极了”。团队开始了解需要多长时间才能看到结果。从“不知道”到“糟糕”到“棒极了”可能需要几周的时间。而且，他们也会开始发现很少有事情会以“棒极了”结束。最后，我们正在建设的项目的规模与结果几乎没有关系。通常，我们构建的最小的东西会取得最大的成果。

原文链接：

Becoming Outcome Focused: Q&A with Jeff Patton