客服热线 :  400 168 0525
Service 六西格玛
  • 用最低成本,全面覆盖企业开展的项目策划、定位、推广、建
  • 站、运营的培训需求

QA是个技术活—质量是旅程,而不是终点(实践篇)

日期: 2019-03-05
浏览次数: 2

做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负责,对资源的利用和配置要求更高。)

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

 


  • 主讲老师
推荐方案 / Cases
  • 专家课程
  • 课程好不好,不听不知道!立即报名!
分享到:
客服热线: 400-168-0525
Copyright ©1999 - 2019 北京冠卓咨询有限公司
犀牛云提供企业云服务
X
1

QQ设置

在线咨询

---------------------

3

SKYPE 设置

4

阿里旺旺设置

5

电话号码管理

  • 400-168-0525
6

二维码管理

展开