似水流年一场“鸡同鸭讲”的会议
我曾经参加过一场让我印象深刻的需求评审会。
业务方说：「我们需要一个智能的客户管理功能，要能识别高价值客户。」
开发方问：「什么叫智能？什么叫高价值？有什么具体指标吗？」
业务方说：「就是那种……你懂的，重要的客户」
开发方：「……」
这场会开了3个小时，两边都很累，但什么也没定下来。问题出在哪里？缺一份PRD。
PRD是什么？
不好的PRD：「系统要能识别高价值客户」
好的PRD：「系统根据RFM模型计算客户价值分，分数>80为A级客户，60-80为B级客户，<60为C级客户，并在客户详情页显示分级标签」
PRD的标准结构
一份完整的PRD通常包含以下部分：
| 章节 | 内容 | 写给谁看 |
|---|---|---|
| 1. 概述 | 背景、目标、范围 | 所有人 |
| 2. 用户与场景 | 用户角色、用户故事 | 设计、开发 |
| 3. 功能需求 | 功能列表、优先级 | 开发 |
| 4. 业务规则 | 逻辑、公式、条件 | 开发、测试 |
| 5. 界面原型 | 线框图、交互说明 | 设计、开发 |
| 6. 非功能需求 | 性能、安全、兼容 | 开发、运维 |
| 7. 验收标准 | 如何判断做完了 | 测试、业务 |
实战模板：客户流失预警功能PRD
1. 概述
背景： 当前客户流失发现滞后，往往流失后才知道，挥回成本高、成功率低。
目标： 实现客户流失风险的提前预警，降低流失率20%。
范围： 本阶段实现风险识别和预警推送，不包含自动干预。
2. 用户与场景
用户角色：
- 服务顾问：接收预警，执行干预
- 客服主管：查看预警汇总，跟踪干预效果
用户故事（User Story）：
- 作为服务顾问，我需要收到高风险客户预警，以便及时联系干预
- 作为客服主管，我需要看到预警数据看板，以便了解整体风险状况
3. 功能需求
| 功能 | 说明 | 优先级 |
|---|---|---|
| 风险识别 | 每日自动计算客户流失风险分 | P0 |
| 预警推送 | 风险超阈值时推送给SA | P0 |
| 预警看板 | 显示各级别风险客户数量 | P1 |
| 干预记录 | 记录SA的干预行为和结果 | P1 |
优先级说明：
- P0 = Must have（必须有），不做就不能上线
- P1 = Should have（应该有），建议本期做
- P2 = Nice to have（有了更好），后期迭代
4. 业务规则（最重要的部分！）
规则1：风险分计算公式
流失风险分 = 进店间隔分(40%) + 消费金额分(30%) + 满意度分(20%) + 投诉分(10%)
规则2：各维度评分标准
| 进店间隔 | 分值 |
|---|---|
| <30天 | 0 |
| 30-60天 | 20 |
| 60-90天 | 50 |
| 90-180天 | 80 |
| >180天 | 100 |
规则3：预警分级与响应
| 风险分 | 预警级别 | 响应时效 | 响应方式 |
|---|---|---|---|
| ≥60 | 无预警 | - | - |
| 60-75 | 黄色 | 7天内 | 短信+APP |
| 75-90 | 橙色 | 3天内 | 电话回访 |
| >90 | 红色 | 24小时 | 店长介入 |
5. 界面原型要点
预警列表页：
- 默认显示红色+橙色预警
- 支持按风险级别筛选
- 显示客户姓名、联系方式、风险分、上次进店日期
- 支持一键拨打电话
客户详情页：
- 显示风险分组成（雷达图）
- 显示流失风险趋势（近三个月）
- 显示历史干预记录
6. 非功能需求
| 类别 | 要求 |
|---|---|
| 性能 | 风险计算在每日凌晨4点完成，耗时<2小时 |
| 安全 | 客户信息只对分配的SA可见 |
| 兼容 | 支持iOS/Android APP和PC端 |
7. 验收标准（Definition of Done）
- 风险分计算结果经业务抽样验证，准确率>85%
- 预警推送延迟<5分钟
- 通过功能测试、性能测试、UAT用户验收测试
PRD写作的常见坑
核心认知
PRD的本质价值：
- 消除歧义：让所有人对「要做什么」有一致理解
- 减少返工：开发前把逻辑想清楚，而不是开发完才发现不对
- 质量基线：有了清晰的验收标准，开发、测试、业务都知道“做到什么程度算完”
记住：好的PRD不是写给自己看的，而是写给不了解业务的开发人员看的。