研发流程裁剪规则要解决的是“哪些活动必须做、哪些可以合并或省略、由谁批准、留下什么证据”。本文给出一套可直接落地的规则骨架：先建立流程活动基线，再按风险等级、产品类型、变更性质和交付节奏设定裁剪维度，为每个可裁剪活动写明条件、替代控制、审批角色与记录要求，最后用试点验证并纳入流程评审。
要点总览（TL;DR）
- 裁剪规则要写清四件事：哪些活动必做、哪些可合并或省略、由谁批准、留下什么证据；缺少任何一块，规则都会退化成项目自行决定。
- 规则建立在流程活动基线之上，按项目风险等级、产品类型、变更性质、交付节奏设定维度，判定结论收敛为必做、可合并、可省略、可替代控制四类。
- 制定过程分五步：梳理活动清单、写裁剪条件与替代控制、确定审批角色与层级、规定记录字段、发布并纳入流程评审。
- 裁剪申请由项目负责人提出，质量或流程负责人审核条件符合性，技术负责人确认替代控制可行，流程管理岗维护台账并在评审中抽查。
- 规则发布前用检查清单核对必做覆盖、条件完整、审批到岗、记录可追溯和试点验证，任一项不满足先补齐再发布。
裁剪规则先定什么：基线、维度与判定口径
裁剪规则的本质是一套判定机制，而非逐条讨论某个活动删不删。规则要能回答四个问题：这项活动在什么条件下可以不做？不做之后用什么控制补位？谁有权批准？留下什么记录？这四个问题对应规则的四块内容：基线、维度、判定口径和审批记录。缺少任何一块，规则都会退化成“项目自己看着办”。
流程活动基线：裁剪的参照物
裁剪的前提是有一条完整的活动清单作为参照。基线通常来自三个来源：组织共用流程文件中的活动定义、历史项目的实际活动清单、现有流程评审记录中沉淀的检查项。基线要写到活动级别，例如“需求评审”“设计评审”“代码走查”“集成测试”“上线前安全检查”，而不是停留在“需求阶段”“开发阶段”这种阶段名称上。基线不清晰时，先补基线再谈裁剪，否则裁剪结论无法对照，也无法审计。
基线还要标注每项活动的属性：是否为法规或合同强制要求、是否与交付质量直接相关、是否有下游活动依赖它的产出。这些属性决定了后续哪些活动可以被划入“必做”，哪些可以进入裁剪讨论范围。
裁剪维度：用少量维度稳定区分结论
维度不宜多，以能稳定区分判定结论为准。常用的四个维度是项目风险等级、产品类型、变更性质和交付节奏。风险等级可按项目对业务的影响、技术成熟度、合规要求综合判定；产品类型区分平台类、应用类、定制交付类；变更性质区分新功能、缺陷修复、配置调整；交付节奏区分常规迭代与紧急发布。维度取值要写成可判定的档位，例如风险等级分为高、中、低三档，并给出每档的判定依据，避免评审时各说各话。
判定口径：四类结论
判定结论建议收敛为四类：必做、可合并、可省略、可替代控制。必做活动在任何维度组合下都不得裁剪；可合并指活动保留但可与相邻活动合并执行，例如把设计评审与需求评审合并为一次评审会；可省略指在特定维度组合下可以不执行；可替代控制指活动本身省略，但必须用另一种控制手段补位，例如省略独立代码走查，改为提交前静态检查加同行评审。凡给出“可省略”结论的活动，必须同时写明替代控制，避免出现控制真空。
| 维度 | 取值示例 | 对应裁剪结论 |
|---|---|---|
| 项目风险等级 | 高 / 中 / 低 | 高风险项目：关键评审、安全活动为必做；低风险项目：部分评审可合并 |
| 产品类型 | 平台类 / 应用类 / 定制交付类 | 平台类：架构评审必做；定制交付类：可按合同要求调整文档类活动 |
| 变更性质 | 新功能 / 缺陷修复 / 配置调整 | 缺陷修复：可省略完整需求评审，保留影响分析；配置调整：可替代控制 |
| 交付节奏 | 常规迭代 / 紧急发布 | 紧急发布：评审可合并为一次快速评审，事后补记录 |
规则还要说明它与组织共用流程的关系：裁剪规则是共用流程的配套判定文件，不另起一套流程。共用流程定义“标准做法是什么”，裁剪规则定义“在什么条件下可以偏离标准做法、偏离时如何控制”。两者版本要联动，共用流程修订后，裁剪规则中引用的活动名称和编号要同步更新。
按步骤制定裁剪规则：从活动清单到审批条件
制定过程分五步，每步都有明确的输入、动作、输出和完成标志。按顺序推进，可以避免规则写成原则性描述而无法执行。
步骤一：梳理活动清单并标注必做项
输入是组织共用流程文件和历史项目活动清单。动作是把活动拆到可执行粒度，逐项标注是否属于法规、合同或安全强制要求，是否被下游活动依赖。输出是一张带属性的活动清单。完成标志是清单中的每项活动都有唯一编号、责任角色和必做/可裁剪标记，且必做项有明确依据。
步骤二：为可裁剪活动写裁剪条件与替代控制
输入是步骤一的活动清单和选定的裁剪维度。动作是对每项可裁剪活动写明：在哪些维度取值组合下可合并、可省略或可替代控制，以及替代控制的具体做法。输出是活动级的裁剪条件表。完成标志是每项可裁剪活动至少有一条条件，且每条“可省略”结论都配有替代控制，没有只写“视情况而定”的条目。
步骤三：确定审批角色与审批层级
输入是裁剪条件表和活动的风险属性。动作是按影响面匹配审批层级：影响交付质量、安全或合规的裁剪，审批层级提高到质量负责人或技术负责人；仅影响文档形式或活动合并顺序的裁剪，可下放到项目负责人审批。输出是审批矩阵，写明每类裁剪结论对应的审批岗位。完成标志是每个可裁剪活动都能在矩阵中找到唯一审批角色，不存在“多人均可批”的模糊地带。
步骤四：规定记录与证据要求
输入是审批矩阵。动作是定义裁剪申请和审批记录必须包含的字段：项目标识、风险等级判定依据、被裁剪活动编号、裁剪理由、替代控制措施、审批人、审批日期。输出是记录模板和裁剪台账的字段定义。完成标志是任一裁剪记录都能凭字段还原“谁在什么条件下批准了什么偏离、用什么控制补位”。
步骤五：发布规则并纳入流程评审
输入是前四步的全部产出。动作是发布规则文件，选定一至两个项目试点，收集执行中的歧义点并修订，然后把裁剪规则的执行情况加入流程评审检查项，设定复核周期。输出是正式发布的规则文件和评审检查项。完成标志是试点项目按规则完成了至少一次完整裁剪申请与审批，评审检查项中已包含裁剪记录抽查条目。
角色与交付物：谁提裁剪、谁批、谁留证据
规则能否落地，取决于每个角色是否清楚自己交什么。裁剪过程中通常涉及四类角色，职责和交付物如下表。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 项目负责人 | 判定项目风险等级，识别需要裁剪的活动，提出裁剪申请 | 裁剪申请单：项目背景、风险等级及依据、被裁剪活动、裁剪理由、拟采用的替代控制 |
| 质量或流程负责人 | 对照裁剪规则审核申请是否符合条件，检查替代控制是否覆盖原有控制目标 | 审核意见：条件符合性结论、需补充的控制措施、是否提交上级审批 |
| 技术负责人 | 确认替代控制在本项目技术条件下可行，评估对交付质量的影响 | 技术确认意见：替代控制可行性结论、遗留风险说明 |
| 流程管理岗 | 维护裁剪台账，汇总裁剪记录，在流程评审中抽查执行情况 | 裁剪台账：按项目记录裁剪活动、审批结论、执行状态；评审抽查记录 |
审批记录与裁剪台账的维护责任要写进规则，不能默认由提申请的人自己归档。台账建议按项目和时间两个口径可查：按项目能还原某个项目裁剪了哪些活动，按时间能看出某类裁剪是否被频繁使用、是否需要修订规则。裁剪申请、审批意见和台账如果分散在邮件和聊天记录里，审计时很难还原，建议放在统一的工作项或文档中承载。ONES 支持在工作项中配置审批字段与状态流转，并把裁剪申请作为文档关联到项目，审批记录和台账可以在同一处留存和检索，便于流程评审时直接抽查。
示例：一个迭代项目的裁剪申请怎么写
以下为演示情景，用于说明字段填写方式，不代表任何真实项目。某应用类产品的一个常规迭代，计划在两周内完成三项缺陷修复和一项配置调整，项目负责人按规则发起裁剪申请。
项目背景与风险等级判定：项目标识为“订单模块 3 月迭代”，产品类型为应用类，变更性质为缺陷修复与配置调整，交付节奏为常规迭代。按规则判定风险等级为中：不涉及资金结算主链路，但影响订单查询结果展示。判定依据填写为“变更范围限于查询展示层，无数据结构变更，无合规强制要求”。
被裁剪活动及理由：申请将“完整需求评审”合并到“技术方案评审”中一次完成，理由是本迭代无新增需求，仅修复已知缺陷；申请省略“独立代码走查”，理由是两个缺陷修复各涉及不超过五十行代码，且已有自动化回归用例覆盖。
替代控制措施：需求评审合并后，评审记录中须包含缺陷影响范围分析和回归范围确认；代码走查省略后，改为提交前静态检查零告警加一名同模块开发人员同行评审，评审意见附在合并请求中。
审批结论与记录字段：质量负责人审核认为条件符合，要求补充回归用例清单；技术负责人确认同行评审安排可行。审批结论为“同意，附条件执行”。记录字段包括：项目标识、风险等级及依据、被裁剪活动编号、裁剪理由、替代控制、审批人、审批日期、执行状态。该记录进入裁剪台账，在下次流程评审时抽查执行情况。
完成检查：裁剪规则是否可执行、可审计
规则发布前，用以下清单逐项核对。任一项不满足，说明规则还存在执行或审计缺口，应先补齐再发布。
- 必做活动是否全部覆盖：活动清单中标注为必做的活动，在裁剪条件表中均无“可省略”结论，且有明确的依据说明。
- 每个可裁剪活动是否都有条件与替代控制：不存在只写“视情况而定”或“由项目决定”的条目；每条“可省略”结论都配有可执行的替代控制。
- 审批角色是否明确到岗位：审批矩阵中每个裁剪结论对应唯一岗位，不出现“相关负责人”这类无法追责的表述。
- 裁剪记录是否可追溯：记录字段完整，能凭台账还原项目、活动、理由、替代控制、审批人和日期；记录集中存放，不依赖个人邮箱。
- 规则是否纳入流程评审与定期复核：流程评审检查项中包含裁剪记录抽查条目，规则文件有明确的复核周期和修订责任人。
- 是否经过试点验证：至少一个项目按规则完成完整裁剪申请与审批，执行中发现的歧义已回写到规则中。
这套检查清单也可以作为规则修订时的自检工具。当组织共用流程发生变化，或某类裁剪在台账中频繁出现，说明规则中的维度取值或条件需要调整，按清单重新核对一遍即可判断修订范围。
常见问题
低风险项目能否直接省略评审活动？
可以省略部分评审，前提是规则中已为该项活动写明低风险档位下的裁剪条件，并配套替代控制。例如缺陷修复类变更可省略完整需求评审，保留影响范围分析；省略后仍要有记录说明依据。若规则中该活动标注为必做，则任何风险等级下都不得省略，需要先修订规则再执行。
裁剪申请被驳回后应该怎么处理？
驳回意见应写明不满足的条件，例如替代控制未覆盖原有控制目标、风险等级判定依据不足。项目负责人按意见补充材料后重新提交，或改为按标准流程执行被裁剪活动。若同一类申请反复被驳回，说明规则中的条件描述或维度取值存在歧义，应在规则复核时修订，而不是逐次特批。
紧急发布场景下审批来不及走完怎么办？
规则中可以预设紧急通道：允许先执行后补审批，但必须限定适用条件，例如仅限影响线上可用性的故障修复，并规定补审批的时限和补录字段。紧急通道同样要留替代控制和记录，事后在流程评审中抽查。紧急通道使用频率过高时，应回头检查常规审批层级是否设置过重。
裁剪台账应该记录到什么粒度？
建议按“项目＋被裁剪活动”记录，每条包含项目标识、风险等级及依据、活动编号、裁剪理由、替代控制、审批人、审批日期和执行状态。这个粒度既能还原单个项目的裁剪全貌，也能按活动统计某类裁剪的使用频率，为规则修订提供依据。只记录项目层面的汇总结论，审计时无法核对具体活动的控制是否到位。
组织共用流程修订后，裁剪规则要同步改哪些内容？
至少同步三处：活动名称与编号、必做项标记、审批矩阵中引用的角色。共用流程新增活动时，要判断它进入必做清单还是可裁剪范围，并补写对应条件与替代控制。建议在规则文件中标注所依据的共用流程版本号，版本变化时触发一次规则复核，避免规则引用已失效的活动定义。
