研发治理制度要解决的是研发过程中“谁在什么条件下做决定、由谁负责、留下什么记录”的问题。它把决策权、责任边界、过程规则和例外处置写成可执行条款，避免评审靠临时召集、例外靠口头同意。本文按治理范围、编写步骤、角色分工、条款示例和运行检查五个部分展开，帮助读者从零建立或修订制度；项目集状态监控与投资决策不在本文范围内。
要点总览（TL;DR）
- 研发治理制度先划定治理对象与决策层级：需求、技术方案、质量、变更、资源、风险六类事项逐项明确是否纳入，决策按项目团队、研发管理部门、跨部门治理会议分层，并写清与项目集运行、投资决策的接口。
- 制度推行按四步走：梳理现有决策与评审活动形成现状清单，编写含触发条件、责任人、时限和输出物的条款，选一到两个团队试运行一个完整周期，修订发布后宣贯并纳入例行检查。
- 角色与交付物要一一对应：治理委员会或研发管理部门定规则、裁例外，研发负责人与项目经理负责执行和发起，质量、架构等专业角色出具评审意见，归口人员维护例外台账与复盘报告。
- 条款写法做到可判定、可追溯、有责任人、有时限，用“涉及架构调整”“跨团队依赖”等可观察事实描述触发条件，避免“重要”“必要时”等模糊表述。
- 制度发布后用检查清单验证运行：抽查评审记录、核对例外台账、追溯决策层级、跟踪复盘改进项，并设置应评审无记录、例外无审批、重大决策无法追溯等阻断项，配套定期复审机制。
研发治理制度先定什么：治理对象与决策层级
制度编写的第一步是划定治理对象和决策层级。范围不清，条款就会写成泛泛的管理要求；层级不清，同一件事会在多个会议上重复讨论，或者无人拍板。建议先用一张对照表把“什么事、谁决定、依据什么、留下什么”固定下来，再进入条款编写。
治理对象：六类事项纳入制度
研发治理通常覆盖以下六类事项，组织可结合自身情况增减，但每类都应明确是否纳入制度：
- 需求：需求准入、优先级调整、范围变更的决策规则。
- 技术方案：重大技术选型、架构调整、外部依赖引入的评审要求。
- 质量：质量门禁的设置、放行条件与豁免审批。
- 变更：已承诺范围或排期的变更申请、评估与批准路径。
- 资源：关键人力调配、跨团队支援的决策归属。
- 风险：重大风险的识别、上报与处置责任。
与项目集运行、投资决策的边界要写清楚：项目集运行关注多项目的状态监控与协调，投资决策关注立项与资源投入的取舍，这两类事项由相应机制处理。研发治理制度聚焦研发过程中的决策规则与过程规则，两者在接口处说明“向谁报送、何时触发”，不重复定义。
决策层级：三层划分与对照表
决策层级可按项目团队、研发管理部门、跨部门治理会议三层划分。具体授权范围需结合组织规模与授权体系确定，下表给出一种常见划分方式，供对照改写：
| 决策层级 | 典型决策事项 | 决策依据 | 留痕要求 |
|---|---|---|---|
| 项目团队 | 迭代内需求排序、一般技术方案选择、日常变更 | 项目计划与团队约定 | 评审记录、变更记录 |
| 研发管理部门 | 跨团队需求准入、质量门禁豁免、重要技术方案 | 制度条款与质量标准 | 评审结论、例外审批单 |
| 跨部门治理会议 | 重大范围调整、关键资源调配、制度修订 | 治理制度与业务目标 | 会议纪要、决议记录 |
层级划分完成后，按“影响面大、争议多、当前最缺规则”的顺序排列条款优先级。第一版制度不必覆盖全部六类对象，先解决高频且容易失控的事项，后续按复审机制补充。
制度落地的操作步骤：从条款编写到试运行
制度从编写到运行可分四步推进。每一步都应有明确的输入、动作、输出和完成标志，避免制度停留在文档阶段。
第一步：梳理现有决策与评审活动
输入：近半年的会议纪要、评审记录、变更单、例外审批记录。动作：逐项列出实际发生的决策与评审活动，标注发起人、参与人、决策方式、是否留痕、是否存在重复评审或缺失环节。输出：现状清单，包含活动名称、频率、痛点。完成标志：清单经研发负责人与项目经理确认，能指出三到五个最需要制度化的事项。
第二步：编写制度条款
输入：现状清单、治理范围与决策层级对照表。动作：为每个纳入治理的事项编写条款，每条写明触发条件、责任人、时限和输出物；条款之间检查是否冲突，与相邻机制的接口是否写清。输出：制度草案与条款框架。完成标志：每条条款都能回答“什么情况下触发、谁负责、多久内完成、产出什么记录”。
第三步：选择试点团队试运行
输入：制度草案、试点团队名单。动作：选择一到两个业务代表性较强、风险可控的团队试运行一个完整周期，记录执行偏差、条款歧义和额外负担；对偏差分类，区分条款问题与执行问题。输出：试运行偏差清单与修订建议。完成标志：偏差清单完成分类，主要条款完成一轮修订。
第四步：修订发布、宣贯与纳入日常检查
输入：修订后的制度文本。动作：正式发布并组织宣贯培训，把评审、例外审批等动作嵌入团队日常流程；将制度执行情况纳入例行检查，明确检查频率与责任人。输出：发布版本制度、培训记录、检查计划。完成标志：试点外团队完成宣贯，首次例行检查按计划执行并形成记录。
角色分工与交付物：谁定规则、谁执行、谁监督
制度无人负责或职责重叠，通常源于角色与交付物没有对应关系。建议在制度正文中附一张角色职责与交付物矩阵，明确每类角色的动作和产出。
| 角色 | 核心职责 | 主要交付物 |
|---|---|---|
| 治理委员会或研发管理部门 | 制定与修订制度、裁决例外、复审制度运行情况 | 制度文档、例外裁决记录、复审报告 |
| 研发负责人 | 在本领域执行制度、组织评审、对评审结论负责 | 评审记录、决策结论 |
| 项目经理 | 按触发条件发起评审与变更申请、维护过程记录 | 变更申请单、评审材料、过程数据 |
| 质量、架构等专业角色 | 按职责范围出具评审意见、把关门禁标准 | 评审意见、门禁检查结论 |
| 制度归口管理人员 | 维护例外台账、汇总复盘报告、跟踪检查项 | 例外台账、复盘报告、检查记录 |
矩阵中每项交付物都应有模板和存放位置，避免记录散落在个人文档中。制度文档、评审记录、例外台账和复盘报告构成制度运行的主要证据链，后续检查直接以此为依据。
当评审、例外审批和过程记录需要在系统中流转时，可以把这些动作放到研发管理工具中承载。ONES 可承载研发过程中的工作项流转与记录留存；ONES Performance 提供效能管理实践体系，支持对系统内产生的研发数据进行多维度分析，并从交付效率、交付质量、资源效率、完成情况四个维度形成度量，还预置了面向管理人员、项目经理等角色视角的仪表盘模板，可减少重复配置。制度检查中需要的过程数据，可借助这类度量结果作为参考，具体配置需结合组织实际流程核验。
示例：一份研发治理制度的核心条款怎么写
条款写法决定制度能否执行。以下示例展示需求准入、技术方案评审、质量门禁与变更例外三类条款的写法，读者可参照改写为组织自己的文本。
需求准入条款示例
第X条 需求准入。新增需求进入排期前，由需求提出人提交需求说明，项目经理在2个工作日内组织准入评审。评审人包括产品负责人与研发负责人；涉及跨团队依赖时，增加相关团队负责人。通过标准为：目标与验收标准明确、依赖方确认可配合、工作量评估完成。评审结论记入需求评审记录，未通过的需求退回补充材料，不进入排期。
技术方案评审条款示例
第X条 技术方案评审。涉及架构调整、核心组件替换或引入外部关键依赖的技术方案，须在开发启动前完成评审。方案提交人提前3个工作日发出评审材料，评审人包括架构负责人与相关模块研发负责人。评审结论分为通过、有条件通过、不通过三类，有条件通过须列明整改项与完成时限。评审记录归档至项目文档，作为后续变更的依据。
质量门禁与变更例外条款示例
第X条 质量门禁与例外。发布前须通过约定的质量门禁检查，检查项与标准由质量角色维护。确因业务需要无法满足门禁时，由项目经理提交例外申请，写明原因、影响范围、补偿措施与有效期，经研发管理部门审批后方可放行。例外申请与审批记录登记至例外台账，有效期届满自动失效，需延续的重新申请。
条款写法要点
- 可判定：触发条件用可观察的事实描述，例如“涉及架构调整”“跨团队依赖”，避免“重要”“必要时”等模糊表述。
- 可追溯：每条条款指明输出记录的名称与存放位置，评审结论、审批意见可回查。
- 有责任人：明确发起人、评审人、审批人，不用“相关方”笼统指代。
- 有时限：写明提交提前量、评审完成时限、例外有效期，便于检查执行偏差。
完成检查：判断制度是否真正运行
制度发布不等于制度运行。判断标准是看关键动作是否按条款发生、记录是否完整、决策是否在约定层级完成。以下检查清单可用于发布后首轮检查，也可作为定期复审的输入。
| 检查项 | 证据来源 | 通过标准 |
|---|---|---|
| 评审是否按触发条件执行 | 评审记录、需求与方案文档 | 抽查样本中应评审事项均有评审记录，缺失率在约定阈值内 |
| 例外是否留痕并按时关闭 | 例外台账 | 例外均有申请与审批记录，过期例外完成关闭或续期 |
| 决策是否在约定层级完成 | 会议纪要、审批记录 | 越级决策与重复决策有说明，重大事项可追溯到对应层级 |
| 复盘是否形成改进项并跟踪 | 复盘报告 | 复盘报告列出改进项、责任人与完成时限，并有跟踪记录 |
| 过程数据是否可用于检查 | 过程数据、度量仪表盘 | 关键指标可按团队与周期取数，数据来源与口径有说明 |
检查中设置阻断项：应评审事项无记录、例外无审批、重大决策无法追溯，任一项出现即判定制度未有效运行，需限期整改并复检。检查结果向治理委员会或研发管理部门报告，作为制度修订依据。
制度还应设置定期复审机制，复审周期与触发条件由组织根据业务变化速度确定，例如每半年复审一次，或在组织架构、业务方向发生重大调整时启动专项复审。复审输出修订清单，明确条款增删改与生效时间，保持制度与研发实际同步。
常见问题
第一版研发治理制度要不要覆盖全部六类治理对象？
不必一次覆盖全部。建议按“影响面大、争议多、当前最缺规则”的顺序排列条款优先级，第一版先解决高频且容易失控的事项，例如需求准入和变更审批，其余对象在复审时逐步补充。覆盖范围过宽会让首版制度难以执行，试运行时偏差集中，反而拖慢推行节奏。
试点团队怎么选，试运行多久比较合适？
试点团队建议兼顾业务代表性与风险可控：选择流程相对完整、负责人愿意配合的团队，避免用最复杂的团队做首轮验证。试运行周期以覆盖一个完整研发周期为宜，让需求准入、技术评审、质量门禁和例外审批都有机会实际发生。试运行期间重点记录条款歧义和执行负担，偏差要区分是条款本身的问题还是执行不到位，前者修订条款，后者补充宣贯和培训。
制度条款和现有研发流程规范是什么关系，会不会重复？
两者可以分工：流程规范描述工作怎么开展，治理制度规定什么条件下必须做决策、由谁决定、留下什么记录。编写时先梳理现有评审与审批活动，把已经在流程中稳定运行的动作引用过来，制度只补充决策权归属、例外处置和留痕要求，避免同一件事在两份文件中出现不同规定。条款之间以及与相邻机制的接口要逐条检查是否冲突。
例外审批放行后，怎么防止例外长期挂着不关闭？
在条款中给例外设定有效期，到期自动失效，需要延续的重新申请。例外申请写明原因、影响范围、补偿措施和有效期，审批记录统一登记到例外台账，由归口管理人员定期核对。检查时把“过期例外是否完成关闭或续期”作为固定检查项，未关闭的例外列入整改清单并明确责任人，避免例外变成默认放行。
制度运行检查的数据从哪里来，需要专门统计吗？
检查证据优先取自日常已经产生的记录：评审记录、变更申请单、例外台账、会议纪要和复盘报告。过程数据可从研发管理系统中按团队和周期取数，减少手工汇总。当评审、例外审批和过程记录在系统中流转时，ONES 可承载工作项流转与记录留存；ONES Performance 提供效能管理实践体系，支持对系统内产生的研发数据进行多维度分析，并从交付效率、交付质量、资源效率、完成情况四个维度形成度量，还预置了面向管理人员、项目经理等角色视角的仪表盘模板，可减少重复配置。具体配置需结合组织实际流程核验。
