研发治理制度执行不下去，常见原因是制度与研发实际工作脱节、执行角色与授权不清、缺少流程承载与记录、缺少反馈与修订机制，四类原因往往叠加出现。诊断时先界定失效范围，再用证据逐项验证假设，按风险从低到高处置并设定验证指标。本文提供一条从症状识别到恢复验证的完整路径，涉及流程承载与记录时，可借助ONES这类研发管理平台把制度条款落到工作项和评审记录上。
要点总览（TL;DR）
- 研发治理制度执行不下去，通常是制度与实际工作脱节、角色授权不清、缺少流程承载与记录、缺少反馈修订机制四类原因叠加，诊断时应逐项用证据验证而非凭症状下结论。
- 判断制度设计问题还是执行问题，可看失效是否集中在少数条款：同一批人在其他条款执行良好、唯独某几条频繁失效，更可能是条款设计问题；普遍失效且执行者表示不知道或没时间做，更可能是授权与承载问题。
- 处置按风险从低到高推进：先明确责任人与授权、简化条款、补充最小记录；再试点调整评审门禁与例外审批；条款大改或流程重构需满足诊断充分、干系人支持、有备份与回退方案三个前置条件并设停止点。
- 恢复验证看评审按时率、例外数量、记录完整率、门禁跳过率等可统计指标，观察窗口覆盖连续两个迭代，避免把短期关注误判为执行习惯形成。
- 复发预防靠固定复盘、条款修订机制和条款责任人三项机制，让制度随业务节奏持续可修订，在早期发现失效。
执行不下去的具体表现与范围界定
“执行不下去”是一个笼统判断，直接讨论原因容易各说各话。第一步是把问题拆成可观察的症状，并界定它影响了哪些团队、哪些阶段、哪些条款。范围界定清楚，后续取证才有针对性，处置也不会误伤正常运行的机制。
常见症状清单
研发治理制度失效通常有以下几类可观察表现，可以对照自查：
- 评审走过场：评审会按时召开，但参会人不看材料，意见停留在格式层面，评审结论与后续实际工作脱节。
- 门禁被跳过：制度规定的技术评审、质量门禁在进度压力下被口头豁免，或先上线后补评审。
- 模板填了不用：需求文档、设计说明、变更记录按模板填写，但填写内容无人阅读，也不影响任何决策。
- 例外频繁：制度设置了例外通道，实际执行中例外成为常态，标准路径反而少见。
- 记录缺失：评审结论、豁免理由、责任人签字没有留存，事后无法追溯某项决定由谁做出。
按三个维度界定范围
症状确认后，需要回答“问题有多大”。建议按团队、阶段、制度条款三个维度交叉界定：哪些团队失效明显、哪些团队执行正常；失效集中在需求阶段、开发阶段还是发布阶段；是整份制度失效，还是某几条关键条款失效。范围界定表可以这样填写：
| 症状 | 涉及团队 | 涉及条款 | 影响程度 |
|---|---|---|---|
| 技术评审结论未记录 | 平台组、业务组A | 评审管理第3条 | 高：无法追溯决策依据 |
| 发布门禁被跳过 | 业务组B | 发布管理第5条 | 高：质量风险直接暴露 |
| 需求模板填写率低 | 全部团队 | 需求管理第2条 | 中：影响需求可追溯性 |
| 例外审批频繁 | 业务组A | 变更管理第4条 | 中：标准路径被架空 |
影响程度可以按“是否直接影响交付质量或决策依据”来分级，不必追求精确量化。范围界定完成后，还应明确本文讨论的边界：这里聚焦组织管理机制层面的制度执行问题，项目集运行状态监控、投资决策与项目组合治理属于另外的管理议题，不在本文展开。如果症状主要出现在项目集层面的资源调配或投资优先级上，应转向对应的治理机制排查。
原因假设与排除证据
症状只是线索，原因需要证据支撑。实践中常见的错误是把某个显眼症状直接当成结论，例如看到评审走过场就断定“团队不重视”，据此加强考核，结果问题依旧。正确做法是先列出原因假设，再为每个假设设计验证证据，按排查顺序逐项确认或排除。
四类原因假设与验证证据
| 原因假设 | 验证证据 | 排查顺序 |
|---|---|---|
| 制度与研发实际工作脱节 | 抽查制度条款与近期实际工作项的对应关系；访谈一线人员，确认条款在其工作中是否有可操作落点；统计因条款不适用而产生的例外 | 第一步：成本低、覆盖面广，优先排查 |
| 角色与授权不清，评审无人负责 | 查阅制度中的角色定义与授权范围；核对评审记录中的实际参会人与签字人；访谈评审组织者，确认其是否有权做出结论 | 第二步：与第一步并行，访谈即可完成 |
| 缺少流程承载与记录，执行无法追溯 | 抽查评审、门禁、变更的记录完整率；确认制度要求的关键节点是否有系统或文档承载；统计“做了但没留痕”的比例 | 第三步：需要调取记录，耗时稍长 |
| 缺少反馈与修订机制 | 查阅制度最近一次修订时间与修订依据；确认是否有收集执行问题的固定渠道；访谈制度维护人，了解问题上报后的处理路径 | 第四步：文档与访谈结合，可最后完成 |
取证方式与判断标准
访谈、记录抽查、例外统计是三种主要取证方式，各有适用场景。访谈适合快速了解角色授权和条款可操作性，建议覆盖制度维护人、评审组织者和一线执行者三类角色，每类至少两到三人，避免单一视角。记录抽查适合验证执行是否留痕，抽取近三个月的评审记录和门禁记录，按条款逐项核对。例外统计适合判断制度与现实的距离，例外数量持续偏高，通常说明标准路径与实际工作不匹配。
判断是制度设计问题还是执行问题，可以看一个关键信号：如果同一批人在其他条款上执行良好，唯独某几条频繁失效，问题更可能出在条款设计；如果所有条款普遍失效，且访谈中执行者普遍表示“不知道要做”或“没时间做”，问题更可能出在角色授权与流程承载。两类问题经常同时存在，诊断结论应写明每条已确认原因的证据，未确认的假设保留为待验证项，不写入处置方案。
按原因分层的处置步骤
原因确认后，处置动作应按风险从低到高排序。低风险动作可以先做，快速验证方向；中风险动作涉及流程调整，需要小范围试点；高风险动作改动制度核心条款或重构流程，必须设定前置条件和停止点，避免在问题未查清时大改制度造成新的混乱。
低风险动作：先做且可快速验证
- 明确角色与授权：为每条关键条款指定唯一责任人，写明其可以做出的决定范围，例如评审组织者有权判定评审通过与否，无需层层上报。产出物是角色授权表，完成标志是责任人确认签字。
- 简化条款：把无法落到具体工作项的条款改写为可操作动作，例如把“充分评审”改为“评审需覆盖接口设计、性能影响、回滚方案三项，结论记录在评审单”。
- 补充记录：为评审、门禁、例外建立最小记录要求，只记录结论、责任人和时间，不追求大而全的模板。
中风险动作：小范围试点后推广
- 调整评审门禁：根据诊断结果合并冗余评审、取消无决策价值的评审，把门禁设置在真正影响质量的节点。调整前选择一个团队试点一个迭代，观察门禁是否被跳过、评审是否产生有效结论。
- 设置例外审批：为确实需要绕开标准路径的场景设置例外通道，明确审批人、有效期和补做要求，并统计例外数量作为制度健康度指标。例外审批的前提是标准路径本身合理，否则例外只会掩盖设计问题。
高风险动作：大改条款或重构流程的前置条件
制度条款大改或流程重构属于高风险动作，启动前应满足三个条件：已完成证据充分的诊断，确认现有制度的结构性问题无法通过局部调整解决；已取得关键干系人（研发负责人、质量负责人、制度维护人）的明确支持；已准备好旧制度的完整备份和回退方案。执行过程中设置停止点：试点团队出现交付质量下降或执行成本明显上升时暂停推广，回到诊断阶段复核假设。流程重构期间，新旧制度并行运行的时间不宜过长，应明确切换日期和切换后的责任归属。
处置动作与原因的对应关系
| 已确认原因 | 对应处置动作 | 风险等级 | 停止点 |
|---|---|---|---|
| 制度与实际工作脱节 | 简化条款、重写可操作动作 | 低 | 条款改写后一线仍无法执行，回到访谈复核 |
| 角色与授权不清 | 明确责任人、发布授权表 | 低 | 责任人拒绝承接授权，需上级协调 |
| 缺少流程承载与记录 | 补充最小记录要求、引入工具承载 | 中 | 记录成本超过执行收益，缩减记录范围 |
| 评审门禁设计不合理 | 合并评审、调整门禁节点 | 中 | 试点迭代门禁跳过率未下降 |
| 制度结构性失效 | 条款大改或流程重构 | 高 | 试点质量下降或成本明显上升 |
流程承载是处置中容易被忽略的一环。制度条款如果只写在文档里，执行与否依赖个人记忆，记录也难以追溯。把评审、门禁、例外审批落到具体工作项上，让每次评审有对应的任务、结论和责任人，执行情况才能被统计和复盘。ONES的工作项管理与评审记录能力可以承载这类流程：制度条款对应到工作项类型和状态流转，评审结论随任务留存，例外审批留下审批记录，管理者据此查看执行情况，而不必依赖事后补文档。工具承载的前提是条款本身已经简化到可操作，否则只是把模糊要求搬进系统。
恢复验证与复发预防
处置动作落地后，需要验证制度是否真正恢复执行，而不是只看“有没有发通知、有没有改文档”。验证应围绕可统计的指标展开，设定观察窗口，并把复盘和修订固化为常规机制，防止问题再次积累。
验证指标与观察窗口
| 指标 | 口径 | 观察窗口 | 恢复参考 |
|---|---|---|---|
| 评审按时率 | 按制度要求应召开的评审中，按时召开且形成结论的比例 | 处置后连续两个迭代 | 较处置前明显上升并稳定 |
| 例外数量 | 单位时间内例外审批的次数及占标准路径的比例 | 处置后一个月 | 例外占比下降，且每笔例外有审批记录 |
| 记录完整率 | 抽查的评审、门禁、变更记录中，结论、责任人、时间齐全的比例 | 处置后一个月 | 抽查样本完整率达到约定水平 |
| 门禁跳过率 | 应经过门禁的发布中，实际跳过门禁的比例 | 处置后连续两个迭代 | 跳过率下降且无未审批跳过 |
观察窗口不宜过短。一个迭代内指标好转可能只是处置动作带来的短期关注，连续两个迭代保持稳定才说明执行习惯已经形成。验证时同时关注反向信号：如果评审按时率上升但评审结论质量没有改善，说明执行停留在形式层面，需要回到条款可操作性继续调整。
复发预防检查项
- 定期复盘：每季度用一次固定会议复盘制度执行情况，输入是指标数据和例外统计，输出是待修订条款清单，责任人为制度维护人。
- 条款修订机制：明确谁可以提出修订、修订由谁审批、修订后如何通知到执行者。修订记录随制度文档留存，避免条款版本混乱。
- 责任人机制：每条关键条款保留唯一责任人，责任人变动时完成交接，防止条款因人员流动而无人维护。
- 新团队接入：新团队或新项目启动时，把制度条款和记录要求纳入启动检查，避免执行标准在扩张中稀释。
复发预防的核心是让制度保持可修订。研发治理制度服务于研发工作，业务节奏、团队结构、技术栈变化后，条款需要随之调整。把复盘、修订、责任人三项机制固定下来，制度失效就能在早期被发现和纠正，而不是等到执行全面停滞再启动一轮大改。
常见问题
制度条款本身没问题，为什么执行还是不到位？
条款合理不代表能被执行。常见卡点在于角色与授权：制度写了“需评审”，但没写谁组织、谁有权下结论、结论不通过时由谁决策。评审组织者没有授权，只能把争议层层上报，评审就退化为形式。另一类卡点是承载缺失，制度要求的关键节点没有对应的工作项或记录位置，执行与否依赖个人记忆，事后无法追溯。排查时先核对每条关键条款是否有唯一责任人、明确授权范围和记录落点，再判断是否需要调整条款本身。
例外审批频繁，应该收紧审批还是修改制度？
先看例外的成因再决定。如果例外集中在少数条款，且申请理由高度相似，通常说明标准路径与实际工作不匹配，应收紧例外之前先修订条款，让标准路径可执行；如果例外分散、理由各异，可能是审批门槛过低，需要明确审批人、有效期和补做要求，并统计例外占比作为制度健康度指标。例外审批的前提是标准路径本身合理，否则收紧审批只会把绕行推到更隐蔽的地方。
小团队人少事多，制度执行成本会不会过高？
执行成本主要来自记录和评审的颗粒度，而非制度本身。团队规模较小时，可以只保留影响交付质量的关键节点，记录要求压缩到结论、责任人、时间三项，评审合并到已有的迭代会议中，避免单独增设会议。判断标准是这条记录或这次评审是否会影响后续决策；不影响决策的环节可以简化。简化后仍需保留可追溯性，否则出问题时无法定位责任和依据。
制度修订后，如何让新老团队执行同一套标准？
修订生效时同步做三件事：明确切换日期和切换后的责任归属，避免新旧版本长期并行；把修订内容和变更点通知到所有执行者，并保留修订记录随制度文档留存；在新团队或新项目启动检查中纳入制度条款和记录要求，防止执行标准在团队扩张中稀释。切换后一个观察窗口内抽查执行情况，发现理解偏差及时澄清，而不是等到季度复盘才处理。
验证指标好转了，是否说明制度已经恢复执行？
指标好转是必要信号，但需要排除形式化执行。可以对照看两组数据：评审按时率上升的同时，评审结论是否真正改变了工作项或决策；记录完整率达标的同时，记录内容是否具备可读的决策依据。如果指标改善集中在处置后的第一个迭代，随后回落，说明只是短期关注带来的效果。连续两个迭代保持稳定，且反向信号没有出现，才可以判断执行习惯已经形成。
