优先级

作者：Mitch Lacey。 所有者，Mitch Lacey & Associates，Inc，一家专门从事 Agile 和 Scrum 的采用和改进的咨询公司。

2012 年 1 月

在本文中，Mitch Lacey 讨论了已证明对许多敏捷团队非常有用的三种方法：客户满意度的 Kano 模型、Luke Hohmann 提出的一系列革新方法和 Karl Weigers 的相对权重模型。 所有这些都可以帮助你从粗略地设置积压工作 (backlog) 的优先级转变为通过圆满地权衡风险、重要性和客户满意度来进行精确排序。

应用于

应用程序生命周期管理；Team Foundation Server

本文内容：

• 简介

• 客户满意度的 Kano 模型

• 革新方法

  • 修剪产品树

  • 购买一项功能

• 相对权重 – Karl Weigers

• 结束语

若要保持敏捷团队有效地工作，必须先按优先级别对产品积压工作中的项进行排序，然后随着项目进度更新这些优先级。 所有产品积压工作都必须根据业务价值和风险设置优先级。 通过识别此优先级顺序，团队可以更专注于最有可能致使产品成功的功能。 秩序井然并按优先顺序排列的积压工作不仅可以使团队和客户满意，还能使业务盈利。 有关积压工作的信息，请参阅 生成和管理产品积压工作、创建积压工作 (backlog) 和 梳理和估计积压工作。

对产品积压工作进行排序和确定优先级时，必须考虑许多因素，并能够为你的决策提供合理证明。 刚开始着手解决原始产品积压工作时，过程可能看起来非常艰巨。 幸运的是，无需立即对积压工作中的每一项进行完美排序。 在 估计 中，我介绍了一种称为“Big Wall”的技术，这是一种可以快速有效评估原始产品积压工作并与利益干系人合作形成粗略优先顺序的方法。

这个粗略优先顺序是很好的起点，可能对你的情况已经足够好了。 但在某些情况下，你可能还想优化这些优先级或以更科学的方式对积压工作进行优先级排序。 你可使用多种方法完成这项工作。 在下面的文章中，我讨论了已证明对许多敏捷团队非常有用的三种方法：客户满意度的 Kano 模型、Luke Hohmann 提出的一系列革新方法和 Karl Weigers 的相对权重模型。 所有这些都可以帮助你从粗略地设置积压工作 (backlog) 的优先级转变为通过圆满地权衡风险、重要性和客户满意度来进行精确排序。

客户满意度的 Kano 模型

客户满意度的 Kano 模型是东京理科大学的 Noriaki Kano 教授于 20 世纪 80 年代开发的。 他的模型提供了区别基本和区分属性的简单排名方案。 这是一种基于调查表的方法，这种模型是将产品特征可视化和促进设计团队内部辩论的一种强大工具。

在 Kano 模型中，我们以两种不同形式问一系列问题：功能性和失效性。 例如，假设我们正在询问客户有关汽车 GPS 导航系统的问题。 我们首先问功能性形式的问题：

• 如果这辆汽车有 GPS 导航系统，你感觉怎么样？

我们将回答限制为以下答案：

• 我喜欢这样

• 我期望如此

• 无所谓

• 我可以接受这种方式

• 我不喜欢这种方式

对于此例，假设我们虚构的客户的回答是“我喜欢这样”。

接下来，我们问失效性形式的问题：

• 如果这辆汽车没有 GPS 导航系统，你感觉怎么样？

我们虚构的客户可从以上列出的任何答案进行选择。 但是，答案通常是不同的。 对于此例，比如说，我们的虚构客户对该失效性形式问题的回答是“我期望如此”。

针对实际项目执行此操作时，我们可以用这一系列的相反问题来询问多个客户组，即代表客户组织的不同职能的不同人员群体。 可能有市场营销组、会计组、制造组，等等。 但是，为了理解该模型，假设我们只问一个客户组的一个问题。 我们编译答案对（功能性和失效性形式的答案）后，我们将其映射到一个网格，如表 1 所示。

表 1 – Kano 映射

请注意，在我们的示例中，虚构客户对功能性问题的回答是喜欢，而对失效性问题的回答是期望。 我们将此答案对映射到网格中后，我们可以看到这两个属性的交集是 E，如黄色高亮显示的正方形所示。 让我们看看，这对按优先顺序排列的积压工作来说意味着什么。

