研发管理

该条目对应的页面分类是研发管理。

研发管理(Research and Development Management，简称R&D Management)

　　研发管理就是在研发体系结构设计的基础之上，借助信息平台对研发进行的团队建设、流程设计、绩效管理、风险管理、成本管理、项目管理和知识管理等活动。

　　研发管理首先要确定研发体系结构，然后按照体系结构组建高水平研发团队，设计合理高效的研发流程，借助合适的研发信息平台支持研发团队高效工作，用绩效管理调动研发团队的积极性，用风险管理控制研发风险，用成本管理使研发在成本预算范围内完成研发工作，用项目管理确保研发项目的顺利进行，而知识管理让研发团队的智慧联网和知识沉淀。

　　研发体系设计

　　在具体的研发模式上，通常有以下三种，通常有以下三种：

　　研发团队建设

　　研发是一项创造型的工作，卓有成效的研发需要优秀的研发团队来完成，可以说"有什么样的研发团队就有什么样的研发成果"。卓越的研发团队由以下三个因素决定：团队中的个人、团队机制和团队文化

　　研发流程设计

　　研发优势的唯一可持续源泉是卓越的研发管理流程。以某项卓越设计、天赐良机、对手的某个失策或某一次幸运为基础的优势是不可能长久的。而优越的研发流程则始终能够发现最佳的机遇，推出有竞争力的产品和服务，并以最快的速度把这些研发成果投入市场。

　　研发流程改进也是个持续的过程，需要不断的持续改进研发流程。研发流程管控保证研发流程设计与改进的持续性、规范化、程序化。

　　研发成本管理

　　随着微利时代的来临，企业要从各个方面节约成本，包括研发成本也要控制。研发成本控制并非指压缩研发规模或者减少研发投资，而是指减少研发中不必要的开 支，用较少的投入获取较大的研发成果。研发成本管理要和研发成果收益结合起来。产品在其生命周期的不同阶段，所能获取的利益不同，研发要在产品的不同生命 周期有不同的投入，比如在新产品开发的时候研发投入较大，但是研发收益几乎没有，一旦新产品开发出来，收到市场的欢迎，则要加大研发投入，改进产品性能。 到产品的成熟期，市场竞争激烈，产品改进研发投入要收缩，直至完全取消。

　　研发项目管理

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

　　研发绩效管理

　　研发管理的绩效管理能够有效的激励研发团队积极工作，促成研发成果。研发管理的绩效评价指标有如下几个方面：研发项目的难度、研发效率和研发质量。研发绩效管理应该考虑企业的整体战略，应用平衡记分卡等工具制定研发绩效评估系统。

　　研发风险管理

　　研发人员可能被竞争对手挖角，对外泄密或者恶意破坏。研发信息风险指研发信息可能被研发人员泄密或者破坏，也可能因为遭受灾难、意外事件或者别人的攻击导 致风险。研发成果风险指研发出来的产品或者服务可能是过时的或者是不受欢迎的，或者研发的投入太大引至企业经营风险，或者研发的投入大于研发产生的效益。 研发风险管理则是以风险为主要的控制目标，制定一系列规章制度有效将风险降低到可接受水准以下，否则就必须增加控制措施。

　　研发管理至少应具备以下三种条件：

　　1、 制造一个鼓励创新、适合研发的环境，必须采取弹性而目标化的管理，不以死板的制度限制员工的创意，必须要求实质的成果。

　　2、 将行销的观念融入研发中：为使有限的资源发挥最大的效益，研发部门亦须有"行销感"，最好是让行销人员参与研发的过程，如此产品才具有市场价值。

　　3、 研发策略的订定与掌握：有了策略方针，才能对手中所掌握的有限资源善加规划、运用，以求在最短的时间内，达到最高效益。

　　研发管理与技术创新的关系

　　在技术创新过程中必须理清技术创新与科研管理的关系。

　　第一，技术创新必须建立在企业现有的现实基础上。由于当前世界的技术进步是建立在不断创新的基础上，对于任何一种新产品来讲都具有许多技术创新点。如何确定新产品的技术创新定位是与企业的现实基础直接相关的，也是该新产品研制成功的关键。

