研发管理体系Word文档格式.docx

研发管理体系Word文档格式.docx

《研发管理体系Word文档格式.docx》由会员分享，可在线阅读，更多相关《研发管理体系Word文档格式.docx（11页珍藏版）》请在冰豆网上搜索。

卓越的研发团队由以下三个因素决定：

团队中的个人、团队机制和团队文化

1.3.研发流程设计

　　研发优势的唯一可持续源泉是卓越的研发管理流程。

以某项卓越设计、天赐良机、对手的某个失策或某一次幸运为基础的优势是不可能长久的。

而优越的研发流程则始终能够发现最佳的机遇，推出有竞争力的产品和服务，并以最快的速度把这些研发成果投入市场。

　　研发流程改进也是个持续的过程，需要不断的持续改进研发流程。

研发流程管控保证研发流程设计与改进的持续性、规范化、程序化。

1.4.研发成本管理

　　随着微利时代的来临，企业要从各个方面节约成本，包括研发成本也要控制。

研发成本控制并非指压缩研发规模或者减少研发投资，而是指减少研发中不必要的开支，用较少的投入获取较大的研发成果。

研发成本管理要和研发成果收益结合起来。

产品在其生命周期的不同阶段，所能获取的利益不同，研发要在产品的不同生命周期有不同的投入，比如在新产品开发的时候研发投入较大，但是研发收益几乎没有，一旦新产品开发出来，收到市场的欢迎，则要加大研发投入，改进产品性能。

到产品的成熟期，市场竞争激烈，产品改进研发投入要收缩，直至完全取消。

1.5.研发项目管理

　　研发属于动态作业，整个流程可能横跨所有部门，故研发是以项目为导向的，研发管理中项目管理不可或缺。

1.6.研发绩效管理

　　研发管理的绩效管理能够有效的激励研发团队积极工作，促成研发成果。

研发管理的绩效评价指标有如下几个方面：

研发项目的难度、研发效率和研发质量。

研发绩效管理应该考虑企业的整体战略，应用平衡记分卡等工具制定研发绩效评估系统。

1.7.研发风险管理

　　研发人员可能被竞争对手挖角，对外泄密或者恶意破坏。

研发信息风险指研发信息可能被研发人员泄密或者破坏，也可能因为遭受灾难、意外事件或者别人的攻击导致风险。

研发成果风险指研发出来的产品或者服务可能是过时的或者是不受欢迎的，或者研发的投入太大引至企业经营风险，或者研发的投入大于研发产生的效益。

研发风险管理则是以风险为主要的控制目标，制定一系列规章制度有效将风险降低到可接受水准以下，否则就必须增加控制措施。

四.产品研发原则

1.8.相信原则

　　相信规范；

　　相信工具；

　　相信经验；

　　相信上层。

1.9.不相信原则

　　对自己完成任务的正确性和完整性不相信；

　　对下层完成任务的正确性和完整性不相信；

　　对已验证过的任务进行综合的正确性和完整性不相信；

　　对已验证过综合的系统适应性正确性和完整性不相信。

五.纵横分工原则

1.10.横向分工

　　按专业分工划分。

如：

通信、软件、硬件、结构、电源等。

1.11.纵向分工

　　按层次划分。

　　系统设计、开发与调试，生产加工、测试与验证

　　信息文档化原则

　　信息规范化；

　　流程阶段化；

　　传递文档化；

　　文档模板化。

六.产品研发需求分析过程

设计过程是在项目启动的条件下，根据需求分析的要素定义，旨在建立一套规范的研发设计流程，明确专业技术分工，确定设计考虑的范围和要素，消除研发状态混淆不清、研发问题隐藏和向后传递等问题。

在设计过程主要进行以下过程设计：

　　系统设计规范；

　　系统需求设计；

　　硬件设计需求；

　　软件设计需求；

　　系统可靠性设计；

　　硬件测试性要求；

　　软件测试性要求；

　　硬件系统逻辑顶层设计；

　　软件顶层设计（概要设计）；

　　硬件逻辑详细设计；

　　软件详细设计与编码；

　　硬件测试环境设计；

　　软件测试平台设计。

七.仿真验证过程

仿真验证过程设在设计过程完成的基础上，为了充分保证设计的正确性，提高设计质量，消除后续工程实施的不确定性，并验证工程余量的要求，必须对新产品的关键技术进行仿真验证，以确保新产品的关键技术的工程可行性。

