功能请求优先级框架：七种方法怎么选，分数怎么用

用五个问题比较七种方法

对每种方法都问相同的问题：它回答什么决策？最低需要什么证据？输出是什么？适合在哪个阶段使用？最容易在哪儿误导人？ 是否有数字，并不决定一种方法是否适合当前任务。

下面是编辑层面的选择建议，不是效果排行榜。“适用情境”表示我们会在什么条件下考虑该方法，不代表某家公司采用后已经获得可验证的收益。

七种框架：用途、示例与局限

1. RICE：比较有边界的候选项，不是直接比较工单数

Intercom 对 RICE 的说明包含覆盖范围、影响、信心和工作量：分数＝覆盖范围 × 影响 × 信心 ÷ 工作量。覆盖范围要有一致的时间周期，工作量可以用人月表达。计算时，80% 信心写成 0.8，而不是 80。Intercom 的 RICE 说明

本文案例选择“一个季度内预计使用该变化的不同工作区账户数”，这是明确声明的案例单位，不是所有团队必须采用的口径。同一账户提交十二条工单，按账户口径计算时仍是一个账户。也不能某一行填使用人数，其他行继续填账户数，然后把结果放在一起比较。

128 分不是新增 128 个客户，更不是财务回报。这个分数只在输入口径一致的候选集合中有相对意义。RICE 适合在功能范围确定后辅助比较，但不能判定某个访问缺陷是否可接受、前置能力是否存在，或特定工程师是否能在需要的那一周投入。把这些问题列在分数旁边，不要让公式替你回答。

2. ICE：讨论赢家之前，先把公式写出来

GrowthHackers 的 NorthStar 官方说明给影响、信心、易实施程度分别打 1—10 分，然后取平均值：ICE＝（影响＋信心＋易实施程度）÷ 3。易实施程度越高，表示越容易开展。GrowthHackers 官方 ICE 说明

公式差异真的会改变结论。在一个独立的虚构演示里，实验 X 的三项输入是 9、2、9，平均值为 6.67；Y 是 6、6、6，平均值为 6.00。按平均值，X 靠前。如果改用乘法，X 为 162，Y 为 216，顺序恰好相反。因此，表头不能只写“ICE”，还要写清采用的版本与公式。

面对可逆的小实验，应先约定低分、高分分别对应什么，再请实际负责执行的人判断易实施程度。信心两分也不等于经过统计校准的 20% 成功概率。对于代价高、难撤回的承诺，这种轻量估计可能不够；正确的下一步通常是调查最薄弱的假设，而不是多加几位小数。

3. MoSCoW：明确本次版本能够协商的范围

MoSCoW 区分 Must、Should、Could 和本次不做的 Won't。Agile Business Consortium 强调具体时间范围、缺少该要求是否仍能交付可用版本，以及是否存在替代办法。DSDM 常见的 Must 比例建议针对的是交付工作量，不是卡片张数。MoSCoW 原始组织指南

在下文的虚构版本里，负责人已经把 F00 定为必须完成的事项。它是案例预先给定的限制，不是本文作出的法律或安全结论。如果某个优化有可接受的临时办法，就记录临时办法的负担，以及从什么时间开始不再可接受；不能仅因为提出者职位高、不愿等待，就把它写成必做。

MoSCoW 不负责给每一个 Should 排出精确先后。它首先让范围与缓冲空间可见；若仍需比较可选功能，再采用适合的方法。“本次不做”也需要理由和重新考虑的触发条件，否则它只是一个礼貌的遗忘标签。

4. Kano：先研究满意度，再给功能贴标签

Kano 在 1984 年的研究区分了质量属性与满意度之间的不同关系。后续实证论文介绍了针对属性存在与不存在的成对问题。这样的研究过程，与内部团队讨论某功能“听起来是否惊喜”完全不同。原始论文书目与摘要；PLOS 实证研究

例如工作队列通知，一个用户群体可能认为理所当然，另一个群体却可能觉得通知打扰太多。在称它为基本期待或魅力属性之前，应明确测试的属性、选择相关用户群体，并检查成对回答。模糊答案、不同群体之间的分歧也要保留，不能只报告一个方便推进项目的分类。

如果你不确定功能提供的是哪一类价值，Kano 值得考虑。但它不提供工程工作量，也不会自动给出发布日期。本页完整案例没有 Kano 调研，因此没有给任何候选功能编造“用户已验证”的 Kano 分类。缺少研究，意味着下一步要研究，而不是请 AI 补一个听起来合理的标签。

