如何在Scrum框架中真正实现价值最大化？

Scrum框架的存在是为了更快地为利益相关者创造价值。这听起来不错，对吧？但什么时候才算是“有价值”呢？对于这样一个在Scrum中如此核心的概念，实际上却很少有关于“价值”的明确指导。我们担心，如果没有一个有意义的定义，这个词可能只是空谈。

在本文中，我们提供了一种更细致的方式来理解“价值”对于你的产品以及产品待办事项（Product Backlog）来说意味着什么，并以此为基础与团队及其利益相关者展开讨论。

本文是我们最受欢迎的文章之一的重写版。新版文章中加入了许多新的见解和观点，我们也在某些地方改变了原来的看法。你还可以下载完整尺寸的海报（PDF），或者获取一个完全准备好的自助工作坊（PDF），以便与团队和利益相关者一起使用这一模型。

如何在Scrum中最大化价值

在Scrum框架中，Scrum团队的重要目标是尽可能频繁地交付有价值的增量成果（Increment）——至少每次冲刺（Sprint）都要交付一次。每个增量都让团队和利益相关者距离一个有价值的产品目标更近一步。如果做不到这一点，就很难了解还需要什么，并且难以降低复杂工作的风险。产品负责人（Product Owner）负责最大化开发人员所做工作的价值。虽然这听起来很棒，但在现实世界中，这究竟意味着什么呢？

你如何确定你的Scrum团队交付了有价值的东西？你需要观察或看到什么样的现象？你的团队交付的所有工作是否应该立即对利益相关者有价值？或者可以有一些延迟？在行为和决策方面，“最大化价值”意味着什么？产品目标如何指导什么是有价值的？Scrum团队如何决定产品待办事项中哪些条目比其他条目更有价值？他们基于什么做出这些决定？在决定什么是“价值”时，你从谁的角度出发？

这些问题很难回答。《Scrum指南》巧妙地避免了对“价值”下定义，并认为它取决于工作所针对的背景和利益相关者。但如果Scrum团队缺乏一个有效的价值定义，他们如何才能高效工作呢？我们可以很容易地想象一个Scrum团队，他们完美地完成每次冲刺，并且每次都向利益相关者交付高质量的增量成果，但实际上并没有交付任何有价值的东西。事实上，我们经常在“僵尸Scrum”案例中看到这种情况；虽然每个人都在按部就班地工作，但最终却没有产生任何价值。这说明仅仅“做Scrum”并不会自动带来价值。

两种视角理解价值

价值与利益相关者

每当Scrum框架提到“价值”时，它指的是Scrum团队与利益相关者之间的交易。换句话说，只有当某件东西被交付并经过利益相关者验证时，它才是有价值的——在此之前，任何价值都是假设性的。

正如我们在另一篇文章中提到的，利益相关者是那些在产品中实际拥有利益的人，而不是那些仅仅传达或代理他们，自己并不具备的需求的人。当Scrum团队交付的工作有价值时，这些利益相关者会获得收益，而当团队没有交付有价值的工作时，他们会蒙受损失。因此，虽然那些积极使用你的产品或投资其开发的人可能是你的利益相关者，但你在营销部门的同事可能并不是。虽然你的同事可能对你的产品或如何营销它有有用的意见，但他（她）可能既不使用它，也没有投资其开发。

这给了我们一个重要的见解：我们需要从实际利益相关者（而不是代理人）与Scrum团队之间的交易角度来看待价值。这也凸显了Scrum团队在大组织中常常面临的一个挑战。实际的利益相关者通常被隐藏在组织的层级之下，价值问题往往被完全忽略，因此重点转向完成尽可能多的工作，而不考虑这些工作的价值。

价值与持续性

这种关于利益相关者与Scrum团队之间交易的视角也引起了人们对未来交易可持续性的关注。毕竟，如果一个Scrum团队免费提供所有工作，他们或他们的产品不会持续太久。同样，预算可能也不允许团队满足利益相关者的所有潜在需求。这显然是更关注那些在产品开发中投资的利益相关者（如投资者或支付Scrum团队工资的组织）的问题，而不是那些主要使用产品的利益相关者。但最终，这两个群体都受益于可持续发展。