在有条件的情况下，要对设计实现的硬件电路进行仿真验证，以保证产品基础运行平台（硬件系统）的稳定型；

还要对软件设计和软硬件综合进行仿真验证，以保证软件实现的正确性和软硬综合的融合性。

八.开发调试过程

由于IT产品设计中蕴藏了大量的设计者对产品功能要求的理解和处理思想，而这些理解与实现有紧紧地依靠设计者个人的知识背景、专业领域和个人能力等方面的限制，因此必然在产品功能的设计实现中，存在大量的错误和不完善的地方。

　　另外，在设计中还采用了大量的设计工具，设计者面对的不是产品，而是面对的由一组工具组成的设计平台，设计者根据工具的功能，发出相应的命令，由工具完成命令的实现。

由于工具实现过程是工具的设计者依据通用情况考虑的，对产品设计者来说是一个"

黑箱"

操作过程，因此必然存在工具设计者的思想与产品设计者思想和理解存在着差异，特别是对产品的一些不太重要的性质或要素尤为突出。

这就是IT行业中经常谈到的工具的副作用。

　　因此，建立产品的开发环境是IT产品研发重要的组成部分。

九.测试验证过程

对于IT产品的研发来说，测试环境具有十分特殊的地位。

从发达国家IT产业的研发来看，产品测试的费用和测试周期占产品研发费用和周期的40%左右，并保持上升的趋势。

由此可见，测试环境对IT产品的研发来讲，具有十分重要的意义。

　　为什么测试环境具有如此重要的地位？

其主要因素是由IT产品自身的特征所决定的。

由于IT产品的功能设计是一种事前决策规则设计，决策人的能力和知识背景、环境要素的变化状态都将影响决策的质量。

那么在环境要素动态组合变化的基础上，如何确认决策的正确性，特别是非正常环境变化的基础上，如何确认决策的安全性，是一项难度很大的任务。

这种确认的技术难度在通常状态下要比决策本身难度大得多。

这就是测试环境具有重要地位，也是IT产品与传统产差异的主要特征之一。

十.产品研发构型划分

产品的构型是产品研发成功的保证。

　　新产品研发过程构型定义是站在工程的角度上，对新产品研制过程里程碑的定义。

1.12.关键技术构型

　　根据"

需求分析"

定义的关键技术，在企业技术储备的基础上，定义该新产品采用的关键技术的构型状态，验证其关键技术的可行性，确定产品的新技术的含量和定位，为后继的构型消除新技术带来的不确定性。

1.13.原理样机构型

　　根据关键技术构型确定的新技术的定位，根据其它成熟技术的配套，定义新产品原理样机的构型状态，验证产品所有功能、新技术与成熟技术融合的可行性，并在满足系统功能的前提下，对软硬件的逻辑进行适应性修正，确定新产品软硬件功能实现的正确性，为后继的构型奠定软硬件功能的基础。

1.14.工程样机构型

　　根据原理样机构型软硬件的功能，根据工程环境的要求（如：

重量、功耗、尺寸、散热、电磁兼容性等），以及和其它设备的铰链关系，定义新产品工程样机的构型状态，完善原理样机构型在应用工程环境中要素要求，验证新产品在应用的（或模拟的）工程环境中的性能指标和实现功能的正确性，为最终形成产品的应用状态-生产样机的构型奠定工程化的基础。

1.15.生产样机构型

　　根据工程样机构型验证的结果，定义新产品生产样机的构型状态，提交给用应用试验环境验证。

从用户使用的角度出发，通过大量的、不同用户的应用试验实例，验证新产品所有功能实现的效果和正确性，并根据其结果形成最终使用结果意见，提交给研发部门。

研发部门根据产品的当前状态，根据企业或行业的生产能力，生成生产流程和相应的生产工艺文件，并确定测试与检验标准，为产品的生产奠定基础。

十一.产品研发验证划分

（1）设计验证环境：

系统功能仿真、硬件设计操作（时序）仿真、软件功能仿真；

（2）开发验证环境：

硬件测试、软件测试、软硬件综合测试；

　　（3）系统验证环境：

与各种环境、各种型号、各种厂家的产品综合试验环境；

　　（4）例行试验环境：

温度、振动、场强、电磁干扰试验等

十二.研发管理方法

研发管理方法，通俗地讲就是：

