05 频度与探测度——多久出一次、能不能提前发现
开篇除恐
这一章要学的东西，是两把尺子。一把量"这件事多久出一次"，一把量"出了事能不能提前发现"。它们各是 1 到 10 的棋盘，跟上一章的严重度长得一模一样——你把上一章记得的记法搬过来就行。
很多人觉得这两把尺子比严重度难，事实上不是。难在收集数据，不在打分本身。
白话化：频度和探测度各是什么
** Occurrence（O，频度）**：这个失效模式多久会出现一次。一天一次是高分，每十年一次是低分。用 AIAG 标准表的参考：
- O = 1：几乎不可能——概率低于 1/20 年
- O = 4–5：偶尔出现——每批或每月都能碰到的程度
- O = 8–10：经常出现——几乎所有批次或每次启动都有
** Detection（D，探测度）**：现在有检测手段吗？检测手段能提前发现它吗？注意这里问的不是"失效本身发生的概率"，而是"失效发生了之后，我们能多早发现"。
这是很多人绕不过去的弯。举个例子：
- 刹车钢线断裂：骑行前肉眼可检查，断裂前没有预警信号，属于 D = 2–3（容易发现：检查一次就能看见）
- 密码框类型错误：开发时看代码能发现，QA 写一个用例就能拦住，属于 D = 2
- 弱网超时逻辑缺失：正常测试环境很难复现，真到生产环境弱网才暴露，属于 D = 7–8
同样一个失效，因为"有没有检测措施"不同，D 的差别可以很大。
直觉先行：没有数据的时候先定性
真正的问题是：很多团队手里没有历史数据，请问怎么打分？
分两种情况处理：
情况 A：有同类产品的历史记录（同一条产线跑了三年，年度缺陷统计在手边）：直接用数据。比如过去一年发生 40 次，对应 O = 5 左右。
情况 B：没有历史数据，这是大多数团队的情况。这时候按"粗糙但有方向"的规则打分，先画出重点区域，再慢慢填充数据。粗糙的 FMEA 比没有 FMEA 好，但不粗糙的 FMEA 会误导决策——记清楚这个度。
没有数据时建议的分级：
- O 打分问自己：这个失效是"设计上就不可能"（O = 1）还是"一定会来"（O = 10）？中间按"偶尔/经常/几乎每次有"叠放。
- D 打分问自己：现在有没有监控或检查？如果有，大概多久能发现？上线后立刻发现 = D = 1–2；到用户报修才被发现 = D = 8–10。
常见错误：把频度和严重度搞混
一个典型的错误：把"后果可怕"当成"常出问题"。钢线断裂后果严重，不代表它每天发生——事实上在正常维护条件下它的 O 偏低。频度和严重度是两个独立的维度，不要相互渗透。
另一个典型错误：D 打分"出了这个缺陷我得重做，算重做难度"。D 不是难度，是"检测窗口"——在缺陷变成了用户能感知的后果之前，你有多少时间窗口发现它。
例子
☼ 热身：自行车刹车钢线的频度与探测度（自编）
还是钢线断裂这个失效模式：
| 项目 | 分值 | 理由 |
|---|---|---|
| O | 3 | 正常维护下 2 年一换，中间断裂概率低 |
| D | 3 | 每次骑行前可以肉眼检查，卡扣可见；断裂前有锈迹预警 |
如果骑行者完全不保养：O 升到 6，D 升到 6（锈迹不明显，断裂前也很难发现）。
☼☼ 正经：登录流程四个失效模式的频度与探测度（自编）
| 序号 | 失效模式 | O | D | 理由 |
|---|---|---|---|---|
| 1 | 按钮色对比不足 | 4 | 2 | 设计评审和 QA 走查都容易发现，但仍有纰漏；旧版本遗留概率中等 |
| 2 | 按钮太小 | 4 | 2 | 同 1，移动端适配流程漏掉这个场景时才有 |
| 3 | 密码框明文 | 3 | 2 | 开发阶段代码审查大概率能拦；但有些团队不审查前端表单类型 |
| 4 | 弱网无超时提示 | 6 | 7 | 常规测试环境模拟弱网比例低，生产环境弱网时才暴露；测试人员主动做弱网测试的比例也不高 |
O 和 D 一起呈现，设计师最该关注的是什么？
是第 4 项：频度 6（不算低），探测度 7（基本发现不了），这是最危险的一类——经常发生但隐身。
这一章要带走的东西：
- 频度（O）问"多久出现一次"，探测度（D）问"失效发生了之后，多久能发现"。
- 两把尺子的骨架和严重度一样：1 几乎不可能、10 几乎必然/几乎发现不了。
- 没有历史数据时先按"粗糙但有方向"的打法，把握好粗糙度和误导度之间的度。
- O 和 S 是两个独立维度，不要混；D 是检测窗口，不是缺陷复杂程度。
就这样。