真实问题
“下个迭代有 20 个需求，但只有 2 个研发。老板、销售和运营都说自己的最急，我该怎么排优先级？”
问题判断
现在不是 20 个需求怎么打分，而是本迭代没有一个明确要保护的主结果。
如果不先确定版本要改变什么，任何评分都会把主观偏好包装成精确数字。资源越少，越不能平均照顾所有目标。
为什么这是核心问题
排序标准必须来自版本目标，而不是需求提出人的权重。
- 激活、留存、转化、稳定性和内部效率是不同结果，不能放在同一把尺子上直接比。
- 合规、严重故障等硬约束必须先处理，但不应让所有“紧急”需求都伪装成硬约束。
- 一个小迭代同时追多个结果，最后往往没有任何一项产生可解释变化。
行动建议
今天用一页表完成取舍，并让所有相关方看到机会成本。
先定一个版本主结果
明确本迭代只保护激活、留存、转化、稳定性或效率中的一个结果，同时单列不可回避的合规与故障项。
把 20 个需求改写并归类
每项写成“为哪类用户，在什么场景，改变哪个行为或指标”，补上证据、预期收益和不做的真实损失。
只保留主攻项和风险项
选择一个最可能解除当前阻塞的需求，加一个必须修的风险项；其余明确标记后置、降级、合并或拒绝。
决策条件
按约束、结果贡献、证据和可逆性依次拍板。
- 立即进入版本：属于法律合规、核心故障等硬约束，或直接解除本版本主结果的最大阻塞。
- 降级验证：潜在收益高但证据不足，先用原型、人工流程或小流量验证。
- 进入下个版本：价值成立，但与本版本主结果无直接关系。
- 明确拒绝：没有目标用户、行为证据和不做损失，只是相关方偏好。
常见问题
需求排序前需要先定什么？
- 需求优先级应该先用 RICE 评分吗？
- 不要先评分。先确认本版本要改变的唯一业务结果、必须处理的合规或稳定性硬约束，再比较候选需求对该结果的贡献、证据与机会成本。
- 研发资源不足时应该保留几个需求？
- 资源很紧时，优先保留一个能解除当前核心阻塞的主需求和一个必须处理的风险项；其余需求明确后置、降级、合并或拒绝。