做QA应该是水无常形，兵无常法。Checklist、指标仅仅是冰山一角，最关键需要建立的是人对产品质量态度和责任感。我们经常分享结果（模板、流程），为什么做和如何思考做这个事的思维方式更加值得分享，明白当初为啥做这个事，才可以促进态度和理念的复制，否则只能模仿形而失去了最重要的神。当然，各个优秀实践，可以作为一种案例可以进行货架化知识管理，便于查询。

§实践篇§

Ascend P1 是我司的第一款旗舰机，高层期望开始创造华为的品牌，责任重大，同时AP+modem第一款商用，HAP 5.2 首款商用，首款LCD/TP一体式来料，华为最薄设计，N个固件新器件…… 困难重重。 最要命的是，Ascend P1 半路接手，同时要求项目提前计划2个月上市，跟着项目组走过了最疯狂的一段时间，本着找到关键的20%，重点突破，小循环逐步改进的工作思路，做了不少尝试，有好的结果（我们赢得了100万，），也有不好的结果（改版次数多，VS试制流程执行不到位），回首看看，有的也有失，简单总结一下给大家分享，欢迎各位方家批评指正。

一、 确定项目质量工作的思路：

认清现状:

1、 上海团队第一次做智能机，能力不足（北研团队软件人均问题单修改能力是1.5个/天，上海团队最多就是1个/天），项目团队对项目保质按期交付还是存在疑虑。

2、 Ascend P1是华为公司第一款旗舰机，余总及其重视并且要求提前上市，提出提前2个月交付的要求，并许诺200万项目交付悬赏奖（100万/月），版本经理比较狂热。

换位思考，明确工作思路：

“项目团队不是不希望改进和提升，更多的时候是他们遇到问题不知道如何去改进。”

终端是强项目交付牵引，但是项目运作又是强资源矩阵（至少目前是），项目交付应该还是第一位的，整个项目团队的成员都还是希望能够按期交付，按质量要求交付。

新软件平台，新硬件平台，新项目定位，一定会遇到问题，而且是一堆的问题，拿着质量的要求、标准去要求团队达成，是一种质量人员的做法；融入到项目运作中，切实的协助项目组识别关键问题，解决运作过程中的问题，也是一种质量人员的做法。

项目按期交付，拼命往前冲的大势无法阻挡，那我宁可选择融入到项目团队中，实实在在的将产品质量做好，切切实实的将项目运作过程中的问题解决。虽然将面临一堆的问题，但是我阳光总在风雨后，不经历痛苦，哪能感受幸福。 ^_^

找到问题关键的20%，集中优势兵力重点突破，采用小循环的方式逐步改进，成为和U9200一起奋斗过程中的主要工作思路。

二、 扮演好几个角色：

1）刹车人（狂热队伍中的冷酷者）

如果说质量中最不愿见的是“变量”，项目管理中最不乐见的是“变更”，那么项目运作过程中最害怕的是“狂热”，团队一旦开始狂热，如果不及时的刹车，那么项目运作必然失控。

前段时间我们HR祈宇，和我交流时说：“如果别人离职，我可能还会想法挽留一下，但是你小子太冷酷了，要么不干，要干就一定想清楚了，而且是无法被动摇的。” 没错，在狂躁的项目运作过程中，你一定要冷静，甚至冷酷，要仔细观察，认真分析，拨开迷雾看到本质，因为真相只有一个。

 音频TDD改版

TDD是系统性问题，TR4A后出现了反复，修改音频问题，结果导致射频性能出现了下降，因为需要提升射频性能，达到公司要求的余量要求，急着要改版。

要保证修改的有效性，因此直接回的邮件“不同意改版，需要将修改方案评估清楚”（可惜原邮件找不到了 ^_^）,拉上射频有线、天线、音频、硬件基带的人一起评估修改方案，现场讨论中发现了几个新问题，重新进行方案验证……

Tips：

各部门的研发兄弟都有一个向上的心，都希望自己的领域没问题，往往容易犯顾头不顾腚的毛病。我们希望各领域优秀，但是我们更加希望产品是优秀的，因此就需要取舍和平衡，作为PQA应该系统的去思考问题，要引导产品达到最佳的平衡，当然建议在平衡的前提下，也可以获取某方面的最优化（卖点、亮点）。

在交付压力的牵引下，一定会想方设法的去赶试制，但是多次试制更多的可能是带来资源的耗费，毕竟华为公司每个项目上的资源并不充分。要冷静对待问题，珍惜和把握每一次机会。

