一种基于服务协作模式的研发管理方法和系统与流程

本发明涉及研发管理领域，具体而言涉及一种通过构造研发管理服务组件和通过服务协作的方式进行研发管理的方法和系统。

背景技术：

研发管理，简单来说，是指对研发部门及其工作进行管理。在IT 产品研发行业中，其范围可能涵盖软件产品创意的产生、软件产品需求、软件产品设计、软件产品开发、软件产品测试、软件产品发布等整个过程；从研发管理角度来说，会基于该软件产品研发的商业目标或产品规划的目标，并围绕软件产品研发的过程符合性、交付范围、交付时间、交付质量、技术评审、版本发布等维度，进行过程审计、需求管理、计划管理、缺陷管理、配置管理、评审管理等研发管理活动，其范围涵盖研发质量管理、研发项目管理等。研发管理的目标是职责明确、管理规范、过程有效，方针是优质的产品、满意的服务。

而研发项目本身的复杂性，外在市场环境的快速变化，研发团队能力的差异等，加上研发项目数量的不断增加，研发方法和技术的不断变化，领导决策的不同需求等因素，必然要求研发管理的高效性、规范性，也必然导致研发管理的复杂性，研发管理的范围和深度是不断变化和拓展的，研发管理体系的建设也是要不断应需而动的。

在行业内，一种模式是每个研发项目设置自己的研发管理人员开展研发管理活动，这种模式的缺陷是研发项目组各自为政，自定义研发管理标准和规范，当我们跳出研发项目组在更高层面审视研发状态时，会发现全局视线上的数据是孤立且数据的规范性欠缺，由此可用性较差。尤其是当企业在进行研发管理体系建设时，这种模式管理成本高、管理的规范性欠缺、管理效率较低等弊端就展现的更加明显，企业研发体系在从不规范走向规范的过程中，必然需要总体规划、基于企业发展阶段、夯实基础建设工作，才能为企业在多变的市场环境中持续成长提供基础保障，既解决短期面临的问题，也为企业未来更上一层楼奠定良好基础。

一种模式是在所有研发团队之上设置研发管理机构，将机构的人员分配至项目按CMMI和PMBOK等管理规范进行全周期的研发管理，这种模式可以一定程度提升管理的规范性，但一方面管理与研发的紧密度有所欠缺、研发与管理存在抵触，另一方面面对研发管理的复杂性，对研发管理人员全面的研发管理能力也有很高的要求，对其依赖程度同样也就较高，而面对人员流动的行业事实，这是需要尽量规避的。同时面对研发内外的复杂和多变，如何使研发管理能够体现高效性以及快速响应、拥抱变化，如何变化和拓展研发管理的范围和深度，以适应新的研发模式和需求，是上述模式所欠缺的。

而在文章《基于项目管理的软件产品研发管理研究》（胡红艳、刘咏梅-《企业技术开发》-2006）中，也指出，几种常见的软件产品研发管理模式一般是基于如下几种体系与方法而建立起来的，ISO9000质量标准对高技术性的软件研发企业的帮助不大，它适用面广但专业性弱，也不符合软件产品的特性，所以它的指导价值不高，CMM对软件过程改进有很多有益的指导，但它对企业如何进行软件过程改进没有强制要求，对开发工作的直接指导性较弱，而且CMM投入很大。而文章中同时指出的IPD和RUP模式，更是软件开发模式，不在本专利讨论之列。文章提出了基于项目管理的研发管理模式，将软件产品研发项目生命周期分为几个阶段，并分析了各阶段所应注意的具体关键问题。文章的关注点是这几个阶段中一些项目管理中具体的问题，给出得方案也是针对每一个具体问题。而对于如何建立规范高效的研发管理体系，如何应对复杂多变的研发管理需求等是欠缺的。