　　第二，科研管理必须严格控制技术创新带来的随意性和不可预见性。由于技 术创新的含义就是在产品研制过程中引入了企业不熟悉或者未掌握的新技术，如何预期新技术带来的效应，严格控制研制过程各个技术状态，把技术创新纳入到规范 化的科研管理流程中去是新产品研制成功的必要保证。

　　第三，技术创新必须建立在规范化科研管理的基础上。由于技术创新需求在产品的生命周期内不断变化和增 加，在科研过程中必须锁定技术创新的变化，使整个研制过程技术状态控制在系统预期设计的状态控制流程中去。

　　研发管理与技术创新考虑的基本要素：

　　a.技术创新主要考虑的几个主要方面： 市场需求、技术储备、人力资源、资金需求、设备状态、研制周期；

　　b. 技术创新状态在系统需求设计时确定；

　　c. 在项目研制过程中要严格控制技术创新, 所有的后续设计与研制必须控制在系统设计的控制流程内；

　　d. 新的技术创新一般按阶段在系统升级产品中或新立项产品中统一解决；

　　e. 确因十分必要, 新的技术创新首先在系统设计师会议上研究, 确定该项目当前研制的技术状态, 确定的各状态回溯节点, 修改系统需求设计, 形成新的项目的所有的研发控制文件,以及新的响应文档。

　　研发管理和面向市场的关系

　　在技术创新过程中必须理清面向市场与规范管理的关系。

　　第一，要面向市场，市场需求是企业新产品的主要来源；

　　第二，在新产品开发前要确定当前市场的需求, 并预测一定量的市场需求的超前发展的余量。

　　第三，在新产品开发过程中, 应冻结市场需求的变化, 所有的开发与研制过程都必须严格控制在系统规范管理的控制流程中。

　　第四，市场新的需求一般在系统升级产品或新立项的产品中考虑。

　　研发管理与面向市场考虑的基本要素：

　　a.市场需求是研发项目的主要来源；

　　b.在系统需求设计时要确定当前市场的需求, 并预测一定量的市场需求的超前发展的余量；

　　c.在系统需求完成后, 冻结市场需求, 所有的后续设计与研制都必须严格控制在系统设计的控制流程中；

　　d.市场新的需求一般在系统升级产品或新立项的产品中考虑。

　　系统最优和局部最优的关系

　　在系统设计时, 综合分析和考虑市场需求、技术储备、资金状态、设备状态、以及研制周期等重要因素，尽可能在当前情况下进行系统综合考虑，尽可能做到系统最优设计。

　　在系统设计时,一般不考虑局部最优。主要原因如下：

　　a.在系统设计阶段, 无法详细考虑局部的实现；

　　b.一旦系统设计完成, 所有的局部实现必须严格在系统设计的控制下, 遵循系统规范和约束条件实现局部设计；

　　c.在系统设计时, 一般都考虑了系统余量, 所以局部最优对整体系统性能影响不大；

　　d.追求局部最优很容易带来系统失控和一些副作用, 将影响系统最佳的实现。

　　（1） 相信原则

• 相信规范；
• 相信工具；
• 相信经验；
• 相信上层。

　　（2）不相信原则

• 对自己完成任务的正确性和完整性不相信；
• 对下层完成任务的正确性和完整性不相信；
• 对已验证过的任务进行综合的正确性和完整性不相信；
• 对已验证过综合的系统适应性正确性和完整性不相信。

　　纵横分工原则

　　（1）横向分工

• 按专业分工划分。如：通信、软件、硬件、结构、电源等。

　　（2）纵向分工

• 按层次划分。
• 系统设计、开发与调试，生产加工、测试与验证

　　信息文档化原则

• 信息规范化；
• 流程阶段化；
• 传递文档化；
• 文档模板化。

　　需求分析过程

　　需求分析过程是在新产品研发启动之前，对新产品研发过程将要涉及到的各种要素进行系统化、定量化的分析，使之后继的研发过程都在预先研发要素设计的控制流程中。在需求分析过程主要进行以下要素分析：

• 市场需求可行性分析；
• 关键技术需求分析；
• 开发环境需求分析；
• 开发成本需求分析；
• 人力资源需求分析；
• 研发进度估算与分析。

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