这种长期性和可持续性就是为什么“商业价值”可能比单纯的“价值”更准确，尽管《Scrum指南》只谈到了后者。商业价值的一个常见定义是：“商业价值是所有那些长期决定公司健康和福祉的价值形式。”

这种关于长期性的视角也解释了为什么2020年版的《Scrum指南》正式确立了一个单一的产品目标，以在多个冲刺中为开发工作带来焦点。当然，也存在一个可能性是，利益相关者的需求远远超出团队的承受能力，而产品目标则为团队提供了一个基准，帮助他们决定哪些是有价值的，哪些则不是（至少现在不是）。某个利益相关者的需求可能非常有用，但如果它不符合产品目标，那么它就不值得花时间，应该把时间花在更有价值的事项上。

五种价值类型

理解利益相关方与产品长远发展的背景后，我们对多个Scrum团队开发的商业产品的产品待办列表进行了分析。我们将其中的项目按价值类型进行了分类，最终归纳出了五种主要的价值类型。以下是这些价值类型的详细讨论（顺序不分先后）。

注： 因为我们的经验主要集中在商业组织，因此大多数示例也是来自此类组织。这些价值类型并不一定适用于非商业组织，特别是“商业价值”这一类。然而，即便是非商业组织，也可以从经济角度审视待办项。

商业价值

商业价值是最直接的价值类型，涵盖了所有能够为开发产品的组织直接带来收入的产品待办项。如果所有其他条件保持不变，这项工作会带来净利润。

例如，当某项产品待办完成后，客户会为其支付费用。这可能是你产品的新版本、新功能或可解锁的附加内容。也可能是新的付费下载内容、网上商城中的新产品，或者是客户直接付费的其他内容。虽然交付和付款之间可能有一些环节，但我们倾向于将这些项目视为发票中会出现在客户账单上的项目。

**关键问题**：在产品目标的框架下，这个待办项如何增加我们的收入或利润？如果答案非常明确，那么这项工作就具有明显的商业价值。如果很难回答这个问题，你可能在处理其他类型的价值（见下文），或者这个待办项可能根本没有价值，需要将其移除。

效率价值

并非产品待办列表中的所有项都会直接带来收入。但是，它们可以通过降低生产、维护和交付的成本直接影响利润。这些项目代表了简化、自动化、减少或优化产品开发过程中其他工作的工作项，使其他工作更高效。从经济学的角度来看，这些项目提高了成本效率，通过花费更少的钱来提供相同的价值，或者如果你不是商业企业，这意味着节省了时间。这就是效率价值。

例如，如果代码库的某项更改让你能够使用更少的服务器运行相同的产品，你就是在创造效率价值。这还包括自动化或简化开发、操作或交付产品所需的繁琐重复任务。我们曾帮助开发的某个产品的产品待办列表中包含了减少在客户现场安装产品所需时间的任务。虽然这项工作本身不直接产生收入，但确实为我们（以及客户）节省了资金。

更间接地说，某些项目可以减少其他地方的工作，从而降低成本。例如，当某个项目提高了应用程序的稳定性，从而减少了每周的大量热线电话，这也是一种效率价值。

**关键问题**：在产品目标的框架下，这个待办项如何为我们节省金钱或时间？如果这个问题没有得到明确的回答，你可能在处理其他类型的价值，或者这个待办项根本没有价值，需要将其移除。

市场价值

一个产品的成功与否很大程度上取决于潜在用户和客户对它的认知程度。通常，产品开发涉及大量工作来提升这种认知度、进入新市场或区分与竞争产品的差异。这类工作代表了市场价值。

市场活动是这类工作的一个很好的例子。例如，这可能是一个简单推广你产品的网站搭建和文案撰写，或者是在LinkedIn上启动的市场营销活动。即使是写博客文章、录制播客或视频，从这个角度来看，也可以算作市场价值——只要它主要是为了提高你产品的知名度。