而在公开的专利申请“精益研发系统和精益研发方法”（申请号CN200810085059.X）中，它解决的技术问题是“把研发活动中存在的创新、仿真、试验、各个孤岛集成起来，通过精益研发平台让他们形成有机的一体，针对企业各类人员所关心的各类问题，形成各自的看板(质量看板、成本看板、进度看板、资源看板)，帮助企业实时关注企业研发的动态，便于管理、调整、控制。” 精益研发是一种以精益为目标的研发方法，它集成了技术创新、协同仿真以及立体质量设计三个方面，实现产品质量的提升。它的关注点是，在复杂产品的研发中，如何满足客户最关注的产品的功能和性能指标。而通过精益研发的方法和系统将散落的体现产品的功能和性能指标等各种质量数据进行整合，将复杂产品的研发质量所有技术指标完整展现。而研发管理体系如何建设，面对范围与深度不断变化和拓展的研发管理需求，研发管理如何快速反应、灵活应对、积极改进，是上述专利申请所欠缺的。

技术实现要素：

鉴于上述方法的缺陷，本发明提供一种基于服务协作的研发管理方法和系统。其理念一是在于将所有研发管理活动都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成研发管理业务流程。其目的在于将研发管理的业务能力分解为独立性高、粗粒度和可复用的服务，同时便于对服务进行组装和编排以满足业务和流程的变化需求；其理念二是在于运用服务协作的方式来执行这些研发管理服务，建立管理与研发的紧密耦合关系，提升过程改进的敏捷性。

本专利的目的在于运用基于服务协作的研发管理方法和系统，建立以研发管理部为主导，以研发管理人员队伍为专业支撑，以质量审计为手段，以项目管理水平为检验对象，面向研发、面向决策层、面向体系改进的研发管理体系，满足复杂业务和流程的变化需求，建立管理与研发的紧密耦合关系，提升研发的规范性和质量，提升过程改进的敏捷性。

为实现上述目的，基于服务协作的研发管理方法如图1所示包括以下几个步骤：

1、构建研发管理服务组件，即根据选定的研发体系模型梳理提取研发各阶段涉及的所有活动，并从中抽象出研发各阶段涉及的研发管理活动，根据研发管理规则将这些研发管理活动分类映射形成研发管理服务集合，最后依据具体的项目类型裁剪包装形成服务组件。如图1中S1部分所示；

2、设置研发管理服务协作角色，即建立研发管理服务注册中心，并为研发管理人员设立服务提供者和服务请求者的角色的过程。如图1中S2部分所示；

3、以服务协作方式开展研发管理，即服务提供者发布研发管理服务、提供研发管理服务、改进研发管理服务，服务请求者进行项目跟踪、发起研发管理服务请求、改进研发管理服务的交互协作过程。如图1中S3部分所示；

4、运用研发服务数据，即收集、分析研发和管理过程中的数据，形成项目监控指标并看板展示的过程。如图1中S4部分所示。

其中步骤1还包括如下详细步骤，如图2所示。

1.1依据研发项目间的共有特性选择并构建研发体系模型。

1.2梳理、提取研发体系模型各阶段所有活动。步骤1.2还包括如下步骤：

1.2.1梳理研发体系模型每个阶段所有的活动，并形成流程图；

1.2.2对步骤1.2.1中的流程图，形成活动详情描述；

1.2.3从研发体系模型各阶段的维度，以可视化形式展现如上步骤1.2.1和1.2.2所形成的过程资产；

1.2.4对所有活动进行分类归属形成不同的过程，形成如工程类过程、项目管理类过程、支持类过程等；

1.2.5对步骤1.2.4形成的各过程域，再次进行过程梳理和过程定义；

1.2.6以可视化的形式展现如上步骤1.2.5形成的流程图和过程定义等过程资产。

1.3根据步骤1.2抽象出各阶段所有研发管理活动，并将每个研发管理活动视作一个基本服务，这里每个基本服务的颗粒度的设定灵活自主。

1.4将步骤1.3抽象出的各阶段的研发管理活动，打破阶段的边界，按质量管理和项目管理等规范进行拆分重组，形成新的服务集合，这些服务集合是涵盖研发管理活动全集的服务组合。其中步骤1.4还包括如下步骤：

1.4.1依据质量管理、项目管理规范等制定符合实际的研发管理的过程域，如需求管理、计划跟踪、过程质量审计等；

1.4.2依据研发管理的过程域将步骤3形成的服务组件打破重组，将其中的服务映射到研发管理的过程域，形成新的服务组件；

1.4.3新的研发管理服务组件形成检查表、指南、过程定义等知识文档用以描述具体研发管理活动；

1.4.4通过描述服务的功能和调用时机的方式为服务组件中的服务设置调用接口。目的在于便于后续依研发进程匹配对应的研发管理活动。

