产品批产后需要研发单位负责的业务主要包括及时处理产品生产和使用过程中出现的质量问题；主动优化产品，提升产品可服务性、可制造性，降低产品生产供应成本及服务成本；建立并监控产品运行质量指标，确保产品稳定运行，必要时可推动服务团队开展主动维护活动；及时响应来自服务团队提出的求助；及时响应来自采购、生产团队提出的求助；主动总结业务工作中的产品质量及面向产品全生命周期设计（DFX）相关的经验教训，形成案例及时同步给产品开发团队（PDT），推动上游团队提高质量意识，促进主动提升产品质量，主动增强产品DFX能力；跟踪整理产品发布和升级替代记录、产品质量运行状况等，为产品退出管理提供参考依据。研发维护业务与产品开发、服务保障、生产制造、采购、需求管理等业务之间的依赖关系如图1所示。由于研发维护业务一般为突发，具有较大的不确定性，同时其开发需求简单、验证周期短，因此不宜按照产品开发流程开展此类业务，需要建立更加灵活、机动的流程，在保证产品质量的同时能够快速响应内外部客户的需求，提高产品的综合竞争力。

研发维护团队

研发维护团队主要负责产品转维后的研发侧业务，研发维护团队人员数量及技能一般应根据产品定位按需确定。例如，对于目前及未来交付量大的产品，其研发维护业务需求较旺盛，研发维护团队人员数量需求大，专业覆盖范围广；对于交付量较低的产品，可能只有较少的研发维护业务，研发维护团队人员数量需求小，专业覆盖范围窄。

业务覆盖范围方面，根据预计的研发维护业务范围确定需要的研发专业人员。一般应涵盖总体设计、控制系统设计、传动润滑系统设计、部件设计、结构开发专业等在排故和研发维护开发项目中的常用专业人员。

关键岗位方面，要求研发维护团队应配备具备项目管理经验的人员和相关问题接口人，具备项目管理专业技能，能够带领团队完成项目开发；配备客户问题、制造/采购、需求管理接口人，要求服务、设计、开发经验丰富，沟通协调能力强、专业面广。

人员素质方面，对专业技术要求广度大于深度，同时要善于沟通协调，学习能力强。

人员数量方面，根据具体型号研发维护需求而定，可以采取与产品开发团队人员数量配比的方法，如研发维护团队人员数量是产品开发人员数量的1/10。

研发维护流程

转维

转维意味着产品的研发维护权由研发团队转为研发维护团队，产品是否转维要根据具体情况而定，如判断批产后不会大批量爆发问题，可立即实施转维。如批产后很可能集中爆发大量问题，应继续由原研发团队负责，当问题得到充分暴露和改进、产品稳定运行后再转维。

转维是一个持续的复杂过程（见图2），研发团队准备转维和内部自检，协同研发维护团队共同评估后提出转维申请；做出转维决策后，研发团队将数据移交给研发维护团队，发布转维公告；产品平稳运行一段时间后，转维结束。

制订计划：研发团队在产品开发的计划阶段结束前制订初步转维计划，在开发阶段结束前制订详细转维计划，明确转维团队和工作节点。

转维准备：研发团队对照转维检查单进行自检，找出差距，制定改进措施，跟踪措施落地情况，自检达到转维标准后，向研发维护团队提出启动转维。

转维评估：研发维护团队对照转维检查单进行转维评估，当认为达标或有条件达标，则同意启动转维，当评估不达标则拒绝转维申请，当双方分歧，研发团队有权单方面提出转维申请。

转维申请：研发团队编制转维申请报告，正式提出转维申请，报告内容应包括但不限于转维自检情况、研发维护团队评估情况、业务遗留问题及承诺、人力转移等。

转维批准：通过会议形式对转维进行评审并作出决策，决策结论可以是批准、有条件批准、驳回。如果驳回则不转维，将来条件具备后研发团队可再次申请转维。有条件批准是指转维后，研发团队在约定条件下对研发维护团队进行相关支持，并承担约定的责任，相关条件、义务、责任等必须在决策纪要中写明。