　　心若冰清，天塌不惊；

　　万变犹定，神怡气静；

　　尘垢不沾，俗相不染；

　　虚空甯宓，浑然无物；

　　无有相生，难易相成；

　　份与物忘，同乎浑涅；

　　天地无涯，万物齐一；

　　飞花落叶，虚怀若谷；

　　千般烦忧，才下心头；

　　即展眉头，灵台清幽；

　　心无罣碍，意无所执；

　　解心释神，莫然无魂；

　　水流心不惊，云在意俱迟；

　　一心不赘物，古今自逍遥！…… ——《风云》中聂风的冰心诀

丰田的案例：

　　大家都知道丰田汽车公司，可能这家公司是当今社会被人研究最多的企业之一。该公司的经营和管理哲学独树一帜，其中最著名的管理模式是“丰田生产方式”（TPS），业界称为“精益生产”。“丰田生产方式”的核心是PDCA。有人说，当一个典型的美国公司遇到一个问题的时候，如果这个问题必须在一年内解决，该企业会用3个月来做计划，用另外3个月来执行，再用6个月来做微调，处理遗留问题。而丰田在面对类似形势的时候，会用11个月来做计划，用1个月来实施（根本不会留下任何遗留问题）。这种说法虽然比较夸张，但是它体现了丰田对于PDCA的独特理解和经验总结。丰田人认为：计划至关重要！只有彻底的计划（从多个角度全面了解了形势、准确地发现了问题产生的根本原因、考虑可能发生的各种变化、以及参与者的认可或者上级的批准后），实施、检查、处理的结果才能高效达成预期的目标。

2）公正的中立人(公正公平，但是一定要保持中立)

质量人员在华为的定位是中立的，因此总会有这样那样的纠纷问题要质量人来仲裁，希望得到中立的评价意见。当然在研发内部出现类似情况仲裁还可以，因为我们毕竟还呆在研发区。但是对于出现跨研发领域的时候，和大供应链体系（制造&采购）交流的时候，供应链体系经常认为我们是属于研发体系的，容易存在略带敌对的和我们交流。如此情况下，我们应该如何的处理？

Tips:

我分享一下我的做法：

1、首先是澄清具体问题，不要和对方陷入到度量指标，考核指标的漩涡中去（影响产品的具体问题都已经解决了，指标不满足要求也难）。

2、对于问题要制定应对措施和具体责任人，从问题后续的实际表现去评估活动是否有效和相应的进展（避免出现活动做了，但是没有效果）。

3、该踢一脚的还是要踢一脚（忍无可忍无需再忍），当时言辞要客观，避免采用主观类的语言（这个时候就需要体现质量人的专业素养了 ^_^）。

U9200-1 TR6直通率问题 案例：

TR6的时候最容易遇到的就是因为直通率问题，制造体系和产品较劲。U9200-1 爬坡后，为了解决直通率问题，研发体系一直是有人制造现场的（具体的派兵布阵也有一个小实践，在后面和大家分享），组装段的一次直通率从爬坡的20%，一直稳定到了85%以上，而且还有不断上升的利好趋势。当时因为SMT段的一次直通率低，而且不稳定，直接导致全工位一次直通率就被拉到了80%以下，而且极不稳定。

客观公正的给制造体系的各位老大分析了一下U9200-1的直通率趋势，和TR6的一些要求，SMT段的问题很快得以控制和解决。

我发的邮件：

制造体系回复的邮件：

邹总的邮件：

制造代表主导直通率提升:

三、 一点点实践，一点点认知：

1） 关于产品质量评估：

产品质量评估是QA是一定要做的，但是如何做，各地有各地的模板，各人有各人的习惯，我的思考和写作方式分享给大家，请各位方家拍砖。

质量评估对于领导们来说，是希望看到一份产品质量状态的全貌，能够包含产品各方面的完整信息，它除了用于领导的监控，其实也应该是很够很好的引导版本经理规划后续的重点工作，因此可以联合版本经理一起来写，在写的过程中，同时也是对项目状态的一个梳理。第一期可能比较困难，当时后面的只要逐渐更新即可。

我们写一份报告，首先需要列清楚需要体现的维度，然后是收集写作素材（往往会有现成的素材），最后再用客观语言来表述。原始的素材不一定需要重新开始，往往周围的领域已经有人在做了，因此要注意积累渠道和信息源。 积累人脉和渠道的最好方式是分享，将你的工作成果和他人分享（包括业务部门的人），尤其是提供信息给你的那些兄弟，并且要心存感激。 —— 有感于李志《其实你不懂项目管理》

