需求分析怎么做？我踩了18人日坑后，把PRD从30页砍到1张图+5条验收样本
先说个反常识的：需求分析做得越“完整”，项目死得越快。我2021年做跨境电商ERP采购模块，PRD写了30页，评审会开了120分钟，开发做了18人日，上线30天使用率只有4.7%。不是开发不努力，是我们把“用户说的方案”当成了“用户要的结果”。后来我把需求分析改成“证据—约束—验收样本”三层漏斗，同样的功能，评审压到45分钟，返工从26人日降到9人日，7日使用率做到63%。所以这篇文章不给你模板，给你一套能落地的检查动作。
一、需求分析不是写文档，是把愿望翻译成可验收的约束
我见过太多团队把需求分析干成了文档比赛。PRD 从 12 页卷到 38 页，Axure 原型画了 27 个页面，结果开发问“异常流程呢”，测试问“权限怎么判”，业务方说“这不是我要的”。这三个问题其实是一个问题：需求没有变成可验证的约束。我的独立观点是，需求分析的核心不是“收集需求”，而是“降低错误决策的成本”。具体做法是三层漏斗：第一层场景证据，至少访谈 7 个真实用户，记录原话而不是标签；第二层行为约束，写清楚触发条件、角色、频率、耗时、输入输出；第三层验收样本，正常 2 条，异常至少覆盖空值、超时、权限、重复提交、并发 5 类。每层不过关，就别进评审。
二、对比：30页PRD vs 1张用户故事地图+5条验收样本
我们做过一次 A/B 式对照。旧流程：30 页 PRD，评审 120 分钟，需求变更 11 次，返工 26 人日，上线 30 天使用率 4.7%。新流程：1 张用户故事地图，5 条 Given/When/Then 验收样本，评审 45 分钟，变更 4 次，返工 9 人日，使用率 63%。差距不在工具，而在分析顺序。旧流程先写功能清单，再补场景；新流程先画任务流，再切功能。任务流至少标 3 个东西：角色、频率、卡点。比如采购审批流有 5 级审批，字段 47 个，供应商平均每月导出 Excel 1.3 次。如果只写“支持导出”，开发可能做 3 天，但如果写“审批通过后，采购员按供应商维度导出 47 个字段中的 12 个，文件小于 5MB，失败提示重试”，返工就少很多。RICE 也可以算：Reach 1200，Impact 2，Confidence 80%，Effort 15 人日，RICE=128，超过 100 才排进季度。
三、To B 和 To C 的需求分析，根本不是一套打法
To C 需求分析像追热点，看漏斗、看埋点、看 A/B。注册转化率从 38% 掉到 29%，你拆 5 步漏斗，每步看流失，可能 1 天就找到问题。To B 需求分析像拆炸弹，因为买单的人、使用的人、审批的人经常不是同一个人。我吃过这个亏。2021 年那个 ERP，我们以为供应商要“批量导入”，花 18 人日做了导入功能。后来访谈 12 家供应商，9 家说真正痛点是报价单 Excel 格式不统一，导入进来还要手工改 20 分钟。我们改成 3 个模板加 12 条校验规则，使用率从 4.7% 拉到 63%。所以 To B 先画责任链，不是用户旅程：谁发起、谁审批、谁录入、谁背 KPI、谁最后骂人。To C 先画行为漏斗，To B 先画责任链。这个观点可能不讨喜，但能省人日。
四、我常用的 6 步法和 12 项评审清单
步骤不复杂，难的是每步都留证据。1）收集原始素材：访谈 7-12 人，录音转文字，原话贴进表格，不打“用户想要”这种标签。2）还原任务流：从触发到完成，标角色、频率、耗时，超过 5 步就考虑砍。3）写非目标：至少 5 条“这次不做”，比如不做移动端、不做多语言、不做自定义公式。4）写验收样本：正常 2 条，异常 5 类，写成 Given/When/Then。5）排优先级：RICE 公式算，Effort 用人日，Confidence 低于 50% 先验证。6）反述确认：让业务方用自己的话说一遍，不一致就重写。评审清单 12 项：目标用户、场景、触发条件、输入输出、权限、异常、性能、埋点、兼容、依赖、验收样本、非目标。会议控制在 45 分钟，每个需求不超过 3 个角色，验收一次通过率目标 85%，需求变更率目标低于 15%。
五、工具和指标：别让 Jira 变成墓碑
工具我常用 Jira 管需求状态，Confluence 写决策记录，Figma 画关键页，Xmind 拆任务流，Miro 做故事地图，SQL 和神策/Mixpanel 看行为。但工具不是重点。我盯的指标就 4 个：需求变更率、返工工时、验收一次通过率、上线 7 日使用率。B 端 7 日使用率能到 20%-30% 就不错，C 端低于 30% 就要复盘。埋点事件命名要统一，比如 page_view、click_export、export_success、export_fail。我到现在也会漏掉并发和权限边界，别装，漏了就补。需求分析很烦，像在雾里找路，但它省下的不是文档时间，是团队信心。下次评审前，先问一句：这条需求，7 天后用什么数字证明它有用？答不上来，就先别开发。