QA是个技术活——质量是旅程，而不是终点。 （实践篇）

§实践篇§做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能够制止试制，当然是最好的。^_^其他类（U9200 上暂未做完）：5）EWP分析 EWP分析的目的应该有两个，1）早期发现问题，将后续会影响故障率的问题扼杀在摇篮中（判断准确需要经验）；2）解决的问题作为经验优化到设计规则或者经验案例中去，未解决的遗留问题合并到FFR改进中跟踪。 当前我们更多关心的是第一个目的，这个无可厚非，也是正确的，但是我们手头的资源是有限的，问题一定要排序解决，不能全线作战，否则一旦产品过多，紊乱场面无可避免。（北京杨海波EWP分析经验不少，可以咨询。 上海没有专职团队对EWP负责，对资源的利用和配置要求更高。） 几点建议：1、 服务部TCS系统中录入信息和EWP实际收到样机的数据存在出入（TCS系统中故障描述是固定的，当时EWP返回机器的一线网点描述五花八门），一线往回投递时，将录入系统的描述也补充一下，信息统一，表述语言可以一致（或者服务1周2次将TCS数据回传，借助Vlookup 通过IMEI进行人工信息匹配 ^_^）。问题趋势分析一定要坚持做，故障分析一定要排序，我们还是比较穷，人手有限。2、 改善措施，尤其是软件版本的优化，一定要拿到一线网点验证有效性，如果确实有效，服务公告要尽快出，并将此类问题从EWP返回样机中剔除，让EWP分析更加聚焦。但是这个需要和服务确认可行性，EWP流程是否可以增加柔性，当前EWP还是过于刚性化。（U9200水波纹问题已经通过软件改进了，但是EWP机器中水波纹问题的机器还是远远不断返回。 效率，效率啊）3、 EWP分析完了之后，总结和共享一定要多项目一起搞，将共性的改善点提炼出来，放入设计规则。分析的材料，能够成为案例，并且能够货架化，便于后续项目开发中的查询。4、 EWP的人员构成，最好是手机行业有丰富维修经验的人参与其中，这类人学历可能低（大专、中专），贵在实战经验丰富，可以加快分析和定位。（兼职HQA的时候给硬件基带提过，可惜公司招聘策略受限。很怀念以前公司故障机分析人员出的专业分析报告，告诉你定位步骤，具体原因，建议改进方法，现在的分析报告更多地是研发人员的思维角度，而不是维修人员的。）6）FFR FFR应该是所有PQA心中永远的痛，但是我觉得FFR分析是每个PQA必须掌握的工作技能，同时通过FFR分析，能够更好的积累经验，知道哪些问题会成为用户不可接受的问题。但是FFR分析不是指简单的数字分析，一定要找到数字背后的东西，因为数字会骗人。^_^ 首先，说说当前我司采用的FFR计算方法。我司的计算公司基本上是和TL9000推荐的算法相同，通过3个月的活动窗口，去预估一年的故障率。算法本身没有太大的问题，但是数据上却有缺陷。分子采用的是每个月实际收到的故障机数，分母应该是实际在保量，但是我司的数据是通过到货量预估的，往往会较实际在保量大，因为一次性到货5万，在2个月内销售完，还是有点难度的。^_^ 其次，要改进FFR，最关键是解决主要的故障，那么最好对维修工单原始数据有所了解，原是数据可以请陈浩荣GG帮忙从TCS系统中导出。我已经积累了2010年1月-2012年3月终端公司所有产品的原始数据和2009年CDMA FeaturePhone原始数据，原来想搞一个小数据库的，但是一直没有做起来，一直用Excel在处理，数据现在放在小睿电脑上，有需要的可以要，格式我已经统一了。 原始数据中可以细分到国家、外包服务商、产品、维保类型、故障（单台最多有3种）、维修方式、维修备件、购机日、接受日、修好日，通过PSN和工单号进行区分。根据上述的分类，我们可以知道故障的分布/排序，故障常发生的时间段，主要损坏的器件，DOA&DAP在所有故障机中的占比…… 我利用这个原始数据做过一些实践: FFR趋势预估（根据对公式的理解+发货计划）、同一器件在不同产品中的故障率评估、浴盆曲线中早发时间段的估计（没有写成胶片）、北美市场故障比例分析、FP CDMA在不同国家的FFR分析…… 算是积累了一些经验，那些现成的胶片都共享在赵睿那里，有需要的大家可以看看分析的具体思路。模仿仅仅是起步，理解分析的思路，逐渐形成自己的思路和方式才是你最终的目的。 对我来讲，TCS中的原始故障数据就像是一个待发掘的宝库，每次仔细琢磨后，总可以从里面看到不少的东西，能够帮助我更好的去做判断。 最好是可以借助工具的力量来完成分析，单靠人力为之比较不靠谱，当然如果PQA能够访问TCS系统那是最好的了，可惜奋斗了3年多都没有成功，借助吴博的力量都没有成功。我们如今已经是非研发了，希望可以尽早达成目标。 有好的工具平台和数据源仅仅是开始，关键在于使用。毕竟数据是死的，你用不用它都在那里，你用了，帮我们更好的去分析和判断问题，才能发光和发热。 关于工具的忠告：如果遇到工具不好用的情况，请先冷静，毕竟每种工具都有局限性限制，我们首先应该认为是我们没有理解好工具和用好工具，其次再是看看是否有啥工具可以进行组合，补充这个工具的弱点。世界上不存在一种通吃所有需求的工具，因为工具也是人开发的，合理的组合和正确的使用工具，才是王道。 7）800分析 800热线分析也是一种数据分析，它算是和TCS原始数据一样的东西，但是我的理解这两种数据需要站在不同的角度进行分析。如果TCS数据告诉我们的是用户无法忍受的故障，那么800热线就是告诉我们当前用户的偏好和一些使用习惯。换句话说，TCS中记录的故障，客户更加不能容忍；800热线潜藏的更多是商机（改进后可以用来吸引用户的）。千万不能用800热线数据去求证漏测问题，但是用来指引我们改进测试用例，是一个比较靠谱的方向。 我也算是800分析的一个鼻祖了，好像是2009年吧，我是终端第一个做800热线分析的，当初从中提炼出的UCWEB，QQ的需求，第二年就被落实到FP CDMA低端机上，很好的切合了中国电信的需求，有效支撑FP CDMA xxx万的出货。 期间和服务部的兄弟对800热线数据的分类和分析方式做过一些讨论和建议，现在800热线的姐妹们双周例行对数据进行分析，有需求的话可以向杨娇（81007842）、周懿（00163028）寻求帮助，当然也可以和对应的服务代表求助。关于数据分析：数据分析是一个枯燥和繁琐的工作，如果没有IT平台、自动化工具的支撑，但是数据分析能够帮大家找到规律，找到最关键的20%。作为QA一定要有意识的培养自己这方面的素养和能力，它能够帮助我们更理性的判断问题。但是也要记住，一切数据也要用实践和时间去验证，因为不同的数据处理方式会有不同的展示效果。腾讯公司就是一个很关注数据分析的工具，专门有一个团队是进行数据分析的，而且非高等级的专家不能进入，通过数据分析，去找到用户的使用习惯和最心动的点，持续优化，不断地吸引用户使用腾讯的各类增值服务。《统计数字会撒谎》虽然比较浅显，但是大家可以看看，我放了一本在周桂芸哪里，上海的兄弟可以瞅瞅。 ^_^