告诉人们在什么时候做什么事情，而且学会把事情做好。

衡量研发管理优劣的三个关键指标是：

质量、时间和成本。

人们总是希望做得好（即质量高）、做得快（即时间少）而且少化钱（即成本低）。

如果出现三者难以同时兼得的情况，那么决策者一定要搞清楚质量、时间、成本之间的复杂关系，判断孰重孰轻，给出优化和折中的措施。

十三.传统管理方法

1.16."

双岗制"

　　"

是我国许多科研企业针对人员流动造成知识产权流失提出的一种解决方法。

所谓"

是在研发过程的重要位置上设立两个岗，完成同样的工作，互为备份。

"

带来的主要问题是：

　　第一，由于重要的岗位用两套人马使用两套设备完成同样的工作，造成人力资源和设备资源浪费；

　　第二，如果两套人马完成的结果不一致，造成确认成本的增加；

　　第三，由于研发过程有许多环节，如开发过程：

设计、仿真、调试、测试；

研制阶段：

原理件、工程件、工艺件、试验件、试用初件等，如果两套人马生成的两套版本都要通过验证过程的所有环节，将大大的增加研制成本、研制周期和造成资源的浪费。

　　由于在每个"

研制成本和研制周期几乎翻一番，这样，如果在该产品研制过程中有多个"

位置，整个研制成本和研制周期将会形成爆炸性组合增加。

1.17."

重要的部分由多个人分解承担"

，这是我国许多科研企业针对人员流动造成知识产权流失提出的另一种解决方法。

是研发过程中将重要的部分和环节进行任务分解，由多个人共同承担和协作完成。

　　第一，如果将重要的部分和环节进行任务分解，将增加系统内部通信开销和协作成本；

　　第二，如果采用重要的工作由重要的人承担的原则，如果重要的人员不再承担其它重要的工作，将造成人力资源的浪费；

如果重要的人员还承担其它重要的工作，如果一旦人员流动，将会造成多个重要任务的知识产权流失，涉及和影响的面会更大；

　　第三，由于研发过程环节很多，重要任务的分解和多个人员的参与将会大大增加研发成本和研制周期。

1.18."

记者式"

的研发方法

　　接受主题:

根据上级领导的要求立项和接受项目

　　采访素材:

自行搜寻和定义市场需求

　　自行归纳:

自行归纳核定系统功能需求

　　自由发挥:

独立自由完成功能的实现

　　自己定稿:

自行定义测试和验收的标准

研发管理方法主要问题是：

第一，以个人为主体，从接收任务（接受主题）、搜集需求（采访素材）、定义功能（自行归纳）、独立研究（自由发挥）、自行测试（自己定稿）到任务交付，整个研发过程都由个人控制完成，从而受到了个人认知能力的限制。

特别在当今知识经济社会中，知识爆炸、专业分工与综合技术是知识经济的主要特征，因此，个人认知能力远远不能满足社会的需求；

　　第二，由于个人专业分工的限制，"

研发管理方法往往只突出了个人的专业领域的应用，而忽视了其它专业领域的有效介入；

例如：

硬件工程师只突出了硬件设计的有效性，忽视了系统设计、仿真分析、软件设计、硬件测试、软件测试、系统综合等专业应用发挥；

　　第三，自行定义测试和验收标准属于自己立法，自己执法，与研发产品质量控制和最终确认的基本原则相违背。

　　第四，"

研发管理方法将导致知识产权落入个人控制之中。

1.19."

逐级下达式"

研发管理方法

　　主题选择决策：

上级领导

　　系统功能确定：

由承担任务书个人的能力和理解力确定

　　研制状态控制：

项目组各自为政

　　结果测试确认：

自定义测试与验收标准

研发管理方法主要问题是

　　第一，以责任传递为研发控制流程的主线，以任务书为研发任务完成的目标，忽略了研发过程和研制状态节点的控制与检验；

　　第二，责任书和任务书难以全面反映市场需求和产品功能定义，把市场需求和产品功能定义交给任务组来完成，从而受到任务组认知能力的限制，难以体现多专业系统综合和企业整体水平的有效发挥，造成产品研制目标与市场需求脱钩；

　　第三，各任务组以任务书为研发任务完成目标，以责任书为交付状态，各自为政，造成各任务组之间技术协调和系统综合难度增大，难以有效实现系统总体目标；

