FMEA团队评审的重点，是让设计、工艺、质量、制造、测试等人员围绕同一条失效逻辑形成可执行的风险结论，而不是把已经填写好的FMEA表格逐行念一遍。进行“FMEA团队评审怎么开展，FMEA评审意见不一致如何处理”时，需要把分析边界、失效链、评价依据和后续措施放在同一套逻辑中讨论，才能避免会议时间很长，却只留下大量待确认项。AIAG&VDA FMEA采用七步法，并把风险分析、优化和结果文件化分别作为独立阶段。

FMEA中的发生度，是用来评价失效原因出现的可能性，而不是判断失效后果有多严重，也不是衡量问题能否被检测出来。评分的时候既要参考历史数据，也要结合现有的预防控制措施、产品或过程的成熟度，以及从相似项目中获得的经验。AIAG与VDA统一方法进一步细化了严重度、发生度和探测度的判定条件，并且强调了预防控制的有效性，以及产品与过程经验对评分带来的影响。

FMEA预防措施怎么填写FMEA预防措施和探测措施怎么区分，很多团队在做DFMEA或PFMEA时，都会在这个地方被绊住。表格看上去不过是两栏内容，可是它们底下真正的指向并不一样，预防措施更偏向于“让失效的原因不要出现”，探测措施则更偏向于“原因或者失效模式已经发生后，怎样把它给找出来”。要是把这两类控制手段写混了，后面的发生度、探测度就会跟着失真，做出来的FMEA也容易变成一种走过场的文件。

在做FMEA的功能分析时，要紧的地方并不是把零件的名儿一个一个列出来，而是先得把这个对象“到底要完成什么功能”给说明白了。不少FMEA做起来很辛苦，原因就是一开始就直接从结构树上往下抄，功能没有被真正地展开，后头的失效模式当然也就容易漏掉。只要功能这一层拆分得对路，后面那些功能上的失效、它们造成的影响、背后的原因，还有要去控制它们的措施，才能找得到落脚的地方。

在功能安全、质量策划、过程审核和设计评审这些工作里面，我们常常会碰到两个连在一起的问题，一个是FMEA的失效影响到底要展开到多细才合适，另一个是，如果对失效链路的梳理做得太深，又会带来什么样的麻烦，FMEA做得太粗，评审的时候就会被认为没有把风险给讲透，后面的控制办法也容易落空；可要是做得太细，又可能把整个团队拖进大量价值不高的推演当中，表格越写越厚，而真正需要优先去处理的高风险项，反而被淹没了，更稳当的一种做法，是把失效影响展开到“能判断风险、能定义控制、能分配责任”这个程度，而不是把每一个细枝末节都拆解成一条独立的失效链。

在质量评审、设计变更还有过程审核这些场景里面，有两个问题常常被连在一起看，一个是FMEA里的高风险项为什么迟迟关不掉，另一个是FMEA的措施优先级，一般是按照什么样的逻辑来排的，单看表格的时候，好像只是有几行风险没有关闭，但是到了现场一查，后面很可能连着责任人没有说清楚、措施写得太空、验证的证据不够、风险的分数也没有重新去确认这一类的问题，FMEA并不是把措施填进表格就算把事情做完了，一个高风险项到底能不能被关掉，要看它背后那个失效的原因，有没有被真正地处理掉，而措施优先级的排法，也要按照风险带来的后果和实际可执行的条件来定，不能只是看谁催得比较急。

做FMEA的时候，很多团队前面最顺手的动作，就是先给严重度、发生度、探测度打分，再把RPN一乘，谁大先看谁。这个方法不是不能用，但真到项目现场，单靠一个乘积数字往往不够。因为有些问题严重度很高，只是发生概率暂时不高，RPN看起来不算特别扎眼，可一旦出了事，后果并不轻。还有些问题RPN数值不小，但更多是探测度拉高了分数，未必就是当前最急着处理的项。所以RPN能用，但不能被用死。它更像是一把筛子，先帮你把问题排个队，后面真正怎么处置，还得回到失效后果、现场经验和项目节奏上来看。

做FMEA软件项目时，最容易乱的不是先点哪个按钮，而是项目一建起来以后，结构树、分析对象、模板配置和权限分配各走各的线，最后项目能开，但团队很难按同一套方式协作。公开的XFMEA文档把这条逻辑写得很清楚，项目创建时就要先定项目属性、FMEA结构和配置用的profile，后面系统层级再从项目根节点往下展开；而权限配置这边，也不是只给一个“能不能编辑”的总开关，而是细分到能不能新建层级项、能不能改属性、能不能删项目项、能不能设项目安全。

FMEA表格看起来是一张表，实质是一条风险推导链。审表时如果只盯着评分高低，很容易放过逻辑断裂，后续在设计冻结、试制、量产变更时就会反复返工。更稳的做法是按范围与版本起手，沿着功能到失效模式到影响到原因到控制再到措施闭环逐格核对，把每一行都审成能复现、能解释、能追溯的风险记录。

做失效模式及后果分析即FMEA时，表里两列最容易写乱的就是失效模式与后果。前者写的是功能怎么偏离了预期，后者写的是偏离之后对上一级、对用户、对法规与安全会造成什么影响；把两者写清楚，后续的严重度、探测度与改进动作才有一致口径可落到实处。