1.5依据项目间的差异特性划分项目类型。

1.6将步骤1.4形成的全集的服务组合依据项目类型，裁剪成与项目类型相适应的服务组件。

其中步骤2主要包括如下内容：

建立研发管理服务注册中心、设置服务提供者角色和服务请求者角色。

其中步骤3还包括如下步骤。

3.1研发管理服务组件形成过程产生的研发管理服务组件进入服务注册中心。这里包含研发管理体系建立时形成的服务组件，也包括体系改进时更新的服务组件。

3.2服务提供者执行服务发布操作。

3.3服务请求者对研发项目进行跟踪。

3.4服务请求者向服务注册中心发起服务查找操作，查找此项目类型在现阶段的进程中对应的服务组件。

3.5服务注册中心查询服务是否存在，及服务与查询的一致性。

3.6查询结果返回服务请求者。

3.7服务请求者依据查询结果，做出对应动作。即如果查询结果不符合需求，则提出服务改进，并将改进的服务更新至服务注册中心；如果查询结果符合需求，则发起绑定和调用操作，以便调用服务提供者的服务。

3.8服务提供者提供服务。

3.9服务提供者在实现服务的过程中，当发现服务与实际研发不适应时，提出过程改进，改进服务。

其中步骤4还包括如下步骤：

4.1对研发管理协作服务过程中形成的监控数据进行收集整理，形成多种服务数据。

4.2按不同管理目的和用途，依据设定的监控指标，对服务数据进行抽取，形成不同监控指标数据结果，并以项目看板形式展示。项目看板展示屏用于显示项目指标数据，即展示所有在研项目进度、过程、质量等指标的综合指数并轮播每个项目实施过程中进度、过程、质量等方面的详细状态。

本发明基于上述方法还提出了一种基于服务协作模式的研发管理系统。系统整体功能逻辑如图3所示。其架构分为三层：信息展现层、工具支撑层、基础设施层。

其中信息展现层是指研发管理信息门户，为用户提供交互式操作的界面，是研发管理系统的统一入口，用于显示数据、接受用户输入的数据以及返回数据等。包括开发质量、管理能力、项目结果、服务效果等分析、评价的展现，以及为如下所述工具支撑层的两平台一中心的用户提供交互操作的入口。

工具支撑层主要包括三大逻辑模块，技术支撑平台、项目管理平台、服务注册中心，为研发及管理提供多种支撑工具及支持功能。所述技术支撑平台包括代码检查、版本控制、持续集成、自动化测试，为项目进行研发提供直接的工具支撑，视为研发管理提供的服务内容；所述项目管理平台包括任务下发、问题管理、缺陷跟踪、评审工具，为项目进行研发提供项目管理工具和相关服务；所述服务注册中心包括服务协作角色设置、服务组件维护、服务协作管理等，为开展研发管理提供服务协作的工具支撑。其中所述服务注册中心，一方面用于存储研发管理服务组件信息，每一个研发管理活动都有设定好的对应的项目类型、对应的研发阶段、以及活动描述等；一方面为服务提供者提供发布服务的操作，并为服务请求者提供查询和发起功能以进行服务查找和发起请求操作，同时还提供服务改进功能，即当对研发管理体系进行评估改进以及在研发管理服务协作过程中服务请求者或服务提供者发现并提出过程改进以及跟踪改进过程中，都需要使用过程改进模块，而改进后的服务会由服务提供者发布更新至研发管理注册中心。

基础设施层主要包括有互联网、办公内网和沙箱环境以及服务器和终端等组成的研发网，为研发管理提供网络环境。

本发明提出一种基于服务协作模式的研发管理方法和系统，和现有的方法相比，本发明的技术效果如下。

1.通过将每个研发管理活动视为一个服务并基于研发构建研发管理服务和服务组件：

（1）提高了管理和业务也就是研发管理和研发的耦合关系的紧密性；

（2）提高了研发管理应变的灵活性，面对范围与深度不断变化和拓展的研发管理需求，研发管理可以实现快速反应、灵活应对；

（3）通过将管理人员的知识、经验等以及管理规范等固化到服务组件这一机制建设，尽量减少人员流动因素造成的不利影响，同时也是利用机制更有效于制度的优越性达到知识积累和知识复用的目的。