从软件开发的角度来看，这可能是将应用程序移植到其他平台（例如从iOS到Android，或从Steam到Xbox Live），或者添加吸引新客户群体的功能。

**关键问题**：在产品目标的框架下，这个待办项如何帮助我们吸引更多用户或客户？如果很难说明这一项是如何吸引新用户的，你可能在处理其他类型的价值。

客户价值

即使你的产品已经开始产生收入，具备了高成本效益，并为用户所知，如果客户不愿意继续使用或有机会时会立即转向竞争对手，你的产品依然难以取得成功。因此，提升客户对产品的粘性是有价值的工作，这就是客户价值。

用户体验优化就是这类工作的一个很好的例子。当你让产品更易用、减少错误、更符合用户需求时，就是在提升客户价值。它还包括那些客户不直接付费（即商业价值）但却常常要求的功能，从而让他们继续使用你的产品。

关键问题:在产品目标的框架下，这个待办项如何增加客户继续使用我们产品的可能性？如果你无法明确回答这个问题，你可能在处理其他类型的价值。

未来价值

最后，不可避免的是，产品开发中会有一些工作在完成时并没有明确的价值，但如果不做，可能会在未来（不久）带来巨大问题或重大成本，这就是未来价值。

研究和创新属于这一类别。例如，有时你需要研究当前技术栈面临的问题的替代技术解决方案，或者你想改进团队的实践和流程，这需要一些学习时间。

减少技术债务似乎也是这一类别的一个例子。技术债务是指在过去可能在紧要关头采取的捷径和权宜之计——这些方法在当时可能效果很好，但现在却带来了问题。例如，在代码的某些重要部分中，自动化测试可能缺失；或者文档没有更新；或者代码块变得如此复杂，开发者们都不敢去碰，怕一动就会像积木塔一样倒塌。

关键问题：在产品目标的框架下，这个待办项如何为我们在未来节省金钱或时间？如果你无法明确回答这个问题，你可能在处理其他类型的价值。一个好的产品待办列表中，这类待办项应该少而精，不宜过多。

关于合规性问题

当我们首次分享这个分类时，最常见的问题之一是如何处理现有法规、协议和认证的合规性。是否应该像一些人建议的那样，单独列出“合规性价值”？

对此我们当时感到困惑，现在依然如此。我们的担忧在于，合规性本身并没有实际的价值，它更像是一种手段，最终目的是带来价值。例如，当客户要求合规某个协议并为此付费时，这显然属于商业价值。如果客户没有付费但仍然需要合规以留住他们，这就是客户价值或市场价值。如果合规涉及到安全性或加强措施，是为了防止潜在的安全漏洞造成的损害，那么这属于未来价值。

我们见过太多为了合规而合规的例子，导致了显著的成本增加、效率降低，且更难发布新版本。在一些案例中这样做是有道理的，但在其他情况下则没有。因此，为了避免这种情况，我们鼓励你深入探讨合规性背后的原因，弄清楚为什么这种合规性是有价值的。

此外，我们认为合规性更适合作为完成定义（Definition of Done）的一部分。除非你在谈论具体的功能或特性，否则大多数合规性通常由质量指南组成。而完成定义正是为此而设的，不是吗？

开始讨论价值

我们提出的这个分类显然不是完美的。这些价值类型在多个方面存在重叠，有些待办项可能不完全属于任何一种类型——但它们仍然有价值。

但这并不是重点。重点是你应该和团队以及利益相关方讨论每个产品待办项的价值所在。对于那些你可以轻松归类到一个或多个价值类型的待办项，可能是值得保留的。如果无法归类，你的团队，尤其是产品负责人，就需要有一个非常充分的理由来解释为什么这个待办项仍在产品待办列表中。

“毕竟，如果产品负责人保留那些看似没有价值的待办项，又如何最大化Scrum团队工作的价值呢？”

我们希望这篇文章能激发你与利益相关方一起讨论价值，并做出有目的的决策，决定哪些应该保留在产品待办列表中，哪些应该被舍弃。