5. 加权评分表：让偏好和取舍可以检查

简单加权表按商定权重合并各维度分值，但严谨的多准则决策分析 MCDA 不只是挑几个百分比。英国政府分析职能部门的指南讨论了定义价值刻度、依据刻度范围内的变化确定权重、单独分析成本，以及开展敏感性检查。MCDA 指南

产品讨论中，可以分别比较“减少复核操作负担”和“对本期明确战略目标的贡献”，但应先写清每个刻度的端点。如果“客户影响”“客户价值”“客户收益”其实都在测同一件事，三列并不构成三条独立依据。要么去掉重叠，要么说明区别，并让参与者能够解释为什么给出该分数。

自制的轻量表应标明是决策辅助规则，不应自称经过验证的 MCDA 模型。金额成本和产能限制要单独可见；不能把任意偏好分除以成本，就称为已证明的性价比。略微调整权重就换了第一名，应报告变化暴露的分歧。团队尚未商定的价值取舍，不会因为表格有小数就自动得到解决。

6. 机会评分：先选择未满足的结果，再选择功能

Strategyn 的机会公式是：重要性＋max（0，重要性－满意度）。其量化方法说明使用回答中最高两个等级的比例作为输入，而不是直接把原始顺序等级的均值当成可随意运算的数值。机会算法；输入口径说明

假设有 100 名相关受访者，80 人把某项用户结果的重要性放在最高两个等级，40 人把满意度放在最高两个等级。将两项百分比都除以 10，得到 I＝8、S＝4，机会分数为 12。另一个结果若 I＝5、S＝7，分数为 5，因为负差值按零处理。这些只是演算数据，不是已经采集的客户调研。

结果应描述用户想完成什么，例如“减少找出未解决事项所需的时间”，而不是“我们想做摘要功能”。即使某个结果机会分很高，也不能证明摘要就是有效方案。样本覆盖、分群、题目设计仍会影响研究；选择具体方案、检查可行性和决定投入，需要后续工作。

7. WSJF：检查多等一段时间会失去什么

SAFe 将 WSJF 描述为相对延迟成本除以相对工作时长，公开概述提到用户及业务价值、时间紧迫性、降低风险或创造机会，以及工作规模。SAFe WSJF 概述

在另一个独立演示里，一项工作的延迟分为 13、规模为 5，结果是 2.6；另一项延迟分为 8、规模为 2，结果是 4。后者虽然延迟分更低，却在这些假设下排得更早。这些是相对单位，不是金额，也不是已经实现的经营回报。

实际讨论时要追问：再等一周，什么会具体变差？有限的接口切换窗口，与需求提出者写“紧急”，不是同一类证据。保持比较集合和规模口径一致，并在把工作视为可开始之前检查前置依赖。需要不同人员配置、或包含等待时间的任务，总人力工作量不能直接等同于日历时长。比值帮助讨论先后，但不能替代可执行的排期。

评分之前，先整理请求证据

优先级会议不应该从一列没有出处的总数开始。把原始观察、团队解释、建议方案分别保存。搬运客户材料时保留访问限制；内部规划表也不意味着可以把客户消息扩散给所有人。

工单量可以反映负担，但不能自动替代覆盖范围。去重也不是一刀切：同一账户的两条请求可能描述两个不同问题，不能因为账户相同就合并。保留原始来源编号，审核者才能在发现误合并时恢复真实情况。

完整案例：为什么最高分只能是暂定答案

先确定比较口径，再算基准情景

以下组织、需求、证据和数值全部虚构。团队规划 2026 年第四季度的共享工作队列改进，目标是让负责人无需支持人员协助就完成每周复核。覆盖范围指该季度预计使用变化的不同合格工作区账户数；工作量包含产品、设计、工程和测试的人月，不是日历月。

总产能为八人月。案例负责人先为 F00 访问控制修复预留两人月，再为 F05 事件标准化预留一人月；F02 和 F03 都依赖 F05。剩余五人月用于可选候选功能。F05 在共享产能中只扣一次，没有暗中计入两个功能的增量估算。这些预留不表示已经证明具体人员在具体日期可用。