2.通过建立研发管理服务协作的运作实施模式：

（1）接口人即服务请求者和服务提供者的角色设立及交叉审计同样提高了管理与研发的紧密耦合关系；

（2）提升了质量审计标准的客观性和一致性性；

（3）研发管理服务注册中心的设立提高了过程改进发现的灵敏性和过程改进的及时性，也为研发管理体系的螺旋式改进提供支持。

3.研发管理中以质量审计为手段，检验研发项目的项目管理水平，而基于服务协作的研发管理方法和系统的应用使项目过程质量审计的总体平均分较上一年提升了24%，具体而言软件开发过程中的进度指标（考量项包括任务、工期等）、过程指标（考量项包含需求、配置、计划、评审等）、质量指标（考量项包含不符合项指标、缺陷指标等）等项目综合指数的整体平均值较上一年分别提升19%，29%，30%，。说明研发的项目管理水平、研发产品质量、研发规范性等有了明显的提升。

4.通过对研发管理监控数据资源利用：

（1）以研发指标和研发状态进行项目看板展示，可以提供项目及时、准确、有价值的决策信息预警信息和决策信息；

（2）以审计结果进行得分排序，可以激励项目在科学管理实践上投注精力，提高项目研发效率，增强研发产品质量。

附图说明

图1基于服务协作模式的研发管理方法示意图；

图2研发管理服务组件构建方法的原理图；

图3基于服务协作模式的研发管理系统功能逻辑图。

具体实施方式

以下结合具体实施例和附图对本发明作更详细的说明。

1.研发管理服务组件构建阶段，如图2所示。

（1）建立研发体系模型，如图2中S11所示：

在分析了所在研发部门的所有研发项目的共有特性后，选择了与之对应的迭代开发模型作为研发体系模型。并据此将研发体系模型生命周期设定为六个阶段：规划阶段、定义阶段、构造阶段、验证阶段、发布阶段、交付阶段。其中“定义”、“构造”、“验证”和“发布”是每个迭代周期所包含的阶段，迭代轮次由项目自行定义。

（2）模型描述和可视化展现，如图2中S12所示：

1）对模型的六个阶段的目的、主要活动进行梳理：

以规划阶段为例，包括如下主要活动：指定项目经理、项目规划、发起立项申请、逐级审批、组件项目团队、技术可行性评审、制定高层计划、制定项目计划、配置管理申请审批、配置管理环境初始化、计划计划制定、配置审计等等。然后依据这些主要活动之间的关系形成流程图；

2）文字描述：

对所有阶段、活动、流程图形成阶段描述、活动详情描述、流程描述；

3）可视化展现：

将上述活动的关系流程和详细描述以可视化形成在研发管理系统中进行展现。登陆研发管理信息门户，以系统管理员权进行“阶段描述维护”、“活动页面发布”等，可对如上六个阶段进行新建、编辑、删除、查看、查询等操作，以完成研发体系模型的可视化维护。点击进入“管理能力”大模块中的“研发体系”模块中的“体系模型”，页面可视化展示研发体系的模型概览，及各阶段的活动的可视化图形，包括阶段描述，各阶段的活动的关系图流程图及活动描述；

4）活动按过程分类：

在实施例中，我们根据项目实际开发及管理需要将上述6阶段的主要活动归类定义了三大类共计14个过程：1.工程类：需求开发与管理、软件设计、软件实现、系统测试、软件发布、软件交付、系统性能测试；2.管理类：项目立项、项目计划、项目跟踪与监控、需求管理、项目结项；3.支持类：配置管理；

5）过程流程梳理和过程定义：

对每一类过程形成流程图及过程定义，在实施例中，形成了14个过程流程图和14个过程定义文档；

6）可视化展现：

以可视化的形式展现三大类活动过程。登陆研发管理信息门户，以系统管理员权限进行“过程流程图维护”、“过程页面发布”等，可对如上三大类14个过程进行进行新建、编辑、删除、查看、查询等操作，以完成过程定义的可视化维护。点击进入“管理能力”大模块中的“研发体系”模块中的“过程定义”，页面可视化上述三大类14个过程的过程流程图，过程描述；

7）可视化展现模板指南和角色集：

