需求分析阶段：如何识别伪需求、需求优先级排序方法（RICE/ICE模型）、需求文档（PRD）的撰写规范
需求分析，说白了就是数据产品的「地基」。
我见过太多项目，地基没打好就急着盖楼。结果呢？楼盖到一半发现客户要的根本不是这玩意儿。返工、扯皮、延期，最后产品成了烂尾楼。
这一章，咱们就聊聊怎么把需求分析这步做实。我会把我在项目中踩过的坑、总结的方法，一股脑倒出来。
一、识别伪需求：别被「想要」骗了
伪需求是什么？就是用户嘴上说「我要A」，但实际需要的是「B」。
举个例子。我之前对接过一个业务方，上来就说：「我要一个实时大屏，展示所有订单数据。」听起来很合理对吧？
我多问了一句：「你拿到这个数据之后，下一步做什么？」
他愣了：「嗯……我其实是想知道今天哪个区域的订单异常，好及时调整配送资源。」
你看，他真正需要的是「异常预警+区域下钻」，而不是一个花里胡哨的大屏。这就是典型的伪需求。
识别伪需求的三个核心问题：
- 「然后呢？」——拿到这个数据后，下一步动作是什么？
- 「解决什么问题？」——这个需求对应哪个业务痛点？
- 「不做会怎样？」——如果这个需求不做，业务会受多大影响？
我习惯在需求评审会上，把这三个问题贴在白板上。谁提需求，先过这三关。过不了的，直接打回。
我的小技巧：让业务方用「用户故事」的方式描述需求。格式是：「作为<角色>，我想要<功能>，以便<价值>。」如果「以便」部分说不清楚，大概率是伪需求。
二、需求优先级排序：RICE 和 ICE 模型
需求多了怎么办？排优先级。
我早期做数据产品时，全靠「拍脑袋」。哪个业务方嗓门大，就先做哪个。结果呢？资源全耗在「面子工程」上，真正有价值的需求反而被搁置。
后来我引入了两个模型：RICE 和 ICE。说白了，就是用公式把「优先级」算出来。
2.1 RICE 模型
RICE 是四个维度的首字母缩写：
| 维度 | 含义 | 评分标准（1-10分） |
|---|---|---|
| Reach（覆盖） | 这个功能会影响多少人？ | 1分=仅个别人；10分=全公司/全平台 |
| Impact（影响） | 对单个用户的影响程度？ | 1分=轻微改善；10分=核心痛点解决 |
| Confidence（信心） | 你有多大把握这个需求是真实的？ | 1分=纯猜测；10分=有数据/用户调研支撑 |
| Effort（投入） | 开发需要多少人力/时间？ | 1分=极大投入；10分=极小投入（注意：Effort越高，优先级越低） |
计算公式：RICE Score = (Reach × Impact × Confidence) / Effort
得分越高，优先级越高。
注意：Confidence 这个维度很容易被忽略。我见过有人给一个「我觉得用户需要」的需求打了9分信心分，结果上线后日活为0。后来我规定：没有数据支撑的 Confidence 分，最高只能打3分。
2.2 ICE 模型
ICE 是 RICE 的简化版，适合快速排序：
| 维度 | 含义 |
|---|---|
| Impact（影响） | 同RICE的Impact |
| Confidence（信心） | 同RICE的Confidence |
| Ease（易实施） | 实现难度如何？1分=极难；10分=极简单 |
计算公式：ICE Score = (Impact × Confidence × Ease) / 3
ICE 适合在需求评审会上快速打分。我一般让产品、开发、业务三方各打一次，取平均值。
我的经验：RICE 适合做「战略级」排序，比如季度规划。ICE 适合做「战术级」排序，比如迭代排期。两个模型可以结合使用：先用 RICE 筛出高价值需求，再用 ICE 排开发顺序。
三、PRD 撰写规范：让开发少骂你两句
PRD（产品需求文档）是数据产品经理的「命根子」。写得好，开发效率翻倍；写得烂，开发天天找你「对需求」。
我早期写的 PRD 被开发吐槽过：「你这文档我看完还是不知道要做什么。」后来我总结了一套规范，分享给你。
3.1 PRD 的核心结构
| 模块 | 内容 | 示例 |
|---|---|---|
| 1. 背景与目标 | 为什么要做这个功能？解决什么问题？ | 「当前运营团队无法实时监控活动效果，导致调整滞后。本功能旨在提供活动核心指标的实时看板。」 |
| 2. 用户故事 | 谁在用？怎么用？ | 「作为运营主管，我希望看到每个活动的实时UV和转化率，以便及时调整投放策略。」 |
| 3. 功能描述 | 具体做什么？ | 「提供活动列表页，支持按时间、活动名称筛选。点击活动名称进入详情页，展示UV、转化率、ROI等指标。」 |
| 4. 数据规范 | 数据来源、口径、更新频率 | 「UV来自埋点系统，口径为当日去重设备数，每5分钟刷新一次。」 |
| 5. 验收标准 | 怎么算做完？ | 「列表页加载时间不超过2秒；数据延迟不超过5分钟；支持导出Excel。」 |
| 6. 附录 | 原型图、流程图、参考文档 | 「详见附件：活动看板原型_v2.3.pdf」 |
3.2 数据产品 PRD 的特殊要求
数据产品和普通功能产品不一样。你想想看，开发一个「按钮」和开发一个「数据看板」，复杂度完全不是一个量级。
数据产品的 PRD 必须额外包含：
- 数据血缘图：数据从哪里来？经过哪些清洗？最终怎么展示？
- 指标口径定义：每个指标的计算公式、取数逻辑、排除规则。我见过因为「活跃用户」口径不一致，产品和开发吵了三天。
- 异常处理机制：数据延迟了怎么办？数据缺失了怎么展示？
- 权限与安全：谁可以看？谁可以导出？
PRD 撰写「三要三不要」：
- 要：用「用户故事」描述需求，让开发理解业务场景。
- 要：用「验收标准」明确边界，避免扯皮。
- 要：用「原型图」辅助说明，一图胜千言。
- 不要：写「类似淘宝那样」——淘宝哪个功能？哪个页面？
- 不要：写「尽快上线」——尽快是多快？
- 不要：写「支持所有格式」——所有格式是哪些？
四、知识体系总览
下面这张图，把本章的核心逻辑串起来了。你可以把它当作需求分析的「作战地图」。
五、避坑指南
最后，分享几个我亲身踩过的坑。
我曾经……接手一个数据平台项目，业务方提了50多个需求。我按RICE模型排完序，发现Top 3需求占了80%的价值。但业务方不干了，说「我每个需求都很急」。后来我用了「成本-价值矩阵」，把每个需求的投入产出比算出来，业务方自己就放弃了那些「高投入低价值」的需求。
教训：优先级排序不是「说服业务方」，而是「用数据让业务方自己说服自己」。
另一个坑：PRD写得太细，开发反而看不懂。我后来学乖了：PRD的「功能描述」部分，用「用户操作流程」代替「功能列表」。比如：「用户进入页面 → 看到活动列表 → 点击活动名称 → 进入详情页 → 看到指标数据」。开发一看就明白，不用来回确认。
嗯，需求分析这块，说白了就是「想清楚再动手」。别急着写代码，先把需求理清楚。你省下的时间，远比花在「返工」上的时间多。