关于变更的一个问题

直接怼回去。财务部问：总经理/老板没有财务部更懂财务，为什么要总经理/老板最终确认。因为这是审批权，财务部对上负责公司资金的问题。同样，质量部一般不是生产、技术、设备…部门设立的，而是老板决定的，质量部对上负责公司质量的问题。从’功能+控制’的角度理解，每个职能部门各自都有实现功能的上限和确保质量的下限。最终产品/服务的好坏，是每个职能部门工作的汇聚结果，一旦有直接影响质量的变更，质量部的功能之一---测试，就是要验证和确认最终结果的好坏，所以常见由质量部来最终确认变更(即：测试验证)。现实中，因为测试覆盖率/工作量/可行性…一般会分级分类/流程定义与处理。

但麻烦在于，质量部如何对其结果进行质量保证。常见的有，

对于产品/服务，变更的波及路径，一般非军工级的行业，没有类似FTA(故障树分析)，能确定改了什么地方，会影响到哪些，需要测试(质量部)哪些。一般这些都需要技术回答，但可能都是拍脑袋(经验+直觉)，难免挂万漏一，不是太科学。质量部的FMEA，其模式，其实可以借用，但目前没有对每个不同类型产品，分解到部件/器件/位置。相应的理论、解决方案、IT系统软件，虽有但不常见也很难普及。对于采购/生产…变更的涉及对象，更会碰到一些商业上的不可预见性，百密一疏。

所以，变更的最终确认(或拍板)，还有其他模式，比如会签，一票否决制。比如，涉及供应商的，研发+采购+质量；
另外，软件行业，测试需要回归测试(不管代码改哪里改多少，都需要最终完整测试一遍，自动化+手工)，但对于硬件的，不是很现实。

最后，很多常见质疑(是好事，总比洗脑弱智要好)，来源都是对于一个部门的价值判定。价值就是利益，物质方面有利润来度量。其他职能部门实现功能产生利润，看的到算的清。质量部门实现确保质量的功能，是减少损失的利润，虽然负负得正，但一是拗口不直观，二是如何证明一个质量的可能问题，会损失多少，而通过现实的管理，挽回了多少损失。如同，如何证明我没干过这件坏事(这事不是我干的，虽然查出谁干的就可，但查不出时，我如何证明我没干过)…