研发质量管理培训

研发质量管理培训

研发型企业如何做好质量管理？如何让质量管理深入到研发的各个阶段？

研发部ISO9001质量管理体系审核时应注意哪些方面？

【研发质量管理】什么是产品质量？

【研发质量管理体系】如何理解质量管理的三个阶段？

【研发质量管理】企业研发质量管理现状

【研发质量管理体系】搞好研发质量管理的前提条件是什么？

【研发质量控制管理】质量管理部门的定位

【研发质量控制管理】如何构建研发质量管理体系？

研发型企业如何做好质量管理？如何让质量管理深入到研发的各个阶段？

　　研发管理就是在研发体系结构设计和各种管理理论基础之上，借助信息平台对研发过程中进行的团队建设、流程设计、绩效管理、风险管理、成本管理、项目管理和知识管理等的一系列协调活动。这是百度百科上的定义，不能说没有一定道理，不过却不太实用，很难看出其中的重点所在。

　　套用项目管理铁三角的说法，研发管理三大重点则应该是效率、质量和成本。而团队建设、绩效管理、风险控制、知识管理、流程设计、项目管理等等可以认为是辅助手段或者是包含在进度、质量和成本控制中的内容。例如，流程设计应该是效率范畴中要考虑的问题，提升效率，必然要从过程即流程设计着手;而项目管理本身就包含进度、成本与质量，也与之相符。

　　成本控制上，在人力资源给定的情况下，研发开销是基本固定的。对于研发成本的控制，更多的是资源是否用在刀刃上，是否做对了项目，研究对了课题，这方面的控制主要体现在公司的战略规划、产品规划上面，做错了产品、方向，往往是浪费最大的。规划任何一个新产品都需要做到“大胆设想、小心求证、重质量轻数量”，严格立项过程。而且就研发来说，技术积累很重要，过去的成功经验未必能够复制到新的领域，因而进入任何一个新的领域，都需要慎之又慎。这部分的工作，大部分都产生于公司决策层面和产品规划层面，对于研发部门来说能做的比较少。因而研发管理的重点还是在效率与质量上。

　　对于效率问题，在《研发感悟之二--过程与方法论》、《研发感悟之三--敏捷开发》两篇博客中进行过论述。并据此在09年冬天和2010年初进行过实践，取得了较好的效果。因此，可以说研发效率问题可以说已经基本得到了解决，这里就不再继续探讨。我们这里关注的是研发管理的另外一个重点--质量管理。

　　研发质量很多时候，会被理解为QA(Quality Assurance)和QC(Quality Control)，往往归宿于质量管理部门。QC往往关注的是产品而非体系，在软件研发领域对应的就是测试;而QA则建立体系并确保体系按要求运作，涉及到过程内容(流程设计)。QC是通过对质量的结果进行检测、鉴定，防止劣质产品的发布;QA对研发是否符合过程进行控制。通过QA/QC两个环节的配合，确实能够起到一定的质量控制作用，但质量管理单单靠QA和QC是远远不够的，会存在很多问题与漏洞，更重要的是技术经理们在设计、开发环节中进行控制。

　　首先，在微观问题上，QA人员由于能力的限制对研发过程中细节的把握不可能像开发经理一样到位，这就注定了对于流程是否符合的控制，往往是仅仅解决了要做什么的问题，而无法解决怎么做，做得怎样的问题。“怎么做，做得怎样”，这往往跟执行者的能力相关，仅仅靠流程、控制点是难以达到的。而且过程中的细节问题，很难去全部规范完备、做到滴水不漏，即使真的做到滴水不漏，也必然使得过程过于庞大而导致效率低下。就如同有些SOP去规范员工如何写邮件一样，那应该是小学语文老师的工作，不是QA所要关注的点，也不具有可操作性。

　　解决怎么做，做得怎样的问题则需要技术经理去控制，而且在控制过程中还需要注意方式方法。例如，开发过程中要求规范编码，包括规范编码风格、采取统一的变量命名方式、必要的注释、抽取公用函数解决重用问题、代码不合理情况下进行重构、设计不足情况下优化设计等等。而这些往往就是QA们难以做到，也非QA人员能力范围之内，即使做了也难以控制好的，这就需要技术经理们的去进行管理、同时灵活把握方式方法。就像王传福所说技术人员往往不善于交际、脾气怪一样，程序员们大部分也都这样，容不得其他人指手画脚，技术经理们当面去指出程序员那里代码写得有问题，很多时候会引来反感。一个相对好操作的方法是：由技术经理或者高级程序员，定期不定期，举行代码分析会，从现有程序中抽取带有典型问题的代码，逐一分析，逐步灌输编码的规则、理念，讲述过程中对事不对人。讲得次数多了，等大家基本接受这些规则、理念之后，再进行定期的代码检查。如此开展起来，水到渠成，不会有大多的阻力。

