3. PRD的通用结构
写PRD这事儿，我做了快十年了。说实话，见过太多产品经理把PRD写成「流水账」——想到哪儿写到哪儿，评审会上被开发怼得哑口无言。为什么会这样？因为缺了骨架。
今天我就把PRD的通用结构掰开揉碎了讲。你记住这个骨架，以后写任何PRD都不会跑偏。
3.1 PRD的骨架：背景、目标、范围、功能、非功能
我个人习惯把PRD分成五个核心模块。这五个模块就像人的骨架，缺一不可。
| 模块 | 核心问题 | 常见坑点 |
|---|---|---|
| 背景 | 为什么要做这个功能？ | 写得太虚，全是「提升用户体验」这种空话 |
| 目标 | 做成什么样才算成功？ | 目标不可量化，评审时无法对齐 |
| 范围 | 做什么？不做什么？ | 范围边界模糊，开发容易做过头或漏做 |
| 功能 | 具体怎么实现？ | 细节缺失，开发只能靠猜 |
| 非功能 | 性能、安全、兼容性怎么办？ | 完全忽略，上线后出事故 |
3.1.1 背景：别让开发猜你的动机
背景部分，说白了就是「讲故事」。你要让开发、测试、运营看完就知道——哦，原来我们为什么要做这个。
我在项目中遇到过最离谱的背景描述：「用户反馈不好用，所以我们要优化。」这等于什么都没说。你想想看，开发看到这种背景，他该怎么理解需求？
好的背景应该包含：
- 数据支撑：比如「首页跳出率从30%升到了45%」
- 用户场景：比如「用户在支付环节平均等待8秒」
- 业务价值：比如「预计提升转化率2个百分点」
核心原则：背景要能回答「不做会怎样」这个问题。
3.1.2 目标：用数字说话
目标这块，我建议你直接上数字。别写「提升用户体验」，要写「支付成功率从92%提升到96%」。
为什么？因为数字才能对齐。我记得有一次评审，我说目标是「优化加载速度」，前端说「我觉得现在挺快的」，后端说「服务器压力大没办法」。吵了半小时没结果。后来我把目标改成「首屏加载时间从3秒降到1.5秒以内」，所有人闭嘴了。
目标通常分两类：
- 业务目标：DAU、转化率、留存率等
- 技术目标：响应时间、并发量、可用性等
小技巧：目标不要超过3个。超过3个，说明你没想清楚优先级。
3.1.3 范围：画好你的「圈」
范围是PRD里最容易出问题的地方。说白了，你要明确告诉团队：哪些做，哪些不做。
我曾经吃过一次大亏。当时写了一个搜索功能的PRD，只写了「支持关键词搜索」。结果开发把全文检索、模糊匹配、拼音搜索全做了，工期翻了三倍。为什么？因为我没有写「不做什么」。
范围部分建议这样写：
- 包含范围：明确列出本次要做的所有功能点
- 不包含范围：明确列出本次不做但未来可能做的功能
- 边界条件：比如「仅支持iOS端，Android端后续版本」
注意：范围变更一定要走流程。我见过太多项目因为「顺手加个小功能」导致延期。
3.1.4 功能：细节决定成败
功能描述是PRD的核心。这里我建议你用「用户故事+验收标准」的写法。
举个例子：
用户故事：
作为一个注册用户
我希望在输入手机号后能收到验证码
以便我能完成账号注册
验收标准：
1. 输入11位手机号后，点击「获取验证码」按钮
2. 按钮变为60秒倒计时，不可重复点击
3. 验证码在60秒内发送到手机
4. 输入正确验证码后，跳转到设置密码页面
5. 输入错误验证码，提示「验证码错误，请重新输入」
嗯，这里要注意：验收标准一定要写清楚异常情况。比如「网络超时怎么办？」「验证码发送失败怎么办？」这些细节，开发不会替你想。
3.1.5 非功能：容易被忽略的「隐形需求」
非功能需求，说白了就是「功能之外的品质要求」。很多产品经理会忽略这块，结果上线就出事故。
我建议非功能需求至少包含：
- 性能：接口响应时间、并发用户数、数据量上限
- 安全：数据加密、权限控制、防刷机制
- 兼容性：支持哪些浏览器、哪些手机型号
- 可维护性：日志记录、监控告警、配置管理
避坑指南：我曾经因为没写「验证码接口需要防刷」，上线后被黑产用脚本刷了10万条短信，直接损失5000块。从那以后，非功能需求我一个字都不敢省。
3.2 PRD的版本管理
版本管理这事儿，看着简单，但做好的团队真不多。我见过最夸张的，一个PRD文件夹里有「最终版」「最终版2」「最终版3」「打死不改版」……
我个人习惯用语义化版本号：
| 版本号 | 含义 | 示例 |
|---|---|---|
| v0.1 - v0.9 | 草稿阶段，内部讨论 | v0.3：初稿完成，待评审 |
| v1.0 | 首次正式发布 | v1.0：评审通过，进入开发 |
| v1.1 - v1.9 | 小范围修改 | v1.2：修复了3个逻辑错误 |
| v2.0 | 重大变更 | v2.0：需求范围调整，重新评审 |
每次修改，我要求在文档头部加一个变更记录：
## 变更记录
| 版本 | 日期 | 修改人 | 修改内容 |
|------|------|--------|----------|
| v1.0 | 2024-01-15 | 张三 | 初始版本 |
| v1.1 | 2024-01-18 | 张三 | 修改验证码倒计时逻辑 |
| v1.2 | 2024-01-20 | 李四 | 增加异常处理场景 |
小技巧：每次修改后，在群里@所有人，并附上「变更摘要」。别让大家自己去对比差异。
3.3 PRD的评审流程
评审这事儿，我踩过的坑比走过的路还多。总结下来，评审流程就三步：
3.3.1 预评审：别直接上大评审
我建议你先找技术负责人过一遍。为什么？因为大评审会上，如果技术负责人发现重大逻辑问题，整个会就废了。
预评审要做的事：
- 确认技术可行性
- 对齐核心逻辑
- 预估工作量
3.3.2 正式评审：控制节奏
正式评审会，我建议控制在1小时内。超过1小时，大家的注意力就散了。
评审流程：
- 背景介绍（5分钟）：讲清楚为什么要做
- 功能演示（20分钟）：按用户流程走一遍
- 技术讨论（20分钟）：开发、测试提问题
- 结论确认（5分钟）：通过/有条件通过/不通过
注意：评审会上不要当场改PRD。记下问题，会后统一修改，再发新版。
3.3.3 评审后：闭环最重要
评审结束不代表完事了。你要做三件事：
- 发出评审纪要（含所有待办事项）
- 更新PRD版本号
- 确认下次评审时间（如果有）
我记得有一次评审通过了，但有个技术方案没定下来。我以为开发会自己搞定，结果两周后才发现他们用了错误方案。从那以后，所有待办事项我都会在第二天跟进。
核心总结：PRD的骨架决定了文档的质量，版本管理决定了协作的效率，评审流程决定了落地的成功率。三者缺一不可。