F01 的计算是 240 × 1 × 0.8 ÷ 1.5＝128。具备输入、进入评分的候选项，基准顺序为 F03、F01、F02。F04 不是零分垫底，而是在单独的补证据队列中。写成零分，就意味着你已经知道它没有相应价值；本案例并没有这种证据。

暂定选择 F03 和 F01，占用 2＋1.5＝3.5 个可选人月。加上 F00 与 F05，总计 6.5 人月，剩余 1.5 人月暂不分配。F02 需要两人月，不能原样放进余量。这是一种可解释的提案，不是“按 RICE 从高到低拿项目就一定得到最优组合”的证明。功能覆盖的账户也可能重叠，不能把各行覆盖数相加后宣称独立客户收益。

维护排序之前，先改变一个关键假设

在组合情景中，F02 加 F01 同样占用 3.5 个可选人月，加上预留工作，总计仍为 6.5。计算正确不代表 F02 的信心应该提高。提高该值，需要更好的覆盖、影响或交付假设证据，并由负责人解释为什么修改合理。

敏感性检查不只在排序变化时有用：它也能揭示哪个不确定因素最值得调查。但不能从凭空设定的范围制造概率分布，更不能把结果称为统计置信区间。这里仅是离散的“如果这样会怎样”情景，没有说明每种情景发生的概率。

写决策记录，而不是宣布分数最高者获胜

可复核的记录应类似：“按基准估算，提议 F03 与 F01；继续为 F00、F05 预留产能；F04 等待覆盖与可行性证据。正式承诺前由工程负责人复查 F03 范围。若增至 3.5 人月，重新计算并讨论 F02。最终选择由产品负责人决定。”

还应记录没有选中的事项，以及什么条件会让它重回讨论。F02 不是永远被否决，而是当前估算下无法原样塞进这个提案的剩余产能。若提出更小的摘要版本，它就是边界变化后的新候选项，需要重新估计影响和工作量，不能会后为了让结果好看只改分母。

用五步完成一次优先级复核

1. 固定决策背景。 写明用户结果、分群、规划周期、产能单位和责任人。先列必做事项及前置决定，再比较可选功能。若这些条件存在争议，应解决或明确升级处理，而不是把争议埋进权重。
2. 每个候选项准备一行证据。 来源编号、观察事实、估算与缺失字段分开。去重时保留不同问题，请实际交付负责人确认工作量包含的范围。资料不完整的功能继续可见，但进入探索队列。
3. 选择一种排序方法并记录版本。 写出公式、单位、刻度端点和同分处理办法。有 Kano 或机会研究时，可将其作为问题证据，不要变成来历不明的综合分。保存会议实际采用的输入快照。
4. 挑战看似最优的候选。 先逐项改变重要的工作量、覆盖或信心假设，再检查有意义的组合变化。核对共享前置和排期限制。同分时讨论缺失证据、时机或学习价值，不要制造虚假的精确度。
5. 记录决定与重审触发条件。 建议排序与正式路线图分开。选中、推迟和仅研究的事项，都应有负责人及理由。下一次复核时对比原假设、实际使用和实际工作量，但不要把所有结果变化都归因于一个功能。

选择之后，可参考AI 用户故事验收标准，把批准的范围写成可测试要求。当前置条件、证据缺口或未解决限制需要专门责任人与跟进时，可以使用AI 项目风险登记表。

按实际处境选方法，不按流行程度选

有可靠的同群体使用数据，但功能大小差异明显，可以先用 RICE，并重点检查分母。有几个成本较小的实验，需要决定学习顺序，ICE 可能已经足够。若争论的是固定日期能否发布，则先用 MoSCoW 协商范围。

尚不理解哪些用户结果没有得到满足，就先研究问题。Kano 与机会评分可以分别回答不同的研究问题；两者都不该只是为了让演示文稿显得高级才加进去。对目标群体没有观察，增加框架数量不会增加证据。

团队对真正不同的目标存在分歧时，加权表可以让取舍更透明；等待代价和可启动任务顺序重要时，考虑 WSJF。如果你解释不清第二种框架在回答哪个不同的问题，它大概率只是增加维护负担。先把一套输入口径用对，通常比同时维护七列分数更有意义。

OpenMax 能参与哪一部分，责任又留在哪里

官方文档提供的起点