• 系统设计规范；
• 系统需求设计；
• 硬件设计需求；
• 软件设计需求；
• 系统可靠性设计；
• 硬件测试性要求；
• 软件测试性要求；
• 硬件系统逻辑顶层设计；
• 软件顶层设计（概要设计）；
• 硬件逻辑详细设计；
• 软件详细设计与编码；
• 硬件测试环境设计；
• 软件测试平台设计。

　　仿真验证过程设在设计过程完成的基础上，为了充分保证设计的正确性，提高设计质量，消除后续工程实施的不确定性，并验证工程余量的要求，必须对新产品的关 键技术进行仿真验证，以确保新产品的关键技术的工程可行性。在有条件的情况下，要对设计实现的硬件电路进行仿真验证，以保证产品基础运行平台（硬件系统） 的稳定型；还要对软件设计和软硬件综合进行仿真验证，以保证软件实现的正确性和软硬综合的融合性。

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

　　另外，在设计中还采用了大量的设计工具， 设计者面对的不是产品，而是面对的由一组工具组成的设计平台，设计者根据工具的功能，发出相应的命令，由工具完成 命令的实现。由于工具实现过程是工具的设计者依据通用情况考虑的，对产品设计者来说是一个"黑箱" 操作过程，因此必然存在工具设计者的思想与产品设计者 思想和理解存在着差异，特别是对产品的一些不太重要的性质或要素尤为突出。这就是IT行业中经常谈到的工具的副作用。

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

　　对于IT产品的研发来说，测试环境具有十分特殊的地位。从发达国家IT产业的研发来看，产品测试的费用和测试周期占产品研发费用和周期的40%左右，并保持上升的趋势。由此可见，测试环境对IT产品的研发来讲，具有十分重要的意义。

　　为什么测试环境具有如此重要的地位？其主要因素是由IT产品自身的特征所决定的。由于IT产品的功能设计是一种事前决策规则设计，决策人的能力和知识背 景、环境要素的变化状态都将影响决策的质量。那么在环境要素动态组合变化的基础上，如何确认决策的正确性，特别是非正常环境变化的基础上，如何确认决策的 安全性，是一项难度很大的任务。这种确认的技术难度在通常状态下要比决策本身难度大得多。这就是测试环境具有重要地位，也是IT产品与传统产差异的主要特 征之一。

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

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

　　关键技术构型

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

　　原理样机构型

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

　　工程样机构型

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

　　生产样机构型

　　根据工程样机构型验证的结果，定义新产品 生产样机的构型状态，提交给用应用试验环境验证。从用户使用的角度出发，通过大量的、不同用户的应用试验实例，验证新产品所有功能实现的效果和正确性，并 根据其结果形成最终使用结果意见，提交给研发部门。研发部门根据产品的当前状态，根据企业或行业的生产能力，生成生产流程和相应的生产工艺文件，并确定测 试与检验标准，为产品的生产奠定基础。

　　（1）设计验证环境：系统功能仿真、 硬件设计操作（时序）仿真、软件功能仿真；

　　（2）开发验证环境：硬件测试、软件测试、软硬件综合测试；

　　（3）系统验证环境：与各种环境、各种型号、各种厂家的产品综合试验环境；

　　（4） 例行试验环境：温度、振动、场强、电磁干扰试验等。

　　研发管理方法，通俗地讲就是：告诉人们在什么时候做什么事情，而且学会把事情做好。衡量研发管理优劣的三个关键指标是：质量、时间和成本。人们总是希望做 得好（即质量高）、做得快（即时间少）而且少化钱（即成本低）。如果出现三者难以同时兼得的情况，那么决策者一定要搞清楚质量、时间、成本之间的复杂关 系，判断孰重孰轻，给出优化和折中的措施。

　　1 "双岗制"

　　"双岗制"是我国许多科研企业针对人员流动造成知识产权流失提出的一种解决方法。所谓"双岗制"是在研发过程的重要位置上设立两个岗，完成同样的工作，互为备份。"双岗制"带来的主要问题是：

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

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

　　第三，由于研发过程有许多环节，如开发过程：设计、仿真、调试、测试；研制阶段：原理件、工程件、工艺件、试验件、试用初件等，如果两套人马生成的两套版本都要通过验证过程的所有环节，将大大的增加研制成本、研制周期和造成资源的浪费。