同时将所有各过程中的涉及的管理文档(模板、指南、范例等)及角色也以可视化形式展现出来。登陆研发管理信息门户，以系统管理员权限进行“模板指南维护”、“角色集维护”，可对如上三大类14个过程进行进行新建、编辑、删除、查看、查询等操作，以完成过程定义的可视化维护。点击进入“管理能力”大模块中的“研发体系”模块中的“过程定义”，页面可视化上述三大类14个过程的过程流程图，过程描述。

（3）抽象出每阶段中的研发管理活动，如图2中S13所示：

以“规划”和“构造”阶段为例：规划阶段的主要活动包括指定项目经理、项目规划、发起立项申请、逐级审批、组件项目团队、技术可行性评审、制定高层计划、制定项目计划、配置管理申请审批、配置管理环境初始化、计划计划制定、配置审计等，从中抽取的研发管理活动主要包括：项目可行性评审资料是否及时提交、项目是否通过了项目可行性评审、项目可行性评审资料是否完备、项目经理是否制定了《高层计划》以明确项目各阶段或里程碑计划、《高层计划》中是否明确了各阶段的目的主要任务或版本的功能范围、项目组所有成员是否都有访问配置库的权限、立项资料是否入库、配置项的存放路径是否符合质量规范要求、配置项的名称是否符合命名规范等等。

而构造阶段的主要活动包括跟踪周活动、跟踪里程碑、概要设计、详细设计、制定产品集成策略、代码编写、代码审查、单元测试、产品集成、提交测试、建立和发布基线、需求跟踪等，可能还会包括需求变更等。从中抽取的研发管理活动主要包括：《概要设计说明书》（或《详细设计说明书》）是否按计划输出、完成的工作产品是否提交至配置库指定位置、设计说明书是否纳入了配置库统一管理、设计说明书是否经过评审、设计说明书评审通过后是否纳入基线库、配置项的存放路径是否符合质量规范要求、配置项的名称是否符合命名规范、项目经理内是否定期组织召开项目例会，就项目当前状态、进展、风险等问题进行通报和讨论、若《高层计划》变更，是否通过研发中心总经理审批、《项目进度计划》是否按照变更后的《高层计划》更新、变更后的项目进度计划是否重新发布给项目成员及相关人员、是否按照《高层计划》在《进度计划》中安排需求相关活动、是否定义了需求变更管理机制并执行、是否在变更结束后及时更新需求基线、已交付项目反馈的需求是否进行记录等等。

同时由上还可知，部分研发管理活动是某个研发阶段特有的，而部分研发管理活动是多个研发阶段共有的。即图2所示的服务集合1中的活动a1是对应到两个研发阶段的。而上述“配置项的存放路径是否符合质量规范要求、配置项的名称是否符合命名规范”等等是规划和构造阶段共有的。而构造阶段的“项目经理内是否定期组织召开项目例会就项目当前状态、进展、风险等问题进行通报和讨论、若《高层计划》变更是否通过研发中心总经理审批、《项目进度计划》是否按照变更后的《高层计划》更新、变更后的项目进度计划是否重新发布给项目成员及相关人员、是否按照《高层计划》在《进度计划》中安排需求相关活动、是否定义了需求变更管理机制并执行、是否在变更结束后及时更新需求基线”等等也是定义阶段、验证阶段等共有的研发管理活动。

（4）打破阶段边界，服务重新组合，如图2中S13所示：

1）制定研发管理过程域：

例如在实施例中，结合实际研发管理的需要，设立了需求开发与管理过程、项目计划与跟踪过程、配置管理过程、过程质量审计过程、评审管理过程、缺陷管理过程等。并将第3步各阶段的研发管理活动对应到研发管理过程域中；

2）打破研发管理的阶段边界，按研发管理过程域映射重组：