对于产品质量状态，我通常会从如下的角度思考，当然针对不同的项目背景，所处阶段进行调整，这个需要从实践中积累经验。

需求实现：在TR4之前需要重点关注，尤其是软件需求。可以联合SQA做些事情，Ascend P1就很感谢于姐姐，组织软件、测试、SE等领域做了三次需求实现梳理&排序，明确下来哪些必须在啥时间点完成，哪些需要CCB裁剪。因为需求的颗粒度不同，很多细节上把握不到，Ascend P1需求评估会上明确哪些可以裁剪、哪些必须实现后，对于实现过程中的细节问题，允许通过CCB的方式进行裁决。（对于渠道销售的可以参考操作，对于运营商定制的，一定要和运营商PK，北京这点应该做的挺好，上海火候还差点。）

软件单元测试：现在项目都敏捷了，单元测试如何做，如何评估充分性，没有啥心得，我一般都咨询SQA。

硬件单元测试：主要关心没有测试通过的项目，对于新器件的验证情况也需要重点关照，我没有现成的Checklist，更多的是和开发人员、器件组负责人交流验证方案和结果。建议多看看硬件组器件相关的案例，测试对于器件替代的方案，供应商器件出厂的测试要求，带着疑问去和器件组的兄弟们交流（我作为QA参加过LCD、音频的器件组工作，梳理过音频流程、整理过音频小组的运作方式。），花点功夫在平日，积累交情的同时也能学到不少东西。

硬件测试（含可靠性测试）：除了关注测试的结果和发现的问题以外，我更关心的是测试的覆盖度（所有用例是否都覆盖，V试制和VN试制是否都完成应该的测试覆盖）和问题发现趋势（如果前几次测试没有问题，但是后面有问题，一定会追问一下为什么），历次修改方案也需要和测试用例进行一个比对，防止方案遗漏。Ascend P1 这个工作其实是我提供想法，工具表单的支撑，数据整理工作基本上都是硬件测试接口人做的，需要感谢一下陈雪蓓MM。

软件测试：前期更多地都是关注DTS上的问题，Ascend P1因为和Ascend D1是同软件平台，所以修改问题评估的时候一直是一起评估的，尽管工作量大点，至少避免了遗漏。其实还有一个不同软件版本的关系树可以参考，软件组兄弟应该是有在维护的，我前期基本上是通过交流获取方法，去确定评估方案，最后看到这个树的时候，后悔了好一阵子。这个树可以帮助QA理清楚问题评估方案，以及关键问题的修改合入策略，简单有效。

准入测试、Beta测试、现网测试：这个是测试经理制定的，只是在方案确定的时候，需要和测试经理交流一下，我是借用的信息。就是在识别和评估发现的主要问题上和测试经理交流了不少。

Ascend P1测试这块的信息基本上都是测试经理钱群JJ总结的，非常全面&完整，我就是应用&提炼。

试制问题：DFx or 试制代表手上有非常完整的试制问题清单，最好Review一下，根据经验判断一下那些是TOPn和必须解决的。我有几年制造端产品质量管控的经验，所以判断相对比较容易，其实就是判断此问题是否影响产线效率，因为产线进行的是机械的、重复的操作，简单的才不容易出错，高效的才容易落实，对于产线问题处理要记住“简单就是美”，所以解决方案重点要思考工具&方法的辅助，尽量减少配置或者选择。其他的问题比例、危害度之类的需要辨证的看，不要被数字欺骗，PQA有机会还是多去产线转转，经验还是需要积累的。

Ascend P1 有一个关于返工的优秀实践，对于产线上出现的故障机维修后，统一升级软件到PT测试之前，然后直接往下走流程，深得制造兄弟的喜爱，因为没有那么多状态需要控制。对比北研的返工升级方案，每个测试工位的工具都有返修流程设置，我们研发的角度想，是给了你很多的选择，可以从不同的工位进行返工，但是我们似乎忘记了，产线玩的是海量制造，不是手工作坊，原则越多，产线不同的产品状态越多，越不容易控制，越容易出现疏漏。如果简单的到只有一种返工方式，那么我们核心需要改进的点就是如何减少返工，而不用关注如何增加返工的途径。

