产品经理课程 · 第三阶段：项目管理
📝 13 - 需求文档PRD
模板+功能规格+非功能需求+验收标准
📋 本章导读
PRD是PM最重要的交付物——开发、测试、设计都依赖它来理解"做什么"和"怎么做"。但好的PRD不是长篇大论，而是"刚刚好"的精准表达。本章从模板出发，覆盖功能规格、非功能需求、验收标准，帮你写出让开发能执行、让测试能验证的PRD。
🎯 学习目标
- 掌握PRD的8大核心模块
- 学会用户故事的Given/When/Then写法
- 理解功能需求与非功能需求的区别
- 能编写可验证的验收标准
一、PRD八要素：一个都不能少
| 模块 | 内容 | 常见遗漏 |
|---|
| 1. 背景与目标 | 为什么要做？预期业务价值？ | 只说"老板要的"，不说为什么 |
| 2. 目标用户 | 给谁用？主要场景？ | 假设所有用户都一样 |
| 3. 用户故事 | As a...I want...So that... | 只有功能描述没有用户视角 |
| 4. 功能规格 | 详细功能说明+交互流程 | 只写正常流，异常流靠开发猜 |
| 5. 非功能需求 | 性能/安全/可用性/兼容性 | 完全忽略，上线后才暴露 |
| 6. 验收标准 | Given/When/Then | "功能正常"这种无法验证的标准 |
| 7. 数据埋点 | 要采集哪些行为数据 | 上线后才发现没有数据 |
| 8. 里程碑 | 关键节点和交付计划 | 没有时间锚点 |
二、用户故事：Given/When/Then
验收标准最清晰的写法是Given/When/Then（GWT），它让测试用例从需求文档直接生成。
📋 GWT验收标准模板
用户故事：作为用户，我可以用优惠券下单
验收标准1：正常使用优惠券
Given：用户有1张满50减10元的优惠券
When：用户购买商品金额为60元，选择使用该优惠券
Then：订单金额显示为50元，优惠券状态变为已使用
验收标准2：不满足使用条件
Given：用户有1张满50减10元的优惠券
When：用户购买商品金额为30元，尝试使用该优惠券
Then：优惠券显示为不可选状态，提示"需满50元才可使用"
验收标准3：优惠券已过期
Given：用户有1张已过期的优惠券
When：用户查看优惠券列表
Then：该优惠券显示"已过期"标签，不可选择使用
验收标准4：多张优惠券
Given：用户有3张可用优惠券
When：用户进入优惠券选择页面
Then：按优惠力度从大到小排序，默认选中优惠力度最大的
三、非功能需求：上线前必须想清楚
🔧 非功能需求清单
| 类别 | 需求项 | 示例 | 遗漏后果 |
|---|
| 性能 | 响应时间/并发量/吞吐量 | 首页加载<2s，接口<500ms | 用户体验差，用户流失 |
| 安全 | 数据加密/权限控制/审计 | 密码BCrypt加密，JWT鉴权 | 数据泄露，法律风险 |
| 可用性 | SLA/容灾/降级 | 99.9%可用性，故障自动切换 | 服务不可用，业务中断 |
| 兼容性 | 浏览器/设备/OS版本 | iOS 14+，Android 10+ | 部分用户无法使用 |
| 可维护性 | 日志/监控/告警 | 关键操作记录日志，异常自动告警 | 出问题无法定位 |
| 可扩展性 | 数据量/用户量增长 | 支持10倍用户增长 | 重构成本远超预期 |
四、数据埋点清单：上线即有数据
📋 埋点设计模板
事件名：coupon_apply（优惠券使用）
触发时机：用户点击"使用优惠券"按钮
属性：
- coupon_id：优惠券ID
- coupon_type：优惠券类型（满减/折扣/立减）
- coupon_value：优惠金额
- order_amount：订单原价
- apply_result：使用结果（成功/不满足条件/已过期）
- error_msg：失败原因（仅失败时）
事件名：order_complete（订单完成）
触发时机：支付成功回调
属性：
- order_id：订单ID
- order_amount：实付金额
- used_coupon：是否使用优惠券
- coupon_discount：优惠金额
- payment_method：支付方式
五、案例深度拆解：微信红包PRD
🧧 微信红包：3天上线、PRD仅2页的传奇
2014年春节，微信红包功能从想法到上线只用了3天，PRD只有2页纸。但这两页纸包含了所有关键信息。
- 核心用户故事：过年时想给朋友发红包，但不在身边
- 关键决策：红包金额1-200元（不是任意金额，减少风险和复杂度）
- 异常流：余额不足→引导充值；24小时未领取→自动退款
- 非功能需求：峰值QPS 10万+（当时微信支付的总承载能力）
- 数据埋点：发红包数/领取数/金额/分享率
💡 微信红包PRD的启示：好的PRD不在长度，在于是否包含了"做这个功能的全部必要信息"。2页纸能上线，是因为团队理解了"为什么做"和"核心约束是什么"，而不是因为省略了重要内容。
🧪 练习1：GWT验收标准
写一个"用户评论"功能的3条GWT验收标准，覆盖正常场景、边界场景和异常场景。
🧪 练习2：完整PRD
为"活动报名"功能写一份完整PRD，包含8大模块。重点关注：非功能需求至少5项，埋点事件至少3个。
🧪 练习3：PRD评审
拿你写好的PRD给1位开发、1位测试、1位设计看，记录他们每个人的3个问题。这些问题就是你PRD的盲区。
🏆 本章成就
- ✅ PRD架构师 — 8大模块一个不漏
- ✅ GWT高手 — 用Given/When/Then写出可验证的验收标准
- ✅ 非功能意识者 — 性能/安全/可用性上线前就想清楚
- ✅ 数据先行者 — 上线即有数据，不留埋点盲区
六、PRD写作风格指南
✍️ 写出让开发爱看的PRD
- 清晰>完整>精美：开发最需要知道的是"做什么、为什么、怎么做、怎么验证"——这四点清楚，PRD就是好的
- 一张图>一段话>一句话：能用流程图说明的不用文字，能用表格说明的不用段落
- 先写为什么再写做什么：上下文比细节更重要——开发理解了"为什么"能自己处理50%的边界情况
- 版本记录不可少：每次修改记录"改了什么、为什么、谁确认的"——口头约定0价值
- 链接而非复制：设计稿、API文档、测试用例用链接引用，不要在PRD里重复——避免不一致
📚 PRD推荐阅读
- 《Inspired》Marty Cagan — 产品需求文档的最佳实践
- 《Writing Better PRDs》strong>来自顶级PM的PRD写作指南
- Amazon的"Working Backwards" — 从新闻稿出发写PRD的方法
💡 PRD的核心心法：PRD是契约不是散文。好的PRD让开发看了就能干活、测试看了就能写用例、设计看了就知道约束。如果一个人看了PRD还要来问你3个以上问题，说明PRD还不够清晰。
七、Amazon的"Working Backwards"PRD方法
📝 从新闻稿开始写PRD
Amazon的Working Backwards方法要求在写PRD之前先写一份"未来发布的新闻稿"——假设功能已经上线了，你会怎么向用户介绍？
- 新闻稿结构：标题→问题→解决方案→引言→使用方式→用户引言→起步方式
- 核心价值：如果写不出有吸引力的新闻稿，说明需求本身不够有价值
- 用户引言：用用户语言描述价值——"以前我需要XX，现在只需要YY"
- 从后向前：先定义期望的结果（新闻稿），再倒推需要做什么（PRD）
八、PRD的版本管理
📋 PRD版本规范
版本号规则：Major.Minor.Patch
Major：需求方向变更（如砍掉一个功能模块）
Minor：新增或修改功能点（如增加一种支付方式）
Patch：文字修正、格式调整
每次修改记录：
v2.3.0 | 2024-03-15 | 张三 | 新增微信支付方式
v2.2.1 | 2024-03-12 | 李四 | 修正验收标准措辞
v2.2.0 | 2024-03-10 | 张三 | 新增优惠券使用功能
变更通知：
Minor及以上变更 → 通知开发+测试+设计
Patch变更 → 通知相关开发即可
Major变更 → 召开变更评审会
⚠️ PRD最致命的5个遗漏
- 空状态：第一次打开时页面是什么样？没有数据时显示什么？→用户看到空白页=懵了
- 加载状态：数据加载时显示什么？骨架屏？转圈？→用户看到白屏=以为卡了
- 错误状态：操作失败显示什么？能重试吗？→用户看到报错=以为产品坏了
- 权限边界：未登录/无权限/过期用户看到什么？→开发自行处理=体验不一致
- 数据边界：超长文本？0值？负数？特殊字符？→开发自行处理=线上出bug
✅ PRD自查清单
- □ 每个功能有用户故事？
- □ 每个功能有GWT验收标准？
- □ 空状态/加载态/错误态都描述了？
- □ 非功能需求至少5条？
- □ 埋点事件至少3个？
- □ 异常场景至少5个？
- □ 边界条件（超长/0值/特殊字符）都考虑了？
- □ 版本记录完整？