例如步骤1.3中的规划阶段的“项目可行性评审资料是否及时提交、项目是否通过了项目可行性评审、项目可行性评审资料是否完备、项目可行性评审资料是否及时提交”和构造阶段的“设计说明书是否经过评审、设计说明书评审通过后是否纳入基线库”归入评审管理过程；规划阶段的“项目经理是否制定了《高层计划》以明确项目各阶段或里程碑计划、《高层计划》中是否明确了各阶段的目的主要任务或版本的功能范围”和构造阶段的“《概要设计说明书》（或《详细设计说明书》）是否按计划输出”归入项目计划与跟踪过程。规划阶段“项目组所有成员是否都有访问配置库的权限、配置项的存放路径是否符合质量规范要求、配置项的名称是否符合命名规范”和构造阶段的“完成的工作产品是否提交至配置库指定位置、设计说明书是否纳入了配置库统一管理、设计说明书评审通过后是否纳入基线库、配置项的存放路径是否符合质量规范要求、配置项的名称是否符合命名规范”归入配置管理过程，构造阶段的“是否按照《高层计划》在《进度计划》中安排需求相关活动”归入评审管理过程。按此办法将各阶段的研发管理活动集合全部归类形成需求开发与管理、项目计划与跟踪、配置管理、过程质量审计、评审管理、缺陷管理等多个研发管理服务集合.

3）研发管理过程服务集合描述：

在实施例中，形成“需求开发与管理、项目计划与跟踪、配置管理、过程质量审计、评审管理、缺陷管理”等多个研发管理服务集合的检查表、指南、过程定义等知识文档；

4）服务调用接口设置：

每个服务集合中的活动都设置有服务调用的接口，即每个活动外部包装有与其对应的研发阶段和每个活动的功能描述。

（5）研发项目类型划分：

分析现有项目间的差异特性，划分不同的项目类型。例如将研发体系的项目重点分为：技术预研类、产品预研类，技术开发类、产品开发类，维护类等。之所以将项目按如上类型划分，是为了管理和考核的需要，不同类型有不同的管理侧重点，因此考核的权重设置要有差异。

（6）按项目类型进行服务组件裁剪：

依据上述项目类型，对研发管理服务集合进行裁剪，得到不同类型项目对应的研发服务管理组件，如图2中S15所示。例如对于规划阶段的技术可行性评审这一研发管理服务，不同项目类型的需求差异在于：对预研类项目、新产品研发类项目的要求是必须的，对于涉及架构变化和新技术应用的功能优化和改造等维护类项目要评审，而对于原产品升级改造的维护类项目不需要规划阶段的技术可行性评审，只需要评审增量即可。

以上即为服务组件构件过程，也是研发管理的基础。另外研发管理体系随研发体系进行自我改进时，也遵循如上步骤1即图2所示的方法进行调整，形成新的服务组件。

2. 研发管理服务协作角色设置，如图1中S2部分所示。

建立研发管理服务注册中心。研发管理信息门户的服务注册中心用以保存服务信息，服务注册中心存储了预研类、研发类、交付类、维护类等不同类型项目所对应的需求开发与管理、项目计划与跟踪、组织级配置管理、过程质量审计、评审管理、缺陷管理等服务组件。同时研发管理信息门户的服务注册中心为服务请求者提供检索、查找和返回结果的功能，为服务提供者提供服务发布的功能。

设置服务提供者角色。其角色的职能一方面在于研发管理服务提供者在服务注册中心执行发布操作，发布的服务包括研发管理服务组件构件过程中形成的服务和体系过程改进后形成的服务，目的之一在于使大家知道某个服务的存在及其功能，目的之二在于建立提供者和某一项或多项服务间的关联。另一方面在于服务提供者响应请求并执行研发管理服务，并在这个过程中发现过程改进点。

设置服务请求者角色。当研发工程开始后，研发项目组通常不具备请求进行研发管理的主动性，因而对项目设置接口人角色，即服务请求者角色。其角色职责在于对项目进行跟踪，发起研发管理请求，并在这个过程中发现过程改进点。

在实施例中，我们为每个研发项目设置一个项目接口人，接口人来自于研发管理部，我们将接口人赋予服务请求者。这样设置解决了项目不具备请求进行项目监控的主动性的实际问题，同时项目接口人兼具研发管理和实际研发的视角，既可以贴近实际研发进行全面跟踪，又可以给予研发管理的咨询指导并接受反馈进行过程改进等，由此既减少了研发管理部门与研发团队间的对立，又减少了研发团队进行研发管理的成本，从而可以集中更多精力用于研发并且是规范的研发。