　　当然，也有过程关注如何编写程序、如何进行测试，比如说敏捷开发中的极限编程。在大部分的敏捷开发过程中，并未涉及到QA人员，那么这其中的细节控制定然是需要技术经理们去执行的。

　　其次，QA也好，QC也好，是基于单一产品或者项目为对象进行的，而现实是一个研发中心往往有很多产品线，那么多个产品线之间关系，是 QA/QC们无法关注到的。在宏观问题上，产品线之间的关系、交换，公用模块的抽取，研发路径、实现技术手段的选择等等，这些都质量管理着、业务经理们 (产品规划)能力范畴之外。这部分工作很重要，对产品质量有着重大的影响力，很多有钱的公司，往往请外部的咨询公司来进行规划。比如，浙江移动07年请埃森哲公司进行咨询，花了近200万得到了一份规划报告。不是每个公司都能出得起、会去花这个钱的，那么这就需要技术经理们进行统一的技术分析、技术规划，形成一个蓝图，指引具体产品的工作开展。

　　质量管理是一个涉及到整个研发过程的需要全体人员参与的一项活动，需要质量部门QA、QC人员的努力，还需要需求、设计、开发环节中的技术经理们承担起质量控制的职责，并把质量控制的理念深入灌输到每个员工的思想中，不断改进过程、方法，这样才能有效的推进质量管理工作，才能建立起高效的质量管理体系。

>> 返回目录

研发部ISO9001质量管理体系审核时应注意哪些方面？

　　1、针对软件产品和机电产品其产品实现过程是如何策划的，策划的结果是什么;

　　2、是否针对特殊项目编制了质量计划;

　　3、质量计划的实施和检查情况如何;

　　4、软件产品开发过程中的文档是否符合本公司规范及ISO9001质量管理体系标准相关条款的要求，是否经过批准。

　　5、软件产品是否按要求进行了评审，评审记录及其后所采取措施的记录是否符合要求;

　　6、测试计划、测试用例、测试报告是否齐全并经过批准，测试用例是否满足要求，测试中发现的问题是否纠正并重新测试，记录是否保持;

　　7、软件产品的变更是否按规范进行并保留了相关的记录;

　　8、软件产品的外部测试及记录情况是否符合要求;

　　9、软件的配置管理情况;

　　10、软件产品的安全防护情况;

　　11、测试软件的确认情况;

　　12、软件产品不合格的记录及处理情况;

　　13、机电产品设计过程中记录和技术文件是否齐全;

　　14、机电产品生产和检验过程中的记录是否齐备;

　　15、机电产品不合格品的处理情况。

　　参照ISO9001：2008的7.3条款：

　　设计和开发7.3设计和开发

　　7.3.1设计和开发策划

　　组织应对产品的设计和开发进行策划和控制。

　　在进行设计和开发策划时，组织应确定：

　　a)设计和开发阶段;

　　b)适合于每个设计和开发阶段的评审、验证和确认活动;

　　c)设计和开发的职责和权限。

　　组织应对参与设计和开发的不同小组之间的接口进行管理，以确保有效的沟通，并明确职责分工。

　　随设计和开发的进展，在适当时，策划的输出应予以更新。

　　注：设计开发的评审、验证和确认的目的有区别，可以视产品和组织的方式分别或结合实施和记录。

　　7.3.2 设计和开发输入

　　应确定与产品要求有关的输入，并保持记录(见4.2.4)。

　　这些输入包括：

　　a)功能和性能要求;

　　b)适用的法律法规要求;

　　c)适用时，以前类似设计提供的信息;

　　d)设计和开发所必须的其他要求。

　　应对这些输入进行评审，以确保其充分性与适宜性。要求应完整、清楚，并且不能自相矛盾。

　　7.3.3设计和开发输出

　　设计和开发的输出应以能够针对设计和开发的输入进行验证的方式提出，并应在放行前得到批准。

　　设计和开发输出应：

　　a)满足设计和开发输入的要求;

　　b)给出采购、生产和服务提供的适当信息;

　　c)包含和引用产品接收准则;

　　d)规定对产品的安全和正常使用所必需的产品特性。

　　7.3.4设计和开发评审

　　在适宜的阶段，应依据所策划的安排(见7.3.1)对设计和开发进行系统的评审，以便：

　　a)评价设计和开发的结果满足要求的能力;

　　b)识别任何问题并提出必要的措施。

　　评审的参加者应包括与所评审的设计和开发阶段有关的职能的代表。评审结果及任何必要措施的记录应予以保持(见4.2.4)。

　　7.3.5设计和开发验证

　　为确保设计和开发输出满足输入的要求，应依据所策划的安排(见7.3.1)对设计和开发进行验证。

