TA的首页QA是个技术活——质量是旅程，而不是终点。 （实践篇）
之前写的一篇理论篇，好像还比较受欢迎，将实践篇补齐吧，去掉了一些公司项目相关的信息，附件和图表没法上传了，是一种遗憾啊。^_^§实践篇§
做QA应该是水无常形，兵无常法。Checklist、指标仅仅是冰山一角，最关键需要建立的是人对产品质量态度和责任感。我们经常分享结果（模板、流程），为什么做和如何思考做这个事的思维方式更加值得分享，明白当初为啥做这个事，才可以促进态度和理念的复制，否则只能模仿形而失去了最重要的神。当然，各个优秀实践，可以作为一种案例可以进行货架化知识管理，便于查询。
一、
确定项目质量工作的思路：
认清现状: 项目立项伊始，最关键的是认清现状。在工作中很容易被鼓动的也是一种职业幼稚心理的表现，只有在工作开始之前瞻前顾后的才是帅才。^_^ 企业总是以“活下去再发展”为首要前提的，因此配置的资源一定会存在这样那样的缺陷，当然也有配置给你最好资源的情况存在，那个时候就要小心进度陷阱和人员使用陷阱了。^_^
换位思考，明确工作思路：
“项目团队不是不希望改进和提升，更多的时候是他们遇到问题不知道如何去改进。”
手机是强项目交付牵引，但是项目运作又是强资源矩阵（至少目前是），项目交付应该还是第一位的，整个项目团队的成员都还是希望能够按期交付，按质量要求交付。新软件平台，新硬件平台，新项目定位，一定会遇到问题，而且是一堆的问题，拿着质量的要求、标准去要求团队达成，是一种质量人员的做法；融入到项目运作中，切实的协助项目组识别关键问题，解决运作过程中的问题，也是一种质量人员的做法。
项目按期交付，拼命往前冲的大势无法阻挡，那我宁可选择融入到项目团队中，实实在在的将产品质量做好，切切实实的将项目运作过程中的问题解决。虽然将面临一堆的问题，但是我阳光总在风雨后，不经历痛苦，哪能感受幸福。 ^_^
找到问题关键的20%，集中优势兵力重点突破，采用小循环的方式逐步改进，成为和项目团队一起奋斗过程中的主要工作思路。
二、
扮演好几个角色：
1）刹车人（狂热队伍中的冷酷者）
如果说质量中最不愿见的是“变量”，项目管理中最不乐见的是“变更”，那么项目运作过程中最害怕的是“狂热”，团队一旦开始狂热，如果不及时的刹车，那么项目运作必然失控。
前段时间我们HR和我交流时说：“如果别人离职，我可能还会想法挽留一下，但是你小子太冷酷了，要么不干，要干就一定想清楚了，而且是无法被动摇的。”
没错，在狂躁的项目运作过程中，你一定要冷静，甚至冷酷，要仔细观察，认真分析，拨开迷雾看到本质，因为真相永远只有一个。^_^
Tips：
各部门的研发兄弟都有一个向上的心，都希望自己的领域没问题，往往容易犯顾头不顾腚的毛病。我们希望各领域优秀，但是我们更加希望产品是优秀的，因此就需要取舍和平衡，作为PQA(质量人)应该系统的去思考问题，要引导产品达到最佳的平衡，当然建议在平衡的前提下，也可以获取某方面的最优化（卖点、亮点）。
在交付压力的牵引下，一定会想方设法的去赶试制，但是多次试制更多的可能是带来资源的耗费，毕竟华为公司每个项目上的资源并不充分。要冷静对待问题，珍惜和把握每一次机会。
——《风云》中聂风的冰心诀:
心若冰清，天塌不惊； 万变犹定，神怡气静；
尘垢不沾，俗相不染；
虚空甯宓，浑然无物；
无有相生，难易相成；
份与物忘，同乎浑涅；
天地无涯，万物齐一；
飞花落叶，虚怀若谷；
千般烦忧，才下心头；
即展眉头，灵台清幽；
心无罣碍，意无所执；
解心释神，莫然无魂；
水流心不惊，云在意俱迟；
一心不赘物，古今自逍遥！……
丰田的案例：
大家都知道丰田汽车公司，可能这家公司是当今社会被人研究最多的企业之一。该公司的经营和管理哲学独树一帜，其中最著名的管理模式是“丰田生产方式”（TPS），业界称为“精益生产”。“丰田生产方式”的核心是PDCA。有人说，当一个典型的美国公司遇到一个问题的时候，如果这个问题必须在一年内解决，该企业会用3个月来做计划，用另外3个月来执行，再用6个月来做微调，处理遗留问题。而丰田在面对类似形势的时候，会用11个月来做计划，用1个月来实施（根本不会留下任何遗留问题）。这种说法虽然比较夸张，但是它体现了丰田对于PDCA的独特理解和经验总结。丰田人认为：计划至关重要！只有彻底的计划（从多个角度全面了解了形势、准确地发现了问题产生的根本原因、考虑可能发生的各种变化、以及参与者的认可或者上级的批准后），实施、检查、处理的结果才能高效达成预期的目标。
2）公正的中立人(公正公平，但是一定要保持中立)
PQA（质量人）的定位是中立的，因此总会有这样那样的纠纷问题要质量人来仲裁，希望得到中立的评价意见。当然在研发内部出现类似情况仲裁还可以，因为我们毕竟还呆在研发区。但是对于出现跨研发领域的时候，和大供应链体系（制造&采购）交流的时候，供应链体系经常认为我们是属于研发体系的，容易存在略带敌对的和我们交流。如此情况下，我们应该如何的处理？
Tips:
我分享一下我的做法：
1、首先是澄清具体问题，不要和对方陷入到度量指标，考核指标的漩涡中去（影响产品的具体问题都已经解决了，指标不满足要求也难）。
2、对于问题要制定应对措施和具体责任人，从问题后续的实际表现去评估活动是否有效和相应的进展（避免出现活动做了，但是没有效果）。
3、该踢一脚的还是要踢一脚（忍无可忍无需再忍），当时言辞要客观，避免采用主观类的语言（这个时候就需要体现质量人的专业素养了 ^_^）。
直通率问题 案例：
转量产的时候最容易遇到的就是因为直通率问题，制造体系和产品较劲。为了解决直通率问题，研发体系一直是有人制造现场的（具体的派兵布阵也有一个小实践，在后面和大家分享），组装段的一次直通率从爬坡的20%，一直稳定到了85%以上，而且还有不断上升的利好趋势。当时因为SMT段的一次直通率低，而且不稳定，直接导致全工位一次直通率就被拉到了80%以下，而且极不稳定。
客观公正的给制造体系的各位老大分析了一下直通率趋势，和转量产一些要求，SMT段的问题很快得以控制和解决。 （图像上传不成功，往来邮件就只有省了。）
三、
一点点实践，一点点认知：
1）
关于产品质量评估：
产品质量评估是QA是一定要做的，但是如何做，各地有各地的模板，各人有各人的习惯，我的思考和写作方式分享给大家，请各位方家拍砖。
质量评估对于领导们来说，是希望看到一份产品质量状态的全貌，能够包含产品各方面的完整信息，它除了用于领导的监控，其实也应该是很够很好的引导版本经理规划后续的重点工作，因此可以联合版本经理一起来写，在写的过程中，同时也是对项目状态的一个梳理。第一期可能比较困难，当时后面的只要逐渐更新即可。
我们写一份报告，首先需要列清楚需要体现的维度，然后是收集写作素材（往往会有现成的素材），最后再用客观语言来表述。原始的素材不一定需要重新开始，往往周围的领域已经有人在做了，因此要注意积累渠道和信息源。 积累人脉和渠道的最好方式是分享，将你的工作成果和他人分享（包括业务部门的人），尤其是提供信息给你的那些兄弟，并且要心存感激。
—— 有感于李志《其实你不懂项目管理》
对于产品质量状态，我通常会从如下的角度思考，当然针对不同的项目背景，所处阶段进行调整，这个需要从实践中积累经验。
需求实现：在TR4之前需要重点关注，尤其是软件需求。可以联合SQA做些事情，组织软件、测试、SE等领域做了三次需求实现梳理&排序，明确下来哪些必须在啥时间点完成，哪些需要裁剪。因为需求的颗粒度不同，很多细节上把握不到，那就想办法建立一种机制，把权限下放到最懂业务的地方，例行运作，QA参与并监控就行了。
软件单元测试：现在项目都敏捷了，单元测试如何做，如何评估充分性，没有啥心得，我一般都咨询SQA。
硬件单元测试：主要关心没有测试通过的项目，对于新器件的验证情况也需要重点关照，我没有现成的Checklist，更多的是和开发人员、器件组负责人交流验证方案和结果。建议多看看硬件组器件相关的案例，测试对于器件替代的方案，供应商器件出厂的测试要求，带着疑问去和器件组的兄弟们交流（我作为QA参加过LCD、音频的器件组工作，梳理过音频流程、整理过音频小组的运作方式。），花点功夫在平日，积累交情的同时也能学到不少东西。
硬件测试（含可靠性测试）：除了关注测试的结果和发现的问题以外，我更关心的是测试的覆盖度（所有用例是否都覆盖，V试制和VN试制是否都完成应该的测试覆盖）和问题发现趋势（如果前几次测试没有问题，但是后面有问题，一定会追问一下为什么），历次修改方案也需要和测试用例进行一个比对，防止方案遗漏。工作可以借力哦，但是要采用合作的态度参与其中，帮助解决其中的相关技术问题。^_^(这个工作其实是我提供想法，提供工具表单的支撑，数据整理工作基本上都是硬件测试接口人做的。)
软件测试：前期更多地都是关注缺陷管理系统中的的题，如果涉及同软件平台同时开发产品，最好修改的问题一起评估，尽管工作量大点，至少避免了遗漏。其实还有一个不同软件版本的关系树可以参考，我前期基本上是通过交流获取方法，去确定评估方案，最后看到这个树的时候，后悔了好一阵子。这个树可以帮助QA理清楚问题评估方案，以及关键问题的修改合入策略，简单有效。 准入测试、Beta测试、现网测试：这个是测试经理制定的，只是在方案确定的时候，需要和测试经理交流一下，我是借用的信息。就是在识别和评估发现的主要问题上和测试经理交流了不少。
试制问题：DFx or 试制代表手上有非常完整的试制问题清单，最好Review一下，根据经验判断一下那些是TOPn和必须解决的。我有几年制造端产品质量管控的经验，所以判断相对比较容易，其实就是判断此问题是否影响产线效率，因为产线进行的是机械的、重复的操作，简单的才不容易出错，高效的才容易落实，对于产线问题处理要记住“简单就是美”，所以解决方案重点要思考工具&方法的辅助，尽量减少配置或者选择。其他的问题比例、危害度之类的需要辨证的看，不要被数字欺骗，PQA有机会还是多去产线转转，经验还是需要积累的。
我们产品开发过程中有一个关于返工的优秀实践：对于产线上出现的故障机维修后，统一升级软件到PT测试之前，然后直接往下走流程，深得制造兄弟的喜爱，因为没有那么多状态需要控制。对比每个测试工位的工具都有返修流程设置，我们研发的角度想，是给了你很多的选择，可以从不同的工位进行返工，但是我们似乎忘记了，产线玩的是海量制造，不是手工作坊，原则越多，产线不同的产品状态越多，越不容易控制，越容易出现疏漏。如果简单的到只有一种返工方式，那么我们核心需要改进的点就是如何减少返工，而不用关注如何增加返工的途径。
物料问题&器件验证：影响产线的制程问题从试制问题清单中单独拎出来，还要关心的是器件验证的情况（新器件引入&器件替代），直接在PDM上看BOM编码的发放情况就能知道器件验证的进展，然后有针对性的去咨询相关的责任人。
问题清单：对于质量评估而言，要体现一个整体的趋势（问题发现趋势，遗留问题趋势，DI趋势……），根据展示即可。不要忘记了，调处你认为最关键硬件、软件、制造类问题明确的写出来。
问题评估的记录一定要有序，如果有系统是最好的了，但是如果没有的话，可以采用Excel表单跟踪，但是最好能够增加一定VBA统计功能，可以省不少工作量。^_^ 后面会详细讲，这里简略点一下。市场：这个基本上是版本经理在关心，我了解相关信息，只是用于调整相应活动的开展方式。质量评估上基本不涉及。 ^_^
\s
一份好的质量评估报告，其实是可以被复用的，我写的质量报告就被用于给老总的汇报，早期发货的评估。一份好的质量评估报告，首先要有一个好的框架，第一份可能困难点，但是后面的话就是不断对信息进行刷新。（多么希望后续产品的信息可以集成化在一个系统中，方便查询和展示）
2）项目问题&风险跟踪：
对于功能机时代，产品开发规模小，一个项目组例会就可以Cover，但是我们已经步入了智能机时代，开发一款旗舰机，曾经开玩笑的和版本经理数过人头，FP的30个人，已经演变成了300人以上的队伍，还是一个项目周例会解决问题的效率会比较低下。
我们采用的实践是每日站会的方式，各领域代表将各领域前一天的工作进行总结，将这一阶段的主要问题进行反馈，五角经理轮流主持（虽然能够起到练兵的作用，但是也有不好的地方。），统一写在白板上，进行信息共享和展示。
项目问题、事务、风险统一跟踪，采用Excel自带的共享工作簿功能（不会的同学自己百度、Google，打电话给我也行 ^_^），项目组全员共享，每个责任人对自己任务进行进展更新，支持多人同时更新。
3）问题清单：
每个QA都需要关注的问题清单，那么应该怎么看？
1、
问题单看是要看的，对于智能机那么多问题咋整，首先要学会的是增量的看。问题单号都是体现了一定的顺序，上次看到哪个了，下次从下面一个看起。或者借助工具标示出来哪些是新增的。（自己写了一个小工具，后面会有共享）
2、
问题要学会分类看，可以按照当前责任领域看，可以按照问题模块看（虽然测试和研发的分类不太一样，当前填写的也不准）。
3、
对问题状态有变化的需要关注，特别是状态往回退的。（当然都可以借助于工具）
但是最最最重要的，是将产品的问题单跟踪和统计规则归一，过多的方式，只能够产生混乱，大量的时间浪费在澄清和扯皮中，对我们已经被压缩的不能再压缩的进度是一种极度浪费。
我们在都做了什么？
A、问题单作为数据源的运用：
1、
问题单统计工具归一：
软件有软件的统计方式，测试有测试的统计方式，产品有产品的统计方式，OK，我们首先做到的就是工具表归一化，做了一个工具表，这个世界平静了。其次，统计规则统一，公软件平台类同时开发项目的问题合并在一起统计（优先将试制提的问题直接剔除，其他的评估时候再判断），评估为不修改、非问题的直接不统计，问题单继续走。
2、
问题单排名方式归一：
以前做QCC的时候，有一位同事说过，如果要让这个活动搞起来，就要让马赛起来，要形成竞争。OK，规则和统计方式已经统一了，按照资源组的方式（软件细分到各小组），进行当前问题单状态排序，每天通报。工具相对比较傻瓜化，自己先发几期，后面找一个慧通的兄弟，教会他使用方法，都是他来发，软件问题就这样活性竞争起来，大家也知道如何做了。
3、
问题单评估记录归一：
智能机问题实在是多，新平台旗舰机，问题尤其多啊，排序找重点问题，通过会议纪要的方式记录，后面跟踪有困难。OK，没问题，会议纪要照发，但是每个问题单的结论统一记录到工具表单中，评估结论直接放在里面，便于查询、筛选，状态也一目了然，简单&直接，大家都喜欢。
上面说的天花乱坠，其实就是一个Excel表+Vlookup函数，所有需求都搞定，而且尽可能采用自动化处理，每天0.5-1小时工作量，大家方向很一致。
（日志中添加附件确实比较麻烦，放弃了。 ^_^）
B、问题单数据如何展示：
数据源既然已经有了，如何用呢? 做一个有心人，看看我共享的“咨询工具”系列吧，里面会给你灵感的。
1、
展示问题发展趋势： 二维折线图——最常见的展示方式，大家大家最爱用，大家也都能看得懂。 将已发现问题，关闭问题，新增问题固定的按照时间顺序展示出来，具体情况一目了然。
2、
展示研发和测试的PK：
折线图也可以这样用哦，研发解决问题和测试发现问题可以这样对比，是推研发解决问题还是测试发现问题，很清晰。
将研发每日解决问题和测试每日发现问题（每个软件版本也可以），对比起来，看看到底谁牛逼。^_^
3、
展示研发解决问题的速度：
地层图的使用，这个是和总体组一个GG学的，研发能力基线也可以得到验证哦。(没法上图，有需求的同学，去百度一下就行了。
4）试制现场质量控制：
几个现象：
1、
大家都很忙，各忙各的，一旦是重大项目，各部门都出差，出差日报就满天飞，后端的兄弟很郁闷，到底应该看那份信息，哪份信息最准确？
2、
DFx或者试制代表统筹组织，但是“布朗运动”比较明显，问题攻关全面开花，对于本次试制而言到底哪个问题需要重点解决，优先解决？兄弟们很困惑。
3、
我们在现场改善了很多东西，需要落实的要求很多，EMS的技术员一个人接口我们很多人，我听谁的？EMS的技术员很郁闷。
4、
我们落实了不少方案，效果咋样，有没有新增问题，产线报表、数据咋没有人看呢？
我的项目上的实践：
产线跑不顺，出现的各类问题无非是物料、制程、设计三类。物料问题直接进行筛选，和供应商明确后续的交货和验货要求，基本可以告一段落。制程问题关键是看提升员工的熟练度和核心工位操作的正确性，这个是需要一点点看，一点点纠的，只看报表而不在现场是解决不了问题的。设计问题一旦出现，必然是高比例的不良，那攻关一定避免不了。针对上述的认知，进行了如下人员布局：
跟线人员分为两个职能组：巡线组和攻关组，各设立组长一名。
巡线组：量产爬坡EMS配得都是新手，因此要加强巡线动作，重点关注关键工位的操作正确性和可能由于操作、夹具不良导致的潜在问题。巡线组比较辛苦，跟着实际生产班次走。
攻关组：负责关键遗留问题的攻关。
信息交互方式：每日9:00早站会，小组长将两组信息总结并交流互通，制定新一天的工作计划。
改进效果确认：每日产线问题的梳理，各种问题的趋势判断，识别需要重点关注的问题（之前是我主导，后续教会DFx或者试制代表）
成果及时落地，关键工位识别，相关注意事项增加到伟创力IPQC的巡检要求和操作指导中。
待改进点：
当前试制开工会关注度不足，每次试制需要关注啥，上次遗留的哪些问题已经解决，具体落实了哪些措施和活动，哪些问题不解决，一定要试制前达成一致。
试制的资源是有限的，试制的次数应该是需要受限的，版本经理需要珍惜每次一试制机会，QA能够制止试制，当然是最好的。^_^
其他类：
5）EWP分析
EWP分析的目的应该有两个，1）早期发现问题，将后续会影响故障率的问题扼杀在摇篮中（判断准确需要经验）；2）解决的问题作为经验优化到设计规则或者经验案例中去，未解决的遗留问题合并到FFR改进中跟踪。 当前我们更多关心的是第一个目的，这个无可厚非，也是正确的，但是我们手头的资源是有限的，问题一定要排序解决，不能全线作战，否则一旦产品过多，紊乱场面无可避免。
6）FFR
FFR应该是所有PQA心中永远的痛，但是我觉得FFR分析是每个PQA必须掌握的工作技能，同时通过FFR分析，能够更好的积累经验，知道哪些问题会成为用户不可接受的问题。但是FFR分析不是指简单的数字分析，一定要找到数字背后的东西，因为数字会骗人。^_^
\s
其次，要改进FFR，最关键是解决主要的故障，那么最好对维修工单原始数据有所了解。
原始数据中可以细分到国家、外包服务商、产品、维保类型、故障（单台最多有3种）、维修方式、维修备件、购机日、接受日、修好日，通过PSN和工单号进行区分。根据上述的分类，我们可以知道故障的分布/排序，故障常发生的时间段，主要损坏的器件，DOA&DAP在所有故障机中的占比……
我利用这个原始数据做过一些实践: FFR趋势预估（根据对公式的理解+发货计划）、同一器件在不同产品中的故障率评估、浴盆曲线中早发时间段的估计（没有写成胶片）、北美市场故障比例分析、FP CDMA在不同国家的FFR分析…… 模仿仅仅是起步，理解分析的思路，逐渐形成自己的思路和方式才是你最终的目的。
对我来讲，TCS中的原始故障数据就像是一个待发掘的宝库，每次仔细琢磨后，总可以从里面看到不少的东西，能够帮助我更好的去做判断。
有好的工具平台和数据源仅仅是开始，关键在于使用。毕竟数据是死的，你用不用它都在那里，你用了，帮我们更好的去分析和判断问题，才能发光和发热。
关于工具的忠告：如果遇到工具不好用的情况，请先冷静，毕竟每种工具都有局限性限制，我们首先应该认为是我们没有理解好工具和用好工具，其次再是看看是否有啥工具可以进行组合，补充这个工具的弱点。世界上不存在一种通吃所有需求的工具，因为工具也是人开发的，合理的组合和正确的使用工具，才是王道。
7）800分析
800热线分析也是一种数据分析，它算是和TCS原始数据一样的东西，但是我的理解这两种数据需要站在不同的角度进行分析。如果TCS数据告诉我们的是用户无法忍受的故障，那么800热线就是告诉我们当前用户的偏好和一些使用习惯。换句话说，TCS中记录的故障，客户更加不能容忍；800热线潜藏的更多是商机（改进后可以用来吸引用户的）。千万不能用800热线数据去求证漏测问题，但是用来指引我们改进测试用例，是一个比较靠谱的方向。
我也算是800分析的一个鼻祖了，好像是2009年吧，我是第一个做800热线分析的，当初从中提炼出的UCWEB，QQ的需求，第二年就被落实到FP CDMA低端机上，很好的切合了中国电信的需求，有效支撑FP CDMA xxx万的出货。^_^
关于数据分析：
数据分析是一个枯燥和繁琐的工作，如果没有IT平台、自动化工具的支撑，但是数据分析能够帮大家找到规律，找到最关键的20%。作为QA一定要有意识的培养自己这方面的素养和能力，它能够帮助我们更理性的判断问题。但是也要记住，一切数据也要用实践和时间去验证，因为不同的数据处理方式会有不同的展示效果。腾讯公司就是一个很关注数据分析的工具，专门有一个团队是进行数据分析的，而且非高等级的专家不能进入，通过数据分析，去找到用户的使用习惯和最心动的点，持续优化，不断地吸引用户使用腾讯的各类增值服务。
《统计数字会撒谎》虽然比较浅显，但是大家可以瞅瞅。 ^_^
§后记§
QA流派的解读：
实战流：
【描述】快刀斩乱麻派，遇问题灭问题，人挡杀人佛挡杀佛，属于猛将型人物。
【特点】直觉感强，思维敏捷，反应快，能够快速提供解决方案，快速决策。
流程理论流：
【描述】对IPD流程烂熟于胸，倒背如流，对各类质量的理念，管理的理念有相当的理解，针对问题总能够找到理论依据，旁征博引，滔滔不绝的大道理。^_^
【特点】记忆力超群，对书本知识理解透彻，逢考必高分。流程意识强，遇事必流程。^_^
工具方法流：
【描述】对质量工程方法，具体质量工具有偏好，总喜欢用工具或者方法去解决问题，
【特点】典型左脑逻辑动物，喜欢倒腾，有完美主义倾向。 ^_^
作为QA，你属于哪个流呢？你想成为哪个流呢？ ^_^
没有一个QA会成为某个纯粹的流派，都应该是一个综合体，仅仅是更多偏向于哪边而已。以我个人而言更多的偏重于工具方法流，实战流和流程理论流也会占一小部分，但是不多。
但是不管你是哪个流派，我认为，最为QA最重要的是实践，因为作为QA需要人们去改变心智和习惯，而改变人心智和习惯最强有力的方法就是行动。记得一个科学数据表明，要让人改变一个习惯，需要持续的坚持新习惯68天，单靠宣传产生的改变的力量，我们都不是乔布斯或者马云，效果应该是有限的，还是行动实在些。
学习是为了更好地应用！ —— 毛泽东
做QA应该是水无常形，兵无常法。Checklist、指标仅仅是冰山一角，最关键需要建立的是人对产品质量态度和责任感。我们经常分享结果（模板、流程），为什么做和如何思考做这个事的思维方式更加值得分享，明白当初为啥做这个事，才可以促进态度和理念的复制，否则只能模仿形而失去了最重要的神。当然，各个优秀实践，可以作为一种案例可以进行货架化知识管理，便于查询。
一、
确定项目质量工作的思路：
认清现状: 项目立项伊始，最关键的是认清现状。在工作中很容易被鼓动的也是一种职业幼稚心理的表现，只有在工作开始之前瞻前顾后的才是帅才。^_^ 企业总是以“活下去再发展”为首要前提的，因此配置的资源一定会存在这样那样的缺陷，当然也有配置给你最好资源的情况存在，那个时候就要小心进度陷阱和人员使用陷阱了。^_^
换位思考，明确工作思路：
“项目团队不是不希望改进和提升，更多的时候是他们遇到问题不知道如何去改进。”
手机是强项目交付牵引，但是项目运作又是强资源矩阵（至少目前是），项目交付应该还是第一位的，整个项目团队的成员都还是希望能够按期交付，按质量要求交付。新软件平台，新硬件平台，新项目定位，一定会遇到问题，而且是一堆的问题，拿着质量的要求、标准去要求团队达成，是一种质量人员的做法；融入到项目运作中，切实的协助项目组识别关键问题，解决运作过程中的问题，也是一种质量人员的做法。
项目按期交付，拼命往前冲的大势无法阻挡，那我宁可选择融入到项目团队中，实实在在的将产品质量做好，切切实实的将项目运作过程中的问题解决。虽然将面临一堆的问题，但是我阳光总在风雨后，不经历痛苦，哪能感受幸福。 ^_^
找到问题关键的20%，集中优势兵力重点突破，采用小循环的方式逐步改进，成为和项目团队一起奋斗过程中的主要工作思路。
二、
扮演好几个角色：
1）刹车人（狂热队伍中的冷酷者）
如果说质量中最不愿见的是“变量”，项目管理中最不乐见的是“变更”，那么项目运作过程中最害怕的是“狂热”，团队一旦开始狂热，如果不及时的刹车，那么项目运作必然失控。
前段时间我们HR和我交流时说：“如果别人离职，我可能还会想法挽留一下，但是你小子太冷酷了，要么不干，要干就一定想清楚了，而且是无法被动摇的。”
没错，在狂躁的项目运作过程中，你一定要冷静，甚至冷酷，要仔细观察，认真分析，拨开迷雾看到本质，因为真相永远只有一个。^_^
Tips：
各部门的研发兄弟都有一个向上的心，都希望自己的领域没问题，往往容易犯顾头不顾腚的毛病。我们希望各领域优秀，但是我们更加希望产品是优秀的，因此就需要取舍和平衡，作为PQA(质量人)应该系统的去思考问题，要引导产品达到最佳的平衡，当然建议在平衡的前提下，也可以获取某方面的最优化（卖点、亮点）。
在交付压力的牵引下，一定会想方设法的去赶试制，但是多次试制更多的可能是带来资源的耗费，毕竟华为公司每个项目上的资源并不充分。要冷静对待问题，珍惜和把握每一次机会。
——《风云》中聂风的冰心诀:
心若冰清，天塌不惊； 万变犹定，神怡气静；
尘垢不沾，俗相不染；
虚空甯宓，浑然无物；
无有相生，难易相成；
份与物忘，同乎浑涅；
天地无涯，万物齐一；
飞花落叶，虚怀若谷；
千般烦忧，才下心头；
即展眉头，灵台清幽；
心无罣碍，意无所执；
解心释神，莫然无魂；
水流心不惊，云在意俱迟；
一心不赘物，古今自逍遥！……
丰田的案例：
大家都知道丰田汽车公司，可能这家公司是当今社会被人研究最多的企业之一。该公司的经营和管理哲学独树一帜，其中最著名的管理模式是“丰田生产方式”（TPS），业界称为“精益生产”。“丰田生产方式”的核心是PDCA。有人说，当一个典型的美国公司遇到一个问题的时候，如果这个问题必须在一年内解决，该企业会用3个月来做计划，用另外3个月来执行，再用6个月来做微调，处理遗留问题。而丰田在面对类似形势的时候，会用11个月来做计划，用1个月来实施（根本不会留下任何遗留问题）。这种说法虽然比较夸张，但是它体现了丰田对于PDCA的独特理解和经验总结。丰田人认为：计划至关重要！只有彻底的计划（从多个角度全面了解了形势、准确地发现了问题产生的根本原因、考虑可能发生的各种变化、以及参与者的认可或者上级的批准后），实施、检查、处理的结果才能高效达成预期的目标。
2）公正的中立人(公正公平，但是一定要保持中立)
PQA（质量人）的定位是中立的，因此总会有这样那样的纠纷问题要质量人来仲裁，希望得到中立的评价意见。当然在研发内部出现类似情况仲裁还可以，因为我们毕竟还呆在研发区。但是对于出现跨研发领域的时候，和大供应链体系（制造&采购）交流的时候，供应链体系经常认为我们是属于研发体系的，容易存在略带敌对的和我们交流。如此情况下，我们应该如何的处理？
Tips:
我分享一下我的做法：
1、首先是澄清具体问题，不要和对方陷入到度量指标，考核指标的漩涡中去（影响产品的具体问题都已经解决了，指标不满足要求也难）。
2、对于问题要制定应对措施和具体责任人，从问题后续的实际表现去评估活动是否有效和相应的进展（避免出现活动做了，但是没有效果）。
3、该踢一脚的还是要踢一脚（忍无可忍无需再忍），当时言辞要客观，避免采用主观类的语言（这个时候就需要体现质量人的专业素养了 ^_^）。
直通率问题 案例：
转量产的时候最容易遇到的就是因为直通率问题，制造体系和产品较劲。为了解决直通率问题，研发体系一直是有人制造现场的（具体的派兵布阵也有一个小实践，在后面和大家分享），组装段的一次直通率从爬坡的20%，一直稳定到了85%以上，而且还有不断上升的利好趋势。当时因为SMT段的一次直通率低，而且不稳定，直接导致全工位一次直通率就被拉到了80%以下，而且极不稳定。
客观公正的给制造体系的各位老大分析了一下直通率趋势，和转量产一些要求，SMT段的问题很快得以控制和解决。 （图像上传不成功，往来邮件就只有省了。）
三、
一点点实践，一点点认知：
1）
关于产品质量评估：
产品质量评估是QA是一定要做的，但是如何做，各地有各地的模板，各人有各人的习惯，我的思考和写作方式分享给大家，请各位方家拍砖。
质量评估对于领导们来说，是希望看到一份产品质量状态的全貌，能够包含产品各方面的完整信息，它除了用于领导的监控，其实也应该是很够很好的引导版本经理规划后续的重点工作，因此可以联合版本经理一起来写，在写的过程中，同时也是对项目状态的一个梳理。第一期可能比较困难，当时后面的只要逐渐更新即可。
我们写一份报告，首先需要列清楚需要体现的维度，然后是收集写作素材（往往会有现成的素材），最后再用客观语言来表述。原始的素材不一定需要重新开始，往往周围的领域已经有人在做了，因此要注意积累渠道和信息源。 积累人脉和渠道的最好方式是分享，将你的工作成果和他人分享（包括业务部门的人），尤其是提供信息给你的那些兄弟，并且要心存感激。
—— 有感于李志《其实你不懂项目管理》
对于产品质量状态，我通常会从如下的角度思考，当然针对不同的项目背景，所处阶段进行调整，这个需要从实践中积累经验。
需求实现：在TR4之前需要重点关注，尤其是软件需求。可以联合SQA做些事情，组织软件、测试、SE等领域做了三次需求实现梳理&排序，明确下来哪些必须在啥时间点完成，哪些需要裁剪。因为需求的颗粒度不同，很多细节上把握不到，那就想办法建立一种机制，把权限下放到最懂业务的地方，例行运作，QA参与并监控就行了。
软件单元测试：现在项目都敏捷了，单元测试如何做，如何评估充分性，没有啥心得，我一般都咨询SQA。
硬件单元测试：主要关心没有测试通过的项目，对于新器件的验证情况也需要重点关照，我没有现成的Checklist，更多的是和开发人员、器件组负责人交流验证方案和结果。建议多看看硬件组器件相关的案例，测试对于器件替代的方案，供应商器件出厂的测试要求，带着疑问去和器件组的兄弟们交流（我作为QA参加过LCD、音频的器件组工作，梳理过音频流程、整理过音频小组的运作方式。），花点功夫在平日，积累交情的同时也能学到不少东西。
硬件测试（含可靠性测试）：除了关注测试的结果和发现的问题以外，我更关心的是测试的覆盖度（所有用例是否都覆盖，V试制和VN试制是否都完成应该的测试覆盖）和问题发现趋势（如果前几次测试没有问题，但是后面有问题，一定会追问一下为什么），历次修改方案也需要和测试用例进行一个比对，防止方案遗漏。工作可以借力哦，但是要采用合作的态度参与其中，帮助解决其中的相关技术问题。^_^(这个工作其实是我提供想法，提供工具表单的支撑，数据整理工作基本上都是硬件测试接口人做的。)
软件测试：前期更多地都是关注缺陷管理系统中的的题，如果涉及同软件平台同时开发产品，最好修改的问题一起评估，尽管工作量大点，至少避免了遗漏。其实还有一个不同软件版本的关系树可以参考，我前期基本上是通过交流获取方法，去确定评估方案，最后看到这个树的时候，后悔了好一阵子。这个树可以帮助QA理清楚问题评估方案，以及关键问题的修改合入策略，简单有效。 准入测试、Beta测试、现网测试：这个是测试经理制定的，只是在方案确定的时候，需要和测试经理交流一下，我是借用的信息。就是在识别和评估发现的主要问题上和测试经理交流了不少。
试制问题：DFx or 试制代表手上有非常完整的试制问题清单，最好Review一下，根据经验判断一下那些是TOPn和必须解决的。我有几年制造端产品质量管控的经验，所以判断相对比较容易，其实就是判断此问题是否影响产线效率，因为产线进行的是机械的、重复的操作，简单的才不容易出错，高效的才容易落实，对于产线问题处理要记住“简单就是美”，所以解决方案重点要思考工具&方法的辅助，尽量减少配置或者选择。其他的问题比例、危害度之类的需要辨证的看，不要被数字欺骗，PQA有机会还是多去产线转转，经验还是需要积累的。
我们产品开发过程中有一个关于返工的优秀实践：对于产线上出现的故障机维修后，统一升级软件到PT测试之前，然后直接往下走流程，深得制造兄弟的喜爱，因为没有那么多状态需要控制。对比每个测试工位的工具都有返修流程设置，我们研发的角度想，是给了你很多的选择，可以从不同的工位进行返工，但是我们似乎忘记了，产线玩的是海量制造，不是手工作坊，原则越多，产线不同的产品状态越多，越不容易控制，越容易出现疏漏。如果简单的到只有一种返工方式，那么我们核心需要改进的点就是如何减少返工，而不用关注如何增加返工的途径。
物料问题&器件验证：影响产线的制程问题从试制问题清单中单独拎出来，还要关心的是器件验证的情况（新器件引入&器件替代），直接在PDM上看BOM编码的发放情况就能知道器件验证的进展，然后有针对性的去咨询相关的责任人。
问题清单：对于质量评估而言，要体现一个整体的趋势（问题发现趋势，遗留问题趋势，DI趋势……），根据展示即可。不要忘记了，调处你认为最关键硬件、软件、制造类问题明确的写出来。
问题评估的记录一定要有序，如果有系统是最好的了，但是如果没有的话，可以采用Excel表单跟踪，但是最好能够增加一定VBA统计功能，可以省不少工作量。^_^ 后面会详细讲，这里简略点一下。市场：这个基本上是版本经理在关心，我了解相关信息，只是用于调整相应活动的开展方式。质量评估上基本不涉及。 ^_^
\s
一份好的质量评估报告，其实是可以被复用的，我写的质量报告就被用于给老总的汇报，早期发货的评估。一份好的质量评估报告，首先要有一个好的框架，第一份可能困难点，但是后面的话就是不断对信息进行刷新。（多么希望后续产品的信息可以集成化在一个系统中，方便查询和展示）
2）项目问题&风险跟踪：
对于功能机时代，产品开发规模小，一个项目组例会就可以Cover，但是我们已经步入了智能机时代，开发一款旗舰机，曾经开玩笑的和版本经理数过人头，FP的30个人，已经演变成了300人以上的队伍，还是一个项目周例会解决问题的效率会比较低下。
我们采用的实践是每日站会的方式，各领域代表将各领域前一天的工作进行总结，将这一阶段的主要问题进行反馈，五角经理轮流主持（虽然能够起到练兵的作用，但是也有不好的地方。），统一写在白板上，进行信息共享和展示。
项目问题、事务、风险统一跟踪，采用Excel自带的共享工作簿功能（不会的同学自己百度、Google，打电话给我也行 ^_^），项目组全员共享，每个责任人对自己任务进行进展更新，支持多人同时更新。
3）问题清单：
每个QA都需要关注的问题清单，那么应该怎么看？
1、
问题单看是要看的，对于智能机那么多问题咋整，首先要学会的是增量的看。问题单号都是体现了一定的顺序，上次看到哪个了，下次从下面一个看起。或者借助工具标示出来哪些是新增的。（自己写了一个小工具，后面会有共享）
2、
问题要学会分类看，可以按照当前责任领域看，可以按照问题模块看（虽然测试和研发的分类不太一样，当前填写的也不准）。
3、
对问题状态有变化的需要关注，特别是状态往回退的。（当然都可以借助于工具）
但是最最最重要的，是将产品的问题单跟踪和统计规则归一，过多的方式，只能够产生混乱，大量的时间浪费在澄清和扯皮中，对我们已经被压缩的不能再压缩的进度是一种极度浪费。
我们在都做了什么？
A、问题单作为数据源的运用：
1、
问题单统计工具归一：
软件有软件的统计方式，测试有测试的统计方式，产品有产品的统计方式，OK，我们首先做到的就是工具表归一化，做了一个工具表，这个世界平静了。其次，统计规则统一，公软件平台类同时开发项目的问题合并在一起统计（优先将试制提的问题直接剔除，其他的评估时候再判断），评估为不修改、非问题的直接不统计，问题单继续走。
2、
问题单排名方式归一：
以前做QCC的时候，有一位同事说过，如果要让这个活动搞起来，就要让马赛起来，要形成竞争。OK，规则和统计方式已经统一了，按照资源组的方式（软件细分到各小组），进行当前问题单状态排序，每天通报。工具相对比较傻瓜化，自己先发几期，后面找一个慧通的兄弟，教会他使用方法，都是他来发，软件问题就这样活性竞争起来，大家也知道如何做了。
3、
问题单评估记录归一：
智能机问题实在是多，新平台旗舰机，问题尤其多啊，排序找重点问题，通过会议纪要的方式记录，后面跟踪有困难。OK，没问题，会议纪要照发，但是每个问题单的结论统一记录到工具表单中，评估结论直接放在里面，便于查询、筛选，状态也一目了然，简单&直接，大家都喜欢。
上面说的天花乱坠，其实就是一个Excel表+Vlookup函数，所有需求都搞定，而且尽可能采用自动化处理，每天0.5-1小时工作量，大家方向很一致。
（日志中添加附件确实比较麻烦，放弃了。 ^_^）
B、问题单数据如何展示：
数据源既然已经有了，如何用呢? 做一个有心人，看看我共享的“咨询工具”系列吧，里面会给你灵感的。
1、
展示问题发展趋势： 二维折线图——最常见的展示方式，大家大家最爱用，大家也都能看得懂。 将已发现问题，关闭问题，新增问题固定的按照时间顺序展示出来，具体情况一目了然。
2、
展示研发和测试的PK：
折线图也可以这样用哦，研发解决问题和测试发现问题可以这样对比，是推研发解决问题还是测试发现问题，很清晰。
将研发每日解决问题和测试每日发现问题（每个软件版本也可以），对比起来，看看到底谁牛逼。^_^
3、
展示研发解决问题的速度：
地层图的使用，这个是和总体组一个GG学的，研发能力基线也可以得到验证哦。(没法上图，有需求的同学，去百度一下就行了。
4）试制现场质量控制：
几个现象：
1、
大家都很忙，各忙各的，一旦是重大项目，各部门都出差，出差日报就满天飞，后端的兄弟很郁闷，到底应该看那份信息，哪份信息最准确？
2、
DFx或者试制代表统筹组织，但是“布朗运动”比较明显，问题攻关全面开花，对于本次试制而言到底哪个问题需要重点解决，优先解决？兄弟们很困惑。
3、
我们在现场改善了很多东西，需要落实的要求很多，EMS的技术员一个人接口我们很多人，我听谁的？EMS的技术员很郁闷。
4、
我们落实了不少方案，效果咋样，有没有新增问题，产线报表、数据咋没有人看呢？
我的项目上的实践：
产线跑不顺，出现的各类问题无非是物料、制程、设计三类。物料问题直接进行筛选，和供应商明确后续的交货和验货要求，基本可以告一段落。制程问题关键是看提升员工的熟练度和核心工位操作的正确性，这个是需要一点点看，一点点纠的，只看报表而不在现场是解决不了问题的。设计问题一旦出现，必然是高比例的不良，那攻关一定避免不了。针对上述的认知，进行了如下人员布局：
跟线人员分为两个职能组：巡线组和攻关组，各设立组长一名。
巡线组：量产爬坡EMS配得都是新手，因此要加强巡线动作，重点关注关键工位的操作正确性和可能由于操作、夹具不良导致的潜在问题。巡线组比较辛苦，跟着实际生产班次走。
攻关组：负责关键遗留问题的攻关。
信息交互方式：每日9:00早站会，小组长将两组信息总结并交流互通，制定新一天的工作计划。
改进效果确认：每日产线问题的梳理，各种问题的趋势判断，识别需要重点关注的问题（之前是我主导，后续教会DFx或者试制代表）
成果及时落地，关键工位识别，相关注意事项增加到伟创力IPQC的巡检要求和操作指导中。
待改进点：
当前试制开工会关注度不足，每次试制需要关注啥，上次遗留的哪些问题已经解决，具体落实了哪些措施和活动，哪些问题不解决，一定要试制前达成一致。
试制的资源是有限的，试制的次数应该是需要受限的，版本经理需要珍惜每次一试制机会，QA能够制止试制，当然是最好的。^_^
其他类：
5）EWP分析
EWP分析的目的应该有两个，1）早期发现问题，将后续会影响故障率的问题扼杀在摇篮中（判断准确需要经验）；2）解决的问题作为经验优化到设计规则或者经验案例中去，未解决的遗留问题合并到FFR改进中跟踪。 当前我们更多关心的是第一个目的，这个无可厚非，也是正确的，但是我们手头的资源是有限的，问题一定要排序解决，不能全线作战，否则一旦产品过多，紊乱场面无可避免。
6）FFR
FFR应该是所有PQA心中永远的痛，但是我觉得FFR分析是每个PQA必须掌握的工作技能，同时通过FFR分析，能够更好的积累经验，知道哪些问题会成为用户不可接受的问题。但是FFR分析不是指简单的数字分析，一定要找到数字背后的东西，因为数字会骗人。^_^
\s
其次，要改进FFR，最关键是解决主要的故障，那么最好对维修工单原始数据有所了解。
原始数据中可以细分到国家、外包服务商、产品、维保类型、故障（单台最多有3种）、维修方式、维修备件、购机日、接受日、修好日，通过PSN和工单号进行区分。根据上述的分类，我们可以知道故障的分布/排序，故障常发生的时间段，主要损坏的器件，DOA&DAP在所有故障机中的占比……
我利用这个原始数据做过一些实践: FFR趋势预估（根据对公式的理解+发货计划）、同一器件在不同产品中的故障率评估、浴盆曲线中早发时间段的估计（没有写成胶片）、北美市场故障比例分析、FP CDMA在不同国家的FFR分析…… 模仿仅仅是起步，理解分析的思路，逐渐形成自己的思路和方式才是你最终的目的。
对我来讲，TCS中的原始故障数据就像是一个待发掘的宝库，每次仔细琢磨后，总可以从里面看到不少的东西，能够帮助我更好的去做判断。
有好的工具平台和数据源仅仅是开始，关键在于使用。毕竟数据是死的，你用不用它都在那里，你用了，帮我们更好的去分析和判断问题，才能发光和发热。
关于工具的忠告：如果遇到工具不好用的情况，请先冷静，毕竟每种工具都有局限性限制，我们首先应该认为是我们没有理解好工具和用好工具，其次再是看看是否有啥工具可以进行组合，补充这个工具的弱点。世界上不存在一种通吃所有需求的工具，因为工具也是人开发的，合理的组合和正确的使用工具，才是王道。
7）800分析
800热线分析也是一种数据分析，它算是和TCS原始数据一样的东西，但是我的理解这两种数据需要站在不同的角度进行分析。如果TCS数据告诉我们的是用户无法忍受的故障，那么800热线就是告诉我们当前用户的偏好和一些使用习惯。换句话说，TCS中记录的故障，客户更加不能容忍；800热线潜藏的更多是商机（改进后可以用来吸引用户的）。千万不能用800热线数据去求证漏测问题，但是用来指引我们改进测试用例，是一个比较靠谱的方向。
我也算是800分析的一个鼻祖了，好像是2009年吧，我是第一个做800热线分析的，当初从中提炼出的UCWEB，QQ的需求，第二年就被落实到FP CDMA低端机上，很好的切合了中国电信的需求，有效支撑FP CDMA xxx万的出货。^_^
关于数据分析：
数据分析是一个枯燥和繁琐的工作，如果没有IT平台、自动化工具的支撑，但是数据分析能够帮大家找到规律，找到最关键的20%。作为QA一定要有意识的培养自己这方面的素养和能力，它能够帮助我们更理性的判断问题。但是也要记住，一切数据也要用实践和时间去验证，因为不同的数据处理方式会有不同的展示效果。腾讯公司就是一个很关注数据分析的工具，专门有一个团队是进行数据分析的，而且非高等级的专家不能进入，通过数据分析，去找到用户的使用习惯和最心动的点，持续优化，不断地吸引用户使用腾讯的各类增值服务。
《统计数字会撒谎》虽然比较浅显，但是大家可以瞅瞅。 ^_^
§后记§
QA流派的解读：
实战流：
【描述】快刀斩乱麻派，遇问题灭问题，人挡杀人佛挡杀佛，属于猛将型人物。
【特点】直觉感强，思维敏捷，反应快，能够快速提供解决方案，快速决策。
流程理论流：
【描述】对IPD流程烂熟于胸，倒背如流，对各类质量的理念，管理的理念有相当的理解，针对问题总能够找到理论依据，旁征博引，滔滔不绝的大道理。^_^
【特点】记忆力超群，对书本知识理解透彻，逢考必高分。流程意识强，遇事必流程。^_^
工具方法流：
【描述】对质量工程方法，具体质量工具有偏好，总喜欢用工具或者方法去解决问题，
【特点】典型左脑逻辑动物，喜欢倒腾，有完美主义倾向。 ^_^
作为QA，你属于哪个流呢？你想成为哪个流呢？ ^_^
没有一个QA会成为某个纯粹的流派，都应该是一个综合体，仅仅是更多偏向于哪边而已。以我个人而言更多的偏重于工具方法流，实战流和流程理论流也会占一小部分，但是不多。
但是不管你是哪个流派，我认为，最为QA最重要的是实践，因为作为QA需要人们去改变心智和习惯，而改变人心智和习惯最强有力的方法就是行动。记得一个科学数据表明，要让人改变一个习惯，需要持续的坚持新习惯68天，单靠宣传产生的改变的力量，我们都不是乔布斯或者马云，效果应该是有限的，还是行动实在些。
学习是为了更好地应用！ —— 毛泽东
RSS Feed