• E = 兴奋点。 这些是客户意料之外、真正使产品有别于竞争对手的功能。 它们难以识别，尤其是在最初，因为很难找出引出令人兴奋功能的问题。 因此，兴奋点往往随着项目进展和客户反馈开始而出现并且优先级逐步上升。

  • 客户通过这些功能得到巨大满足，因此愿意支付高价来获取它们。 例如，Apple 的 iPod 以其能够旋转内容以匹配屏幕方向的直观功能取悦了消费者。 但是，缺少该功能不会降低满意度，因为顾客之前并不知道预期会有这项功能。

  • 在我们的示例中，具有 GPS 导航将是令人兴奋的功能。 至少从接收客户反馈的角度来看，探索这项功能的优先级应相对较高。

• B = 基线。 这些功能是产品必须具有的。 它们是必备的高优先级功能。

  • 无论这些基本属性执行得多么好，消费者都将对产品保持中立。 例如，文字处理器必须具有“创建文档”和“保存文档”的功能。 它们是入门门槛。

  • 如果我们已经询问客户组关于安全带的问题，大多数人会回答他们期望新车带有安全带，没有时他们不喜欢。 如果我们将这两个答案映射在网格上，我们会发现安全带是基线 (B)，是必备功能。

• L = 线性。 也称为性能要求，线性功能直接关系到客户满意度。 它们的优先级仅低于基线功能，但必须根据其成本进行平衡。

  • 功能或执行质量提升可提高客户满意度。 功能下降则降低满意度。

  • 产品价格通常与这些属性相关。

• I = 中立的。 这些功能对客户来说最无关紧要，因此对产品最不重要。 它们可能会返回很少或零业务价值。

表 1 还显示了 Q 和 R。

• Q：可疑 – 问题可能不正确或者答案可疑。

• R：反向 – 答案的组合无法计算。 以 GPS 导航系统为例 – 如果有人回答说期望有，但是如果没有也喜欢，这就是 R 答案。

如果一个答案对评定为 Q 或 R，则你应更深入地调查你的问题或答案对。

革新方法

革新方法是帮助你开展主要市场研究的工具。 通过这些工具，消费者以生成有关产品或服务的反馈和输入为目的玩“游戏”。 Luke Hohmann 开发并在他的《Innovation Games》（革新方法）一书中中描述了 12 种以上此类游戏，这本书对任何图书馆来说都颇有收藏价值。 我最喜欢玩的两个用于对积压工作进行优先级排序的游戏是修剪产品树和购买一项功能，Luke 在该书下面的摘录（使用经过授权）中对这两个游戏的进行了描述：

修剪产品树

园丁修剪树木来控制其成长。 有时修剪富有艺术性，我们会得到形状类似动物或有趣的抽象形状的灌木。 大多数时候，修剪的目的在于培育一棵能产出高质量水果的生长平衡的树。 该过程不是关于“切割”– 是关于“塑造”。使用此比喻有助于创造消费者想要的产品。

该游戏

从在白板或厚纸上画出一棵大树或将树的图形图像打印为大幅海报开始。 粗枝表示系统中的主要功能区域。 树的边缘，即其最靠外的枝条，代表当前版本中可使用的功能。 在几张索引卡（最好是树叶的形状）上写出潜在新功能。 请客户将想要的功能放置于树的周围，定义其下一生长阶段。 他们是否构造了一棵平衡生长的树？ 是否有分支或许产品的一项核心功能获得大量增长？ 树是否有没有充分利用的方面变得更强大了？ 我们知道树根（你的支持和客户关心基础结构）需要至少与树冠的发展同步。 你的产品做到了吗？

产品树 – Hohmann

适用的原因

你和你的客户都知道功能的重要性各不相同。 因此，我们倾向于在最重要的功能上下功夫 — 就是那些为客户提供最大价值的功能。 遗憾的是，有时这意味着我们在完善产品所需的功能方面下的功夫太少。 “修剪产品树”游戏为客户提供了一种通过以整体方式了解构成该产品的一系列功能，参与决策过程的方式。

购买一项功能

哪项功能会吸引客户购买你的产品？ 哪项功能将导致客户升级？ 哪项功能将使客户非常满意以致忽略或容忍他们希望你修复或删除的功能？