　　第四，各任务组根据责任书和任务书自行定义自己承担任务的测试和验收标准，从而不仅造成了自己立法，自己执法状态，违背了研发产品质量控制和最终确认的基本原则，而且由于各任务组承担任务的角度和认知能力的不同，各自定义的测试和验收标准难以统一合并形成系统统一的测试和验收标准。

1.20."

小炉匠式"

研发方法

　　自我中心：

以自我为中心，不愿易与别人合作

　　自我封闭：

以自身技术能力为项目全技术状态

　　自我开发：

自我封闭开发，不愿意让别人了解和提建议

　　第一，容易产生以个人为中心，个人的认知能力决定了项目的技术状态；

　　第二，自我封闭开发，不愿意采用自己认知能力之外的成熟技术和新技术，一切从底层开始，低水平重复；

　　第三，缺乏规范设计，增大了产品技术实现的模糊性，难以实现产品的维护和升级；

　　第四，知识产权掌握在个人手中，容易造成知识产权流失。

十四.常见的研发管理方法

1.21.PACE法

　　早在1986年，美国PRTM公司创作了PACE（ProductAndCycle-timeExcellence，产品及周期优化法）方法论。

PACE关注的要素有：

正确决策、项目小组构成、开发活动的结构、开发工具与技术、产品战略、技术管理、资源管理。

PACE算得上是产品生命周期管理领域的方法论鼻祖。

PACE诞生之后，很多企业和学术机构不断地提出了适合于本行业的研发管理方法论。

1.22.ISO9000族质量体系

　　国际标准化组织（ISO）为了满足国际经济交往中质量保证活动的需要，在总结各国质量保证制度经验的基础上，经过近十年的工作，于1987年发布了ISO9000质量管理和质量保证标准系列。

1994年进行了第一次修订，形成了ISO9000族标准。

2000年再进行了重大修订，发布了ISO9000新标准（2000版）。

1.23.CMM/CMMI

　　1986年11月，美国联邦政府委托卡内基梅隆大学（Carnegie-Mellon）软件工程研究所（SEI）开发一套用于评估软件承包商能力的方法。

SEI于1987年9月发布了一套软件过程成熟度框架和一套成熟度问卷。

1991年，SEI将软件过程成熟度框架发展成为软件能力成熟度模型（CapacityMaturityModel，CMM），诞生了CMM1.0。

1.24.PMBOK

　　项目管理知识体系是项目管理专业领域知识的总称，它是20世纪80年代由美国项目管理协会（PMI）总结了项目管理实践中成熟的理论、方法、工具和技术所提出的。

其后经过数次修订，目前最新版是PMBOK2004。

　　PMBOK定义了为44个基本的项目管理过程，从过程输入、输出以及采用的工具和技术的角度给出了项目管理过程的详细描述。

这44个项目管理过程基本覆盖了项目管理实践中的基本管理过程，但是，这些项目管理过程必须和产品实现过程结合起来，才能完成整个项目活动。

1.25.敏捷开发

　　RUP

　　企业在研发管理上经常遇见的问题

　　⑴由于没有目标和方向，缺乏明确的研发战略。

　　⑵研发在公司的定位不清晰，不能有效整合有限的研发资源，也无从发挥研发在企业的价值。

　　⑶研发需求信息的获取较为被动，缺乏对公司内部需求和外部需求的深入调查和分析。

　　⑷形成初步的研发需求清单后，也缺乏相应的机制对其进行甄别和筛选，以形成最终的研发

　　课题。

　　⑸研发工作的组织形式不合理，缺乏整体规划。

　　⑹项目制定中，项目成员没有明确合理的责权利规定，项目的配合和协调工作基本是由研发人员推动的，其他成员和部门只是被动参与。

　　⑺研发基础性总结工作做得很少，知识管理体系不健全，研发和技术的思路及成果系于个人而不是系于公司，破坏了研发的延续性。

　　⑻没有相关的机构和制度来监督和控制项目的运行，项目存在较大的风险，也缺乏项目评审机制对项目进行科学的考核和分析。

　　⑼缺乏研发专业性人才。

　　避免企业在研发管理的五大误区

　　误区之一:

研发管理是研发部门的事情。

　　误区之二:

研发管理改革应立竿见影

　　误区之三:

IPD是研发管理的唯一选择

　　误区之四:

IPD是CMMI的组成部分

　　误区之五:

中小企业不需要研发管理。