§后记§
QA流派的解读：实战流：【描述】快刀斩乱麻派，遇问题灭问题，人挡杀人佛挡杀佛，属于猛将型人物。【特点】直觉感强，思维敏捷，反应快，能够快速提供解决方案，快速决策。流程理论流：【描述】对IPD流程烂熟于胸，倒背如流，对各类质量的理念，管理的理念有相当的理解，针对问题总能够找到理论依据，旁征博引，滔滔不绝的大道理。^_^【特点】记忆力超群，对书本知识理解透彻，逢考必高分。流程意识强，遇事必流程。^_^工具方法流：【描述】对质量工程方法，具体质量工具有偏好，总喜欢用工具或者方法去解决问题，【特点】典型左脑逻辑动物，喜欢倒腾，有完美主义倾向。 ^_^ 作为QA，你属于哪个流呢？^_^没有一个QA会成为某个纯粹的流派，都应该是一个综合体，仅仅是更多偏向于哪边而已。以我个人而言更多的偏重于工具方法流，实战流和流程理论流也会占一小部分，但是不多。但是不管你是哪个流派，我认为，最为QA最重要的是实践，因为作为QA需要人们去改变心智和习惯，而改变人心智和习惯最强有力的方法就是行动。记得一个科学数据表明，要让人改变一个习惯，需要持续的坚持新习惯63天，单靠宣传产生的改变的力量，我们都不是乔布斯或者马云，效果应该是有限的，还是行动实在些。学习是为了更好地应用！ —— 毛泽东