物料问题&器件验证：影响产线的制程问题从试制问题清单中单独拎出来，还要关心的是器件验证的情况（新器件引入&器件替代），直接在PDM上看BOM编码的发放情况就能知道器件验证的进展，然后有针对性的去咨询相关的责任人。

问题单：P1这个软件新平台到目前为止一共发现了14K以上的问题，分布在P1、D1不同的子版本上，还是花了一点小心思的，后面再细讲。对于质量评估而言，要体现一个整体的趋势（问题发现趋势，遗留问题趋势，DI趋势……），根据展示即可。不要忘记了，调处你认为最关键硬件、软件、制造类问题明确的写出来。

市场：这个基本上是版本经理在关心，我了解相关信息，只是用于调整相应活动的开展方式。质量评估上基本不涉及。 ^_^

收集完数据后，就需要整理成文章了，可以看看下面两个胶片，学习一下应该如何汇报和延时，附了一份早期的产品质量周报。

一份好的质量评估报告，其实是可以被复用的，我写的P1质量报告就被用于给余总万总的汇报，EDCP发货的评估。一份好的质量评估报告，首先要有一个好的框架，第一份可能困难点，但是后面的话就是不断对信息进行刷新。（多么希望后续产品的信息可以集成化在一个系统中，方便查询和展示）

2）项目问题&风险跟踪：

对于FP时代，产品开发规模小，一个项目组例会就可以Cover，但是我们已经步入了智能机时代，开发Ascend P1 这样一款旗舰机，曾经开玩笑的和版本经理数过人头，FP的30个人，已经演变成了300人以上的队伍，还是一个项目周例会解决问题的效率会比较低下。

P1 采用的实践是每日站会的方式，各领域代表将各领域前一天的工作进行总结，将这一阶段的主要问题进行反馈，五角经理轮流主持（虽然能够起到练兵的作用，但是也有不好的地方。），统一写在白板上，进行信息共享和展示（不知道会不会有信息安全隐患^_^）。

项目问题、事务、风险统一跟踪，采用Excel自带的共享工作簿功能（不会的同学自己百度、Google，打电话给我也行 ^_^），项目组全员共享，每个责任人对自己任务进行进展更新，支持多人同时更新。

待改进点：

1、 项目在一开始的时候还是有一个FMEA的项目风险跟踪表，我是中期介入的，没有很好的延续用起来，尽管我将遗留的未关闭问题已经放到共享工作簿中，但是后面的监控没有做起来，执行效果不是很好。

2、 每日站会的效果不错，但是五角的主持风格和思路不太一致，内容更新上延续起来比较差。

3、 各领域的信息汇总各领域代表各有风格，信息不能很好地实现对接，靠单人力进行拉通，工作量巨大。

改进建议：

1、 各责任人需要将跟踪起来，项目POP可以作为跟踪责任人。最关键是，要跟踪的事务和项目各领域代表日常工作衔接起来，利用这个牵引各领域代表开展项目工作。

2、 五角都比较新，能力需要培养，如此方式可行，但是要统一会议主持的规范化内容（具体哪些块内容需要问），在白板上的誊写规则也要有大的定义，更换周期不要太频繁，双周或者一个月换一个比较靠谱（虽然说68天是让人养成一个习惯的建议时间，当时偏长了因此借用以前高考中的一个推荐记忆方式7天一学习周期，7天一复习周期，隔2周一个再复习周期）。

3、 各领域的日常事务跟踪和项目的能够进行匹配，最好统一使用项目集成跟踪表的格式，便于后续的复制粘贴，如果能够实现系统化就好了（PLM项目的时候，有幸和三星顾问交流过，三星当前基本上用的就是一个系统进行项目任务的跟踪，羡慕中）。

3）DTS问题：

DTS 问题单是每个QA都需要关注的，那么应该怎么看？

1、 问题单看是要看的，对于智能机那么多问题咋整，首先要学会的是增量的看。DTS问题单号都是体现了一定的顺序，上次看到哪个了，下次从下面一个看起。或者借助工具标示出来哪些是新增的。（自己写了一个小工具，后面会有共享）

2、 问题要学会分类看，可以按照当前责任领域看，可以按照问题模块看（虽然测试和研发的分类不太一样，当前填写的也不准）。

3、 对问题状态有变化的需要关注，特别是状态往回退的。（当然都可以借助于工具）

