一个“如果”引发的35万损失
2024年初，某新能源品牌上线了「配件库存预警系统」。
PRD中写道：
「当配件库存低于安全库存时，系统自动发送预警。」
但PRD没有写的是：
- 如果系统故障了怎么办？
- 如果数据异常（库存-100个）怎么办？
- 如果同时有50个配件需要预警，怎么发？
- 如果预警发出去了但没人处理怎么办？
3个月后，问题全部爆发：
- 系统故障：某天系统升级，2小时不可用，期间有12个关键配件耗尽，但没有人知道
- 数据异常：某个配件由于数据错误显示-50个，系统不停发预警，一晚上发了5000条短信，被当成垃圾信息屏蔽
- 消息飓斗：系统同时检测到85个配件需要预警，在短时间内发送了350条短信，导致重要预警被淆没
最终损失：
- 23个关键配件断货，影响380台车维修
- 客户等待时间平均延長2.5天
- NPS下降6分
- 直接经济损失：35万元
这个案例血淋淋地告诉我们：
PRD中最容易被忽略的不是“正常流程”，而是“异常处理”。魔鬼藏在细节里，而细节藏在那些你没想到的“如果”里。
功能详细设计：魔鬼就在细节里
写法一：用户故事法
不要写枚燥的功能列表，而要用**用户故事（User Story）**的方式描述。
标准格式：
作为 [角色]，我希望 [功能]，以便 [价值]
示例：智能预约系统
❌ 错误写法：
「系统应具备预约查询功能。」
✅ 正确写法：
用户故事1：客户查看空位
作为 车主王先生，
我希望 在选择预约时间时，能看到每个时间段的剩余空位数，
以便 我可以选择等待时间最短的时段，避免白跑一趟。
验收标准：
✅ 显示未来7天的可预约时段
✅ 每个时段显示剩余空位数（如“还剩2个空位”）
✅ 如果无空位，显示“已约满”并灰化
✅ 空位数据实时更新（延迟不超过30秒）
写法二：交互流程图
用流程图明确展示用户操作的每一步。
示例：客户预约流程
开始
↓
[打开App/小程序]
↓
[点击“预约服务”]
↓
[系统自动定位] → 显示最近3家门店
↓
[选择门店]
↓
[选择服务日期] → 默认显示未来7天
↓
[选择服务时间] → 显示每小时的空位数
↓
[选择服务项目] → 系统根据车型+里程智能推荐
↓ ↓
接受推荐 自定义选择
↓ ↓
↓←─────────┐
↓
[填写联系信息] → 自动带出历史信息
↓
[确认预约]
↓
[系统检查空位] → 如果已满，提示重新选择
↓
[预约成功]
↓
[发送确认短信] + [送App推送]
↓
结束
💡 为什么重要？
- 流程图让开发看到完整的操作路径
- 避免漏掉关键步骤
写法三：界面原型图
**原型图（Wireframe）**胜过千言万语。
你不需要高保真设计图，但需要结构清晰的线框图。
示例：预约页面原型
┌─────────────────────────────┐
│ ← 预约服务 ☰ │ 顶部导航栏
├─────────────────────────────┤
│ │
│ 选择门店 │
│ ┌──────────────────────┐ │
│ │ 📍 三里屯服务中心 │ │
│ │ 距您2.3km ★★★★★ │ │
│ └──────────────────────┘ │
│ ┌──────────────────────┐ │
│ │ 📍 朝阳门店 │ │
│ │ 距您5.1km ★★★★☆ │ │
│ └──────────────────────┘ │
│ │
│ 选择服务时间 │
│ ┌──────────────────────┐ │
│ │ 12月28日 周六 📅 │ │
│ └──────────────────────┘ │
│ │
│ 时间段选择： │
│ ┌─────────┐ ┌─────────┐ │
│ │ 09:00 │ │ 10:00 │ │
│ │ 还剩2位 │ │ 已约满 │ │ 可选/不可选状态
│ └─────────┘ └─────────┘ │
│ │
│ 选择服务项目 │
│ ┌──────────────────────┐ │
│ │ ☑ 常规保养 (推荐) │ │
│ │ ☐ 空调清洗 │ │
│ │ ☐ 轮胎检测 │ │
│ └──────────────────────┘ │
│ │
│ ┌──────────────────────┐ │
│ │ [确认预约] │ │ 主按钮
│ └──────────────────────┘ │
└─────────────────────────────┘
关键标注说明：
- 每个元素的位置、大小、状态
- 交互规则（如“点击后变成选中状态”）
- 数据来源（如“空位数从后台实时获取”）
异常处理：决定系统健壮性的关键
异常处理的四大类型
类型1：用户输入异常
| 异常场景 | 处理方式 | 用户反馈 |
|---|---|---|
| 手机号格式错误 | 实时校验，红色提示 | “请输入11位手机号码” |
| 选择已约满的时段 | 预约按钮灰化不可点 | 显示“已约满，请选择其他时段” |
| 未选择服务项目 | 阻止提交，项目框高亮 | “请至少选择一项服务” |
| 网络超时 | 显示加载动画，3秒后提示 | “网络不佳，请稍后重试” |
类型2：系统内部异常
| 异常场景 | 处理方式 | 后续动作 |
|---|---|---|
| 数据库连接失败 | 自动重试3次，间隔1s | 失败后转备用数据源 |
| 第三方接口超时 | 超时5s自动放弃 | 记录日志，告警运维 |
| 并发预约冲突 | 乐观锁机制，先到先得 | 后到者提示“刚被预约” |
| 数据异常（负数、空值） | 过滤异常数据，记录日志 | 发送数据质量报告 |
类型3：外部环境异常
| 异常场景 | 处理方式 | 降级策略 |
|---|---|---|
| GPS定位失败 | 手动选择城市/区域 | 根据历史定位推荐 |
| 短信发送失败 | App推送作为备选 | 用户可在App查询预约 |
| 系统维护升级 | 显示维护公告 | 提供电话预约入口 |
类型4：业务规则异常
| 异常场景 | 处理方式 | 理由 |
|---|---|---|
| 客户黑名单 | 禁止预约，显示“请联系客服” | 恶意爽约、欠款等 |
| 连续爽约3次 | 冻结7天预约权限 | 避免资源浪费 |
| 同一客户重复预约 | 提示“您已有预约” | 防止误操作 |
| 提前不足2小时取消 | 禁止取消，显示原因 | 保障门店排班稳定 |
非功能性需求（NFR）：决定系统生死的隐形要素
什么是NFR？
NFR (Non-Functional Requirements) = 非功能性需求
功能性需求回答「系统能做什么」，NFR回答「系统做得好不好」。
NFR的7大维度
1. 性能需求（Performance）
| 指标 | 目标值 | 测量场景 |
|---|---|---|
| 响应时间 | ≤ 2秒（页面加载） | 4G网络环境 |
| 接口响应 | ≤ 500ms（API调用） | 99%请求 |
| 并发处理 | ≥ 500人/分钟 | 高峰期压测 |
| 数据查询 | ≤ 1秒（单表查询） | 千万级数据量 |
2. 可用性需求（Availability）
| 指标 | 目标值 | 说明 |
|---|---|---|
| 系统可用性 | ≥ 99.9% | 年度停机不超过8.76小时 |
| 故障恢复时间 | ≤ 30分钟（RTO） | 从故障到恢复服务 |
| 数据丢失 | = 0（RPO） | 关键数据不可丢失 |
📝 注释：
- RTO (Recovery Time Objective) = 恢复时间目标
- RPO (Recovery Point Objective) = 恢复点目标
3. 安全性需求（Security）
| 项目 | 要求 | 实现方式 |
|---|---|---|
| 身份认证 | 手机验证码 + 密码 | 短信验证码有5分钟 |
| 数据加密 | HTTPS + AES256 | 敏感数据加密存储 |
| 防刷机制 | 同一IP 10次/分限制 | 超限封禁IP 1小时 |
| 隐私保护 | 符合GDPR规范 | 用户可删除个人数据 |
4. 易用性需求（Usability）
| 项目 | 要求 |
|---|---|
| 新手引导 | 首次使用必须有引导流程 |
| 操作步骤 | 完成预约不超过5步 |
| 错误提示 | 明确、友好，提供解决方案 |
| 无障碍支持 | 支持语音读屏，字体可调节 |
5. 兼容性需求（Compatibility）
| 项目 | 要求 |
|---|---|
| 操作系统 | iOS 12+、Android 8+ |
| 浏览器 | Chrome 80+、Safari 13+、微信浏览器 |
| 屏幕适配 | 375px - 428px（手机） |
| 网络环境 | 4G/5G/WiFi，兼容3G弱网 |
6. 可维护性需求（Maintainability）
| 项目 | 要求 |
|---|---|
| 日志记录 | 关键操作必须记录日志 |
| 监控告警 | 异常率 ＞ 5% 自动告警 |
| 版本管理 | 支持灰度发布、快速回滚 |
| 文档完善 | 接口文档、部署文档、故障手册 |
7. 扩展性需求（Scalability）
| 项目 | 要求 |
|---|---|
| 用户增长 | 支持10万并发用户（未来3年） |
| 数据增长 | 支持1亿级预约记录 |
| 水平扩展 | 支持负载均衡、动态扩容 |
PRD的最后一步：验收标准
验收标准的三大原则
原则1：可测试（Testable）
❌ 错误写法：
「系统界面应该简洁美观。」（无法测试）
✅ 正确写法：
验收标准：
- 页面加载时间 ≤ 2秒（95%请求）
- 按钮距离符合iOS/Android规范（≥44dp）
- 颜色使用品牌VI规范（主色#1890FF）
- 通过10人可用性测试（满意度 ≥ 4/5）
原则2：全面（Complete）
需要覆盖：
- ✅ 功能测试（正常流程）
- ✅ 异常测试（所有异常场景）
- ✅ 性能测试（压力测试）
- ✅ 兼容性测试（多端、多浏览器）
- ✅ 安全性测试（渗透测试）
原则3：可追溯（Traceable）
每个验收标准都应该能溯源到具体的需求：
| 需求ID | 需求描述 | 验收标准 |
|---|---|---|
| REQ-001 | 客户可查看实时空位 | TEST-001：空位数据延迟 ≤ 30秒 |
| REQ-002 | 系统智能推荐服务项目 | TEST-002：推荐准确率 ≥ 85% |
| REQ-003 | 预约成功后发送确认 | TEST-003：短信发送成功率 ≥ 99% |
写给你的行动指南
✅ 今晚的作业
拿出你昨天写的简版PRD，补充以下内容：
- 至少写出5种异常场景及处理方式
- 补充性能、可用性、安全性三大NFR
- 为每个核心功能写出可测试的验收标准
✅ 进阶挑战
- 用“如果…会怎样？”的思路，找出10个可能的问题场景
- 给每个场景设计具体的处理方案
明天，我们将进入Day 53的综合实战演练，把今天学的所有知识连贯起来，完成一个完整的需求管理全流程。