RICE和MoSCoW都用于需求排序，但解决的问题不同：RICE把需求换算成分数，回答“谁先谁后”；MoSCoW把需求划入四个档位，回答“哪些必须进本次范围”。选择哪一种，取决于你当前要拉开顺序，还是要先锁定交付边界。排序结论最终要回到需求工作项上被评审、确认和追踪，ONES可以承载这一过程。
要点总览（TL;DR）
- RICE用触达、影响、信心、投入四个因子算出连续分数，回答“谁先谁后”；MoSCoW把需求划入必须有、应该有、可以有、本次不做四档，回答“哪些必须进本次范围”。
- 候选需求多、需要拉开相对顺序、能统一估算口径时选RICE；交付范围需先锁定、需要多角色确认边界时选MoSCoW。
- 数据不足、估算信心低时，先用MoSCoW粗分档，再对中间档位中数据较充分的需求补做RICE估算。
- 两者可以组合：先用MoSCoW锁定本次范围并排除“本次不做”，再用RICE在“必须有”“应该有”档内排先后。
- 排序结论应记录在需求工作项上，经评审确认后进入状态流转；ONES可承载排序字段、档位与评审记录。
RICE与MoSCoW的核心差异
RICE是一种加权评分方法，用四个因子相乘再除以投入，得到一个可比较的数值。它的价值在于把分散的判断压缩成一个连续分数，让几十条需求能排出相对顺序。
- Reach（触达）：一定周期内受影响的人数或事件数，例如每季度受影响的活跃用户数。
- Impact（影响）：对单个对象的影响强度，团队通常约定一个刻度，如3为巨大、2为高、1为中、0.5为低、0.25为极小。
- Confidence（信心）：对上述估算的把握程度，常用百分比表示，如100%、80%、50%。
- Effort（投入）：完成需求所需的人月或人周。
计算方式为：RICE分数 =（触达 × 影响 × 信心）÷ 投入。分数越高，相对优先级越高。需要强调的是，这个分数是相对排序工具，不是绝对价值判断；四个因子的口径若未事先约定，跨团队的分数不可直接比较。
MoSCoW是一种分类协商方法，把需求划入四个档位：
- Must have（必须有）：本次不交付则目标无法成立，缺少它整个交付失去意义。
- Should have（应该有）：重要且有明确价值，但存在短期替代方案，可以延后一次交付。
- Could have（可以有）：锦上添花，资源有余才做，删掉对目标影响有限。
- Won’t have（本次不做）：明确排除在本次范围之外，并记录原因，供下次评估。
MoSCoW的产出是离散档位，本质是范围协商的结果。它的作用不在于精确排序，而在于让产品、研发、业务等干系人对“这次交付什么、不交付什么”形成共识。四档中“必须有”通常建议控制在总投入的较大比例以内，为变更留出余量，具体比例由团队按交付周期约定。
两者的根本区别落在三处：输出形态上，RICE给连续分数，MoSCoW给离散档位；决策方式上，RICE偏向分析计算，MoSCoW偏向协商共识；数据依赖上，RICE需要触达、投入等估算输入，MoSCoW主要依赖对业务目标和交付边界的判断。
同口径对照：按同一组标准比较两种方法
把两种方法放到同一组标准下对照，差异会落在具体条件上，而不是笼统的“一个精确、一个粗略”。下表按输出形态、数据依赖、共识成本、变更适应和适用规模五个维度展开。
| 比较维度 | RICE | MoSCoW |
|---|---|---|
| 输出形态与可比性 | 连续分数，可在大量需求间拉开相对顺序，便于排序和截断 | 四个离散档位，档内需求之间不区分先后，档间边界清晰 |
| 数据与估算依赖 | 依赖触达、影响、信心、投入四项估算，口径需统一，否则分数失真 | 依赖对业务目标和交付边界的判断，对量化数据要求低 |
| 决策参与人数与共识成本 | 可由少数人完成估算，共识成本集中在因子口径的校准上 | 需要多角色参与协商，共识成本高，但共识一旦形成执行力强 |
| 对需求变更的适应方式 | 新需求加入后重新计算分数即可，调整成本低 | 变更意味着重新协商档位，需回到干系人确认范围 |
| 适用规模与维护成本 | 适合候选需求多、需要持续排序的场景，维护成本随需求数量线性增长 | 适合单次交付范围明确、需求数量中等的场景，每轮交付重新划分 |
从表中可以看出，RICE的优势在可比性和调整灵活性，代价是估算口径的维护；MoSCoW的优势在边界清晰和共识强度，代价是每次变更都要重新协商。两者并不存在普遍更优的一方，差异体现在你所处的决策条件上。
什么情况下选RICE，什么情况下选MoSCoW
选择的第一步是判断当前要解决的问题类型：如果 backlog 里堆着大量需求、需要决定先做哪几条，选RICE；如果本次交付范围尚未锁定、需要各角色确认哪些必须做，选MoSCoW。
选RICE的条件：候选需求数量多，通常超过二三十条；需求之间价值差异需要被量化拉开；团队能就触达、影响、投入的口径达成一致；排序结果需要定期刷新。典型场景是产品 backlog 的常规排序、多个需求竞争同一批研发资源时的取舍。
选MoSCoW的条件：交付周期和范围需要先锁定；干系人来自多个角色，需要共同确认交付边界；存在“这次必须上线”的硬约束；需求变更需要走明确的协商流程。典型场景是版本范围规划、合同交付范围确认、跨部门联合项目的首期范围界定。
数据不足时的处理：当触达和投入缺乏可靠数据、估算信心普遍偏低时，直接套用RICE会得到看似精确实则失真的分数。此时可先用MoSCoW做粗分档，把明显必须和明显不做的需求分开，再对中间档位中数据相对充分的需求补做RICE估算；也可以先给信心因子打低分，让分数反映不确定性，而不是假装精确。
组合使用的顺序：常见做法是先用MoSCoW锁定本次范围边界，把“本次不做”明确排除，再对“必须有”和“应该有”档内的需求用RICE排先后。这样避免对已排除项做无效估算，也让RICE的分数集中用在真正需要排序的候选集上。衔接点在于：MoSCoW的输出是候选集，RICE的输入是这个候选集，两者的档位与分数应记录在同一份需求清单上，便于回溯。
在ONES中落地需求排序
排序方法本身是分析动作，结论要进入需求管理流程才能被执行和追踪。在ONES中，需求以工作项的形式承载，排序所需的字段和档位可以作为工作项属性维护。
具体落地可以按以下流程组织：
- 建立排序字段：在需求工作项类型上增加触达、影响、信心、投入等数值字段，以及MoSCoW档位字段，让每条需求在录入时就带上排序所需的信息。
- 完成估算与分档：由产品负责人牵头，在需求评审前完成RICE因子填写或MoSCoW档位划分，估算依据可记录在需求描述或关联文档中。
- 评审与确认：在需求评审会上，干系人基于工作项上的字段确认排序结论，重点确认“必须有”档位和“本次不做”的排除项，确认结果体现在工作项状态或评审记录上。
- 状态流转与交接：排序确认后的需求进入待开发或已排期状态，研发按排期接手；排序结果发生变化时，更新字段并留下变更记录，相关需求重新回到评审环节。
ONES Assistant 可以理解项目、工作项、迭代和 Wiki 页面等工作上下文，基于项目数据和团队知识回答问题并执行后续操作；在需求澄清阶段，它也能把会议、反馈和文档转化为可执行需求，提炼要点与待澄清问题。这些能力可以帮助团队更快完成排序前的信息准备。排序字段的具体配置方式，建议按团队现有的工作项类型和字段体系设计，并在小范围内先验证字段口径是否够用。
适配场景与选择建议
综合前文的判断，可以按团队与需求特征给出选择建议：
- 需求来源多、backlog 持续增长的产品团队：以RICE为主，建立统一的因子口径，定期刷新分数，用分数决定排期顺序。
- 按版本或合同交付、范围需要先锁定的团队：以MoSCoW为主，每轮交付前完成档位划分，把“本次不做”明确记录并同步给干系人。
- 两者都需要的中大型团队：采用“先MoSCoW划边界、再RICE排档内顺序”的组合顺序，把档位和分数同时记录在需求工作项上。
- 数据基础薄弱、估算信心低的团队：先用MoSCoW粗分档，积累一段时间的触达和投入数据后，再引入RICE。
无论选择哪种方式，都建议先做小范围试点：选取一个迭代或一个需求集，按选定方法完成排序，观察排序结论是否被团队接受、执行中是否出现明显偏差。试点结束后回顾两点——因子口径或档位定义是否需要调整，排序结果与实际交付价值是否一致。验证通过后再推广到全部需求，避免一次性改变所有团队的排序习惯。
常见问题
RICE分数算出来之后，跨团队直接比较分数可以吗？
不建议直接比较。RICE分数是相对排序工具，前提是四个因子的口径一致。不同团队对“触达”统计的是人数还是事件数、对“影响”的刻度约定、对“投入”按人月还是人周估算，都可能不同，分数放在一起会失真。
如果需要在多个团队之间比较，先统一因子定义和取值刻度，再重新计算；或者只在同一份需求清单内部使用分数排序，跨团队层面改用MoSCoW档位对齐范围。
MoSCoW的“必须有”档位应该控制在多大比例？
没有统一比例，取决于交付周期长度和变更频率。原则是给变更留出余量：如果“必须有”占满全部投入，任何新增或调整都会挤压交付，档位划分就失去了协商空间。
团队可以按自己的交付节奏约定一个上限，例如在单个迭代内控制“必须有”的投入占比，并在每轮交付后回顾是否频繁出现“必须有”被临时追加的情况，据此调整下一轮的划分尺度。
需求频繁变更时，MoSCoW的协商成本会不会过高？
会。MoSCoW的档位是协商结果，需求变更意味着重新回到干系人确认范围，参与角色越多，单次调整的成本越高。如果变更频率很高，可以缩小协商单元：把MoSCoW用在版本或合同范围这类需要正式确认的边界上，日常backlog的先后顺序交给RICE处理，避免每次小调整都触发全员协商。
组合使用时，MoSCoW的档位和RICE的分数应该记录在哪里？
建议记录在同一份需求清单的同一批工作项上，而不是分散在表格和文档里。每条需求同时保留档位字段和四个因子字段，评审时能直接看到“这条为什么在必须有档、分数是多少”，变更时也能回溯是哪一步调整了结论。
在ONES中，可以把这些作为需求工作项的属性字段维护，评审确认结果体现在工作项状态或评审记录上，排序变化时更新字段并留下变更记录。
试点验证时应该观察哪些信号来判断方法是否适用？
可以观察三类信号：一是排序结论是否被团队接受，评审时是否频繁出现对分数或档位的争议；二是执行中是否出现明显偏差，例如排在前面的需求实际交付价值低于预期；三是维护成本是否可承受，估算和协商占用的时间是否超出团队预期。
试点结束后据此调整因子口径或档位定义，再决定是否推广到全部需求。
