敏捷团队的5种价值类型定义

前言

Scrum框架的存在是为了尽快向利益相关者交付价值。听起来不错，对吧？但什么是“有价值的”？对于Scrum似乎如此核心的东西，却很少有关于“价值”含义的指导。我们担心，如果没有对其进行有意义的定义，它将仅仅是一个词而已。

在这篇文章中，我们提供了一个更细致的方法来理解“价值”对于你的产品和产品待办事项的意义。

在Scrum中最大化价值

在Scrum框架中，对于Scrum团队尽可能频繁地交付有价值的增量是很重要的——至少每个冲刺一次。每个增量都使团队及其利益相关者离有价值的产品目标更近一步。没有这一点，就很难了解还需要什么，以及降低复杂工作的风险。产品负责人负责最大化开发人员完成的工作的价值。

虽然这听起来是个好主意，但在现实世界中这到底意味着什么呢？

你如何确切地说出你的Scrum团队交付了价值？你需要观察或看到发生了什么？

你的团队交付的所有工作是否都应立即对利益相关者有价值？或者可以有一些延迟吗？

“最大化价值”在Scrum团队做出的行为和决策方面意味着什么？

产品目标如何指导什么是有价值的？

Scrum团队如何决定产品待办事项中哪些项目比其他项目更有价值？他们基于什么做出这些决定？

在决定什么具有“价值”时，你采取的是哪个角度？

这些问题很难回答。Scrum指南巧妙地避免了对“价值”进行定义，并认为它取决于为其完成工作的上下文和利益相关者。但是，当一个Scrum团队缺乏对价值的工作定义时，它如何能够有效呢？我们很容易想象到一个Scrum团队通过完美地完成他们的冲刺，每个冲刺向利益相关者交付高质量的增量，但实际上却没有交付任何有价值的东西。

事实上，在僵尸Scrum的情况下，我们经常看到这种情况；尽管每个人都在按部就班地工作，但最终却没有任何有价值的东西。仅仅“做Scrum”并不能神奇地产生价值。

让我们从两个角度来理解价值：价值与利益相关者。

每当Scrum框架谈到“价值”时，它指的是Scrum团队与其利益相关者之间的交易。换句话说，只有当交付并得到利益相关者的验证时，某物才有价值——在此之前，任何价值都是纯粹假设的。

利益相关者是对产品有实际利益的人——而不是仅仅转达或代理他们个人没有的需求的人。当Scrum团队交付的工作对利益相关者有价值时，他们将获益；当团队没有交付有价值的工作时，他们将损失。

因此，尽管积极使用你的产品或用他们的资金投资于其发展的人可能是你的利益相关者，但你的市场部门同事可能不是。虽然你的同事可能对你的产品或如何营销它有有用的意见，但他或她可能并不使用它，也没有投资于其发展。

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

价值与长期性

通过利益相关者和Scrum团队之间的交易的这种视角也引起了对未来交易的可持续性的关注。毕竟，如果一个Scrum团队把所有工作都免费提供，他们或他们的产品将不会长久存在。

同样，预算可能不允许团队满足利益相关者的任何潜在需求。这显然更多地关系到投资于产品开发的利益相关者（例如投资者或支付Scrum团队工资的组织）而不是主要使用它的人。但最终，这两个群体都会从可持续发展中受益。

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

这种长期性的视角也解释了为什么2020年的Scrum指南正式规定了一个单一的产品目标，以便在大量冲刺的开发中集中注意力。很可能会有比可以或应该解决的更多需求，产品目标为团队提供了一个基准，以便根据什么是有价值的和什么不是（至少目前不是）做出决策。

一个特定的利益相关者需求可能非常有用，但如果它与产品目标不符，那么它就不足以花时间处理，而这些时间本可以用在更有价值的项目上。

现在所有这些考虑仍然是抽象的。当我们开始详细设置产品待办事项并确定每个项目的商业价值时，这将无济于事。你如何确定产品待办事项中的某些项目是“正确的东西”还是“错误的东西”呢？

五种价值类型

考虑到这一点（利益相关者和长期性），我们继续分析了我们与Scrum团队开发的（商业）产品的产品待办事项。我们将这些项目分类为不同类型的价值，并最终得出了五种似乎相当好地描述大多数情况的类型。我们将在下面无特定顺序地讨论这些。

注：由于我们的个人经验主要与商业组织有关，我们的大多数示例也来自这方面。并非所有类型对非商业组织同样相关，尤其是“商业价值”。但即使对于非商业组织，从经济角度看项目仍然是有意义的。

1.商业价值

商业价值是最直接的价值类型，包括产品待办事项中直接为开发产品的组织带来收入的所有项目。在其他所有条件相同的情况下，这项工作将产生净利润。

例如，当一个项目交付后，客户支付以获取它时，这个项目就产生了商业价值。这可能是你产品的新版本、一个新功能或可解锁的附加组件。

也可能是一段新的付费可下载内容、网店中的新产品，或者其他客户直接支付的项目。尽管交付和付款之间可能存在一些层次，但我们喜欢将这些项目看作是发送给客户的发票上的项目。

在这里要问的关键问题是：“（考虑产品目标）这个项目如何增加我们的收入或利润？”回答这个问题越容易，它就越清晰地提供商业价值。如果很难确定，你可能在处理另一种价值（见下文），或者该项目实际上可能根本没有价值，你需要将其移除。

2.效率价值

产品待办事项中并非所有项目都会产生收入。但项目也可以通过直接降低生产、维护和交付成本来直接影响利润。这些项目代表着简化、自动化、减少或平滑产品所需的其他工作的工作；它使其他工作更高效。

