- 该话题包含 0个回复，1 人参与，最后由
更新于 5月、 1周前 。
-
帖子
-
-
我从1998年进入华为从事可靠性工作，至今超过25年半，其中2018年底至2023年底负责公司关键DFX能力建设，可以说我自己的职业生涯几乎完全和华为可靠性紧紧联系在一起，略为扩展到安全性safety、可服务性、节能减排、可制造性/可供应性等DFX。这些年在各位同仁的共同努力下，产品可靠性等关键DFX竞争力持续提升，我有幸参与其中并走到现在，在此，结合自己的思考，准备分几个部分阶段性地打个结，文责自负：
- 如何让客户对可靠性有感觉？
- 华为产品可靠性独步武林的秘密？
- DFX业务的责任结果是什么？
- DFX业务的本质是什么？
- DFX工程能力应该如何建？
- 做DFX需要具备什么样的能力？
前两部分试图跳出华为，跳出DFX，从外部的视角看待DFX，中间两部分想说清楚DFX的目标、业务本质是什么，最后两部分则想谈谈工程能力建设及个人成长。
—————————————————————————————————————————————
1 如何让客户对可靠性有感觉？
这里所说的“客户”，特指外部客户，就是付钱买我们产品的客户，我们需要关注客户的挑战和压力，最终我们的产品要帮助客户商业成功。我认为任何业务要想有大发展，最终都得让客户有感觉。所谓“有感觉”，就是客户认为这个业务对他很重要。客户认为重要的业务，最直观的反映就是在标书中提出要求，甚至作为比拼测试的重要内容，比如运营商客户在标书中明确提出可用度availability 99.999%（俗称“5个9”）的要求，提出服务寿命、重要模块冗余、双归属、异地容灾、设备重启时间、软件升级时间、年返还率、特殊运行环境等要求，提出能耗监测、HVDC高压直流供电、未用端口关断、风扇调速、碳足迹报告、产品使用能效、产品可循环设计等节能减排要求，提出预防性维护、开放APIs、自愈工具（SH-Tools）、Trace Data Interface等可服务性要求。技术能力很强的运营商，如BT，进一步会对流程中DFX活动、交付件、质量标准提出明确要求，目标/需求、分解分配、验证，缺一不可，并逐一审查。比拼测试中，能效比拼是保留曲目，相较而言，可靠性、可服务性则较少涉及。
客户标书大多描述的是功能需求，对于DFX这类非功能需求涉及较少，所以，对于客户标书中明确提出的DFX需求，作为DFX人员应该引起足够的重视，应全面了解不同客户、不同地区、不同行业、不同应用场景标书的DFX要求。如果可能，能拿到和客户签署合同中的SLA相关描述，对自己理解客户的关注点大有裨益。除了标书、合同SLA，还需要关注国际标准、国家标准、区域标准、行业标准等要求。
做到以上这些，只能算是达到了及格线，要想让客户对我们的产品有感觉，还需要：
（1）理解客户DFX方面的挑战和压力。
绝大多数情况，“挑战和压力”都可以转换成钱，即使因为保密原因难以知道确切金额，但同数量级内的大致金额已经很有感觉。比如，发生一次全网中断1小时的严重事故客户的损失是多少，电费占客户OPEX多少，能效提升10%客户的收益是多少，整网凌晨升级一次需要耗费多少人工，现网业务中断时业务恢复需要多少时间，单板年返还率劣化一个点会增加多少备件？还有一些是难以转换为钱，而客户视为不可触碰红线的，比如数据中心里恰好是政府安全部门的数据，千万别丢失数据，全网中断1小时客户CEO就得到国家管理机构去解释等。和客户各层面的人交流越多，对行业越了解，对产品实际运行现场越熟悉，就会对客户的挑战和压力有更深的感受。
多年前经过的几件事印象很深，一件是关于软件升级不中断业务，当时到了客户现场，和客户维护人员一起给产品升级，维护人员提前半年排班，到了那一天，等到夜深人静，月黑风高，开始升级，一次只能升级一个站点，维护中心机房还得有人看业务状态，顺利的话一两个小时就能完成，如果不顺利，比如重启后发现故障，就得排障，如果估摸着在升级窗口内搞不定，只能回退，下次再排计划，陪了两夜我就筋疲力尽，才知道软件升级不中断业务、批量升级、远程升级对客户的价值。另一件是关于高温可靠性，产品运行中高温故障，到了现场才发现产品的运行环境比我们想象的恶劣得多，不但没有我们安装手册中要求的机房，甚至连简易的棚子都没有，裸露在外，或直接放在路边的线缆沟中，我们当然可以把设备故障归因于客户没有按照规定环境使用，但我们选择通过设计改进使产品适应更宽的温度范围，解决了客户的痛点。还有一件是和可安装性相关，从城市驱车近2小时去安装5G基站，那个基站装在一栋八、九层楼的厂房楼顶，仅有一架非常狭窄的简易货梯，容纳两个人基本就得屁股贴屁股了，最上面两层只有简易的楼梯，连电梯都没有，我们的分布式基站体积小重量轻，一人提着就上去安装了，而附近友商的站点，他们得雇吊车开车3小时左右过来安装，结果那天好像是缺少吊钩，还没安装成，据说雇吊车得重新排计划，几个月后了。
实际上，很多客户难以系统说清楚对产品DFX的要求，只能提一些点上的要求，但客户没有提并不表示他没有挑战和压力。
（2）DFX能力要比友商有数量级的提升。
仅仅满足于达到客户的要求是不够的，需要聚焦能给客户带来巨大商业价值的特性，做到比友商有数量级的提升，客户才会有感觉，客户才会有直观的感受，也才有可能将DFX特性变成产品的竞争力。这是我多年工作的直觉，我觉得关于产品竞争力存在“数量级定律”。比如重大事故数，友商一年10起/千台，我们做到1起，甚至小于0.01起；事故恢复时长，友商平均120分钟，我们做到30分钟，甚至10分钟；故障定界定位，友商1小时，我们几分钟。Mate 60昆仑屏的抗摔，Mate、P系列的抗冻、防水，都是遥遥领先的典范。
那种比友商领先几个点，比如友商故障检测准确率90%，我们93%，发学术论文可以，但在实际产品中意义不大，最多能说明我们和友商都还不错，拉不开差距就没法形成竞争力，无法带来商业价值。
—————————————————————————————————————————————
2 华为产品可靠性独步武林的秘密？
现在说“华为产品可靠性独步武林”，虽然不谦虚，但却是实话。记得2005年BT投标，产品可靠性端到端全流程被蹂躏，一打一个准，看到客户的标书就发怵，回答问题的思路都没有，东拉西扯一大堆，就像考试遇到了不会做的题，啰哩啰嗦写了半页卷子，就想着万一老师念我的辛劳，随手给点分就很美了。后来M认证、N认证，一个比一个难，屁颠屁颠跟在前来认证的可靠性老专家身后，小本子上一丝不苟地记着老专家的每一个要求和教诲。再后来，在美国、日本投标，客户又提出各种各样的测试要求、责罚条款，每一次都战战兢兢，恨自己读书太少，美军标的可靠性手册、Telcordia的各种可靠性标准，纸件、电子件一样不落，逐字逐句研读，奉为经典。实在说，是客户，是友商培养了我们，他们是我们的值得敬重的老师。
想不到的是，十几年后，我们的老师逐步退出了历史舞台，当年那个毛头小子现在成为了电信设备商中毫无争议的老大，而业界，所有关于可靠性的知识都定格在了十几年前再没有大的进步。当年老师憧憬的，同时也是国内很多高校、企业所憧憬的，“可靠性是设计出来的”也没有实现。不知不觉，我们开始在业界承担各种标准职位，开始受邀进行主题演讲，开始参加各种panel，开始给业界输出经验，我们产品实际的DFX表现和系统DFX知识逐渐领先业界并且越来越领先。直至某一天，我翻开INCOSE系统工程手册中专业工程（Specialty Engineering）的部分，不得不感叹太浅、离实操太远了，我们，在DFX专业领域已经有了足够的信心。
我经常想，就我们这群人，没有一个国际顶尖院校毕业，没有一个具备业界领先的可靠性从业经验，凭什么做成了业界第一？如果我们这帮人离开华为这个平台，还能不能做成业界第一？
我认为华为可靠性独步武林的秘诀有三：
（1）高端客户有需求，产品有规模。
1998年我进入华为从事可靠性工作时，所在的部门是工艺实验中心下的环境与可靠性试验室，据说1997年，这个模块名称还是“环境实验室”，这和现在很多企业、单位开展可靠性工作的思路如出一辙，都是从可靠性试验开始，在试制阶段对产品做高低温、温度循环、振动、盐雾、淋雨、燃烧等试验，尽可能真实模拟产品在运输、运行阶段的各种条件下能否正常工作，进一步，会深入开展HALT、HASS、ALT、高温老炼（俗称老化）等，这时就不满足于仅仅模拟现场环境了，希望通过施加各种过应力能在批量发货前发现、解决产品问题，实现产品可靠性增长。即使是后来我们从交换机128模块开始所谓的“可靠性设计工作”，其实也就是进行FMEA分析、降额分析、热分析等，那段时间我写了很多规范，包括JTAG设计规范、背板设计规范、可维护性设计规范等等，也开始给产品提需求，这个阶段的感觉是似乎不需要对产品功能有较深的理解，就可以进行可靠性分析。现在想起来，这个阶段我们主要提供的是可靠性分析方法，指导产品测试人员，后来是设计人员进行可靠性分析。国内企业、研究所，乃至整个业界，可靠性开展较好的基本也就进展到这个阶段。
这种情况一直延续到2005年，8年间我们这个团队从三个人发展到了8、9人，部门调整过无数次，最多的一年内我们换了四次部门，我们这几个人分散办工，覆盖了公司所有产品线，哪个产品有诉求就去哪个产品。2005年公司竞标BT的21CN项目，BT提出了系统、严苛的可靠性要求，加上M、N公司对我司进行认证，产品难以应对，于是公司决定将我们这个小团队整体迁入公司总体技术办公室，成立可靠性管理部，在公司层面建立可靠性管理委员会，同时在各产品线总体技术部（后更名为架构设计部）下成立可靠性技术/工程部，明确定义IPD流程及子流程中的可靠性活动，所有研发人员考试，所有设计师参加培训，招聘多年设计经验的设计师加入可靠性队伍，并积极和高校、研究机构合作，招聘业界可靠性大牛，参与各种业界顶级会议、论坛，能力快速提升。
不得不说，如果没有全球高端客户严苛的要求，没有行业领先玩家的深厚积累，华为的可靠性工作大概率还会像2005年以前一样，处于自发的、自下而上的状态。
除了高端客户要求这个最重要的契机，2005年华为公司销售额453亿人民币，海外销售额首次超过国内销售额，不少产品销售额突破10亿，而通信产品在功能上很难有差异，只能是性能、集成度、成本、DFX等拉开差异化。同时，当产品上规模后，事故多、单板返还率高、难以维护等问题被放大，产品对可靠性、可服务性等业务自发产生了需求，这是另一个重要的契机。有几件事至今还记忆犹新，一件事是无线基站的某单板，故障后维护人员需要去现场处理，每一个站点都很偏僻，来回路程花费大量时间，加上该单板发货量大，单板故障率高，维护人员怨声载道。为此，无线可靠性团队专门做了一个“永远在线”的特性，就是在单板部分故障时仍然能通过网管远程管理，重启、升级单板，大大减少了软件故障导致的单板现场维护次数。另一件事是结构部为了降成本，更改了无线抱杆结构件的材料，在家测试验证都没问题，发货到北美后却故障率陡升，变成了批次物料事故，公司损失巨大，后来到现场调研才发现，天气太冷，客户安装人员图省事，并不是在现场安装抱杆设备，而是在温暖的屋里安装好后搬到车上，运输到现场，车子运输途中颠簸振动（我们设计时并未考虑如此场景，当然客户这么做也不符合安装规范），同时，客户安装人员使用的扳手比我们使用的大得多长得多，由此导致很多结构件破损，这问题如果发货量不大很容易处理，但一旦海量发货，而且有些已经安装在世界各种偏僻的角落，整改费用就高得吓人。还有一件事，有次去给某总裁汇报工作，刚进门，站在他办公室门口还没开始说话，领导一看是我就给一通批，情绪激动地叨叨了一个多小时，他说产品出现了重大事故，他就得放下手上的工作，不管白天不管黑夜就得马上出发去一线见客户，递交根因分析报告，写各种保证书，最终还得给各种优惠，“割地赔款”，他很是愤怒、担忧，怪我们不能给他分忧解难，我才知道每一次重大事故我们需要付出如此大的代价。
（2）华为特别有追求。
华为公司的研发很有血性，比如有段时间设置改进目标时，如果已经是业界最佳，每年改进10%，如果不是业界最佳，或不知道业界最佳是谁，每年改进30%。
给DFX业务定牵引目标一样体现出了这种血性。工作中通常有几种定牵引目标的思路：
第一种是和友商比，比如客户满意度，在客户的打分项上，比如设备稳定运行、设备能效等，咱们的客户评价是不是比友商好，一项一项的追赶，好不容易都追上并略微领先，又追求绝对拉开差距。
第二种是和跟自己比，每年都要求要有里程碑式进展，要“上台阶”，这种方式实际操作起来非常困难，主要的原因是作为研发人员，通常对客户的价值关注较少，习惯于埋头拉车，平日大多数的工作，都是一些点的工作，每年都能有一些进展，但都很细碎，难以产生里程碑式的进展，难以打动客户，难以引起关注。举例来说，某主力产品事故平均恢复时间长，由此导致的业务中断时间长，多次引起一级、二级严重事故以及客户投诉，经分析，事故平均恢复时间长主要原因包括故障定界定位时间长、数据恢复时间长、设备重启时间长。如果要彻底搞定此事，需要进一步分析导致故障定界定位时间长、数据恢复时间长、设备重启时间长的根因，针对根因制定技术方案进行原型验证，原型验证通过后技术方案在在研版本中落地，然后开发、测试、版本发布、现网应用、统计现网数据分析改进效果，重复上述步骤直到事故恢复时长能确保不发生一级、二级事故（即事故恢复时长最长不超过30小时，事故平均恢复时长低于10分钟），为进一步巩固成果，还需将相应的设计需求、技术需求、测试需求纳入后续版本的需求基线，输出技术方案设计/测试指导书，提供相应的CBB，同时，针对存量版本制定补丁/升级策略、版本收编计划。至此，此主力产品事故恢复时长长的问题基本解决。这个过程大致需要2到3年，客户界面才能够明显感知到产品能力的提升，算是有了里程碑式的进展。而要竞争力“上台阶”则需要聚焦公司的所有主力产品，将各主力产品事故平均恢复时间长的根因进行深入分析，归类，一类问题一类问题重复上述步骤逐个解决，等到公司所有主力产品事故平均恢复时间长的问题彻底解决，产品事故恢复能力就“上台阶”了，这个过程至少需要3年以上。实际工作中，如果缺乏客户视角，缺乏系统性，缺乏韧劲，往往是针对每个根因做了一小点改进，如做了好几年只是把某类故障的故障检测率从60%提升到了90%，最简配置时的设备重启时间从1小时缩短到了半小时，客户数据量小于**T时数据恢复时长从3小时缩短到25分钟，看起来每年都改进10%以上，甚至有些问题改进还很大，似乎申请个总裁奖都没问题，但这些“改进”都是有前提的，只能在特定场景才能达到如此好的效果，更致命的是，这些“特定场景”并不是现网的普遍场景，这就导致在家里面看起来改进巨大，但在客户界面客户毫无感知。
最后一种是将产品DFX最理想的状态直接作为业务目标。任总提出“高端产品稳定运行，中低端产品生命周期免维修”，还提出向日本、德国的家电学习，为此我们到德国、日本调研其水平，最终了解到他们家电电子部分（电路板）FFR（年返还率）约*%，我们于是以0.*%作为FRU（现场可更换单元，通常为单板/模块）的FFR改进目标，几年后居然绝大部分主力单板都搞定了，甚至于在美国制裁下，我们采用国产元器件，FRU的FFR仍然达成目标，保持了一贯的高水准。“高端产品稳定运行”也进行了分解，其中一个重要的指标就是高端主力产品现网运行一/二级事故数为0，为此成立了公司级工作组推进，共享技术方案，攻克难题，几年后绝大多数主力产品也达成了。还有针对产品调测困难直接将目标设置为“上电走人，一点即通”，针对产品能效将目标设置为“0负荷0功耗”、“按需用能”、“智能手机充电一次拍照一整天”，针对产品可服务性将目标设置为zero touch、self-service、self-healing。说到这，我就想起来余总总说的那句话“求其上得其中，求其中得其下”，直接将产品DFX最理想的状态作为业务目标，直面最强挑战，很多时候刚开始看起来不可能，干着干着，也就实现了。
在公司做可靠性25年，没有哪一年觉得自己业务熟练、游刃有余，倒是每年都觉得很挑战、很难熬，一不留神就被干掉的感觉，我认为除了公司一直在成长，不断开辟新的产业外，还因为我们总是不断地给DFX业务设定非常挑战的牵引目标。
（3）公司研发舍得投入。
很多年前有人问我，为啥华为的产品可靠性能做好，我想了想，从组织、流程、技术、工具等方面说了好一会儿，待我说完了，他说，关键是华为建立了一支规模不小、专职的可靠性设计队伍。
我深以为然。
从2005年底，华为开始建立公司级的可靠性技术组织，开始在各产品线建立专职的可靠性设计师队伍，不包括散热/EMC/安规/防护/环境与可靠性试验/工艺可靠性等人员，全公司几百号专职人员，还设置了公司级的可靠性管理委员会，建立了可靠性设计任职类别任职通道，干可靠性与干设计师相比，同级同酬。这支专职的可靠性设计师队伍，在华为研发有追求、重实效的氛围下，解决产品可靠性TOP问题，落入流程工具固化能力，再解决产品可靠性TOP问题，再落入流程工具固化能力，如此往复，不断垫高产品的可靠性竞争力。对这支队伍的预算投入，粗略用研发平均基线估计每年都得有 * 千万美金，这么多年下来，早已超过 * 亿美金。
公司在每个细分的专业领域都投入很大，比业界任何一个公司都大得多，这应该是能够快速构建工程能力体系的关键。在华为这么多年，不知道从什么时候开始，或许是从进公司5年后第一次涨薪开始，我就觉得公司对自己不薄，自己似乎没有创造相应的价值，对公司总有一种亏欠的心情，自然而然地，就想着能创造更大的价值，别辜负了公司这么大的投入。
—————————————————————————————————————————————
3 DFX业务的责任结果是什么？
DFX业务的责任结果是指DFX业务应该为客户创造什么价值，为公司创造什么价值，在公司的组织体系里应该承担什么独一无二的责任，也就是回答灵魂之问“你帮我解决什么问题”、“你为什么负责”及“哪件事做不好我能开掉你”？
我一直觉得一个业务承担越大的责任就对公司越有价值，只要解决此问题对客户对公司有价值，刚好公司内又没有人管，我都不太纠结于是否在自己的业务范围内。我们应该根据公司业务的发展需要去提升自己的能力，不断学习不断提高，而不能公司业务的发展受限于我们自己的能力。
产品DFX业务责任结果的核心指标是什么？
（1）可靠性
可靠性业务责任结果的核心指标是：网上事故数、业务可用度、设备故障率、FRU（单板/模块）年返还率（FFR）、寿命。
在这些指标中，客户感知最明显的是网上事故，每一次业务中断都会导致客户投入资源进行诊断和恢复，如果是重大事故，即影响面大且业务中断时间长，客户高层还得给上级监管部门进行陈述。相比事故次数，事故恢复时长只要不是太长（如超过2小时），影响度要小一些，也就是客户先关注事故数量，其次关注业务可用度。设备故障不一定会导致业务中断，当设备故障导致业务中断时，客户对设备故障率的关注就会和对网上事故数的关注度一样，当设备故障不导致业务中断时，设备故障率、FRU年返还率影响客户的维护费用，但相比业务中断的影响来说，要小一些。设备的设计寿命需要匹配产品的EOS（退出服务）时间，需要避免单板/模块在设备EOX前出现批量更换。
（2）安全性safety
安全性safety业务责任结果的核心指标是：安全事故数（伤人/重大财产损失）。
我司主要涉及安全性的两个产业，智能电动汽车和数字能源储能，智能电动汽车产业安全性措施主要分为主动安全、被动安全两类，主动安全主要指车辆发生碰撞前的安全措施，被动安全主要指车辆发生碰撞后的安全措施。数字能源储能产业安全性措施主要分为主动安全、被动安全、本征安全三类，主动安全主要指储能电芯燃爆前的安全措施，被动安全主要指储能电芯燃爆后的安全措施，本征安全则主要指储能电芯自身的安全措施。不管是哪个产业，安全性业务责任结果的核心指标都是导致的安全事故数，显然，出现人员伤亡损失肯定大得多。
（3）可服务性
可服务性业务责任结果的核心指标是：事故恢复时间、设备/网络规（划）建（设）维（护）优（化）（运）营工时/成本。
容易理解，相较于规建维优营的工时/成本，客户（这里指最终客户，不涉及华为服务工程师、合作伙伴等）对事故恢复时长会更加关注，事故恢复时间长的原因主要是需要人工进行故障定界定位，尤其对于性能下降、间歇性故障、偶发性故障、静默故障，也有一些设备事故恢复时间长的原因是设备恢复数据的时间较长、设备重启时间较长。在能够对故障定界定位的情况下，缩短事故恢复时间往往依赖于网络规划（业务备用路径）、故障放通、事故演练等，复位、插拔、更换单板永远是好用的三板斧。从客户来说，关心的是规建维优营的成本，但成本数据往往保密，不易获得，所以我们通常能够统计的是工时。不过，工时并不是规建维优营成本的全部，工时加上工具、材料、施工、占地等费用才是。我总觉得可服务性应该有一个类似于可制造性“万元料本制造费用”的指标，不妨叫“万元设备服务费用”（2B）或“万元设备使用成本”（2C），这个指标衡量客户或用户买了我们的设备后，需要花多少成本才能让业务跑起来并运行良好，实现价值创造。
（4）环境可持续性（节能减排）
之前，我们把“节能减排”作为一个DFX，实际上“节能减排”更多强调的是手段，并不是一个产品属性，相比之下，“环境可持续性”会更合适作为一个产品属性，只是“节能减排”这个称谓在公司由来已久，大家已经习惯了。
环境可持续性业务责任结果的核心指标是：能效、低碳、低重、低废。
这几个指标中，能效会直接体现为客户的建设成本CAPEX和电费OPEX，现在系统、数据中心等的功耗越来越大，对电网的需求、电费的节约不是小数目，客户感知明显。低碳则往往成为客户 “双碳”（碳达峰碳中和）目标下制定的基本要求，而且要求有不断明确、细化、趋严的趋势，各国政府更是在推动碳交易、碳税、碳费等，不断减少对环境气候变化的影响。低重同减重，就是减少设备总重量。减废是指减少对环境的污染，包括较少废弃物和减少有害物质，现在通常用设备不能回收利用的重量来粗略衡量。
因为实际运行的系统业务量总在不断变化，所以，“能效”这个核心指标要精确测量且进行比较并不容易，相对易于操作的做法是设定一些典型业务量场景进行测量，这些典型场景能覆盖实际运行的大部分情况，简单地，通常认为待机（0业务量）、50%业务量、100%业务量是比较典型的，也可以加上一些场景，比如30%业务量、70%业务量，但无论如何，和实际运行的能效都有差异，更不用说这里的“业务量”就是一个模糊的概念。对于用户侧设备，如智能手机、笔记本电脑、平板、机顶盒、智慧屏、ONT等，大多数时候处于待机状态，并没有业务量（0负荷），所以待机功耗就是一个关键指标，欧盟ErP指令还对待机功耗和网络待机功耗明确了限值要求，但对于网络设备，通常7×24运行，0负荷待机的场景所占比重不高，所以对待机功耗就没有那么敏感。除了典型场景的能效，还需要关注动态能效，我理解的动态能效应该主要考核“动态”能力，就是能耗跟随业务发生变化的及时性，为了提升动态能效，至少需要能够对系统业务量进行检测，并根据系统业务量动态开启或关闭部分功能模块，进一步，若能根据历史数据或经验规则，对业务量进行一定程度的预测，业务量小时深度休眠，业务量起来前能提前开启部分功能模块，减少深度休眠措施对对业务的影响。
（5）可供应性
可供应性业务责任结果的核心指标是：供应周期、供应成本。
供应周期是指从收到客户订单到产品交付给客户的时间，也叫订单履行周期，通常用Lead Time表示。供应成本通常包括物流成本、仓储成本、报废成本、资金占用成本等，通常用landed cost表示。
客户可以直接感知到Lead Time，对供应成本的感知并不直接，供应成本通常包括存货成本、物料成本和费用成本等，更多体现为华为（作为客户的供应商）自己的设备成本、期间成本、资金占用成本等，没有一个总的、分解到产业经营单元的“供应成本”项，所以，这两个指标相比，供应周期会更为直接、客户易于感知，会尤为重要。
容易理解，供应周期和供应成本互相牵制，不考虑供应成本供应周期可以倾向于零，不考虑供应周期供应成本也可以趋于很小，但这毫无意义，所以，实际工作中考虑的是如何在二者中取得平衡。
（6）可制造性
可制造性业务责任结果的核心指标是：制造周期、制造费用（万元料本制造费用）、出厂质量（开箱合格率/开局坏件/DOA，早期返还率）。
客户可以直观感知到的指标是制造周期和出厂质量，其中制造周期实际上包含在供应周期中，出厂质量通常用开箱合格率、开局坏件或DOA（Dead On Arrival）这类运抵现场但还未装机运行时的缺陷率，加上运行较短时间后的缺陷率，如早期返还率，来进行衡量，对于智能车产业，通常用0公里PPM和IPTV@3MIS （Months In Service），即0公里缺陷率和售后3个月缺陷率来衡量。相较而言，制造费用更多体现在华为（作为客户的供应商）自己的运作成本中。
从责任结果的角度来看，因为我司有专业而强大的技术服务团队、采购供应团队、制造团队，所以，可服务性、可供应性、可制造性更多关注的是产品侧尤其是和设计相关的部分，真正就是 design for X，但产品最终的可服务性、可供应性、可制造性能力还与后端的技术服务团队、采购供应团队、制造团队能力所决定，更确切的说，产品的可服务性、可供应性、可制造性责任结果是产品研发和技术服务团队、采购供应团队、制造团队共同努力的结果，产品设计决定“优生”，后端协作决定“优育”。
各DFX有各自的责任结果，相互协同，从不同维度构建产品竞争力。业界定义的DFX、诸可性少说也得有四、五十种之多，至于哪些是“关键DFX”显然需要考虑业务所处产业、发展阶段、外部环境等等。在华为公司，根据不同产业不同发展阶段的共同诉求，我们通常定义的“关键DFX”主要包括：可靠性、安全性safety、安全性security、可服务性、环境可持续性、可供应性/可制造性。如果哪天有人突然质疑我“华为为什么是这几个DFX，需要进行增减吗？”，我应该如何回答？我想了想，回答这个问题，应该围绕当前几个关键DFX的责任结果来展开。对于已存在的关键DFX，当前责任结果好且未来业务挑战不大的应减少投入，未来新产业新场景挑战大的维持或加大投入。至于判断是否需要新增关键DFX，关键取决于每年客户满意度调查中是否存在非功能性的共性问题，且这共性问题是否无法被当前的关键DFX所涵盖。
—————————————————————————————————————————————
4 DFX业务的本质是什么？
我自己在华为干可靠性25年，我总觉得我给别人讲可靠性三言两语就讲完了，当然，如果你给我一天时间，我也能吧唧吧唧讲个不停，但其实这一天版本都还是围绕着三言两语的业务本质一项项展开，都可以归为细节，知道吧，似乎很重要，不知道吧，其实也问题不大。
这个“三言两语”的版本，我理解就是业务本质，这里的本质就是指某类事物区别于其它事物的基本特质。当然，这里谈的DFX业务本质，是指产品设计阶段DFX业务区别于其他业务的基本特质。
（1）DFX业务的本质是“非功能性”。
可靠性 reliability、可用性 availability、安全性 safety、安全性security、可制造性 manufacturability、可供应性 supply availability、可服务性 serviceability、环境可持续性 environmental sustainability等这样一个集合其实没有一个很好的名字，公司内也有用“诸可性”，简单直接，但在学术界、国际上基本无人采用。公司内，我们现在经常用DFX来代表“诸可性”。
DFX 是design for X的缩写，中文直译过来就是“为了某某的设计”，通常将DFX定义为面向产品生命周期各环节或产品竞争力要素的设计，其中，X可以代表产品生命周期或其中某一环节，如测试验证、生产制造、供应发货、安装部署、运行维护、回收报废、退服等，也可以代表产品竞争力或决定产品竞争力的因素，如可靠性、安全性、电磁兼容、成本等。实际上，上面这个定义我没有找到初始权威出处。关于“DFX”，据考证最早出现于1990年《Bell Labs Technological journal》（也说《AT&T Technological journal》，但我看了杂志，确认封面写的是“Bell Labs Technological journal”），两位AT&T专家 David A. Gatenby 和 George Foo共同署名文章《Design for X ( DFX ) : Key to competitive, Profitable Products》中，文中有段话：The X in DFX stands for manufacturability, installability, reliability, safety, serviceability, and other downstream considerations beyond performance and functionality. DFX is a philosophy and practice that ensures quality products and services, reduces the time to market for a product, and minimizes life-cycle costs. Therefore, it is crucial to achieving customer satisfaction。这里用“DFX”代表manufacturability、installability、reliability、safety、serviceability只是强调在设计中要重视这些特性，并没有说这些特性的流程活动仅限于设计阶段。
而在系统工程领域，如INCOSE 《Systems Engineering Handbook》前五版中，一直没有“DFX”的概念，而用“Specialty Engineering”表达类似的概念。“specialized engineering areas, such as electro-magnetic compatibility, reliability, safety, and security”。“Specialty Engineering”通常译为“专业工程”，不能说错，但 specialty 还有特别的、特殊的等意思，这个“特殊的”在系统工程的概念中实际上是相对于架构、硬件、软件等更一般的工程工作而言，容易理解，这种“特殊”是相对的，“Specialty Engineering”并没有说出“DFX”的本质。在INCOSE 《Systems Engineering Handbook》第五版（2023年）中，其抛弃了“Specialty Engineering”的概念，转而用“Quality Characteristic (QC) ”的概念，并引用 ISO/IEC/IEEE 15288 (2023), Section 3.36 对 Quality Characteristic (QC) 的定义：“inherent characteristic of a product, process, or system related to a requirement”，书中还多次出现“quality attribute”且并未解释二者的不同。我理解“Quality Characteristic”和“quality attribute”并无实质区别。而“质量属性（quality attribute）”这个词是伴随着计算机软件产生的，早在1995年CMU软件工程学院 Mario Barbacci 等就写了一篇技术报告，报告名称就叫《Quality Attributes》。
在 《IEEE Std. 1061 ：IEEE Standard for a Software Quality Metrics Methodology》中定义“软件质量 software quality”为“软件与明确地和隐含地定义的需求相一致的程度”（简单说：质量就是满足要求），定义“软件质量属性 software quality attribute”为反映软件产品某一方面质量的特征或特性（A characteristic of software, or a generic term applying to quality factors, quality subfactors, or metric values）。IST（Information and Software Technology期刊）《Characterizing software architecture changes: A systematic review》等很多文章将“软件质量属性”包括功能、性能、可移植性、可拓展性、可靠性、安全性、易用性、可维护性、可测试性等。很明显，“质量属性”（Quality Characteristic 或 quality attribute）基本上是无所不包，它仍然无法反映“DFX”的本质。
同在INCOSE 《Systems Engineering Handbook》第五版中，引入了另一经常和DFX联系在一起的概念“nonfunctional requirements”，并认为nonfunctional requirements、QC二者大概是一个意思，“QC approaches often generate non-functional requirements”，“nonfunctional requirements (e.g., reliability, maintainability, safety, and security)”，这个非功能性需求（Non-functional requirement）是相对于功能性需求（functional requirement）而言，功能性需求定义系统特定的行为或功能，非功能性需求是指依一些条件判断系统运作情形或其特性，而不是针对系统特定行为的需求。
同时，在《ISO/IEC 25010 : 2011 System and software quality models》中，将产品质量模型定义为包括functional suitability、reliability、performance efficiency、usability、security、compatibility、maintainability、portability，容易看出，除了functional suitability，其他的都是我们日常所说的“DFX”，所以，把 functional suitability 认为是功能性的，其他认为是非功能性的，合情合理。
什么是“功能 function”？我赶紧查标准、咨询专家，这才发现业内也没有一个统一的认识，《ISO/IEC/IEEE 24765 Systems and software engineering —Vocabulary》干脆直接罗列其他各种标准的9种定义，选其中几种我觉得比较靠谱的定义：
a task, action, or activity that must be accomplished to achieve a desired outcome.
the features or capabilities of an application as seen by the user.
an aspect of the intended behavior of the system.
在[美]爱德华·克劳利（Edward Crawley）等著的《系统架构—复杂系统的产品设计与开发》中，“功能，说的是系统能够做些什么”，“功能是可以产生或促进性能的活动、操作或转换”，“功能=过程+操作数”。简单来说，功能就是人打造技术人工物时的目的。人首先需要打造一把切菜刀，这是核心诉求，其次才是需要打造一把好用、耐用、不用经常打磨的切菜刀，切菜是其功能，好用、耐用、不用经常打磨是其非功能。有两种场景会让大家混淆这个界限，一种是当客户提出冗余、防火墙、过载控制等需求时，大家认为这些需求就是功能需求，这种场景下一定要明确，客户提出的需求可以包括功能、非功能需求，另一种是当防火墙、集群、安全网关等作为一种独立的产品出现时，大家就认为安全性、可靠性就是功能需求，这种场景下一定要区分防火墙、集群、安全网关这些产品功能确实是为了增强系统的可靠性、安全性，这时说的“可靠性、安全性”指的是更高层次“系统”的可靠性、安全性，但防火墙、集群、安全网关这些产品自身仍然有可靠性、安全性、可服务性、可制造性等非功能需求。
综上所述，当我们把“诸可性”称为“DFX”时强调的是“设计 / design”，称为“专业工程 Specialty Engineering”时强调的是“特别的 /专业的/ Specialty”，称为“质量属性 quality attribute”时强调的是“质量/quality”。我认为，“诸可性”的本质是非功能性 / nonfunctional，如果生硬地将“诸可性”翻译为英文便于国际交流，或许用“All Non-Functional -ability”较为贴切，也就是所有非功能性能力的总称。
在公司内，虽然大家习惯了叫“DFX”，但需要知道DFX就是指“诸可性”，DFX的本质是非功能性能力，是对功能性的“约束”。
各DFX之间并没有本质的不同，区别主要在于测试验证阶段、供应（含生产制造和供应发货）阶段所需的可测试性、可供应性/可制造性能力偏向于公司内部可见，安装部署、运行维护、退服（回收报废）等阶段所需的可服务性、可靠性/可用性、安全性safety、安全性security、环境可持续性等能力偏向于外部客户可见，基本都涉及GA直到EOL（end of Life，终止产品生命周期，即退服）阶段，其中可靠性/可用性、安全性safety基本不涉及安装部署阶段。
（2）可靠性业务的本质是裕度。
从客户可感知的角度，我们则经常说产品可靠性有三个层次，第一个层次是产品不出事故，第二个层次是产品不出大事故，第三个层次是产品即使出了大事故业务也能快速恢复。产品可靠性的核心指标就是可用度，即我们经常说的可用度99.999%，简称“5个9”，“5个9”等价于一年不可用的时间为5分钟，经常说为“年中断时间5分钟”。对于用户侧的设备、终端，因不是7×24不间断使用，加上成本所限通常不采用部件冗余，故障影响面有限出不了啥大事故，所以更关注的是年故障率（年返还率）。
产品出事故或返厂维修，都是因为发生了故障，而导致故障的原因有很多，可能是环境变化、元器件损坏、加工缺陷、来料缺陷、设计缺陷、代码bug、人为误操作等等，我们当然会想尽办法避错、排错，减少这些失效，但即使是6西格玛水平，仍然有不小的出错机会，我们也知道越简单越可靠，但产品就那么复杂，“简单”也只能是相对而言，所以，认为出错、失效总是无法避免的，得考虑出错、失效后能否不导致产品业务异常就成为了一个设计师的基本常识。
在ICT领域，柜式产品通常对产品体积、重量没有严苛的要求，所以，冗余就成为了提升产品可靠性的关键手段，冗余有很多种方式，最直观的就是部件冗余，就是多一个备用部件，1+1、n+1，这种通常叫空间冗余，还有一种叫时间冗余，就是本来只发一次简单信号，现在发多次，或者发一次复杂的信号以避免常见的失效模式，这还不够，还要等待确认。提前预测出可能发生故障，提前处理故障或提前采取规避手段，都可以算为时间冗余。在此基础上，为保证冗余手段有效，相应的主用单元故障检测、备用单元故障检测、故障定位、故障隔离、故障切换、故障恢复、故障预测等手段也得备上。对于用户侧设备、终端，降额、容差容限就成为了提升产品可靠性的关键手段，降额就是使元部件使用应力低于其额定应力，以从容应对应力波动，在此基础上，选择规格能够承受更大应力的元部件、降低使用应力水平、降低使用应力的变化程度等也得备上。
冗余、降额、容差容限的核心都是裕度。
（3）安全性safety业务的本质是受控
在国际IEC标准体系里，安全性不像可靠性一样，可靠性（Dependability）由单独的TC 56负责，而安全性则分散在不同的TC里，比如：
TC 44：Safety of machinery – Electrotechnical aspects
TC 61：Safety of household and similar electrical appliances
TC 66：Safety of measuring, control and laboratory equipment
TC 76：Optical radiation safety and laser equipment
TC 108：Safety of electronic equipment within the field of audio/video, information technology and communication technology
TC 116：Safety of motor-operated electric tools。
智能汽车产业所涉及的功能安全标准IEC 61508（Functional safety of electrical/ electronic/ programmable electronic safety-related systems），则出自IEC TC/SC 65A。Safety目的是将能够造成人员伤亡或财产损失以及严重破坏环境的危险降低到可以接受范围。传统上将可靠性定义为“在规定的条件下，规定的时间内，完成规定功能的能力”，当把人员伤亡、财产损失等安全事故算做严重事故时，safety也就顺理成章地被纳入可靠性范围中，所以，从这个意义上说，“裕度”也是safety的本质。但因safety事故的严重性，在裕度的基础上，safety的本质还包括了“受控”，即一定要将安全风险控制在可接受范围内。
应对安全风险，需要考虑本质安全、功能安全两部分，本质安全是指通过设计等手段使设备或系统本身具有安全性，即使在误操作或发生故障的情况下也不会造成事故的功能，如消除危险、减少危险，使用危害较小的材料，使用危害较小的工艺条件，设计工艺以减少人为错误、设备故障或故意伤害的可能性或后果等，通常具备失误-安全（误操作不会导致事故发生或自动阻止误操作）、故障-安全功能（设备、工艺发生故障时还能暂时正常工作或自动转变安全状态）。功能安全则是指技术、工艺或设备等在出现故障或错误时，能够及时地通过系统自我检测、诊断和修复，以避免发生安全事故的功能。“受控”主要指的是执行安全功能模块的失效率需控制在一定的概率范围之内（SIL等级越高自然要求越高）。
（4）可服务性业务的本质是自动化
可服务性，serviceability，目的是让客户把设备用起来，运行业务并持续产生商业价值。产品可服务性的对象是客户，要从客户视角来完整的审视产品的可服务性，我司技术服务部门给客户提供的服务仅仅是产品服务的局部。客户需要的是运行业务，而不是购买设备，从这个意义上说，客户最希望的是设备上电就能用，把网线、光纤等连接好，上电走人，自动发现相邻设备、自动联结、自动配置、自动错误检查，涉及到账号、权限、升级、告警处理等需要人工介入的场景，尽可能简单，指示清晰，让客户能容易操作。当产品质量不够好，可服务性不够好时，我司提供无微不至的技术服务就成了重要的兜底手段，但这是无奈之举，长期来看，我们还是应该把产品的可服务性做成产品竞争力，而不是只想着把技术服务做成竞争力。
可服务性最明显的特征是“人”的参与，可服务性业务的终极目标是不需要人参与，也就是自动化，包括自动生成规划方案、即插即用（自发现/自协商/自配置/自纳管）、自动配置、版本自动校验、自动定界、自动化扩容（自初始化配置/自纳管）等，如果不得不需要人参与，则需要做到远程、极简、防人因差错，这些可以认为是不同程度的自动化，基于此，可服务性工作需要对主力产品的服务场景，如工勘、规划设计、软硬件安装、工程集成、调测、验收、配置、巡检、告警处理、扩容、升级、排障、报废处置等，也就是规（划）、建（设）、维（护）、优（化）、（运）营服务场景进行细致梳理，每一个需要人工参与的场景，都要严格的审视是否能通过技术方案的改进促使其自动化。大多数情况下，产品设计师把“人”当做了最后兜底的重要手段，有些缺乏经验的设计师甚至都没有认真考虑设备的服务场景，如果能改变理念，产品在各种服务场景下都尽可能不给人添麻烦，相信可服务性就会有较大的改观。
（5）环境可持续性业务的本质是环境影响
环境可持续性研究的是产品生命周期，包括原材料获取、材料加工、产品制造、产品销售、产品使用、产品最终处置、产品能量回收、产品填埋等环节，核心是节约物质资源和能量资源，并减少废弃物和环境有害物。
容易理解，产品寿命越长、可靠性越高、维护越容易，环境可持续性也越好，所以，往大了说，环境可持续性包括了产品可靠性、可服务性等诸多DFX，但除却这些，环境可持续性更关注节能、节材、减废、减排、无毒害，关键的设计措施包括提升能效、可重用、可回收、减量化、环保等，在这些设计措施中，可重用、可回收、减量化、环保等基本上在设计中一次成型，和设备的运行时间相关性不强，唯独能效能力与产品的运行时间息息相关，再考虑到当前设备容量越来越大耗电越来越高，能效就成为了影响产品OPEX的关键因素，需要重点关注。
环境可持续性最明显的特征是考虑产品对“环境”的影响，其终极目标是产品使用的物质资源、能量资源尽可能少，寿命尽可能长，废弃物基本没有或都可循环利用，报废时对环境无害。
（6）可供应性业务的本质是模块化
供应是指从供应商到客户的过程，包括销售、订单处理、计划、采购、制造、包装发运、中心仓库、站点安装等。从供得上的角度看，原材料至关重要，所以，特制品、稀有品是大忌，非主流原材料、供应商独家，不但价格高、供货周期长，而且供应波动大、风险大。原材料“大路货”才是可供应性的根本。虽然，用“大路货”的原材料做出性能优异、有竞争力的产品，对设计师要求太高，但至少应该成为一种设计习惯。
解决了供得上的问题后，供应就应该更多关心及时、准确、优质、低成本交付，核心指标包括满足客户期望的Lead Time、更高的存货周转率ITO、更低的供应交付成本。如果客户的Lead Time足够长，或我们的供应周期足够短，我们完全可以采用MTO（Make To Order，见单制造）的方式，等客户订单确定后再开始制造，既能够保证Lead Time，还能确保基本不需要供应中心存货、在途存货、区域存货或站点存货等，一举多得。但实际情况往往是MTO模式导致加工任务紧、交货周期长、回款周期长，所以会选择ATO（Assembly To Order，见单装配）或PTO（Pick To Order，见单拣料），不管是哪一种模式，都得预先加工，提前存货，想方设法同时满足客户灵活个性化需求和供应链大规模生产标准化需求，此时，如果能提前加工一些通用模块，用搭积木的方式去实现多种多样的销售配置种类，就显得尤为重要。对于一些通过通用模块搭积木仍无法满足的特殊需求，可通过外挂的特性、接口、功能、配置等实现。这就是DFSC的“小蛮腰”――元器件种类少 + 实体模块数少 + 可销售的配置种类多。“实体模块数少”的核心就是通用模块，这些通用模块是具有特定功能和接口结构的独立单元，具有“高内聚，低耦合”的特点，可以在不同产品之间、同一产品系列之间重用，这样就大大提升了产品的可供应性。
（7）可制造性业务的本质是标准工序及共线生产
就制造环节而言，效率最高、成本最低的方式就是“1个流”，就是从PCB（印制电路板）上板印刷开始，SPI（焊膏检测）、物料贴片、回流焊、压接、单板装备、单板FT（功能测试）、整机装配，直到包装发货，这些环节都能按照同样的节拍流动，任何一环节不等待、不反复。
假如有特殊工序，比如波峰焊，不但波峰线体占地面积大，增加产线长度，用工多，维护贵，而且波峰焊接一致性差，锡珠补焊比例高，波峰焊工序人工干预多、动作多（成型、插装、翻板、刷锡珠、剪脚、洗板、返修等），质量还不高，已属落后工序。类似的特殊工序/设备还有：SMT印锡板点胶、AXI、选择性波峰焊、涂敷、双面波峰、双面手工焊、温循等。虽然制造环节会想尽一切办法提高生产环节自动化水平，但特殊工序研制自动化装备不合算，自然难以提升自动化水平。扩大特殊工序的定义，工序离线（周转、搬运和断点）、反复出入库、装配部件复杂（装配层级多或线缆连接）、装配浪费动作多（拆包装动作多或翻板打螺钉）、产品与自动化不适配（同料不同包装或夹取空间狭小）等也可算在其中。特殊工序成为制造“1个流”的瓶颈。
另一方面，生产线生产能力强，同一时间单个单板的制造需求难以匹赶上生产线的制造能力，所以，同一生产线经常同时生产多个单板，而且通常会安排同一个产品族的多块单板共线生产。如果同一产品族的单板能尽可能平台化、组件化、标准化，如果这些单板还能实现归一化、简洁化，共线单板器件种类数小于产线极限（通常小于500），就会使得多单板共线生产更为容易。
可制造性业务的本质就是共线场景下无特殊工序/装备的自动化“1个流”。
————————————————————————————————————————————
5 DFX工程能力应该如何建？
回答DFX工程能力如何建这个问题，需要先明确三个关键点：
第一，DFX工程能力的构建必须和解决产品重大问题相结合，边打边建。一方面，不将重点放在解决产品实际问题，一门心思建工程能力，必然是刻舟求剑，难以指导产品实践，因为我们能沉淀下来的工程能力，都是以前解决产品实际问题的成功实践，将这些成功实践进行总结就形成了工程能力，这些沉淀下来的工程能力对于解决后续类似的问题当然大有裨益，但能力迁移过程中仍然会发现对新场景、新需求、新业务难以适用，实际上，我们是在不断解决问题的过程中逐渐提升了自己的能力，甚至常有“觉今是而昨非”的感觉，将以前的一点成功经验当做未来成功可靠的向导，自然是刻舟求剑。另一方面，DFX存在的价值就是帮助产品解决一个又一个的难题，如果不能在解决问题中证明自己的价值，建一个“完美”的工程能力又有何意义？更何况，建工程能力需要抓住主要矛盾，产品从来没有出过问题，一些产品已经内化了的能力就没有必要去建设了。
第二，DFX工程能力的构建必须“五化”，即系统化、抽象化、概念化、模型化、工具化，简而言之，就是工程能力的构建必须要从解决单个问题中抽身出来，解决一类问题。
第三，DFX工程能力的构建必须要和研发主流程、研发主桌面、研发主工具相结合，水乳交融，才能不依赖运动，不依赖人员推动，不依赖人员配合，真正固化下来，避免后续踩坑。建工程能力时就需要考虑支撑研发主流程的哪个活动，设计师在执行这个活动时怎样才能自动呈现到设计师面前，需要设计师用什么工具并怎么做，如何自动检查、验证并汇总执行的情况？实现自闭环管理。
就DFX工程能力而言，通常包括组织、流程/活动、工具、知识几部分，共同支撑产品DFX愿景目标。
其中，流程活动是DFX工程能力纳入主流程例行开展的关键，需要明确DFX活动与研发主流程中的哪个活动融合，并明确DFX的交付件、DFX活动的承担角色。流程活动中最重要的是设计、测试两个环节，这也是DFX工程师工作的重点，设计环节涉及IPD流程的charter、概念阶段、计划阶段，重点是DFX需求分析、架构DFX分析（架构设计活动）、系统DFX分析（系统设计活动）和功能DFX分析（功能设计活动），测试环节只涉及IPD流程的验证阶段，重点是对DFX需求的验证。设计、验证形成闭环，这样才基本可以确保DFX活动的例行开展，确保相关能力固化到流程中。
组织是确保DFX流程活动能得到高质量执行的基础，是确保DFX角色能力持续提升的重要保障，各产业可根据需要确定重点建设可靠性/可用性、安全性、可服务性、环境可持续性、可制造性、可供应性中某几个专业的专职队伍，更重要的是，产业主管应该有“DFX是专业性很强的工作，需要有专职团队长时间积累”的基本认识。DFX是非功能的主要部分，尤其可靠性、可服务性、环境可持续性是客户可见的产品的重要属性，完全应该是产品竞争力的重要部分，比较明显的如当前可靠性之于终端、计算、核心网，安全性之于智能车、数字能源，可服务性之于企业，环境可持续性之于数字能源、无线，可供应性可制造性之于数字能源、智能车，这里说的是“当前”，待我司计算解决了有无问题，实现大规模突破海外，终端鸿蒙大规模突破海外，关注点又都必须增加环境可持续性。组织建设的可选形式包括产品某DFX SE（兼职），产业某DFX工程师（专职），产业DFX PL―TMG，公司某DFX C-TMG，公司DFX MC等。专职团队及各TMG的主要职责是技术规划、公共能力建设、基础能力库积累、公共工具开发等。
知识是DFX工程能力的核心，通常包括DFX工程方法、DFX规范/指南/指导书（在我司内部不严格区分，统称规范）、DFX模型、DFX专业库等，其中，需要长时间持续积累的是DFX专业库和DFX模型。各DFX的专业库各不相同，如：可靠性专业库包括元部件故障模式库、元部件故障率库、领域事故根因库、可靠性设计模式库、关键可靠性特性CBB、可靠性测试用例库等，安全性专业库包括领域危害模式库、危害事件库（智能车）、领域危害致因库、领域安全机制库、领域安全测试用例库等，可服务性专业库包括领域可服务性场景库、可服务性测试用例库、可服务性IT工具集等，环境可持续性专业库包括部件功耗库、产品材料环保信息库、LCA生命周期环境影响库等。DFX模型通常分为三类：DFX工程元模型、DFX设计元模型和DFX评估模型，DFX工程元模型描述的是DFX工程活动中涉及到的核心概念及关系，其关注点是DFX工程活动；DFX设计元模型表达的是在产品设计中呈现出来的DFX核心概念以及与产品设计本身核心概念间的关系，其关注点是对产品的描述和产品呈现的DFX属性的描述；DFX评估模型描述的是产品DFX能力和产品各相关要素之间可计算的定量数学关系，通常用函数表示，关注的是在产品设计前期阶段或在验证阶段对产品某DFX能力进行仿真、评估验证。DFX评估模型是DFX数字化的关键，也是产品数字工程的重要前提。当前，可靠性的可靠度（等效于MTBF/年返还率）、可用度，安全性的安全失效率，环境可持续性的能效、硬件能耗，可供应性的供应周期、供应成本，都建立了完善的评估模型。其他两类知识，DFX工程方法和DFX规范/指南/指导书，易于理解，在此不再赘述，只提醒一句，DFX规范除了设计规范，还可以包括测试规范、配置规范、安装规范、实施规范等等。
工具是DFX相关流程活动得以有效执行的的核心关键，我们以前有误解，总认为工具无非是提升效率，没想到当系统越来越复杂，依靠人工已难以开展DFX定性分析工作，此时，如果没有DFX工具作为辅助，研发人员很不情愿开展DFX流程活动，即使勉强开展，效果也大打折扣，更不用说DFX定量分析工作需要大量基础数据和数学运算，没有工具已经不可能开展。到现在，各DFX在工具开发部门的帮助下，多多少少积累了一些工具，如可靠性的FMEA（故障模式影响分析工具）、ReMAP（可靠性仿真评估工具）、RASFire（故障注入工具），环境可持续性BenchSEE（服务器能效测试工具），BenchDEE（存储能效测试工具）、Simapro（商用LCA评估工具）、Insight（材料环保信息检索分析工具），可制造性可供应性的Digismart工具，可服务性的OMRP（OM资源设计和生成）工具等等。当前这些工具都是一些独立的小工具，没有和研发流程、研发工具打通，还各自为战，用户数有限，也没有和产品数据打通。未来，这些工具还是要融入研发主工具中，成为研发人员不知不觉使用的工具，并实现数据与产品研发数据的互联互通、自然流转。
——————————————————————————————————————————————
6 做DFX需要具备什么样的能力？
做DFX工作，需要具备的能力包括知识、技能和态度三个方面，如果按占比来看，大概20：30：50，不过，知识是基础，是前提，是专业性的保证，相当于知识是那个“1”，技能和态度都是之后的“0”。
知识，指的是那些前辈已经发现、总结的概念、规律，对某个DFX而言，就是基础概念、基本理念、数学模型、方法、设计原则等，都是需要进行“记忆”的内容。通常而言，在理解的基础上去记忆相对会容易，比较好的办法就是经典的专业书籍、论文、标准一定要逐字逐句多读几遍，这些系统化、概念化、理论化的经典知识基本掌握后，再尽可能找到更多和专业相关的书籍、论文、标准，扩大接触面，往往在一本书上读不懂的内容，在另一本书中突然就明白了。专业能力的建立需要有一定的接触面的，只有通过深入、广泛的阅读才能具备足够的专业性，基本的要求是别人说到本专业的哪本书、哪篇文章，不管是中文还是英文，基本上都应该在你的已读清单里，如果有人质疑你专业性，你抱上几摞书放到他面前，他可以随便问，如果有人要你推荐专业资料，你也应该能够如数家珍列出清单。另一方面，带着问题去阅读，自己去寻找答案，有机会就向专家请教，通过这种思辨的方式去记忆知识，会较为牢固，理解也深刻得多。同时，知识是有适用边界，甚至保质期的，新技术、新理论层出不穷，需要持续关注、持续学习。
技能，指的是那些你必须亲自做过，亲自经历过，否则就永远不会真的知道的能力，也就是那些你以为你知道但实际上并不知道的能力。简单的例子就是游泳、骑自行车、耍杂技、演讲，你学再多的知识，看再多的演示视频，还得自己亲身去试去体会。提升DFX技能唯一的办法就是自己亲自去做。从了解客户需求开始，charter、需求基线、架构、系统设计、仿真、开发、验证测试、试制、生产、运行、网上问题分析闭环，尽可能都要亲自参与，亲自使用各种工具，有些环节没有亲自动手的机会，也得跟着看跟着跑，只要有机会就多见见客户、和客户运维人员交流、跑现场，经过完完整整地参与几个版本的端到端，书本上的知识才会活络起来，对DFX才会有切实的感受。
和知识和技能相比，其实最难学的是态度。态度是价值观，态度是你选择用来看待世界的那副有色眼镜，态度是你面临选择时的趋向。DFX人员总是属于小众，总是被边缘化（相对产品功能性能而言），总是需要去证明自己的价值，所以，对DFX人员工作态度的要求其实更高。我认为优秀的DFX人员起码得有三个态度：
第一，DFX要解决产品的关键问题，帮助客户商业成功。DFX业务的价值需要通过解决产品一个又一个的问题，解决客户一个又一个的痛点中体现出来，问题越挑战，痛点影响越大，DFX的业务价值就越大。产品的关键DFX一定要想着做成产品的竞争力，成为产品的主要卖点，支撑产品攻城拔寨大规模销售，前提是在客户界面上能量化商业价值，能折算成钱，不管是add value 还是 save cost，都要尽可能能折算成钱。“折算成钱”这句话大家容易有疑问，觉得有很多改进难以用钱来衡量，但从我的经验来看，如果能够和质量人员、产品人员一起，到一线调研，建立质量损失函数模型，说服力是非常强的。我们很多时候就是只看到了单指标的改进，比如故障检测率从80%提升到90%，漏报率从5%改进到3%（当然，我们会说改进了40%），检测精度从10mm提升到7mm，电池柜吊装时间从15分钟改进到5分钟等，难以直观感知这些改进带来的价值，偏偏DFX改进是需要综合权衡，做多一点或少一点，投入不一样。有两个比较好的例子可以参考，一个是网上批次物料问题改进项目时，和质量、服务、产品一起估算了平均一次批次物料问题整改的损失**万元，由此容易得出各环节拦截的价值，产品也很认可该项目的价值；另一个例子是，储能电池安全目标制定时，某主管关注的唯一问题就是一次起火事故损失多大，户用储能损失多大，工商业、电站储能损失又多大。在“折算成钱”的过程中，不要走向一个极端，自己凭感觉拍脑袋，也不要走向另一个极端，追求零误差，我们一定要自己深入一线调研，掌握一手信息，并和一线、质量、产品等相关人员充分沟通，大家一起来建立模型，并持续优化，模型如果误差较大，就只能退而求其次，把改进产生商业价值的场景描述清楚，模型是否精确其实并没有那么重要，更重要的是趋势，没有一个数量级的偏差就挺好了。
第二，深入一线才能得到真实的反馈，也才能建立自己的敬畏之心。DFX人员一定要寻找、创造更多的机会和行业、客户面对面交流，交流标准、标书、需求、痛点，到产品里参与系统设计、测试验证，到制造、仓储、运输、安装、升级、配置、演练、运维等现场，到一线不但能让我们了解需求背后的故事，需求背后的逻辑，了解产品DFX真实的情况，而且这些信息也会成为后续开展工作时最有说服力的证据。深入一线才能帮助我们实现认知闭环。
第三，心中有罗马，随时布道。DFX人员应该象传教士一样，心中有罗马，时刻记着一定要给客户给产品创造价值，给人价值感，利用一切机会传递DFX创造价值的故事，用故事来布道，这种怀揣理想，坚定热情的态度我认为是最重要的。之所以这态度特别重要，是因为DFX的价值并没有那么显性，需要我们自己首先笃信DFX的价值，然后才能证明DFX的价值，同时，DFX价值的实现需要跟进产品端到端流程环节并和其他业务协同，需要深入一线，需要和客户打交道，需要和供应商打交道，需要和上下游打交道，沟通、推动，事务繁杂，需要很强的韧性，更需要坚定的热情。
————————————————————————————————————————————
写在最后
我刚开始发心要写这篇总结时，估摸就几千字，后来想了一下结构，觉得都是自己想总结的内容，内容也熟，最多持续一周就能完成，没想到一动笔，就像随意在地里挖一锄头，泉水就直往上涌，搞得我手忙脚乱，眼睁睁地看着水肆意流淌，等我找来了盛水的坛坛罐罐，水突然又没有了，我只能沮丧地另择场所继续挖，晚上做梦和早上跑步时才思泉涌，坐到电脑前江郎才尽。我就在“才思泉涌”和“江郎才尽”之间反复游荡。
一方面，我觉得现在DFX工作难度比二十年前大多了，比如智能车、数字能源、计算等新产业无人可学，比如无法像以前一样获取最先进的合作资源，比如DFX数字工程、DFX融入全量设计的系统工程没有经验可以借鉴，比如DFX能力已融入了组织流程，产品DFX竞争力强，当前的研发主管再也不会像以前的总裁一样向我叨叨一个多小时就只因担心网上有重大事故，比如DFX人员再难以有机会端到端跟进几个产品了，难以重复我们当初的成长路径。
另一方面，按照现在的招聘标准，我是决计进不了华为的，所以，江山倍有人才出，现在的兄弟们可比我们当初强太多，我25年职业生涯从什么都不懂开始，向前辈学习，向美国学习，依靠组织的力量最终实现行业领先，而现在的兄弟们，他们和业界站在同一起跑线上，即使被制裁被束缚，相信仍然会勇攀高峰。
总体来看，我对DFX业务充满信心，新产业、新行业存在不少DFX能力洼地，数字化、智能化对ICT基础设施（包括云）DFX要求更高，智能车、新能源也还需要我们建立DFX标杆。
就这信念撑着，工作之余断断续续写，煎熬了一个多月，终于写完，如释重负。无论如何，总是给这25年的经历打了个结，如果再能让某位兄弟觉得有收获，那就是法布施，很圆满了。
做困难事，必有所得。
（来源：华为，章迅）
-
- 哎呀，回复话题必需登录。
