研发治理制度要写清楚三件事：谁在什么节点做决策、评审按什么标准通过、例外如何申请和留痕。本文给出一份假设情景下的完整制度范本，覆盖治理组织、分级决策、评审门禁、变更例外和度量复盘，并逐条解释条款的设计意图与可调整空间。制度落地时，评审记录、变更审批和复盘文档需要有稳定的承载方式，ONES 可在相关章节衔接说明。
要点总览（TL;DR）
- 研发治理制度的核心是写清三件事：决策权归属、评审门禁的通过标准、例外的申请与留痕，三者缺一都会导致制度空转。
- 范本按总则、治理组织、决策分级、评审门禁、变更例外、度量复盘六章展开，条款中的角色、时限和门槛均为示例值，方括号处需按组织实际填写。
- 决策分级用“事项类型加影响门槛”双重界定，并为每级设置唯一最终裁决主体，避免争议事项被搁置。
- 评审门禁要同时写明评审角色、输入材料和可核验的通过标准；例外条款要设有效期、做统计，并与制度修订挂钩。
- 换到其他组织时，治理组织随规模调整、门禁随研发模式调整、决策分级与既有授权体系对齐，这三条结构建议保留。
示例目标：这份制度要解决什么问题
本文的制度范本设定在一个假设的中型研发组织中：约三百名研发人员，同时运行十余个研发项目，产品线分为两条，设有独立的 PMO 和质量管理岗位。该组织此前的管理方式是项目负责人各自推动，重大事项靠临时会议决定，评审记录散落在邮件和聊天工具中。这一背景为演示情景，不代表任何真实客户实践，读者应把它当作填写制度的起点，而非可以直接发布的标准文本。
制度要约束的对象是研发项目从立项到上线后的治理动作，包括决策事项的归属、评审节点的设置、变更与例外的处理、治理数据的采集与复盘。制度要解决三类反复出现的问题：
- 决策无归属。技术方案选型、范围调整、上线时间变更等事项，经常出现“谁都可以拍板、谁都不最终负责”的情况，会议开完没有结论，或者结论无人执行。
- 评审走过场。评审会开了，但输入材料不齐、评审角色缺位、通过标准模糊，评审意见无法转化为可跟踪的整改项。
- 例外无记录。跳过评审、延期上线、降低测试标准等例外处理靠口头同意，事后无法追溯是谁批准的、基于什么理由，同类例外反复发生。
制度覆盖研发项目的治理决策、评审门禁、变更例外与治理度量。项目集层面的运行监控、资源池调度和项目组合投资决策不在本文重点范围内，这些机制通常由独立的项目集管理或投资管理流程规定，需要时另行制定。
完整示例：研发治理制度全文范本
以下为制度范本全文，条款中的部门名称、角色名称、时间要求和金额门槛均为示例值，方括号内为需要按组织实际填写的内容。
第一章 总则
第一条 目的。为规范研发项目的治理决策与评审活动，明确各角色的治理职责，保证研发投入的可追溯性，制定本制度。
第二条 适用范围。本制度适用于组织内所有立项的研发项目，包括新产品研发、既有产品重大版本迭代和平台类基础设施建设。研发投入低于[示例：20人天]的小型改进由项目负责人自行管理，报 PMO 备案。
第三条 术语。治理委员会指承担研发重大事项决策职责的跨部门组织；PMO 指负责治理流程运行与数据汇总的项目管理办公室；评审门禁指项目在特定阶段必须通过的结构化评审；例外指偏离本制度规定流程或标准的处理请求。
第二章 治理组织与角色职责
第四条 治理委员会。由研发负责人、产品负责人、质量负责人和 PMO 负责人组成，研发负责人担任主席。职责包括：审批重大立项与终止、裁决跨部门资源冲突、审批一级例外、审议季度治理报告。委员会每[示例：两周]召开一次例会，紧急事项可召集临时会议。
第五条 PMO。职责包括：维护治理流程与模板、组织评审门禁的排期与记录、汇总治理指标、跟踪评审整改项与例外事项的闭环、向治理委员会提交治理报告。PMO 对流程执行情况有检查权，对评审结论不直接做业务判断。
第六条 产品负责人与技术负责人。产品负责人对需求范围与优先级负责，技术负责人对技术方案与架构合规负责。二者共同对方案评审的输入材料完整性负责，并在评审后[示例：3个工作日]内完成整改项的分配。
第七条 项目负责人。对项目整体交付负责，包括按门禁要求提交评审材料、组织评审、跟踪整改项、发起变更与例外申请、维护项目治理记录。
第三章 决策分级
决策事项按影响范围分为三级，分别对应不同的决策主体和升级路径。下表为示例分级，金额与范围门槛需按组织实际填写。
| 级别 | 典型事项 | 决策主体 | 升级路径 |
|---|---|---|---|
| 一级决策 | 项目立项与终止、预算超过[示例：100万元]的投入、跨产品线范围调整、一级例外 | 治理委员会 | 委员会内部表决，主席有一票裁决权 |
| 二级决策 | 版本范围重大变更、上线时间调整超过[示例：两周]、技术架构重大调整、二级例外 | 产品负责人与技术负责人联签，报 PMO 备案 | 双方意见不一致时提交治理委员会裁决 |
| 三级决策 | 迭代内需求优先级调整、非关键路径技术方案选择、三级例外 | 项目负责人 | 超出授权范围时逐级上报 |
第八条 决策记录。各级决策均需形成书面记录，包含决策事项、决策依据、决策人、决策时间和执行责任人。决策记录由 PMO 归档，作为后续变更与复盘的事实依据。
第四章 评审门禁
第九条 门禁设置。研发项目设置三道门禁：立项评审、方案评审、上线评审。门禁未通过的项目不得进入下一阶段，确需提前进入的按例外流程处理。
第十条 立项评审。输入材料包括项目目标与成功标准、初步范围、资源需求、里程碑计划、风险清单。评审角色为治理委员会指定代表、产品负责人、技术负责人、PMO。通过标准为：目标与成功标准可度量、资源需求与排期匹配、主要风险有应对措施。评审结论分为通过、有条件通过、不通过三类，有条件通过的整改项需在[示例：5个工作日]内关闭。
第十一条 方案评审。输入材料包括需求说明、技术方案、测试策略、上线与回滚方案。评审角色为技术负责人、产品负责人、质量负责人及相关领域专家。通过标准为：需求范围与立项一致、技术方案覆盖非功能要求、测试策略与风险等级匹配、回滚方案可执行。
第十二条 上线评审。输入材料包括测试报告、遗留缺陷清单及处理意见、上线检查单、监控与应急方案。评审角色为项目负责人、质量负责人、运维代表。通过标准为：阻断级缺陷清零、遗留缺陷有明确处理计划、上线检查单全部确认、应急联系人到位。
第五章 变更与例外
第十三条 变更分类。变更分为范围变更、进度变更、技术方案变更和资源变更四类。变更申请需说明变更内容、原因、影响评估和应对措施，按第三章的决策分级确定审批主体。
第十四条 例外申请。例外分为三级：一级为例外跳过门禁或突破重大约束，由治理委员会审批；二级为例外调整评审范围或延期整改，由产品与技术负责人联签；三级为例外调整迭代内执行顺序，由项目负责人审批并报 PMO 备案。
第十五条 例外记录与时效。例外申请需记录申请理由、影响范围、补偿措施、有效期和审批人。例外默认在[示例：一个版本周期]内有效，到期自动失效，需继续执行的重新申请。PMO 按月统计例外数量与类型，连续两个月同类例外超过[示例：3次]的，提交治理委员会评估是否修订制度。
第六章 度量与复盘
第十六条 治理指标。治理指标聚焦制度执行情况，示例指标包括：门禁按期评审率、评审整改项按期关闭率、变更数量与类型分布、例外数量与闭环率、决策事项平均响应时长。指标口径由 PMO 定义并公布，数据来源为评审记录、变更记录和例外台账。
第十七条 复盘频次与输出。项目上线后[示例：两周]内完成项目复盘，输出复盘报告，内容包括目标达成情况、门禁执行情况、变更与例外复盘、改进项及责任人。PMO 每季度汇总各项目复盘结果，形成治理报告提交治理委员会，报告需包含指标趋势和下季度制度修订建议。
逐项解释：关键条款为什么这样写
范本中的条款不是唯一写法，但每一条都对应一个具体的管理失效场景。理解条款要解决的问题，比照抄条文更重要。
决策分级条款：权限边界与升级路径
决策分级条款的核心是把“谁能定”写成可判断的规则，而不是笼统的授权描述。范本采用“事项类型加影响门槛”的双重界定：事项类型说明决策对象，影响门槛（金额、延期天数、范围跨度）说明严重程度。这样写的好处是，项目负责人遇到具体事项时可以自行对照判断，减少“这件事要不要上报”的反复请示。
升级路径必须写到“意见不一致时怎么办”。很多制度只写了谁审批，没写审批人之间分歧如何处理，结果是争议事项被搁置。范本中二级决策采用联签加委员会裁决的设计，就是为了给分歧一个明确的出口。换到其他组织时，门槛数值和联签角色可以调整，但“每级决策都有唯一最终裁决主体”这一结构建议保留。
评审门禁条款：角色、输入与通过标准
评审走过场的根源通常不在评审会本身，而在三个前置条件缺失：评审角色没有明确到岗位、输入材料没有清单、通过标准没有可判断的描述。范本对每道门禁分别写明输入材料、评审角色和通过标准，三者缺一不可。
通过标准要写成可核验的判断句。例如“主要风险有应对措施”比“风险可控”更可操作，因为评审时可以逐条核对风险清单是否都有对应措施。评审结论分为通过、有条件通过、不通过三类，是为了避免二元结论导致的两种极端：要么全部放行，要么整体打回。有条件通过配合整改项关闭时限，让评审意见真正进入执行。
例外处理条款：避免例外变成常态
例外条款的设计要点是让例外“有成本、有期限、有统计”。范本要求例外申请记录理由、影响、补偿措施、有效期和审批人，其中有效期是关键：没有期限的例外实际上等于修改了制度。到期自动失效、需继续执行则重新申请，能促使申请方评估是否应该走正式变更流程。
例外统计与制度修订挂钩，是防止例外常态化的第二道机制。当同类例外反复出现，说明制度条款可能脱离实际，此时应修订制度而不是继续批量批准例外。这一条在落地时容易被忽略，建议在 PMO 的月度工作中固定安排例外分析。
度量条款：指标选取与数据来源
治理指标应衡量制度本身的执行质量，而不是替代业务效能指标。范本选取的门禁按期评审率、整改项按期关闭率、例外闭环率等指标，数据都来自治理流程自身产生的记录，采集成本低、口径争议小。指标定义必须由 PMO 统一公布，否则不同项目按各自理解填报，汇总数据失去比较意义。
度量与复盘条款要写清输出物和责任人。复盘报告不是项目总结的替代品，它聚焦治理动作的执行情况；季度治理报告要包含指标趋势和制度修订建议，让度量结果能够反馈到制度本身，形成闭环。制度落地时，评审记录、变更审批和复盘文档需要有统一的承载工具，否则指标采集会退化为人工汇总。ONES 效能管理可自动收录系统内流转的研发数据并形成分析指标，提供交付效率、交付质量、资源效率、完成情况四个维度的度量实践体系，并预置面向管理人员、项目经理等角色的仪表盘模板；治理指标中依赖系统数据的部分可以在此基础上配置，具体指标口径仍需结合组织实际定义。
可迁移规律：换到其他组织怎么改
范本的价值在于结构，条款内容需要按组织实际替换。以下四条规律说明哪些部分应当保留、哪些部分应当调整。
治理组织随规模变化调整
组织规模较小时，治理委员会与 PMO 的职责可以由同一批人兼任，甚至由研发负责人直接承担决策与流程维护，此时制度应简化会议频次和报告层级，保留决策记录和例外台账即可。组织规模扩大、项目数量增多后，决策与流程执行的分离变得必要，PMO 作为独立角色承担流程运行和数据汇总，治理委员会聚焦重大裁决。判断是否需要分离的信号通常是：决策会议被日常流程问题占满，或者流程执行无人跟踪。
评审门禁随研发模式调整
瀑布模式下，三道门禁与阶段划分天然对应，评审材料偏重文档完整性。敏捷模式下，门禁可以合并或下沉：立项评审保留在项目或大型特性启动时，方案评审融入迭代计划会，上线评审与发布检查单结合，评审频次提高但单次范围收窄。混合模式下，按项目风险等级差异化设置门禁，高风险项目保留完整三道门禁，低风险项目采用简化评审。无论哪种模式，评审角色、输入材料和通过标准三要素都应保留，这是门禁有效性的基础。
决策分级与授权体系对应
决策分级不是孤立文件，它需要与组织现有的授权体系对齐。如果组织已有财务授权、人事授权等制度，研发治理的决策门槛应引用这些制度中的既有标准，避免出现同一事项在两套制度中门槛不一致。授权体系调整时，治理制度的决策分级条款应同步修订，并在制度中写明联动关系。
制度落地需要同步的管理动作与工具承载
制度发布只是起点，落地需要同步完成几件事：评审模板与检查单的准备、评审排期机制、决策与例外台账的建立、指标口径的公布、以及承载这些记录的工具配置。工具承载的重点是让评审记录、变更审批和复盘文档在同一个地方沉淀，减少人工汇总。ONES 效能管理支持对研发过程中产生的数据进行多维度、精细化、自定义的分析，并支持将仪表盘共享给其他用户，便于 PMO 向治理委员会和项目团队同步治理数据；评审与变更审批的流程承载需结合组织实际选用的工具配置，本文不展开具体配置方式。
适用边界：这份范本不适合直接照搬的情形
使用这份范本前，需要确认以下边界条件，避免把示例当成通用标准。
- 示例性质。本文全部情景、角色设置和门槛数值均为假设，用于演示制度结构，不代表任何真实客户实践，也不构成行业标准。发布前应由组织内部相关部门评审并替换为实际参数。
- 强监管行业的合规要求需另行补充。金融、医疗、汽车电子等受强监管的行业，研发过程还需满足相应的合规、审计与追溯要求，这些要求通常严于本范本，需在制度中单独成章或引用外部规范。
- 项目集运行监控与投资决策不在范围内。多项目资源调度、项目组合优先级排序、投资回报评估等机制，需要项目集管理或投资管理流程另行规定，本制度只处理单个研发项目的治理动作。
- 制度文本需结合组织实际评审后发布。范本中的角色名称、会议频次、时限要求和金额门槛都需按组织实际填写，并经过法务、财务、质量等相关方评审，确认与现有制度无冲突后再发布。
- 度量指标需验证可采集性。范本列出的治理指标依赖评审记录、变更记录和例外台账的完整留存，发布前应确认这些记录有稳定的采集方式，否则指标会因数据缺失而失去参考价值。
把这份范本当作填写模板使用，逐条替换示例值、补充组织特有的合规要求、确认指标数据可采集，再经过内部评审发布，制度才具备执行基础。
常见问题
组织规模较小，治理委员会和 PMO 可以由同一批人兼任吗？
可以。规模较小时，决策与流程维护由同一批人承担是常见做法，制度可相应简化会议频次和报告层级，保留决策记录和例外台账即可。判断是否需要把两者分开的信号通常是：决策会议被日常流程问题占满，或者流程执行无人跟踪。此时再考虑让 PMO 作为独立角色承担流程运行和数据汇总。
敏捷研发模式下，三道评审门禁必须全部保留吗？
不必按瀑布模式原样保留。敏捷模式下门禁可以合并或下沉：立项评审保留在项目或大型特性启动时，方案评审融入迭代计划会，上线评审与发布检查单结合，评审频次提高但单次范围收窄。混合模式下可按项目风险等级差异化设置。无论怎么调整，评审角色、输入材料和通过标准三要素都应保留，这是门禁有效性的基础。
例外申请批准后，到期还需要重新走流程吗？
需要。范本中例外默认在一个版本周期内有效，到期自动失效，需继续执行的重新申请。这样设计是为了促使申请方评估该事项是否应转为正式变更。同时 PMO 按月统计例外数量和类型，同类例外连续两个月超过设定次数时提交治理委员会评估是否修订制度，避免例外变成常态。
治理指标的数据从哪里来，需要额外投入采集工作吗？
范本选取的门禁按期评审率、整改项按期关闭率、例外闭环率等指标，数据都来自治理流程自身产生的评审记录、变更记录和例外台账，采集成本较低。前提是这些记录有稳定的留存方式。ONES 效能管理可自动收录系统内流转的研发数据并形成分析指标，提供交付效率、交付质量、资源效率、完成情况四个维度的度量实践体系，并预置面向管理人员、项目经理等角色的仪表盘模板；具体指标口径仍需结合组织实际定义。
制度发布后，怎样判断它是否真的在运行？
可以看几个治理流程自身产生的信号：门禁是否按期评审、评审整改项是否按期关闭、例外是否在有效期内闭环、决策事项是否有平均响应时长记录。这些数据反映制度执行质量，而非业务效能。PMO 每季度汇总形成治理报告提交治理委员会，报告包含指标趋势和制度修订建议，让度量结果能反馈到制度本身。