但是最最最重要的，是将产品的问题单跟踪和统计规则归一，过多的方式，只能够产生混乱，大量的时间浪费在澄清和扯皮中，对我们已经被压缩的不能再压缩的进度是一种极度浪费。

我们在Ascend P1上都做了什么？

A、问题单作为数据源的运用：

1、 问题单统计工具归一：

软件有软件的统计方式，测试有测试的统计方式，产品有产品的统计方式，OK，我们首先做到的就是工具表归一化，做了一个工具表，这个世界平静了。其次，统计规则统一，P1、D1软件类问题合并在一起统计（优先将试制提的问题直接剔除，其他的评估时候再判断），评估为不修改、非问题的直接不统计，问题单继续走。

2、 问题单排名方式归一：

以前做QCC的时候，有一位同事说过，如果要让这个活动搞起来，就要让马赛起来，要形成竞争。OK，规则和统计方式已经统一了，按照资源组的方式（软件细分到各小组），进行当前问题单状态排序，每天通报。工具相对比较傻瓜化，自己先发几期，后面找一个慧通的兄弟，教会他使用方法，都是他来发，软件问题就这样活性竞争起来，大家也知道如何做了。

3、 问题单评估记录归一：

智能机问题实在是多，P1、D1新平台旗舰机，问题尤其多14K啊，排序找重点问题，通过会议纪要的方式记录，后面跟踪有困难。OK，没问题，会议纪要照发，但是每个问题单的结论统一记录到工具表单中，评估结论直接放在里面，便于查询、筛选，状态也一目了然，简单&直接，大家都喜欢。

上面说的天花乱坠，其实就是一个Excel表+Vlookup函数，所有需求都搞定，而且尽可能采用自动化处理，每天0.5-1小时工作量，大家方向很一致。

原来还想再优化优化，现在看来要留给后面的有志之士了。 ^_^

B、DTS 问题单数据如何展示：

数据源既然已经有了，如何用呢? 做一个有心人，看看我共享的“咨询工具”系列吧，里面会给你灵感的。

1、 展示问题发展趋势：

最常见的展示方式，大家大家最爱用，大家也都能看得懂。

到底哪种趋势比较适合P1，我下了不少功夫，北研M860、C8860、U8860、S8600、U8600的数据图形我都做过，大家不妨也看看，其实用用R版本度量工具，一切其实很简单。

2、 展示研发和测试的PK：

折线图也可以这样用哦，研发解决问题和测试发现问题可以这样对比，是推研发解决问题还是测试发现问题，很清晰。

3、 展示研发解决问题的速度：

地层图的使用，这个是和总体组一个GG学的，研发能力基线也可以得到验证哦。

C、关于DTS问题单，不得不说的痛：

1、 步骤之长世所罕见：

我经历的那么多家公司，我们终端用的流程真可谓历史之最，大量的问题单采用的是13步，基本上是业界的2倍。增加了那么多审核&确认的步骤，是为了啥？问题单我的理解，就是驱动研发工作的一种工具，研发人员日常的工作就是解单，慎重合入，其实控制一个合入入口就可以了，将问题修改方案的评估做在平时，为啥还要体现流程，结果现在问题单反而流不起来了，过TR点还要催单，纯粹的人力浪费。走一个问题单，需要多少人力成本，不知道有没有人算过。

2、 必填项填不准，如何利用数据：

和软件开发的兄弟交流过，问题模块分析，居然软件和测试的不太相同，那应该如何去正确理解呢？是不是需要培训？ 同时也折射出一个问题，测试能力问题，如何判断这个是一个问题，是测试的必备能力，但是现在似乎差好几口气。

DTS原始数据上那么多的问题点，数据分析如何进行？ R版本度量工具基本上是有力使不上。当前的DTS数据我对它是又爱又恨，真的像是一盘没有绞肉的麻婆豆腐，真希望有哪位大侠可以像《中华小当家》中演的那样，创新改良后作出一盘没有绞肉的梦幻麻婆豆腐（大豆做绞肉）。

从DTS问题中折射出的测试问题：

1、 测试只管发现问题，不管判定是不是问题：

海思的测试同事曾经很好奇地问过我，终端的测试很奇怪，判断是否是问题居然说是研发来做，研发的时间最宝贝，这个不是应该测试来完成么? 因此在海思能够看到测试的兄弟，整出来各种脚本，测试工具，羡慕啊，啥时候我们也可以才这样？