　　验证结果及任何必要措施的记录应予以保持(见4.2.4)。

　　7.3.6设计和开发确认

　　为确保产品能够满足规定的或已知预期使用或应用的要求，应依据所策划的安排(见7.3.1)对设计和开发进行确认。只要可行，确认应在产品交付或实施之前完成。确认结果及任何必要措施的记录应予以保存(见4.2.4)。

　　 7.3.7设计和开发更改的控制

　　 应识别设计和开发的更改，并保持记录。在适当时，应对设计和开发的更改进行评审、验证和确认，并在实施前得到批准。设计和开发更改的评审应包括评价更改对产品组成部分和已交付产品的影响。

　　 更改的评审结果及任何必要措施的记录应予以保持(见4.2.4)。

>> 返回目录

什么是产品质量？

　　质量两个字已经是老掉牙的名词了，还没有发明货币之前以物易物的交易，我们的老祖宗就知道看货色了，货色就是我们通常讲的产品质量，企业要赚钱，货好才是硬道理，货不好，卖得再起劲，那叫骗人，货好，卖不出去，那是笨蛋。产品质量是一切硬道理之上的硬道理。

>> 返回目录

如何理解质量管理的三个阶段？

　　几乎所有的企业在产品的质量上都会下一番功夫，书上说那叫质量管理，根据一个叫朱兰的质量管理大师的说法，质量管理有三个阶段，最初是质量检验阶段，那个时候企业的管理者认为产品质量是检验出来的，因为通过检验可以把质量不好的产品挑出来，后来发现只是在事后来检验，故事都发生了，返修、报废的损失无法避免，这些损失就是利润呀，所以就思考能不能在制造过程中控制质量呢?这就到了质量管理的第二阶段：统计质量管理阶段。在这个阶段，著名的新老七大质量管理工具闪亮登场，统计学在质量管理方面的应用得到了充分的发挥，我们在质量改进方面拍脑袋也变得越来越科学，越来越尊重数据了。再到后来，人们发现单纯在制造过程中控制质量也控制不住，而且成本也不低，一些产品缺陷是先天性的，好多产品从娘胎中出来就躺在了担架上，这个时候，人们意识到产品质量是设计出来的，这就到了质量管理的第三个阶段：全面质量管理阶段。这时，6SIGMA、QFD等质量管理工具开始被一些企业应用到产品规划和产品设计中，从一开始就进行质量的设计，这些企业属于先知先觉。

>> 返回目录

企业研发质量管理现状

　　不过，从我们咨询长期与企业接触的情况来看，先知先觉的企业实在太少了，大部份企业的产品质量控制重点还是在制造过程，不是说这些企业不想在源头(产品设计)来控制产品质量，实在是不知道如何在设计中构建产品质量，有些企业是被客户逼到去做研发质量控制，比如有些企业要想成为某大客户的供应商，客户就要对企业进行认证，第一轮认证下来，问题列了一大串不说，还被客户画了一个像，类似于“公司不具成长性”、“过程不可控制”、“质量不可追溯”、“质量管理只是形式而没有实际效果”等等。这时，企业老总以及各级管理者都犯迷糊了，你说我们ISO9000早就通过认证了，年年内审、三年一度的外审也没问题，公司还有专门的质量管理部门、ISO9000办、研发管理办都在抓质量，质量就象阶段斗争一样年年讲月月讲天天讲，怎么就不灵呢?客户审出的这些问题难道我们自己审查不出来?还是我们对这些问题都习惯了而不当成问题了，所谓久居鲍鱼之室而不闻其臭?还是我们这些年的质量管理都象中国足球一样的假(甲)A?

　　面对企业的这些困惑，我们来剖析一下企业在研发质量管理方面存在的一些误区，能被大家有所借鉴就满足了。

>> 返回目录

搞好研发质量管理的前提条件是什么？

　　首先，研发质量管理的基本前提是研发的业务流程要理清楚。很多企业的研发管理者说，我们搞产品开发这么多年了，流程肯定是有的，要不然怎么做得出产品呢?然而，大多数企业的产品开发流程可操作性不强，基本上是按ISO9000的要求设计的，一般是4到7页纸，产品开发流程独孤一剑(只有一个层次)，有少量的模板或检查表，企业经常是写流程的人不执行流程，执行流程的人不写流程，开发流程是ISO9000办或质量部或研发管理办为开发人员写的，而开发人员觉得这个流程只是为了应付ISO的要求，缺乏可操作性，实际工作中就不按照流程操作，在大多数开发人员眼里按流程操作是做不出产品来的，还不如自己的经验来得实在。企业对流程的管理也存在两个极端，一是流程经常变，使用人员无所适从，二是流程没有责任人，没有人维护，纸上的规定与实际运作相差太远还没有修订，对于一些新的业务，老流程不适合了也没有人改，业务部门等不及了就自己搞一套，另立山头，也不管是否符合公司的体系，直接挑战公司的权威部门(通常是9000办)，权威部门没有能力也没有精力管，也就作打鸟状--睁只眼闭只眼。这实际上不仅仅是企业才存在这样的问题，我们国家的法制建设尤为典型，法制建设总是滞后于社会新业务的发展，经常以司法解释对付之，实在对应不了就象对付传销一样把它强制毙掉。企业的管理者也如法炮制，上头一压下来就不顾实际的加大打击力度，导致底层人员怨声载道，干群关系极不融洽，到最后干脆溜之大吉—不干了。

