10 小组讨论——最被低估的技能
开篇除恐
FMEA 从来不是一个人能做完的工作。不是因为它难，是因为你要打分的那个人，脑子里装着那套系统的运行细节——那些细节只存在于每天写代码、每天跑测试的人脑子里。一头大象拆散了，需要四、五个人围着看每一块。
但小组讨论有一个出名的问题：人多，反而容易把结果变平。
白话化：讨论的三个角色
一个有效的 FMEA 讨论，需要三类人：
- 熟悉系统的人（开发工程师、测试工程师）：提供"这个组件怎么跑的、它曾经出过什么事"的细节
- 熟悉用户的人（产品经理、客服代表）：提供"用户真正踩到的是什么坑"
- 熟悉流程的人（测试人员、运维）：提供"这个环节在真实环境里实际怎么运转"
三类人凑在一起，一张表才能填得完整。少任何一类，那张表就有盲区。
讨论怎么开：步骤化
把整个过程切成清晰的步骤，主持人照着走：
第一步：独立打分（10 分钟）
每个人拿到一张 S/O/D 打分纸（或用匿名问卷工具），先不讨论，各自给最熟的 5–8 行打分。这一步的目的是拿到每个人私下的判断，没有从众压力。
第二步：逐行公开（40 分钟）
主持人按 RPN 从高到低排，逐行念。每行宣布三个分数，然后问"谁分差得最大？分最高或最低的人，说来听听"。
注意这里：主持人不问"大家觉得多少合适"，只问"分最高的说一句，分最低的说一句"。这是最能产出信息的方式。
第三步：二轮投票（10 分钟）
拿到争议信息后，所有人再投一次。第二轮的结果通常比第一轮更接近真实分布。
第四步：记录差异（5 分钟）
哪些行分歧最大，在备注栏留下争议原因。这些备注后面看会很有用。
整场控制在 1.5 小时内。超过这个时间，专注力下降，分数会越来越敷衍。
常见错误：讨论变吵架
三个对策：
- 争论"这个失效存不存在"时，把它记下来，评分跳到下一行。 不存在的模式不会被标到，不影响正式表。争论影响节奏。
- 有人对打分有情绪时，答复"我记下来，复盘时看"。不追赶情绪，转回流程。
- 设计范畴和过程范畴分开讨论，不要混。 DFMEA 和 PFMEA 的参与者不完全重叠，混在一起效率低。
软件测试场景的特殊性
测试工程师在团队里的优势是熟悉系统缺陷历史、有可靠的 O 数据来源（缺陷跟踪系统、线上监控）。唯一的弱势是对"架构决策"的理解可能不够深。建议：邀请架构师参与 DFMEA 讨论，测试工程师负责 PFMEA 部分。
例子
☼☼ 正经：一次 8 行打分讨论的流程示例（自编）
场景：登录功能 PFMEA，8 行打分。有测试工程师、后端开发、产品经理三人参与。
第一轮独立打分（匿名汇总后显示）：
第5项（弱网无超时提示）：S=7/7/6，O=6/5/4，D=7/8/9
分差最大在 D：开发说"超时-重发逻辑依赖前端，代码审查能发现，D=4"，测试说"历史上弱网覆盖差，我没特意测，D=7"，产品说"用户反馈我们经常收到'重复扣费'投诉，说明一直没拦到，D=8"。
二轮投票（讨论过原因之后）：D=7，三方达成共识。
备注栏记下争议：D 的分数取决于"缺陷发现机制是否覆盖弱网场景"——这本身就是 FMEA 的建议措施来源。
这一章要带走的东西：
- FMEA 小组必须有三类角色：懂系统、懂用户、懂流程。
- 讨论流程四步：独立打分 → 逐行公开（问极值）→ 二轮投票 → 记录争议。
- 不追责，不发散，不纠缠"存不存在"，跳过记录。
- 分数有分歧不是坏事，是信号：分歧往往指向那张表最有价值的地方。
就这样。