11 从分析到行动——把 RPN 变成清单
开篇除恐
最后一步。很多人在这里停住。
"分析做完了，表也填了，RPN 排了，然后呢？"
然后什么也没发生。FMEA 最久被诟病的一件事就是"做完一份报告放抽屉"。这一章要让你做完知道下一步是什么。
白话化：RPN 冰冷，行动温暖
RPN 是一个排序工具，不是一张预算单。它帮你把风险从高到低排成队，但"排在最前面的要不要修"是一个独立的决策。
这个决策需要权衡：
- 修的成本：改一条密码加密方式可能要两周，加一个超时提示可能半天。
- 不修的成本：现在不修，出了问题什么后果。是用户投诉，还是数据泄露上书新闻？
这两个数字放在一起，才是"要不要修"的答案。
怎么排优先级：一个思维框架
漏斗式筛选：从 RPN 最高的开始看，逐项过这三个问题：
- 这个失效模式的 S 是多少？
- S = 9–10（致命/系统崩溃）→ 必须处理，跳过后面两步。
-
S ≤ 8 → 继续看。
-
改进成本高吗？
- 低成本（改动接口、加一行校验、改配置）→ 立刻排进迭代
- 中等成本（改算法、重构一段逻辑）→ 排进下个版本
-
高成本（重构架构、换核心技术选型）→ 单独评估，可能动方案本身
-
这个失效的频度 O 是多少？会不会真发生？
- O ≤ 3（很少见）→ 可以列为"长期跟踪"，先不投入资源
- O ≥ 6（常见）→ 即使 RPN 不高，也值得倒排期先改
这个漏斗的核心逻辑：S 高是红灯，O 高是黄灯，RPN 是综合排序。
行动项怎么写
一张不合格的"建议措施"长这样："增强监控""优化流程""后续跟进"。这三句话可以被写进任何 FMEA 表，它合格的标准是：任何人拿到这条，知道自己什么时候交什么。
合格标准：
- 谁来做——负责人名字，不是"开发组"，是 "@李四"
- 具体改什么——不说"优化监控"，说"在登录接口增加失败率告警，超过 20% 持续三分钟触发 P1 告警"
- 什么时候交——"M 月 D 日前"或"Sprint XX 结束前"
- 怎么验证——"验证方式：注入 30% 失败率流量，确认告警在 90 秒内触发"
总共四个信息。缺任何一个，这条行动就是死信。
闭环：做完还要复查
FMEA 不是做完一次就扔的。建议的复查节奏：
- 每次迭代/批次结束时：回看行动项完成情况，更新 O 值（因为改了措施之后，频度会变）
- 有重大缺陷或上线事故后：重新审视相关行的 S 和 O，看有没有判断错的地方
- 每年一次全面复查：整个表重新打分，看整个产品的风险格局有什么变化
复查不需要重做整张表，只需要看三条：RPN 排名有没有大的变化、行动项有没有落空、有没有新增的失效模式从用户反馈里冒出来。
例子
☼☼ 正经：把第 7 章登录 FMEA 的行动项填上（自编）
取第 7 章登录 FMEA 表中 RPN 最高的三项，写出符合上述标准的行动项：
第 5 项（弱网无超时提示，RPN 294）
- 负责人：@前端组王五
- 改什么：在登录提交按钮上增加 10 秒超时检测；超时后显示"网络不佳，请重试"，并禁用提交按钮 3 秒
- 什么时候：Sprint 23 结束前（7 月 25 日）
- 验证：用 Charles 限速到 GPRS 速率，确认 10 秒超时后显示提示，重复提交被拦截
第 6 项（无幂等性 key，RPN 150）
- 负责人：后端开发张六
- 改什么：登录提交接口增加幂等键（idempotency key）处理逻辑，同一 key 30 秒内只预留一次
- 什么时候：Sprint 23 开发任务，7 月 28 日提测
- 验证：10 秒内快速点击提交 5 次，数据库只插入一条记录
第 2 项（按钮太小，RPN 40）
- 负责人：UI 设计师
- 改什么：移动端登录按钮最小尺寸从 36×36 改为 48×48
- 什么时候：设计稿更新，Sprint 24 计划会确认排入
- 验证：真机测试 iPhone SE（375×667 屏幕），手指能准确点击
三条行动项共同特点是每条都有"谁 / 改什么 / 什么时候 / 怎么验"四个要素。任何人拿到这条，明天就知道怎么写代码。
☼ 热身：这张 FMEA 表的复查计划（自编）
上面三张行动项，建议的复查点是：Sprint 23 上线后一周，检查弱网测试覆盖率是否达标、幂等性是否在压测通过、按钮尺寸是否在真机上验证。复查人：测试工程师李四。
这一章要带走的东西：
- RPN 是排序，不是预算。判断修不修，要看 S 和经济逻辑。
- 漏斗筛选：S=9–10 必须处理，低成本镰刀优先割，O 低长期跟踪。
- 行动项必须写清：谁 / 改什么 / 什么时候 / 怎么验证，缺一不可。
- FMEA 做完不是结束：每次迭代复查一次 RPN 排名和行动项完成率，每年全表重评。
就这样。