>> 返回目录

质量管理部门的定位

　　难道质量管理就是吃力不讨好，专门得罪人的部门?管理者的定位就是服务，毛主席早就说过共产党员就是要全心全意为人民服务，企业的管理者也是一样，研发的质量管理人员要为研发服务，前提是要把研发业务搞清楚，然而通常情况下质量管理人员又搞不清楚具体的研发业务，研发各业务部门才最清楚具体的研发业务，这就要对研发质量的责任部门/责任人进行定位了，事实上研发各业务部门/主管才是研发质量的责任部门/责任人，质量管理部门是质量专业的行业管理者，质量管理部门要为业务部门提供质量管理的各种方法和工具，而真正的质量责任人是谁做事谁负责。这样一来，企业的研发质量管理者就把一大堆质量管理工具、方法向研发人员宣贯、培训，似乎自己完成了自己的使命，但研发人员的质量意识还是没有提高，效果还是不好，大多数企业的研发质量管理部门都是后来发展起来的，原来有一帮人搞制造质量的管理，就让质量管理向上延伸到研发，可惜你让搞制造质量管理的人去管研发质量，就象让卖药的去做广告，什么广告都有一股苏打水的味道。研发业务的多变性、不确定性、创新性本身就充满变数和风险，如果用管制造质量的思路去管研发质量注定要管死，有些聪明的企业就从研发人员中抽调业务骨干来管质量，并树立起质量管理部门的权威性和独立性，所谓独立性就是质量管理部门具有在必要的时候向公司老板直接汇报的通天大道。

>> 返回目录

如何构建研发质量管理体系？

　　怎么样才能构建好研发的质量管理体系呢?首先必要把ISO9000的质量管理程序层层落实到研发的各种业务流程中，要构建一套优秀的产品开发流程并不容易，优秀的产品开发流程具有如下6大特征：

　　>>清晰的层次结构―――可管理

　　>>明确的阶段划分―――可控制

　　>>明确的阶段交付―――可衡量

　　>>统一的术语定义―――易沟通

　　>>明确的角色职责―――易分工

　　>>明确的绩效指标―――易评价

　　只有当研发流程变得很优秀的时候，我们的研发质量才有管理的基础，还要把研发质量管理的活动：质量策划、质量控制、质量保证、质量改进融入到具体的产品开发活动中，否则质量就会变成质量部的事，而质量部又负不起这个责任。比如，设计评审是质量控制常见的措施之一，而企业在设计评审中存在的典型现象就是：评审抓壮丁、先开科普会、再开批斗会。评审会经常找不到人参加，只好抓壮丁，抓一个算一个，但经常是能做主的抓不住，来的人又做不了主;评审会上才看评审材料，试想，开发人员几个月呕心沥血搞出来的东西，评审会上只分钟就能看明白?所以项目经理一上来要先给大家来一场科普，与会人员才搞的明白(也不一定能搞明白)，搞明白了当然就可以批斗了，这样的评审对项目组来讲苦不堪言，长此以往，项目组就会千方百计的逃避评审，或者应付评审，项目偷跑是经常的事。

　　是不是流程体系、质量体系构建好了，产品质量就一定会好呢?不一定。流程、制度都是纸上的东西，最终需要人来操作，人的业务技能、职业素养是保证产品质量的另一重要因素，当然这不是今天要谈的主题。很多企业在推行质量管理感到困难重重，常用的一招就是加大考核力度，为此设计了相应的KPI(关键绩效指标)，期望通过考核的牵引来保证推行的力度，我们曾遇到一集团公司的考核管理，集团公司有很多职能部门分管各事业部，分管部门为了工作好推动，都制定了相应的KPI来考核事业部，而事业部为了完成任务又会把指标分解下去，这样层层分解的指标最终会落到干活的部门， 有一事业部下面的业务部门KPI达70多项，问部门经理如何完成这70多项的KPI任务?答日“顺其自然”，因为这么多东西不可控就不用控，就象现在的小孩又要读书，还要补习班、提高班、兴趣班、奥数班一样，到头来干脆离家出走，自个儿玩去!

>> 返回目录