产品规划师不断地争论这些以及其他种类的问题。 选择正确的一组功能添加到一个版本通常成为短期失败和长期成功之间的差异。 遗憾的是，太多产品规划师没有让受其影响最大的人群（即消费者）参与进来就做出此决定。 “购买一项功能”游戏通过让消费者帮忙决策来提高此决策的质量。

购买一项功能 – Sterne

该游戏

创建一个潜在功能的列表，并为每项功能制定价格。 就像在实际产品中一样，价格可以基于开发成本、客户价值或其他东西。 尽管价格可以是你想要对该功能收取的实际费用，但这通常不是必需的。 消费者可以使用你给他们的玩具钞票购买他们想在你的产品的下一版本中拥有的功能。 请确保某些功能的定价足够高，以至于没有客户想要购买。 鼓励客户凑钱购买特别重要和/或昂贵的功能。 这将有助于激励客户间协商哪种功能是最重要的。

这个游戏对四到七名客户的小组效果最佳，这样你可以为客户创造更多通过协商凑钱的机会。 与“产品包装盒”游戏不同，“购买一项功能”游戏基于的是很可能在你的开发路线图中的功能的列表。

适用的原因

产品规划师常常落入认为客户已明确定义产品优先级的陷阱。 有的人确实清楚。 而大多数人并不。 当呈现一组选项时，许多客户仅会说“我全都想要”，并将确定其要求优先级的责任放到你的肩上。 或者，产品经理通常通过与客户一一合作来收集功能优先顺序，但在实际进程中却不自觉地再一次担起对功能进行优先级排序的责任。 通过让客户以小组的形式参与并向他们提供有限的资源，可为他们提供以团队方式对他们的需求进行优先级排序的机会。 但这并不是奇妙所在。 妙处在于组织会话，以便客户相互之间就特定功能进行协商。 正是这种协商可以增强你对客户真正需求的理解。

相对权重 – Karl Weigers

用于确定优先顺序的另一个极好的方法是“相对权重”，其由 Karl Weigers 在 1999 年引入。 此方法不仅提供了一种基于用户参与和反馈来确定需求要求优先顺序的机制，而且还包括团队的专家判断。 与“Kano 模型”和“革新方法”一样，“相对权重”让产品所有者能更好地衡量要实现哪些功能以及以什么优先顺序。

第一步是为功能的相对好处分配权重。 好处就是具有最终产品中的功能给用户带来的好处。 下一步是分配相对损失。 损失就是不具有最终产品中的功能给用户带来的后果。 （评估好处和损失可实现与 Kano 方法的功能性形式和失效性形式问题相同的功能。）这些权重是代表你的公司对功能的好处和风险的评价的任意数字。 它非常类似于教师如何确定在确定总分时给予家庭作业、到课情况、小测验和考试的权重；不同教师有不同的标准。 如果你认为好处超过损失，请以你认为适合的比率提高其权重，使其超过损失。 如果你认为损失超过好处，请相应地调整权重。 在表 2 的示例中，我们赋给好处的相对权重为 2 而损失的相对权重为 1，意味着好处将是将决定最终优先级的更重要因素。

以相同的方式，我们确定成本百分比和风险百分比的权重。 在下面的示例中，风险对项目不特别重要，因此成本百分比问题被赋予权重 1 而风险百分比被赋予权重 0.5。 （请注意，尽管好处和损失在计算值百分比之前就进行了加权，但成本和风险是以百分比进行加权的。）如果你有高风险项目，可使风险的权重高于成本。

设置权重之后，我们会要求用户对每项功能的相对好处和相对损失进行评分。 以一个设定的数值范围对每项好处和损失进行评定 — Weigers 建议的范围是 1-9，但也可以选择其他范围，只要在使用时保持一致。 相对好处是该功能将提供的价值；相对损失是不使用该功能的潜在负面影响。

例如，让我们假设一个可能的功能是“使小组件符合萨班斯-奥克斯利法案”。对用户来说几乎没有相对好处，但对业务来说相对损失则很大 - 不这样做可能会使公司无法继续经营。 因此，我们可能看到相对好处的分数为 1 或 2 而相对损失的分数为 8 或 9。

在下面的示例中，用户将“查询供应商订单状态”这一功能的相对好处评为 5 分。 他们将其相对损失评为 3 分。 为了得出该功能的总值，我们将这两个数字乘以他们的相对权重并相加：