移交数据：决策转维后，研发团队将该项目的研发权利和责任交接给研发维护团队，交接内容包括但不限于项目过程数据及结果数据（含项目文件夹全部数据、相关IT系统全部数据）、业务遗留问题（如尚未关闭的测试问题、尚未处理完毕的生产问题和客户问题等）、转维过程文档（如转维计划、措施、自检表）等。

发布转维公告：由研发维护团队起草转维公告，经签署后发布至所有利益相关方，包括但不限于产品开发团队、成附件单位、测试部、资料开发部、工艺开发部、质量部等。

转维结束：       转维后产品持续稳定运行一段时间（如3个月），研发维护团队进行二次评估，确认转维效果，总结转维经验教训并提出改进建议（用于管理改进，有必要可在产品开发团队例会汇报），转维工作正式结束。

在转维前，可根据实际情况，安排研发维护团队提前介入产品开发过程，如参与进行客户测试、支持制造采购和服务领域等，以提前熟悉产品并为产品开发团队提供帮助。

制定维护策略

维护策略是研发维护团队为提升产品全生命周期表现，对近期和中长期研发维护工作做出的总体安排。在已有研发维护团队时每年制定，新成立研发维护团队时在维护团队成立后制定，每年刷新。

维护策略包含不足与挑战、设定维护业务目标、管理维护业务、保障产品运行质量、优化产品等5个模块，维护策略需在产品开发团队例会上汇报，用于向上承诺以及与相关方对齐。

管理维护需求

维护需求主要包括以下两类：客户对该产品的需求；公司内部提出的能够提高产品质量、降低产品成本等的需求。研发维护团队应设置需求管理接口人主动参与需求管理工作，一般作为产品需求分析团队成员开展维护项目需求分析活动，确保分发给研发维护团队需求的适宜性。

分发给研发维护团队的需求会纳入维护项目进行开发，其处理方式分为两种：一是对于紧急需求，优先考虑加入到当前正在开发的项目，必要时可单独启动开发项目；二是对于非紧急需求，将其纳入项目规划中，作为项目中的一项需求与其他问题/需求合并为一个项目进行开发。在需求实现后按照需求管理相关要求进行需求闭环。

规划项目

项目规划属于产品规划的一部分，是研发维护团队从事项目开发的主要输入，在规划执行中若遇到突发紧急重大问题/需求时必须单独启动紧急项目解决的，可以临时启动紧急项目，该项目被称为计划外项目（不在规划清单里），应尽量降低计划外项目的比例，尤其是在产品质量相对稳定的情况下。

通常，规划的制定应由产品规划团队负责，但研发维护项目规划由于其特殊性，是由研发维护团队负责而不是产品规划团队，主要原因包括产品规划流程较为复杂，不太适合研发维护项目这类规模和投入较小的项目；研发维护项目内容较为细碎，产品规划团队难以理清研发维护项目的细节；研发维护项目规划的节奏需要根据产品状态进行不断调整，与产品规划的节奏较难匹配。

研发维护项目规划按年度滚动刷新、批量立项，产品规划团队授权不授责，要对规划的正确性负责，规划过程中需邀请产品规划团队进行方法论指导和规划评审，同时将规划预算纳入产品路标中。

监控产品运行质量

监控产品运行质量是进行产品主动优化、改进的重要依据，是提高客户满意度的基础，该项工作由客户问题接口人负责组织，一般需要协同服务领域共同进行。主要包括监控产品运行质量指标（质量问题数、问题及时解决率等），确保产品稳定运行，必要时可推动服务团队开展主动维护活动；持续收集、分析产品在客户侧的运行数据（取得客户授权下），识别潜在问题，开展主动优化；通过客户走访或其他业务工作（如问题定位、重大任务保障、用户培训等），注意倾听客户声音，了解客户使用中的抱怨和不理解，收集问题。