从经济角度来看，这些项目通过花费更少的资金为交付给利益相关者的相同价值提高了你的成本效率。或者，如果你不是商业企业，它节省了你多少时间。这就是效率价值。

例如，如果对代码库的更改使您能够用更少的服务器运行相同的产品，那么您就产生了效率价值。但它也可能涉及自动化或简化必要的开发、运营或交付过程中繁琐和重复的任务。

对于我们帮助开发的产品之一，我们在产品待办事项中有减少在客户现场设置产品所需时间的项目。尽管这个项目本身并没有产生收入，但它确实为我们（和客户）节省了金钱。

更间接地，项目也可以减少其他地方的工作，从而降低成本。例如，当一个项目增加了应用程序的稳定性，从而减少了每周帮助台的大量来电。

对于每个项目，关键问题是：“（考虑产品目标）这个项目如何为我们节省金钱或时间？”如果情况不明显，你可能在处理其他类型的价值。或者该项目根本没有价值，你需要将其移除。

3.市场价值

一个产品的成功程度取决于知晓它的潜在用户和客户的数量。通常情况下，产品开发涉及大量工作来增加这种认知度，进入新市场，或与竞争产品区分开来。这项工作代表了市场价值。

市场活动是这种工作的一个很好的例子。例如，这可能是为推广你的产品而设置和撰写简单网站的工作。或在LinkedIn上启动一项营销活动。甚至写一篇博客文章、录制一期播客或视频也可以从这个角度被视为“市场价值”——只要它主要关注于为你的产品创造认知。

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

对于每个项目，关键问题是：“（考虑产品目标）这个项目如何让我们吸引更多用户或客户？”如果很难证明这个项目如何吸引新用户，你可能在处理其他类型的价值。

4.客户价值

即使你的产品正在产生收入，具有高效率，并且为用户所熟知，但如果客户不继续使用你的产品，或者一有机会就转向竞争对手，要成功仍然很困难。因此，使你的产品对其客户更有用和有价值的工作是有价值的。这实际上增加了你的产品的“粘性”，正如埃里克·里斯在《精益创业》中所说的那样。这就是客户价值。

对于每个项目，关键问题是：“（考虑产品目标）这个项目如何增加客户继续使用我们产品的可能性？”如果你无法清楚回答这个问题，你可能在处理其他类型的价值。

5.未来价值

最后，你的产品必然会有一些工作在完成后并没有产生任何明确的价值，但在（近）未来如果不完成可能会导致巨大问题或显著成本。这就是未来价值。

研究和创新是这一类工作的例子。有时候你需要研究与当前技术堆栈面临的问题的替代技术解决方案。或者你想要改进团队的实践和流程，这需要你花一些时间学习。

减少技术债务似乎也是这一类别的一个例子。技术债务包括在产品之前应用的所有捷径和快速修复——可能在紧要关头——这些可能当时效果很好，但现在却带来了问题。例如，一些重要部分的代码可能缺少自动化测试。或者文档没有更新。或者代码块已经变得像意大利面条一样纠结，开发人员不敢触碰它，担心它可能像代码的竞技塔一样全部崩塌。

未来价值的一个风险是所有时间都花在了可能在未来有价值的事情上，而没有考虑到现在什么是有价值的。虽然将这类工作从产品待办事项中移除可能很诱人，但这些项目可能代表着对未来灾难的防范。即使未来仍然大部分未知，但其中一些防范措施可能是明智的保留——即使它们不会立即产生价值。

对于每个项目，关键问题是：“（考虑产品目标）这个项目如何在未来为我们节省金钱或时间？”如果你无法清晰回答这个问题，你可能在处理其他类型的价值。一个良好的产品待办事项应该只有少数这样的项目，而且不要太多。

合规性呢？

当我们首次分享这个分类时，最常见的问题之一是如何处理现有法规、协议和认证的合规性。有人建议“合规性价值”是否应该成为其自己的类型？

我们当时对这个问题感到困惑，现在仍然如此。我们在这里的担忧是合规性本身并不真正有价值。相反，它是一种手段，希望是有价值的。例如，当客户要求遵守某个协议并为此付费时，这显然是商业价值。

如果客户不为此付费，但他们仍然要求这样做以保持他们的支持，那么这就是客户价值或市场价值。如果合规性涉及安全或加固，那么是为了防止潜在的安全漏洞造成的损害。这就是未来价值的例子。

我们看到太多的例子，即为了合规性而遵循合规性，结果导致了巨大的成本、效率降低，并使发布变得更加困难。虽然在某些发生这种情况的情况下是合理的，但在其他情况下却并非如此。因此，为了避免这种情况，我们鼓励你深入挖掘合规性，确定为什么合规性有价值。

此外，我们认为合规性更适合于“完成定义”。除非你谈论特定的功能或功能，否则大多数合规性通常包括质量指南。这难道不正是“完成定义”所用之处吗？

开始关于价值展开对话

我们在这里提出的分类法当然不是完整的。各种类型在几个方面有重叠，有些项目可能并不明确地属于任何一种类型，但仍然具有价值。

但这并不是重点。重点是你应该与你的团队和利益相关者就产品待办事项中每个项目的价值展开对话。对于那些你可以轻松分类到这些类型中的一个或多个的项目，你可能正在处理有价值的东西。

如果你不能，你的团队，尤其是你的产品负责人，需要有一个异常有说服力的理由，解释为什么它仍然在产品待办事项中。毕竟，产品负责人如何通过保留看似没有价值的项目来最大化Scrum团队完成的工作的价值呢？

我们希望这篇文章激发了你与利益相关者就价值展开对话，并对在产品待办事项中保留什么和丢弃什么做出有意义的决定。