(Benefit * Weight) + (Penalty * Weight) = Total Value

(5 *2) + (3*1) = 13

在这里，该功能的总值为 13 分。

得到功能的总相对值和值百分比后，我们从用户回到团队来进行深入研究。 要求团队使用相同数值范围来估计实现每项功能的相对成本。 Karl Weigers 解释说：“开发人员基于要求复杂程度、所需用户界面工作的范围、重复使用现有设计或代码的潜在可能性以及所需测试和文档的级别等因素来估计成本评分。”

估计相对成本后，我们再估计相对风险。 Weigers 还说：“开发人员在 1 到 9 的数值范围内估计与每个功能相关的技术或其他风险的相对程度。 估计值为 1 表示闭着眼睛都能编程，而 9 表示需要严肃思考可行性、是否有具有所需专业技能的人员以及对经验证或不熟悉的工具和技术的使用。 这个电子表格将计算每个功能带来的总风险的百分比。”

记录相对好处、损失、成本和风险的值后，我们将每列加起来。 这些总计将用于计算百分比。

• 总值百分比：使用相对好处和损失的总值除以底部的总和。 在下面的示例中，该值为 13/154 = 8%。

• 相对成本百分比：使用相对成本值除以底部的相对成本总和。 在下面的示例中，该值为 2/42 = 4.8%。

• 相对风险百分比：使用相对风险值除以底部的相对风险总和。 在下面的示例中，该值为 1/33 = 3%。

• 优先级：使用值百分比除以（成本百分比 * 成本权重）+（风险百分比 * 风险权重）。 在下面的示例中，应该是 8.4%/((4.8% * 1) + (3% * 0.5))。 得出优先级值 (1.345)。

得到优先级值后，我们降序排列优先级列，以便优先级最高的项位于顶部。 随着产品积压工作中的项增多或出现更多有关情景的信息，我们需要重新评估优先级。

最后，工作表看起来会像这个表一样：

通过采用这种方法，你可以更好地理解适用于团队和利益干系人的范围。 这还有助于更好地为讨论打下基础，因为客观地考虑每项功能的好处、损失、成本和风险等因素可能并不容易。

Weigers 还介绍了如何让模型更符合你的现状：

“使用以前产品的一系列完整的要求或功能调整此模型供自己使用。 调整加权系数，直到计算的优先级顺序与你对测试集中的要求的实际重要性的事后评估一致。 此模型还可有助于你在评估提出的新要求时作出平衡决策。 使用模型估计它们的优先级别，让你知道它们与现有要求的匹配程度，以便选择适当的实现顺序。 可采取的将要求优先顺序从策略情景转移到客观和分析情景的任何行动都将提升项目以最恰当的顺序提供最重要的功能的能力。”

Karl Weigers 写了两本更加详细探讨相对权重的书：Software Requirements, Second Edition（《软件要求（第 2 版）》）和 More About Software Requirements: Thorny Issues and Practical Advice（《再论软件要求：棘手问题和实用建议》）。

无论使用这些方法的其中一种还是其他方法，请记住产品积压工作是动态的。 并非排定一次优先级就可以一了百了 — 重排优先级是维护正常积压工作的预期组成部分。 若要使你的项目保持正轨，必须不断地重新评估情景、它们对项目的重要性以及新信息对积压工作的影响。 你必须尽力让利益干系人和客户参与整个项目。 此外还须记住，对项的估计是确定其优先级所必需的。 切勿让积压工作变得陈旧和死气沉沉。 花时间和精力整理和梳理积压工作 — 你的最终产品和利润都会取得成果。

请参见

概念

协作（进一步探讨） [重定向]

协作 [重定向]

使用 team Web access，请求并处理利益干系人反馈

跟踪工作和管理工作流 [重定向]

1. Agile Software Requirements(《敏捷软件要求》)，Dean Leffingwell、Addison Wesley

   “Attractive Quality and Must-be Quality”（《魅力质量与必备质量》）Noriaki Kano，Quality JSQC 1984 年 10 月 第 2 期第 14 卷。 Kano 的原创文章。

2. First Things First: Prioritizing Requirements《重要的事先做:为要求设置优先级别》 作者 Karl E Wiegers