过年前，P1的问题发现比较少，因此严重反馈过几次，导致结构问题大量上升，结果后来一打听，原来测试开展了外包和华为测试的大比武，大搞自由测试求单，是我们的用例发现不了问题，还是我们的测试用例不完整，那为什么不在10几K的用例开开刀，改良改良呢？ 3-4重交互后发现的问题，是否可以将解决的程度降低？

以前李小龙曾经说过，做小灵通的时候总共的用例才1K，但是已经比CDMA FP的几千条用例发现的问题多了。其实，测试用例是贵精不贵多，如果是界面全覆盖，那想办法自动化即可，对于交互类的问题，可以人工测试，哪些是常用的交互，哪些问题是用户最关心的，800热线、FFR退机，都可以找到线索。

2、 只关注了数量，忘记了质量：

如何去评判测试的质量，其实很简单，看看对于测试提交的问题，多少个问题研发是需要修改代码的就行了。那么我们P1 一共有14K多的问题，我简单的统计过，对于已经关闭或者撤销的问题，已经表示是问题解决的应该不超过60%。HAP平台也的进行总结的时候统计过，一共处理过8K的问题单，但是需要改动代码的不超过40%。 那么剩下的那些问题都是咋整的？ 这些问题是不是浪费了呢？ 我没有仔细去分析过，建议测试总结的时候可以看看。

4）试制现场质量控制：

几个现象：

1、 大家都很忙，各忙各的，一旦是重大项目，各部门都出差，出差日报就满天飞，后端的兄弟很郁闷，到底应该看那份信息，哪份信息最准确？

2、 DFx或者试制代表统筹组织，但是“布朗运动”比较明显，问题攻关全面开花，对于本次试制而言到底哪个问题需要重点解决，优先解决？兄弟们很困惑。

3、 我们在现场改善了很多东西，需要落实的要求很多，EMS的技术员一个人接口我们很多人，我听谁的？EMS的技术员很郁闷。

4、 我们落实了不少方案，效果咋样，有没有新增问题，产线报表、数据咋没有人看呢？

在Ascend P1上的实践：

产线跑不顺，出现的各类问题无非是物料、制程、设计三类。物料问题直接进行筛选，和供应商明确后续的交货和验货要求，基本可以告一段落。制程问题关键是看提升员工的熟练度和核心工位操作的正确性，这个是需要一点点看，一点点纠的，只看报表而不在现场是解决不了问题的。设计问题一旦出现，必然是高比例的不良，那攻关一定避免不了。针对上述的认知，进行了如下人员布局：

• 跟线人员分为两个职能组：巡线组和攻关组，各设立组长一名。

• 巡线组：量产爬坡EMS配得都是新手，因此要加强巡线动作，重点关注关键工位的操作正确性和可能由于操作、夹具不良导致的潜在问题。巡线组比较辛苦，跟着实际生产班次走。

• 攻关组：负责关键遗留问题的攻关。

• 信息交互方式：每日9:00早站会，小组长将两组信息总结并交流互通，制定新一天的工作计划。

• 改进效果确认：每日产线问题的梳理，各种问题的趋势判断，识别需要重点关注的问题（之前是我主导，后续教会DFx或者试制代表）

• 成果及时落地，关键工位识别，相关注意事项增加到伟创力IPQC的巡检要求和操作指导中。

待改进点：

当前试制开工会关注度不足，每次试制需要关注啥，上次遗留的哪些问题已经解决，具体落实了哪些措施和活动，哪些问题不解决，一定要试制前达成一致。

试制的资源是有限的，试制的次数应该是需要受限的，版本经理需要珍惜每次一试制机会，QA能够制止试制，当然是最好的。^_^

5）EWP分析

EWP分析的目的应该有两个，1）早期发现问题，将后续会影响故障率的问题扼杀在摇篮中（判断准确需要经验）；2）解决的问题作为经验优化到设计规则或者经验案例中去，未解决的遗留问题合并到FFR改进中跟踪。 当前我们更多关心的是第一个目的，这个无可厚非，也是正确的，但是我们手头的资源是有限的，问题一定要排序解决，不能全线作战，否则一旦产品过多，紊乱场面无可避免。（北京杨海波EWP分析经验不少，可以咨询。 上海没有专职团队对EWP负责，对资源的利用和配置要求更高。）

文章来自网络，版权归作者所有，如有侵权请联系删除

精益六西格玛让我们的质量、效率、成本、管理上了一个台阶，并得到了美国质量协会、中国质量协会等单位的奖励和认可。”

———上海贝尔某某公司