做数学和编程的“调味师”

我是一个思维跳跃但是肉体懒惰的人，不喜欢简单的重复。2016年春天，机缘巧合下我有幸看到了吴军的《数学之美》。书中介绍了在解决问题时如何化繁为简，如何用数学和编程去解决工程问题，如何跳出固有思维不断去思考创新。数学+编程所展示的“简单粗暴”的效果，让我深受震撼，心中将“数学+编程”应用到质量工作中的小火苗已经跃跃欲试。

2016年秋，我有幸加入华为，华为高压力快节奏的工作和全面详细的数据好像催化剂和助燃剂，“嘭”的一下，心中的小火苗一下变为了火炬，指引我踏上了新式质量管理之路。

一个“宏”减了一个人的工作量

2018年1月26日，某产品功能测试不开工累计xx pcs，切片发现单板上的晶振内部小晶体焊点有裂纹，经问题攻关小组共同决策，必须紧急隔离产品7000余件，其中理货中即将发运的产品1400件，涉及数百个合同。此时正值春节前发货高峰，而且马上是小周末，浪费1分钟就可能导致货物无法及时装车，海/陆/空运都会延误，对交付产生巨大影响。要从众多物料中从中找出这些不良品，时间紧、任务重，该怎么办？

作为一名PQE（产品质量工程师），我是生产质量问题发生时的“指挥官”，必须hold住全场。我第一时间向MQE（物料质量工程师）、车间、质检和库房领导求助，挤出一支由来研发制造实践的产品经理、车间维修工段长、质检检验员、库房操作员、质量工程师和技术员组成的12人“混编连”，扑向了“战场”——R3-1F高架库。

战斗刚打响，我们已经做好明确的分工：这12个人中，库房两位同事负责用叉车将产品从立库移下来，剩下的人分为两组，每组1人扫描条码、1人监控电脑上的数据，提醒是否为不良品，1人根据指令粘贴良品/不良品标签，2人搬运并区分开良品和不良品。但是30分钟后，我们发现这样行不通。只分两个组效率太低了，预计需要通宵才能搞定；但是分三个组人员又不够，已经没人能支援了，怎么办？继续用“血肉”硬拼吗？

此时我头脑里灵光一闪，为什么要专人区分是否是不良，难道不能让系统自动提醒吗？我想起以前做过一个能够自动播放音乐的“宏”，是否能改造利用下，当扫描到不良时让电脑自动播放声音提醒呢？这样不就省一个人了吗？

经过15分钟修改和测试，我在Excel 2016中实现了“VLOOKUP查找条码+IF语句判定是否不良+宏自动播放告警声音”的功能。于是我们重新划分为4个作战小组：每组1人扫描条码，1人根据提示音粘贴良品和不良品的标签。剩下2人专门区分搬运，2个人继续从立库上将风险品换下来。

经过8个小时鏖战，我们终于在晚上19:40完成了全部库存产品的清理和区分，可以保障正常发货了。

事后大家感叹，没想到“隔离”还可以这样玩，原来预估30多个小时的工作量，8个小时就完成了，真的是“科技是第一生产力”啊！

胜利后的合影
 

 “Python”菜鸟的初战

其实，这已经不是我第一次用编程解决问题了。

2016年12月，我还是一个刚来3个月的“菜鸟”。当时的主管猛哥问我：“咱们部门的大数据质量预警接口 交给你，有没有信心搞好？”我真是又惊又喜：惊的是这可是一级部门重点项目的重要子项目，我能行吗？喜的是数据分析和预警正是我擅长和感兴趣的，而且领导又如此信任我。虽然有点意外，我还是决定接下这个重担。

当时可用的预警只有交验不良预警和测试项预警，而测试项预警只推送给单板测试工艺人员。把测试项预警推送给PQE，就是我第一个任务。

当我信心满满冲上去的时候，一盆冷水兜头浇下来：这么多编码，怎么配啊？原来，测试项预警需要按编码+工序+团队来配置预警，不同级别对应不同门限，又需要根据编码归属的产品线，分配给不同的团队。复杂的配置逻辑，光是“Ctrl+C”、“Ctrl+V”都要很久，根本无法下手，这可怎么办？