同时为研发项目设置多个服务提供者角色，服务提供者角色的职责主要包括需求开发与管理、项目计划与跟踪、组织级配置管理、评审管理、缺陷管理等，以及实施项目计划质量审计、项目跟踪质量审计、配置审计、需求开发与管理质量审计等过程审计，以及发布这些服务，并在项目反馈中发现过程改进等。

另外，如果将上述服务提供者角色的主要职责（需求开发与管理、项目计划与跟踪、组织级配置管理、评审管理、缺陷管理等，以及实施项目计划质量审计、项目跟踪质量审计、配置审计、需求开发与管理质量审计等过程审计）分为审计职责和其他管理职责，则对于每一个项目来说，其接口人除被赋予服务请求者角色，还可以被赋予服务提供者角色，提供部分其他管理职责。而对于这一个项目来说，过程审计人员仅具有服务提供者角色，负有审计职责和部分其他管理职责。这样的设置，即从项目接口人中剥离审计的职责，解决了同一人兼具教练员和裁判员角色的问题。但在不同项目间同一人可以兼具审计人和接口人职责，即研发管理人员在项目间是交叉配置角色的。简单来说，就是同一人可以作为服务请求者接口多个项目，并可以作为服务提供者对其提供除审计外的研发服务，而另外的人员作为服务提供者对这几个项目提供审计服务和其他服务。

如上的设置一方面减少研发团队与研发管理团队的对立，另一方面减少研发管理过程中的主观性，减少管理标准的不一致性，另外也提高了研发管理人员的配置效率。

3.如上设置好服务协作的角色后，即可开始研发管理服务协作的过程,如图1中S3所示。

（1）将研发管理服务组件保存在服务注册中心：

包括在研发体系及研发管理体系进行改进过程中形成的更新的研发管理服务组件以模板、检查表、指南等文档形式保存在服务注册中心。以“需求开发与管理质量审计”和“组织级配置管理”这两个服务组件为例。“需求开发与管理质量审计”将其中的所有相关研发管理活动以审计报告检查表的形式形成文档，其主要内容包括审计项、审计项对应的阶段及项目类型、审计结果、审计方式、审计得分等，这里审计结果字段是指符合情况和适用情况，如“符合、不符合、不完全符合、未开始、不适用”，并赋予审计得分。而“组织级配置管理”则将研发活动不同阶段所需的所有配置管理活动形成过程文档，主要包括流程图、活动描述、输入输出、进出口准则等过程描述，其活动主要包括：配置管理申请审批、配置管理环境初始化、基线计划制定、配置项管理、建立和发布基线、执行配置审计、配置库备份、项目资料归档等等，每个活动即服务都有其对应的研发阶段的描述。具体操作即登陆研发管理信息门户系统，以组件提交的权限进入“研发管理注册中心”，提交研发管理服务组件并保存和发布。

（2）服务提供者进行服务发布：

服务发布的过程就是人员和活动进行匹配并发布的过程。在实施例中，研发管理人员对研发管理服务组件中的活动进行分工认领，并登陆研发管理信息门户以服务发布的权限进入“服务注册中心”，选择对应的服务填写服务提供者并保存和发布，让大家知道某项服务的存在。而无论服务请求者还是服务提供者，其发起的过程改进，同样会提交至服务注册中心，服务更新后，由对应服务提供者进行服务发布。

（3）服务请求者进行项目跟踪：

项目接口人以跟踪周例会、日常访谈、研发系统查看等方式进行项目跟踪，以了解研发的实际情况。

（4）发起研发管理请求：

接口人根据研发实际情况以及研发管理规范等发起响应的研发管理请求。例如当某项目研发进程进行到第二轮迭代的时，遇到一个审计周期，则项目接口人发起审计请求；或者当项目研发进程中，项目经理需要readmine项目管理工具的使用指导或培训，则项目接口人发起指导或培训请求。具体操作即为项目接口人登陆研发管理信息门户进入“服务注册中心”，查找对应的审计服务或readmine指导或培训服务。

（5）研发管理服务注册中心响应查找请求：

研发管理服务注册中心根据接口人的查询输入，查找是否存在与阶段对应且功能匹配的服务，以及查询服务提供者的可预约时间。

（6）查询结果显示：

研发管理服务注册中心页面展示模糊查询结果。按阶段、服务介绍、提供人、提供人可预约时间等字段展示0条或多条结果。

