可靠性如何嵌入产品开发流程

前言

为帮助大家系统构建可靠性工程的知识体系，我们启动系列了专题文章。首期以杨广斌博士《产品生命周期可靠性工程》为主线，详解全流程可靠性框架。后续将深入FMEA、寿命数据分析、加速试验、FTA、DOE等核心专题。敬请关注。

为什么你的项目总是延期？

我见过太多这样的项目：

• 设计师画完了，制造说"做不出来"

• 制造搞定了，安装说"接口对不上"

• 测试通过了，客户端说"这根本不是我想要的东西"

一代代工程师在这个循环里耗尽青春。这些现象的背后，是一个共同的根因：串行开发。

杨博士在书中说："每个阶段完成后才开始下一个阶段，而每个后续阶段对变更的灵活性都更小。"

翻译：生命周期越往后，能改的地方越少，要花的钱越多。

01

串行开发：代价最贵的玩法

传统的瀑布式开发，是一个阶段做完再做下一个。设计完了，再做工艺；工艺完了，再做测试。

这种模式的成本规律值得单独说一遍：每往后一个阶段，典型情况下修改一个设计问题的成本，可达前一个阶段的10倍。

为什么？

因为每个阶段沉淀下去的东西不一样。设计阶段的改动，成本是改的是图纸；制造阶段的改动，成本是工艺文件加设备；到了客户端再改，成本是召回成本加赔偿。

更麻烦的是：前一阶段的问题会往后积累放大。设计阶段一个没说清楚的细节，到了制造阶段可能变成一堆返工单。

所以串行开发有个外号叫"救火模式"——永远在填上一个阶段挖的坑。

02

并行开发：把人相关方从一开始就拉进来

解决串行开发问题的方法，杨博士在书里叫并行工程（Concurrent Engineering）。

原文定义： "并行工程是一种系统性方法，将产品的设计和制造、以及售后服务支持整合在一起。它要求产品开发过程中所有参与方，从一开始就考虑所有生命周期要素。"

换言之：不是等设计画完了再叫制造来挑刺，而是设计阶段就把相关部门都拉进来。

这样做有两个直接好处：

1. 第一次就把事情做对的概率大大提高

2. 缩短上市时间

这是写在书里的。现实中能不能做到，是另一个问题（后面会说到）。

03

可靠性嵌入的三个关键节点

并行开发不是让可靠性工程师打酱油，而是让他们在三个关键节点真正发挥作用。

节点1：产品规划阶段

规划阶段做的可靠性规划决策，影响整个产品生命周期。

你有没有见过好多企业在这个阶段犯懒——可靠性要求那一栏写的是"满足客户需求"。这六个字等于没写。

真正的规划阶段，可靠性工程师应该做这几件事：

•设定具体可靠性目标（不是"满足客户"，而是"B10寿命达到X小时"，或"15万公里无大修"）

•把客户期望翻译成工程指标

•从可靠性角度评估备选方案

"可靠性必须在设计阶段就嵌入产品（Design-In），而不是靠测试测出来（Test-Out）。"

这句话直接挑战了很多企业的惯常做法——可靠性工作就是买设备、做试验、发报告。

节点2：设计与开发阶段

这是可靠性工程师的主战场，也是代价最贵的阶段。

杨博士在书中给了一组数字：设计阶段消耗的总产品开发时间只有5%，但70%到80%的全寿命周期成本（LCC），在这个阶段已经被决定了。

注意这两个数字的对比：5%的开发时间，决定了70%到80%的后续成本。

这就是为什么设计阶段的一个错误决策，后面要用数倍到数十倍的成本来弥补。

在这个阶段，可靠性工程师的核心任务是把可靠性"设计进去"——杨博士的原文用了Design-In，与之对应的是Test-Out：

•Design-In：在设计层面，用分析手段提前找到潜在的失效模式，在图纸完成之前就消灭它

•Test-Out：先把产品做出来，再用测试去撞，看看哪里会坏

前者的成本是分析的时间，后者的成本是材料、设备和返工。

可靠性分配、FMEA、容差分析、稳健设计、故障树分析（FTA）——这些工具都属于design-in的手段，后续篇目会逐一展开。借助FMEA软件这类工具，可以把这个过程系统化管理。

节点3：验证与确认阶段

测试是验证手段，是最后的守门员，不是救场手段。

验证阶段的核心任务是：证明设计达到了最初定的可靠性目标，而不是"让产品通过测试"。

测出来了，没达标，怎么办？

"如果产品未能通过验证测试，改的是产品设计，不是测试条件。"

这件事说起来简单，实际上是很多企业跨不过去的一道坎——改设计意味着追加成本和影响进度，而调整测试条件只需要内部开一次会。

04

串行 vs 并行：一张表说清楚

05

为什么大多数企业做不到

说了这么多并行开发的好处，现实里为什么大多数企业还是在用串行模式？

原因就一个：组织结构不支持。

串行开发的底层是职能型组织——设计部门、制造部门、质量部门，每个部门只对自己那一段负责，上下游靠文件移交。

要实现并行开发，需要的不是再买一套工具，而是把组织形态改掉——把相关职能的人拉到同一个团队，给他们共同的目标。

这件事的难点不是技术，是组织里的利益结构。并行开发意味着职能部门的边界要被打破，而职能部门往往不愿意主动放弃自己的控制权。

说到底，这需要最高管理层的推动，不是可靠性工程师能单独解决的问题。

06

可靠性工程师的角色

杨博士有一句话，我建议所有可靠性工程师给自己的领导看一遍： "可靠性工程团队是工程团队的有机组成部分，不是在外部审核和批准他人工作的旁观者。"

怎么理解这句话？

大家是不是也见过一些企业的可靠性部门是这样的：设计方案评审的时候，可靠性工程师被叫来，PPT翻完，问"有没有问题"，可靠性工程师抬头看一眼，说"没问题"，然后在签字栏上盖章走人。

这不是可靠性工程师，这是盖章机器。

真正的可靠性团队应该：

•从第一天就参与项目，了解产品在做什么

•在设计评审中说话有分量，不只是提建议

•能够在过程中推动设计优化，不只是最后的挑刺

核心问题是：可靠性工程师在组织里有没有话语权？

"可靠性工程师必须从项目一开始就参与进来，而不是被叫来审查或批准。"

我见过太多企业回答不了这个问题。

07

一句话总结

可靠性工作做得越早，成本越低；做得越晚，代价越大。并行开发的核心就是这一句。 至于能不能做到，取决于组织愿不愿意让正确的人在正确的时间介入——而这件事，最终还是需要最高管理层拍板。

08

下期预告

讲了这么多流程，有些读者可能想问：我到底应该怎么做？

别急，下一篇我们回到最基本的概念：可靠性到底怎么定义？

可靠性三要素——功能、时间、条件，大家应该都有所耳闻吧？可靠性就是在规定条件下、规定时间内、完成规定功能的能力。把这三个词说清楚，后续的任务剖面分析、环境试验、寿命数据分析、FMEA，可靠性指标及目标确定等都好理解。