深度好文:质量只是旅程,而不是终点

57次阅读
没有评论

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

 

1
统一方法和思路

1、 确定项目质量工作的思路:

 

认清现状: 项目立项伊始,最关键的是认清现状。在工作中很容易被鼓动的也是一种职业幼稚心理的表现,只有在工作开始之前瞻前顾后的才是帅才。^_^ 企业总是以“活下去再发展”为首要前提的,因此配置的资源一定会存在这样那样的缺陷,当然也有配置给你最好资源的情况存在,那个时候就要小心进度陷阱和人员使用陷阱了。^_^

 

2、换位思考,明确工作思路:

 

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

 

手机是强项目交付牵引,但是项目运作又是强资源矩阵(至少目前是),项目交付应该还是第一位的,整个项目团队的成员都还是希望能够按期交付,按质量要求交付。新软件平台,新硬件平台,新项目定位,一定会遇到问题,而且是一堆的问题,拿着质量的要求、标准去要求团队达成,是一种质量人员的做法;融入到项目运作中,切实的协助项目组识别关键问题,解决运作过程中的问题,也是一种质量人员的做法。

 

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

 

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

2
扮演几个角色

 

1、刹车人(狂热队伍中的冷酷者)

 

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

 

前段时间我们HR和我交流时说:“如果别人离职,我可能还会想法挽留一下,但是你小子太冷酷了,要么不干,要干就一定想清楚了,而且是无法被动摇的。”

没错,在狂躁的项目运作过程中,你一定要冷静,甚至冷酷,要仔细观察,认真分析,拨开迷雾看到本质,因为真相永远只有一个。^_^

 

Tips:

 

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

 

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

 

——《风云》中聂风的冰心诀:

心若冰清,天塌不惊;万变犹定,神怡气静;

 

尘垢不沾,俗相不染;

 

虚空甯宓,浑然无物;

 

无有相生,难易相成;

 

份与物忘,同乎浑涅;

 

天地无涯,万物齐一;

 

飞花落叶,虚怀若谷;

 

千般烦忧,才下心头;

 

即展眉头,灵台清幽;

 

心无罣碍,意无所执;

 

解心释神,莫然无魂;

 

水流心不惊,云在意俱迟;

 

一心不赘物,古今自逍遥!……

 

丰田的案例:

 

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

 

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

 

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

 

Tips:

 

我分享一下我的做法:

 

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

 

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

 

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

直通率问题 案例:

 

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

 

客观公正的给制造体系的各位老大分析了一下直通率趋势,和转量产一些要求,SMT段的问题很快得以控制和解决。(图像上传不成功,往来邮件就只有省了。)

3
一点点实践、一点点认知

 

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统计功能,可以省不少工作量。^_^ 后面会详细讲,这里简略点一下。市场:这个基本上是版本经理在关心,我了解相关信息,只是用于调整相应活动的开展方式。质量评估上基本不涉及。 ^_^

 

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

 

2、项目问题&风险跟踪:

 

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

 

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

 

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

 

3、问题清单:

 

每个QA都需要关注的问题清单,那么应该怎么看?

 

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

 

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

 

C、对问题状态有变化的需要关注,特别是状态往回退的。(当然都可以借助于工具)

 

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

4
我们都做了什么

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

 

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

 

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

 

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

 

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

 

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

 

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

 

4、问题单数据如何展示:

 

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

 

5、 展示问题发展趋势: 二维折线图——最常见的展示方式,大家大家最爱用,大家也都能看得懂。将已发现问题,关闭问题,新增问题固定的按照时间顺序展示出来,具体情况一目了然。

 

6、展示研发和测试的PK:

 

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

 

将研发每日解决问题和测试每日发现问题(每个软件版本也可以),对比起来,看看到底谁牛逼。^_^

 

7、展示研发解决问题的速度:

 

地层图的使用,这个是和总体组一个GG学的,研发能力基线也可以得到验证哦。(没法上图,有需求的同学,去百度一下就行了。

5
几个现象

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

 

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

 

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

 

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

6
项目上的实践

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

 

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

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

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

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

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

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

 

待改进点:

 

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

 

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

7
其它类

1、EWP分析

EWP分析的目的应该有两个,1)早期发现问题,将后续会影响故障率的问题扼杀在摇篮中(判断准确需要经验);2)解决的问题作为经验优化到设计规则或者经验案例中去,未解决的遗留问题合并到FFR改进中跟踪。当前我们更多关心的是第一个目的,这个无可厚非,也是正确的,但是我们手头的资源是有限的,问题一定要排序解决,不能全线作战,否则一旦产品过多,紊乱场面无可避免。

 

2、FFR

 

FFR应该是所有PQA心中永远的痛,但是我觉得FFR分析是每个PQA必须掌握的工作技能,同时通过FFR分析,能够更好的积累经验,知道哪些问题会成为用户不可接受的问题。但是FFR分析不是指简单的数字分析,一定要找到数字背后的东西,因为数字会骗人。^_^

 