OpenMax 的 AI 产品经理文档包含就绪度评估、评分矩阵和暂不处理清单的提示词示例，可作为整理候选信息和讨论草稿的起点。但提示词本身不能证明它已连接你的需求系统，也不能证明你的审批规则会被自动强制执行。OpenMax AI 产品经理文档

先尝试一个边界明确的任务

先把虚构案例包交给助手，要求保留编号，将 F00、F05 识别为单独预留工作，保持 F04 不评分，并复现四种情景。在引入已获授权的真实材料前，对照预期计算检查输出。可以这样布置任务：

仅依据这个案例包准备讨论草稿。保留公式、单位、来源编号和缺失值。区分必做事项、共享前置、已评分候选和仅供研究的项目。展示基准计算以及各项假设变化。不要批准路线图，不要编造证据，不要合并不同问题，也不要更新任何已连接系统。列出需要责任人回答的问题。

这是一项编辑建议的试用任务，不是 OpenMax 已通过实测的报告。准备处理真实材料时，应向相关负责人核实访问、保留、连接器行为和写入权限。受限原文不能因为要展示决策依据，就被复制到公开输出中。

哪些时候工作表反而更合适

如果团队只有六个清楚的候选项，一次简短会议加工作表可能就够了。助手的价值应来自准备可追溯材料、发现不一致时确实减少了工作，而不是默认所有优先级决策都必须自动化。目标、限制、假设和最终承诺，仍应由产品与交付责任人负责。

先复算虚构案例，再把空白工作表用于一次真实规划。只是想生成比较表，不需要顺手授予系统写入权限。

哪些错误会让优先级框架失去可信度

最容易漏掉的是行与行之间含义变化：请求数与账户数、本月与下季度、增量工作量与总工作量、取平均的 ICE 与相乘的 ICE。表格公式可以全部正确，比较对象却完全不相容。

另一个错误是把必须履行的事项当成低分功能；反过来，也有人把每项商业偏好都写成必做，以绕开讨论。应请有权限的责任人确认实际限制及依据。本文不提供安全、法律或合规判断，这类限制必须由相关合格审核者处理。

最后，会议排出一列顺序并不代表流程成功。好的决策过程还应让延期事项可见、保留不确定性、支持重新考虑，并留下谁决定了什么的记录。若之后发现公式或证据错误，保留旧快照，修正受影响的候选项，并告诉依赖该决定的人具体改了什么。

常见问题

哪一种功能请求优先级框架最好？

不存在通用赢家。按决策和证据选择：RICE 比较口径一致的候选估算，ICE 适合轻量实验，MoSCoW 协商版本范围，Kano 与机会评分支持研究，加权表暴露取舍，WSJF 讨论延迟成本下的执行顺序。

ICE 应该取平均还是相乘？

本文引用的 GrowthHackers NorthStar 官方说明采用影响、信心和易实施程度的平均值。有些团队使用乘法变体，两种算法可能产生不同排序，因此必须声明公式与版本，不能混在同一列比较。

RICE、Kano 和 MoSCoW 能一起用吗？

可以，前提是分别回答不同问题，例如先研究满意度，再确认版本限制，最后比较有资格进入排序的候选项。不要直接把 Kano 分类或 MoSCoW 标签转成数字加到 RICE，除非另行明确设计并论证一个新模型。

覆盖范围缺失的功能应该排在哪里？

保持不评分，并记录缺失证据、负责人及下一步研究。零分表示已知覆盖为零，与未知不同。可以另行批准一个有边界的探索任务，但不能因此假装功能价值已经确定。

OpenMax 能自动决定路线图吗？

已查看的文档提供准备与评分提示词，不是自主路线图决策适用、或你的控制规则已落实的证明。合适时可以用于准备讨论草稿，但假设、限制和正式承诺仍需由有责任的人决定。

来源、方法与本次修订范围

资料核对日期为 2026 年 9 月 4 日。各方法定义附近附有来源；比较判断、示例和完整案例均为原创编辑分析。1984 年 Kano 引文只核对了书目信息与摘要；SAFe 只使用公开 WSJF 概述，不声称读过需登录的细节。本文没有实施客户调研，没有运行 OpenMax 产品任务，也没有做优先级效果基准测试。

本次修订纠正旧稿的 ICE 公式，区分七种决策用途，并加入可复算输入、缺失数据处理、敏感性情景及编辑模板。这不构成框架认证，不保证搜索排名，也不替代涉及重大风险限制的专业审核。