需求分析、优先级与版本范围

玩家想要排行，你想加皮肤，测试又发现有人丢进度。三件事都有理由，但本周只够做一件。给每件事打分，最高的就应该先做吗？

本篇帮助你从诉求追到问题，再用当前目标、证据和约束决定版本范围。以下数字均为模拟练习。

为什么先比较问题，而不是功能名字

“加排行榜”已经选定方案，背后可能是比较能力、分享巧解，也可能只是想知道总共多少关。先还原影响谁、何时发生、频率、损失、现有替代和证据，才知道它与存档问题是否在解决同一种目标。

丢失进度可能低频，却直接破坏退出后继续的承诺；皮肤可能覆盖所有人，但未必改善当前最危险的障碍。覆盖人数不能独自决定先后。先处理合规阻断、严重资产或数据错误和主流程无法进入等必要条件，再比较可选机会。

假设本阶段要确认首次玩家能独立开始。路径反馈不清直接影响这个目标，皮肤则要证明它如何改变理解。选皮肤的代价不只是三人天，还包括这三天无法获得引导证据。

MoSCoW 的“必须有”，应指删掉后当前目标无法成立；“接下来”和“以后”保存可选方向。若所有项目都是必须有，分类就没有帮助你做选择。

Intercom 的 RICE用覆盖、影响、信心和工作量比较机会：Reach × Impact × Confidence / Effort。直观上，一项变化帮助更多人、对每人更重要，预期收益就更大；依据薄弱时要折减；占用资源越多，每单位投入能换来的收益越小。

下面采用相同周窗口、相同影响量表与人天单位，量表是本练习自定，不是原框架的标准阈值：

候选	覆盖	影响	信心	工作量	分数
引导改进	100 人	2	0.7	2 人天	70
皮肤	30 人	1	0.3	3 人天	3

70 不是预计新增七十名用户，影响评分也不是转化率；它只是统一假设下的比较值。真正值得讨论的是：为什么相信覆盖一百人，影响为何是二，若工作量翻倍排序是否仍成立？

早期依据很少时，使用区间或小中大，比给出小数更诚实。对会推翻计划的未知，也可以先按“重要且不确定”排序，优先研究，而非直接开发。

只做进入和游玩、没有结束和恢复，可能让你无法检查短暂休息的体验。更有用的窄版本是：少量题，但进入、理解、游玩、结束、退出恢复能完整走通。范围同时写设备、数量、异常和暂不支持的情况，才不会用“很小”掩盖缺口。

新想法进入时，写清替换什么、增加多少成本、影响哪项验收与日期。“顺手加一下”如果不支付机会成本，就会不断挤压已承诺的质量。需求池是候选集合，不是承诺清单；长期缺证据的项可以注明原因后归档。

一个高分活动若依赖尚未存在的奖励系统，总成本要把依赖算进去。隐私、存档安全等必要条件也不能因覆盖人数少而被低分淘汰。战略不同，影响量表就应重设，不能跨目标比较旧分数。

练习：列十项功能，逐一改写为问题。为当前版本只选支撑同一个学习目标的一组，写三个删减项和撤回条件，进入 PRD 模板。