研发维护团队定期（每月或每季度）编制产品运行质量报告，对产品整体运行质量进行分析，提出潜在问题并制定相应措施。

问题处理

问题来源主要包括4类：服务领域，指的是产品在客户侧使用过程中出现的问题，服务团队无法解决，向研发求助，由研发维护团队接手，需进一步定界、定位并给出解决方案；制造领域，指的是在生产制造、产品包发货运输过程中发现的，相关部门解决不了，从而转给研发，由研发维护团队接手，须进一步定界、定位并给出解决方案；采购领域，指的是在原材料及元器件采购过程中发现的，相关部门解决不了，从而转给研发，由研发维护团队接手，需进一步定界、定位并给出解决方案；研发领域，指的是批产后，研发团队（可能是产品开发团队，也可能是研发维护团队）发现的问题，可能是开发新批次过程中发现旧批次也存在问题，或者从事其他工作时偶然发现。

问题处理过程一般是一个逐级求助、解决和闭环的过程，以客户侧问题为例，客户使用中的问题，通报给现场服务团队，如服务团队无法解决，会将问题提交给研发维护团队，由研发维护团队（或求助研发团队）进行问题定位、方案制订和措施同步工作，并将解决方案（现场规避方案和产品改进方案）提供给服务团队，经服务团队（必要时邀请研发维护团队参加）与客户沟通达成一致后，转入实现环节，开发完成后进行二次措施同步、归零评审和问题闭环。

问题处理相关活动包括问题定位（确定问题发生部位、机理分析、影响分析和问题复现）、制订初步方案、判断是否研发维护团队承接、判断维护任务是否紧急、项目开发、措施同步、问题闭环。

问题处理过程由质量保证（QA）部门负责质量管理工作，监督并检查质量问题处理过程，监视、测量系统运行的有效性，组织质量问题的归零评审。此外，应对相关数据进行管理，确保关键节点构型数据的完整性、一致性和可追溯性。

研发维护项目开发

研发维护项目主要是在原型号状态上落实新的需求或者排故措施，属于增量开发,具有以下特点：主要是对技术状态进行局部小改进，新需求宜少且简单；产品初始需求基本不改变；总体设计方案不改变，子系统间接口不改变；验证试验复杂度低；项目周期短、投入少。

研发维护项目“麻雀虽小，五脏俱全”，可能会涉及多个部件/子系统的改进，因此尽管规模小，项目流程也需要明确定义，主要包括需求分析、方案设计、实现和验证4个阶段，与产品开发阶段划分^[2]的对应关系如图3所示，需要说明的是，除客户和组织明确要求外，研发维护项目一般不包括产品开发流程PTR7之后的验证活动，如需开展，应在项目规划时讲明，并得到批准。

研发维护项目开发一般使用研发流程开展，但需对其进行裁剪,考虑覆盖多数研发维护开发项目，抽取相关活动形成裁剪后的流程视图，如图4所示。该视图包括结构件、软件、成附件和资料的开发活动，实际项目未全部涉及，应根据具体情况而定。

结束语

研发维护流程的核心价值是实现研发维护与产品开发分离，旧产品/版本由研发维护团队负责，新产品/版本由产品开发团队负责，这样既可避免日常研发维护工作（尤其是突发排故任务）对产品开发团队的直接冲击，让产品开发团队更加聚焦于新产品/版本开发，又有利于研发维护团队聚焦解决客户问题，提升客户服务满意度。

（韩秋冰，中国航发动力所，高级工程师，主要从事航空发动机产品研发体系建设研究）

参考文献

[1] 王桂华.关于产品研发流程及流程架构的探讨[J].航空动力,2020(5):48-52.

[2] 韩秋冰.航空发动机产品开发流程阶段划分[J].航空动力,2020(3):48-50.