　　由于在每个"双岗制"研制成本和研制周期几乎翻一番，这样，如果在该产品研制过程中有多个"双岗制"位置，整个研制成本和研制周期将会形成爆炸性组合增加。

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

　　"重要的部分由多个人分解承担"，这是我国许多科研企业针对人员流动造成知识产权流失提出的另一种解决方法。所谓"重要的部分由多个人分解承担" 是研发过程中将重要的部分和环节进行任务分解，由多个人共同承担和协作完成。"重要的部分由多个人分解承?quot;带来的主要问题是：

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

　　第二，如果采用重要的工作由重要的人承担的原则，如果重要的人员不再承担其它重要的工作，将造成人力资源的浪费；如果重要的人员还承担其它 重要的工作，如果一旦人员流动，将会造成多个重要任务的知识产权流失，涉及和影响的面会更大；

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

　　3 "记者式"的研发方法

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

　　采访素材: 自行搜寻和定义市场需求

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

　　自由发挥: 独立自由完成功能的实现

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

　　"记者式"研发管理方法主要问题是：第一，以个人为主体，从接收任务（接受主题）、搜集需求（采访素材）、定义功能（自行归纳）、独立研究（自由 发挥）、自行测试（自己定稿）到任务交付，整个研发过程都由个人控制完成，从而受到了个人认知能力的限制。特别在当今知识经济社会中，知识爆炸、专业分工 与综合技术是知识经济的主要特征，因此，个人认知能力远远不能满足社会的需求；

　　第二，由于个人专业分工的限制，"记者式"研发管理方法往往只突出了个人的专业领域的应用，而忽视了其它专业领域的有效介入；例如：硬件工程师只突出了硬件设计的有效性，忽视了系统设计、仿真分析、软件设计、硬件测试、软件测试、系统综合等专业应用发挥；

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

　　第四，"记者式"研发管理方法将导致知识产权落入个人控制之中。

　　4 "逐级下达式"研发管理方法

　　主题选择决策： 上级领导

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

　　研制状态控制： 项目组各自为政

　　结果测试确认： 自定义测试与验收标准

　　"逐级下达式"研发管理方法主要问题是

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

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

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

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

　　5 "小炉匠式"研发方法

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

　　自我封闭：以自身技术能力为项目全技术状态

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

　　"小炉匠式"研发管理方法主要问题是：

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

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

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

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

　　PACE法

　　早在1986年，美国PRTM公司创作了PACE（Product And Cycle-time Excellence，产品及周期优化法）方法论。 PACE关注的要素有：正确决策、项目小组构成、开发活动的结构、开发工具与技术、产品战略、技术管理、资源管理。PACE算得上是产品生命周期管理领域 的方法论鼻祖。PACE诞生之后，很多企业和学术机构不断地提出了适合于本行业的研发管理方法论，

　　ISO9000族质量体系

　　国际标准化组织（ISO）为了满足国际经济交往中质量保证活动的需要，在总结各国质量保证制度经验的基础上，经过近十年的工作，于1987年发布了 ISO 9000质量管理和质量保证标准系列。1994年进行了第一次修订，形成了ISO 9000族标准。2000年再进行了重大修订，发布了 ISO 9000新标准（2000版）。

　　CMM/CMMI

　　1986年11月，美国联邦政府委托卡内基梅隆大学（Carnegie-Mellon）软件工程研究所（SEI）开发一套用于评估软件承包商能力的方法。 SEI于1987年9月发布了一套软件过程成熟度框架和一套成熟度问卷。1991年，SEI将软件过程成熟度框架发展成为软件能力成熟度模型 （Capacity Maturity Model，CMM），诞生了CMM 1.0。

　　PMBOK

　　项目管理知识体系是项目管理专业领域知识的总称，它是20世纪80年代由美国项目管理协会（PMI）总结了项目管理实践中成熟的理论、方法、工具和技术所提出的。PMBOK还在不断更新和完善当中，目前最新版是PMBOK2012。

　　PMBOK定义了为44个基本的项目管理过程，从过程输入、输出以及采用的工具和技术的角度给出了项目管理过程的详细描述。这44个项目管理过程基本覆盖了项目管理实践中的基本管理过程，但是，这些项目管理过程必须和产品实现过程结合起来，才能完成整个项目活动。

　　敏捷开发

　　RUP