在参加一个客户会议的时候，IT 部门的总监很沮丧。“我们需要完成所有这些功能，但不可能在情人节之前全部完成。我认为敏捷会使事情更快。”我告诉他，“敏捷是有帮助，但我们真正需要的是对这些功能排优先级。”他回答说，“他们都是高优先级。”
责任分散
当所有事情都是高优先级，就意味着没有事情是高优先级，然后我们就陷入了互相指责的不良气氛和错位的期望中。这就是为什么企业需要更好地对功能排序。维基百科把责任分散定义为“…一种社会心理 现象，当其他人在场的时候，人们不太可能付诸行动承担责任或者干脆不作为。”优先级弱化或没有优先级就制造了一种责任分散。团队感到重负不堪，干系人没有得到他们想要的东西，以及项目经理觉得没有用。
当我们开始的时候并不了解项目的一切
然而我们非常重视“敲定”每一项需求，以此不会错过什么。这是个傻事。总会有事情没有考虑到。就算我们在开始的时候了解一切，事情也会改变的。新的需求产生，发现差距以及他们瞄准了新的机遇。
MoSCoW 方法
MoSCoW 方法是一项排列优先级的技术，用来与干系人及彼此对功能的重要性达成共识。它也是很好的一个轻量级排优先级的技术，尤其是当你需要粗略“大量”排序的时候。MoSCoW 是缩写，分别代表如下：
- 必须有 – 是指对项目成功关键任务的部分。当我们创建或者更新产品的时候，这些功能是产品封装“品牌承诺”的部分。例如， Basecamp 的部分品牌承诺是，“这是共享文件、讨论、协作文档、分配任务以及检查到期日期的一个地方。”那些就是该项目功能的关键性任务，因为他们被封装在了与项目有关的所有营销和沟通中。
- 应该有 – 这些功能并不是绝对的关键任务，但没有他们，产品看起来就会感觉“不完整”。“应该有”的一个例子，你的竞争对手产品有的功能，并且你知道为了达到功能平等，你也需要有。
- 可以有 – 这些功能是“观望的”，并且根据时间、范围和预算有 50/50 的机会发布。
- 不会有 – 这些功能绝对不会发布，或许因为他们很不确定、价值命题未知，或者因为他们太“奇怪”而不理解。这就是不会有的功能的例子。
优先级强化了更严谨的思维过程
不管你是领导、项目经理或者关键干系人，对每个功能说“是”是非常容易的，尤其是如果它意味着在其他人越来越多的列表中增加什么东西。我们尝试着推回去，但是徒劳，因为最终一天我们都想发布，从而让项目成功，以及让干系人满意。每一项增加都是成本，而让成本可见最简单的方式就是强行排优先级。试想一下这样的场景：
“嘿，Pat 项目经理，我是业务人员 Bob，我们有一个新的需求需要加进去，第一季度的报表需要它”
“嘿，Bob，昨天晚上我收到你的邮件了，我把它给团队做了估算。好像需要 4 个星期的额外工作。我们可以做，但我们不能同时做其它的所有内容，所以请告诉我它的优先级相对于其它所有内容是什么，我好知道把它放在哪里。”
在这个例子中，Pad 使成本让 Bob 可见，现在让 Bob 决定这个新需求的优先级。如果没有优先级，永远不会产生这样的对话。现在 Bob 会开始问 Pat 和团队更深层次的问题，例如“如果我把这个其它功能挪掉，那个不是很重要，这样可以做吗？”或者“我们可否做这个功能的瘦小版本，这样也可以。”不理解成本，Bob 就不会排优先级。现在 Bob 理解了成本，他就会有更好的基础与团队和项目经理（PM）洽谈。
优先级使有限资源最佳利用
在人类历史上从没有任何一个软件项目有足够的时间、金钱和人力。因此项目必须从我们手头的资源中得到最大的价值。对功能排优先级意味着我们的业务伙伴能够帮助我们理解整个列表中什么可以带来更大的价值以及更少的价值。这样，就算我们没有完成所有的功能，但我们专注于最有价值的功能。我们可能无法发布完全充实的美景，但我们可以发布最小可行产品（Minimum Viable Product），得到用户反馈，基于使用情况和客户所想，对显著的功能列表重新排列优先级。
优先级排序练习是大家玩游戏的一部分，因为没有人有足够的信息。团队最好的理解一个功能需要用多少时间。干系人和产品经理理解它的价值，以及项目经理和 Scrum Master 理解时间与成本的影响。所有三方需要以透明的方式一起协商优先级和范围。
优先级排序是风险管理的一种形式
优先级排序是风险管理的一种形式。项目管理学院（Project Management Institute）在 2015 年的意向报告中指出“64% 的公司频繁地使用风险管理技术。”这可能是因为当人们想到风险管理计划，他们想象的是 3 本满满的文档，内容围绕着风险缓解计划及概率的可疑价值。其实不必那样做。
对你的功能列表排优先级，仍然可以给你一个可行的轻量级风险管理计划。有助于管理风险优先级排序的一种方式是，围绕成本与价值的强行对话。我们一直都想创建用最小成本产生最大价值的产品。这样最小化了产品风险。有助于管理风险优先级排序的另种方式是，当我们企图排优先级时，用来决定优先级所需的任何信息缺口都变得异常明显。这样最小化了知识风险。最后，如果一个功能是高优先级，而团队不知道将会如何解决处理，给与团队需要的支持则最小化了与项目有关的社会和技术风险。
有助于排序的三项技术
按知识价值排序
在项目初始，你不知道的内容对你也许会有损害。随着时间推移，移除未知因素是积极影响项目健康的巨大机会。为了按照知识价值排序，我们必须愿意承认我们没有所有未知的答案。当我们这样做，我们就可以在列表中排一些“知识价值”的条目，例如研究和原型。
对于有风险的项目，这非常有用。为什么？因为风险的对立面不是分析。风险的对立面是知识。因为风险是未知，降低风险的最好方式就是减少未知，并用知识来减少未知。
你怎么知道什么时候需要按照知识价值排序呢？这里有几个信号有助于你理解是时候停止考虑功能，而开始考虑降低风险了。
- 团队说，“我们不知道这是否可行…”
- 产品负责人说，“我不知道客户对这个怎么反应”
- 架构师说，“我不确定这个平台是否支持这个功能”
- 业务分析师说，“我还没有弄清楚那部分的需求”
- 测试人员说，“我怎么测呢？”
对于如上的每一个例子，都是缺乏知识的清晰信号，从而妨碍了某人有信心地往前走。
按增收（Increased Revenue）排序
这永远是赢家，但它严重依赖于产品负责人的老练程度，他能够清晰地讲述这个功能或者用户故事的 ROI。因此，当排序时，这是一个考虑因素。举一个付款方式的例子，下面是这个例子：
“用户体验模型显示 15% 的人点击 Paypal 的按钮走付款流程。我们的购物车放弃率也是 15%。实现 Paypal 作为支付方式将会大量地降低我们的购物车放弃率并导致收入会增加 10%-15%”
如何计算这个功能潜在的增加收入
- 创建一个可比的标准，衡量当前的收入差距。
- 量化潜在的收入增加（或者用百分比，或者用美元）
- 对比增加收入（超过一年）和创建该功能的成本。
- 对于所有增加收入相关的功能，按照递减的增收排序
按成本节省排序
这是另一个容易说清并易于辩护的，但需要一些研究以及数字计算来获得稳妥的基础。成本节省或者“总拥有成本（Total Cost of Ownership）”节省一直是新项目背后的驱动力。举一个转换平台来降低成本的例子：
“旧平台每笔交易需要 10 秒，而新平台每笔交易需要 7 秒。把功能挪到新的平台上，每笔交易会节省 30% 的时间，而且每个月我们会做超过 100 万笔的交易。”
在上面的例子中，成本节省非常容易直接地计算出来。现实生活中的大多数情况会更复杂混乱。这有一些为排序计算成本节省的技巧：
任何间接节省时间的功能都会降低成本，例如自动化手动任务。调查你的客户手动执行该任务的时间花费，并用这个人的“成本 / 小时”来算出成本节省的数字。
砍掉一些功能有时可以节省成本。举一个例子，公司推出仅有核心功能的“轻量化”版本软件。更少的功能 = 更少的维护成本。
创建开放的 API，允许开发人员创建功能可以节省成本。这是因为功能开发的任务转移到了开发社区中，这意味着个体的开发人员会承担资金提供并支持这个插件。
总结
多年来我和很多公司都合作过，优先级排序都是最难的一个，也是他们需要学习的一个惨痛教训。他们已经习惯了一切皆高优先级的模式，其结果就是他们没有得到想要的项目产出。他们的团队失去动力，并且大家因为提供了劣质的产品而感到沮丧。优先级不仅限于项目级别。我合作的一些最成功的公司还使用同样的技术用于：
项目集层面：有效地排序有助于复杂的项目管理，有助于搞清楚项目与项目集之间的相互依赖。尽管没有什么可以移除复杂性，但排序有助于把它分成块，从而容易计划和执行。
战略层面：有效地排序有助于根据策略需要调整战略优先级。其结果是易于理解和易于沟通战略计划，强行对不同的计划排序。战略计划经常都是 2 天的领导异地会议做出的，但通常并没有什么切实的内容值得大家拥抱庆祝，以及无法弄清“今年我们要做什么？”
将同样的价值驱动思维用于这些高层次上对人、项目以及下游的团队都有极大的影响。很容易让大家朝着使命看齐，并在上线的时候少些意外。
关于作者
Tirrell Payton，Payton Consuling 的首席，Payton Consuling 是在圣地亚哥的一家小公司，帮助公司从技术团队中得到更多的价值。在加入 Payton Consulting 之前，Tirrell 曾是麦肯锡数字咨询实践的咨询师。
查看英文原文： Why Companies Need to do a Better Job of Prioritizing Features
评论