我毫无头绪地回到家，预警配置的难点依然不断在脑袋里闪现。洗澡的时候我突然想到：多表关联且有固定的配置逻辑，为什么不用编程自动生产一个表单，来解决这个问题呢？我赶紧洗完澡，从沙发下面翻出《Learn Python the Hard Way》和《利用Python进行数据分析》，简单过了下内容，发现果然可以这样实现！当晚我兴奋地装好Anaconda，配置好环境，凌晨3:00，终于放心地睡觉了。

从这天起，每晚我都会抽出时间一边翻书一边写代码。一个星期后，第一版300+行的代码终于完成了！手工+代码半自动地实现了9个基表14种逻辑到一张配置基表的转化，成功将测试项预警运转了起来。后来我又不断进行迭代和重构，经过十几个版本的修补，终于形成了现在稳定的420行代码。有了它，就可以实现根据加工量筛选，根据不同产品设置不同门限推送不同团队，并自动与上一期配置表做增量对比的自动配置功能，成功将配置时间从40小时/次降低到了5分钟/次。

大数据质量预警的出色表现，让我们获得了2017年华为质量奖制造质量奖三等奖。作为团队中的一分子，我感到特别骄傲。

截至2018年6月，这段代码已经运行了60多次，使测试项预警覆盖了7940个常用编码，占全年总测试量的99.58%，也实现了泛网络产品功能测试类批量问题100%预警拦截的壮举，成功避免xxxK pcs物料上板造成返工。我也经常被制造IT的兄弟调侃：“最烦你们这种懂代码的业务，需求太多了！”

数学建模实现零缺陷

制造每天大约产生一万条维修数据，如何从茫茫数据中挖到TOP问题并改进呢？2016年底，一个单板报废的案例给了我启示。

华为制造质量数据记录是比较全面的，当时我又痴迷于尝试用数据方法解决质量问题，所以我就想，如果我把“物料编码+缺陷代码”组合在一起作为一个简单的模型，同时看缺陷数和比例，是否能够就能够判断物料的典型问题呢？

于是，我用Python做了一个简单的模型，每天抓取前加工维修数据。正好这时某物料抬高导致两块单板焊盘撕裂，我把这个数据套进我那简陋的数学模型里，惊讶地发现，2016年此编码抬高问题累计发生了32起，占此编码全部问题的59%。这是一件令人振奋的事情，根据数学模型，可以锁定抬高问题就是这个编码的典型问题。

验证模型有效性的机会来了！经过组织设备、互联、研发工艺和MQE兄弟们的多轮细致分析，我们终于找到了问题的根因：贴片机抓取的中心点与封装库设计的中心点存在差异，两个中心点相差了0.3毫米。

中心点差异示意图

对齐了中心点选取标准并调整设备抓取中心点后，这个编码已经连续18个月未发生问题，真正做到了“零缺陷”。同时，此数学模型识别出1420类多个物料都有同类问题，推广至今已有多个编码再未发生贴片抬高问题。

根据业务经验总结出的数学模型一战成名，其准确有效使我信心满满。于是我继续扩大它的应用，尝试在硬件版本Charter阶段就导出典型物料问题，从设计阶段实现典型制造问题的预防。此举在波分某新产品试制中效果显著，产品试制直通率远超目标水平。

时间总是过得特别快，转眼我已经来到华为700多天了。作为一名生产质量问题处理的“主官”，在这个没有硝烟的战场上，我希望尽可能地用各种手段武装自己，指引我的小组攻克一个又一个质量难题。

随着“战斗经验”的积累，我已经掌握了数据程序化自动分析、文本词频分析、数据可视化、数学建模和质量预警等多种战术手段。数学、编程与质量融合调味成不同的组合，爆发出巨大潜力，使我沉迷其中，无比享受。随着华为制造智能质量控制和大数据质量预警的快速发展，这些手段会成为我们特有的质量武器。

本文为《华为人》版权所有，未经允许不得转载。如需转载请联系编辑部hwrb@huawei.com