需求池里每个功能都有人说“很重要”：销售说客户要，老板说竞品有，运营说能增长，研发说必须重构。最后版本越做越大，核心任务反而没有做好。
优先级不是一个万能公式，而是一套让取舍公开、可解释、能被新证据修正的过程。
01 先明确本阶段只解决什么问题
同一个功能，在“验证需求”“提高留存”“扩大收入”“降低成本”四种阶段中的优先级完全不同。没有阶段目标，评分会把不相关的价值混在一起。
用一两个可衡量结果约束版本，例如“让新用户在10分钟内完成首个订单”，而不是“提升体验”。
02 把功能改写成用户任务和结果
“增加消息中心”是方案，不是问题。先写清谁在什么场景下缺少什么信息，导致什么后果，再判断消息中心是否是最小解法。
需求描述越接近真实任务，越容易发现更轻、更快的替代方案。
功能优先级评估维度
| 维度 | 要问的问题 | 常见偏差 |
|---|---|---|
| 用户价值 | 解决多大痛点，影响多少目标用户 | 把少数大客户声音当全部用户 |
| 业务价值 | 影响收入、留存、效率还是合规 | 所有价值都写成“提升转化” |
| 证据强度 | 有数据、访谈、实验还是猜测 | 把自信程度当事实 |
| 成本与依赖 | 设计、开发、数据、运营成本多大 | 只估开发，不算上线后维护 |
| 风险 | 安全、合规、品牌与失败影响 | 只看成功收益，不看损失 |
| 时效 | 是否有政策、合同或市场窗口 | 长期愿望被包装成紧急 |
03 评分模型用于讨论，不用于自动决策
RICE、ICE、MoSCoW都可以使用，但分数来自假设。应在评审会上说明数据来源、置信度和依赖，而不是把小数点当作客观真理。
对于安全、合规和系统稳定等“必须做”事项，可以单独设门槛，不与增长功能简单竞争分数。
04 先做薄切片，验证整条价值链
MVP不是把每个模块都做得简陋，而是用最小范围跑通核心任务。支付流程可以先支持一种方式，但从选择到结果必须完整。
只有半个流程的功能无法验证价值，还会积累大量临时状态。
05 考虑依赖和组合，不孤立看单项
某个功能分数很高，但依赖数据治理、权限或基础组件，就需要把依赖纳入路线图。多个小功能组合后才能形成价值，也应作为一个主题评估。
路线图用目标和问题组织，比用一长串功能名称更利于团队理解。
06 上线后回看假设，更新评分
记录每项功能当初的价值假设、成功指标和成本预估。上线后比较实际使用、业务结果和维护成本。
长期不复盘，团队会不断高估新功能、低估优化和删除旧功能的价值。
常见问题
哪个优先级模型最好？
没有万能模型。小团队可用价值/成本矩阵，数据较成熟时使用RICE；关键是口径一致和定期复盘。
老板指定的功能还需要评估吗？
可以执行，但仍应写清目标、成本、风险和成功标准，避免后续无法判断效果。
客户提出的需求应该马上做吗？
先判断是否代表目标市场、是否有替代方案、是否影响续费或合同，再决定。
技术债如何进入优先级？
将其转化为稳定性、开发效率、安全和业务风险，用可衡量影响参与规划；严重风险可设为必须项。
功能做完没人用怎么办？
检查发现入口、使用场景和原始假设。若价值不成立，应敢于合并、下线或停止继续投入。
链接复制成功