（7）服务执行者根据查询结果进行对应动作：

项目接口人根据页面结果进行判断，若查询结果显示服务存在且与需求一致，则接口人绑定并调用此服务，即预约某时段某服务提供者服务，“研发管理服务注册中心”触发邮件通知到服务提供者。若查询结果显示服务不存在或者与需求不一致，接口人在“研发管理服务注册中心”的“过程改进”建立一条或多条改进项，待后续商定解决，例如汇总关于readmine的指导的相关改进意见后，编写readmine使用手册并对新任项目经理入职培训中增加这一培训事项。

（8）服务提供者响应请求，执行服务：

例如对某预研类项目在规划阶段组织技术可行性评审；对项目进行第N次需求开发与管理审计等。

（9）服务提供者提出过程改进：

在服务提供者响应服务请求并执行研发管理活动中，根据所提供的研发管理活动与实际研发的适应程度，提出过程改进。例如在项目计划质量审计过程中，其中两条审计项为“以访谈方式检查《高层计划》是否在项目立项后1个月内通过研发中心评审”、“以访谈方式检查《项目进度计划》是否通过研发中心评审”，在实际审计过程中，发现研发项目在规划阶段进行技术可行性评审时，已经提交并由被评审了高层计划和项目进度计划，这两个审计项可以通过“直接参与方式检查项目是否通过了可行性评审”这一审计项覆盖。因而审计人员即服务执行者在“研发管理服务注册中心” 的“过程改进”建立改进项，在后续研发管理部讨论后，决定将原来的审计项“以访谈方式检查《高层计划》是否在项目立项后1个月内通过研发中心评审”、“以访谈方式检查《项目进度计划》是否通过研发中心评审”删除，并更新“直接参与方式检查项目是否通过了项目立项评审”为“直接参与方式检查项目是否通过了可行性评审”。

4.服务数据利用。

（1）数据收集整理

在对研发项目进行研发管理的过程中，会实时产生大量不同形式的数据。其形式包括文档、工具记录等，如项目跟踪过程中的访谈记录，质量审计过程中的计划质量审计报告、跟踪质量审计报告、需求开发与管理质量审计报告、配置审计报告，以及通过研发管理信息门户的评审管理工具形成的评审管理记录、通过研发管理信息门户的项目管理工具readmine进行任务管理、缺陷管理等形成的记录。并对这些文档和工具记录等进行加工整理。

（2）数据利用

对这些数据的利用首先是审计报告的可视化的展现。具体操作是服务提供者及审计人员以“审计信息维护”的权限进入研发管理信息门户系统，提交审计报告文档。而在研发管理信息门户系统在读取了审计报告的数据后，在“审计报告”模块会以可视化的形式展现各过程的审计结果。展示页面以折线图的形式展示每个过程最近12次的平均过程符合度的审计得分，同时可以看出此过程的过程符合度整体变化趋势，另外页面还会以列表形式展示截止目前所有项目未关闭的不符合项列表；点击折现点可查看每次的详细审计报告，而每次的详细审计报告又是以柱状图的形式展现此次所有研发项目的过程符合度得分，如此还可以进行项目间的横向比较，同时页面还会展示此次过程审计的主要问题及最佳实践；而点击每个柱状图后又会展示此项目此次过程审计的详细报告，包括审计内容、审计方式、审计结果等。

对数据的利用还表现为以看板形式展示项目监控指标。其中每个研发项目最近要发布版本的工期状态、完成状态、项目累计缺陷状态从readmine项目管理工具记录中读取，而项目累积的文档评审状态从评审管理工具记录中读取，项目累计不符合项状态、过程符合度状态从审计报告记录中读取。由此形成每个项目的详细研发状态，以轮播形式展示在看板一侧。同时设定项目进度指标、过程指标、质量指标等的考量方式和计算方式，从readmine项目管理工具记录和审计报告记录中读取相应数据形成每个项目在这几方面的综合指数，展示在看板另一侧。看板数据每日更新。为研发团队和各级决策层提供准确实时的监控预警数据和决策依据。

对数据的利用还表现在运用审计报告形成的得分进行排名建立质量审计激励制度，目的在于引导项目重视自我改进，促进项目管理的有效性提升，推动研发管理工作的开展。