制定研发治理制度，核心是把“谁在什么条件下做什么决策、留下什么证据”写成可执行条款。本文按范围划定、六步制定、角色分工、条款示例、试点修订、发布前验收的顺序展开，适用于正在从零搭建或重构研发治理体系的组织。文中条款为演示情景，需结合组织实际调整。
要点总览（TL;DR）
- 先按决策对象划定研发治理制度的范围：技术方案、阶段放行、质量门禁归制度，跨项目协调归项目集运行，立项投资归项目组合决策，同一事项只设一处决策权。
- 用六步法制定：识别治理问题、确定决策权与评审节点、撰写条款、评审征求意见、试点运行、发布与修订，每步明确输入、输出、负责人和完成标志。
- 条款按“适用对象、触发条件、动作、证据、例外”五要素撰写，评审与例外要求须对应可留存的记录，无法验证的要求应补充记录或删除。
- 制度发起人、治理委员会、PMO、研发团队、质量与审计五类角色在制定与运行阶段各有交付物，升级路径要写明时限。
- 发布前按范围、角色、条款、证据、例外、修订六类检查项验收，范围不清与决策权重叠是主要阻断项。
先定治理范围：哪些事项进制度，哪些归其他机制
研发治理制度管的是研发过程中的决策与约束：谁有权批准什么、哪些节点必须评审、评审要产出什么记录、偏离规则时如何申请例外。它回答“规则怎么定、决策怎么做、证据怎么留”，不承担项目集层面的进度协调与资源调度，也不替代项目组合层面的投资取舍。把这三类事项混写在一份文件里，制度会变得又长又难执行，出问题时也找不到责任主体。
划分边界的实用方法是按“决策对象”归类：涉及单个研发项目或产品线的技术方案、阶段放行、质量门禁，归研发治理制度；涉及多个项目的优先级排序、跨项目资源调配、依赖协调，归项目集运行机制；涉及立项投资、预算分配、项目终止，归项目组合投资决策机制。同一事项只在一个机制中设定决策权，其他机制引用而不重复定义。
范围清单建议用三列表格填写：事项、归属机制、责任角色。填写时逐条问两个问题——“这个决策由谁拍板”“拍板依据的记录在哪里”，答不上来的事项说明归属尚未理清，需要先确认再入制度。清单由制度发起人起草，PMO汇总，治理委员会确认后作为制度正文的附件，后续新增事项先进清单再决定是否入制度。
| 事项 | 归属机制 | 责任角色 |
|---|---|---|
| 技术方案评审与阶段放行 | 研发治理制度 | 技术评审组、研发负责人 |
| 质量门禁与缺陷放行标准 | 研发治理制度 | 质量负责人 |
| 跨项目优先级与资源协调 | 项目集运行机制 | 项目集经理 |
| 立项投资与预算审批 | 项目组合投资决策机制 | 投资决策委员会 |
核心步骤：从治理问题到制度条款的六步法
制度制定容易写成原则汇编，原因是从“应该重视什么”出发，而不是从“现在哪里出了问题”出发。六步法要求每一步都有明确输入、动作、输出和完成标志，避免制度停留在口号层面。
| 步骤 | 输入 | 动作 | 输出 | 负责人 | 完成标志 |
|---|---|---|---|---|---|
| 1. 识别治理问题 | 近一年评审记录、缺陷与返工数据、复盘纪要、审计发现 | 归纳高频问题，标注问题对应的决策缺失或执行偏差 | 治理问题清单（问题、影响、涉及环节） | PMO | 问题清单经治理委员会确认，每项有事实依据 |
| 2. 确定决策权与评审节点 | 治理问题清单、现有流程 | 为每类决策指定拍板角色，确定必须评审的节点及触发条件 | 决策权矩阵与评审节点表 | 制度发起人 | 每个节点有唯一责任角色，无权限重叠 |
| 3. 撰写条款 | 决策权矩阵、评审节点表 | 按“适用对象、触发条件、动作、证据、例外”五要素成文 | 制度条款初稿 | PMO牵头，各角色参与 | 每条条款可被第三方按字面执行 |
| 4. 评审与征求意见 | 条款初稿 | 组织研发、质量、审计角色逐条评审，记录分歧与处理结论 | 评审意见表与修订稿 | 治理委员会 | 分歧项全部有处理结论 |
| 5. 试点运行 | 修订稿、试点范围 | 在选定团队运行一个周期，收集执行障碍 | 试点反馈记录 | 试点团队负责人 | 试点周期结束且反馈已归类 |
| 6. 发布与修订 | 试点反馈、最终稿 | 正式发布，建立版本号与修订触发条件 | 发布版本与修订记录 | 制度发起人 | 版本生效日期与责任人明确 |
六步中第2步最关键：决策权不清，条款写得再细也会在执行时反复请示。确定决策权时，对每类决策只指定一个最终拍板角色，其他角色提供输入意见；评审节点则按风险设定，高风险节点强制评审，低风险节点可采用抽查或事后复核，避免所有节点一律评审导致流程拥堵。
角色与交付物：谁定制度、谁执行、谁监督
制度制定与运行涉及五类角色，职责和交付物需要在制度正文中写清，避免出现“制度由PMO写、执行靠自觉、监督没人管”的局面。
| 角色 | 制定阶段职责与交付物 | 运行阶段职责与交付物 |
|---|---|---|
| 制度发起人 | 提出制定动因，确认治理范围清单，主持决策权划分 | 批准例外申请中的重大事项，发起修订 |
| 治理委员会 | 确认问题清单与范围，评审条款并裁决分歧 | 定期审议制度执行情况，决定修订方向 |
| PMO | 起草条款，组织评审与试点，维护版本记录 | 跟踪评审节点执行，汇总例外与偏差数据 |
| 研发团队 | 提供现状问题与执行反馈 | 按条款执行评审与记录，提出例外申请 |
| 质量与审计 | 评审条款的可检查性，确认证据要求 | 抽查记录完整性，出具审计发现 |
决策与升级路径需要单独写明：常规事项由节点责任角色决策；超出其权限的事项升级至治理委员会；涉及投资或跨项目资源的，按范围清单转入对应机制处理。升级路径要给出时限，例如“升级申请提交后三个工作日内给出答复”，避免事项在升级环节停滞。
制度条款示例：评审节点与例外处理怎么写
可执行条款的共同特征是：读完之后知道什么时候触发、谁参与、达到什么标准算通过、留下什么记录。以下两条为演示情景，可直接改写后使用。
评审节点条款示例
“凡涉及核心模块架构变更或对外接口调整的研发任务，在开发启动前须完成技术评审。评审由技术评审组组织，参与角色包括架构负责人、相关模块研发负责人、测试负责人。通过标准为：变更影响范围已列明、回滚方案已确认、测试范围已界定，三项缺一不通过。评审结论与参与人意见记入评审记录，关联至对应研发任务，未附评审记录的任务不得进入开发状态。”
例外处理条款示例
“因交付时限等原因无法按条款执行评审的，由任务负责人提交例外申请，写明偏离条款、原因、风险与补偿措施，经研发负责人审批后生效，单次例外有效期不超过两周。例外事项须在生效后十个工作日内完成复盘，复盘结论记入例外台账。同一团队同一季度例外超过三次的，由PMO提交治理委员会分析条款合理性。”
条款与证据要一一对应：评审条款对应评审记录，例外条款对应申请单与复盘记录。撰写时逐条检查“这条要求能否从记录中验证”，无法验证的要求要么补充记录要求，要么删除。评审记录、例外申请与复盘结论需要在研发管理工具中留存并可追溯，ONES 的任务流转与记录能力可承载这类过程留痕；ONES 效能管理还能基于系统内流转的数据形成分析指标，帮助治理委员会在定期审议时查看评审执行与例外分布情况，具体配置方式以产品实际版本为准。
试点与修订：让制度跑起来并持续校准
制度发布不等于落地。试点的作用是在小范围内暴露条款与实际的冲突，常见冲突包括节点过多拖慢交付、证据要求超出团队记录能力、例外审批链条过长。
试点范围建议选择一个完整研发团队或一条产品线，周期覆盖至少一个完整交付周期，使评审节点和例外处理都能被实际触发。试点期间保留原有做法作为对照，便于判断制度带来的变化。
反馈收集设三个渠道：节点执行人记录执行障碍，团队负责人在周期末提交汇总反馈，质量与审计角色抽查记录完整性。评估指标可包括评审按时完成率、例外申请数量与分布、因评审发现的问题占比。指标口径在试点前确定，避免事后解释。
修订触发条件写入制度：条款与实际冲突导致无法执行、例外集中出现在同一节点、组织架构或研发模式发生调整、外部合规要求变化。每次修订记录版本号、修订内容、生效日期与批准人，旧版本归档保留，便于追溯历史决策依据。
完成检查：制度可执行性的验收清单
发布前按六类检查项逐项核对，每项给出通过标准与所需证据。任一项不通过即视为阻断项，完成整改后方可发布。
| 检查类别 | 检查项 | 通过标准 | 证据 |
|---|---|---|---|
| 范围 | 治理范围清单是否完整 | 每项事项有唯一归属机制与责任角色 | 范围清单及治理委员会确认记录 |
| 角色 | 决策权是否唯一 | 每类决策只有一个最终拍板角色，升级路径有时限 | 决策权矩阵 |
| 条款 | 条款是否可执行 | 每条含适用对象、触发条件、动作、证据、例外 | 条款评审意见表 |
| 证据 | 证据要求是否可验证 | 每条要求对应可留存的记录，抽查可复现 | 证据清单与抽查记录 |
| 例外 | 例外处理是否闭环 | 申请、审批、时限、复盘四要素齐全 | 例外台账模板 |
| 修订 | 修订机制是否明确 | 触发条件、版本管理、批准人已写入 | 修订记录模板 |
阻断项集中在范围与角色两类：范围不清会导致制度与项目集、投资机制冲突；决策权重叠会导致执行时反复请示。这两类通过后，条款与证据的检查以抽样方式验证，抽取若干条条款模拟执行一遍，确认记录要求能够落地。全部检查项通过并留存证据后，制度进入发布流程。
常见问题
研发治理制度和项目集管理、投资决策的边界怎么划？
按决策对象划分：涉及单个研发项目或产品线的技术方案、阶段放行、质量门禁，归研发治理制度；涉及多个项目的优先级排序、跨项目资源调配与依赖协调，归项目集运行机制；涉及立项投资、预算分配与项目终止，归项目组合投资决策机制。同一事项只在一个机制中设定决策权，其他机制引用而不重复定义。范围清单由制度发起人起草、PMO汇总、治理委员会确认，后续新增事项先进清单再决定是否入制度。
制度条款写出来团队执行不了，通常是什么原因？
常见原因有三类：一是条款只写原则，没有触发条件和通过标准，执行人无法判断何时启动、做到什么程度算完成；二是证据要求超出团队现有记录能力，要求无法从记录中验证；三是评审节点设得过密，所有节点一律评审导致流程拥堵。对应做法是逐条检查“这条要求能否从记录中验证”，无法验证的补充记录要求或删除；评审节点按风险分级，高风险强制评审，低风险采用抽查或事后复核。
试点应该选多大范围、运行多久？
建议选择一个完整研发团队或一条产品线，周期覆盖至少一个完整交付周期，使评审节点和例外处理都能被实际触发。试点期间可保留原有做法作为对照，便于判断制度带来的变化。反馈渠道设三条：节点执行人记录执行障碍，团队负责人在周期末提交汇总反馈，质量与审计角色抽查记录完整性。评估指标如评审按时完成率、例外申请数量与分布，口径应在试点前确定。
例外申请频繁出现，说明制度有问题吗？
例外集中出现在同一节点，通常说明该条款与实际执行条件存在冲突，可作为修订触发条件之一。制度中可约定：同一团队同一季度例外超过设定次数时，由PMO提交治理委员会分析条款合理性。同时要区分两类情况：因交付时限等合理原因产生的例外，按申请、审批、时限、复盘闭环处理；因条款本身不可执行产生的例外，则进入修订流程，修订时记录版本号、修订内容、生效日期与批准人。
评审记录和例外台账放在哪里比较合适？
关键是记录能关联到对应研发任务并可追溯。评审结论与参与人意见应关联至具体任务，未附评审记录的任务不进入下一状态；例外申请单与复盘结论进入例外台账，便于统计分布。ONES 的任务流转与记录能力可承载这类过程留痕，ONES 效能管理能基于系统内流转的数据形成分析指标，帮助治理委员会定期审议时查看评审执行与例外分布，具体配置方式以产品实际版本为准。