其次,要改进FFR,最关键是解决主要的故障,那么最好对维修工单原始数据有所了解。

 

原始数据中可以细分到国家、外包服务商、产品、维保类型、故障(单台最多有3种)、维修方式、维修备件、购机日、接受日、修好日,通过PSN和工单号进行区分。根据上述的分类,我们可以知道故障的分布/排序,故障常发生的时间段,主要损坏的器件,DOA&DAP在所有故障机中的占比……

我利用这个原始数据做过一些实践: FFR趋势预估(根据对公式的理解+发货计划)、同一器件在不同产品中的故障率评估、浴盆曲线中早发时间段的估计(没有写成胶片)、北美市场故障比例分析、FP CDMA在不同国家的FFR分析……模仿仅仅是起步,理解分析的思路,逐渐形成自己的思路和方式才是你最终的目的。

 

对我来讲,TCS中的原始故障数据就像是一个待发掘的宝库,每次仔细琢磨后,总可以从里面看到不少的东西,能够帮助我更好的去做判断。

 

有好的工具平台和数据源仅仅是开始,关键在于使用。毕竟数据是死的,你用不用它都在那里,你用了,帮我们更好的去分析和判断问题,才能发光和发热。

 

关于工具的忠告:如果遇到工具不好用的情况,请先冷静,毕竟每种工具都有局限性限制,我们首先应该认为是我们没有理解好工具和用好工具,其次再是看看是否有啥工具可以进行组合,补充这个工具的弱点。世界上不存在一种通吃所有需求的工具,因为工具也是人开发的,合理的组合和正确的使用工具,才是王道。

 

3、800分析

 

800热线分析也是一种数据分析,它算是和TCS原始数据一样的东西,但是我的理解这两种数据需要站在不同的角度进行分析。如果TCS数据告诉我们的是用户无法忍受的故障,那么800热线就是告诉我们当前用户的偏好和一些使用习惯。换句话说,TCS中记录的故障,客户更加不能容忍;800热线潜藏的更多是商机(改进后可以用来吸引用户的)。千万不能用800热线数据去求证漏测问题,但是用来指引我们改进测试用例,是一个比较靠谱的方向。

 

我也算是800分析的一个鼻祖了,好像是2009年吧,我是第一个做800热线分析的,当初从中提炼出的UCWEB,QQ的需求,第二年就被落实到FP CDMA低端机上,很好的切合了中国电信的需求,有效支撑FP CDMA xxx万的出货。^_^

8
关于数据分析

 数据分析是一个枯燥和繁琐的工作,如果没有IT平台、自动化工具的支撑,但是数据分析能够帮大家找到规律,找到最关键的20%。作为QA一定要有意识的培养自己这方面的素养和能力,它能够帮助我们更理性的判断问题。但是也要记住,一切数据也要用实践和时间去验证,因为不同的数据处理方式会有不同的展示效果。腾讯公司就是一个很关注数据分析的工具,专门有一个团队是进行数据分析的,而且非高等级的专家不能进入,通过数据分析,去找到用户的使用习惯和最心动的点,持续优化,不断地吸引用户使用腾讯的各类增值服务。

 

§后记§

 

QA流派的解读:

 

实战流:

 

【描述】快刀斩乱麻派,遇问题灭问题,人挡杀人佛挡杀佛,属于猛将型人物。

 

【特点】直觉感强,思维敏捷,反应快,能够快速提供解决方案,快速决策。

 

流程理论流:

 

【描述】对IPD流程烂熟于胸,倒背如流,对各类质量的理念,管理的理念有相当的理解,针对问题总能够找到理论依据,旁征博引,滔滔不绝的大道理。^_^

 

【特点】记忆力超群,对书本知识理解透彻,逢考必高分。流程意识强,遇事必流程。^_^

 

工具方法流:

 

【描述】对质量工程方法,具体质量工具有偏好,总喜欢用工具或者方法去解决问题,

 

【特点】典型左脑逻辑动物,喜欢倒腾,有完美主义倾向。 ^_^

作为QA,你属于哪个流呢?你想成为哪个流呢? ^_^

 

没有一个QA会成为某个纯粹的流派,都应该是一个综合体,仅仅是更多偏向于哪边而已。以我个人而言更多的偏重于工具方法流,实战流和流程理论流也会占一小部分,但是不多。

 

但是不管你是哪个流派,我认为,最为QA最重要的是实践,因为作为QA需要人们去改变心智和习惯,而改变人心智和习惯最强有力的方法就是行动。记得一个科学数据表明,要让人改变一个习惯,需要持续的坚持新习惯68天,单靠宣传产生的改变的力量,我们都不是乔布斯或者马云,效果应该是有限的,还是行动实在些。

 

学习是为了更好地应用! —— 毛泽东

文章转自:质量工程师之家

正文完
 0
评论(没有评论)