研发流程裁剪的核心做法，是先建立组织共用的流程基线，再按项目类型、风险等级和交付约束，对活动、评审、文档和角色职责做有依据的增删与合并。裁剪的目标是让流程强度与项目风险匹配，同时保留必要的质量与合规控制点。本文按“定基线、定规则、走申请审批、明确分工、做完成检查”的顺序展开，单工作项状态操作和现成体系框架的整体介绍不在讨论范围内。
要点总览（TL;DR）
- 裁剪的对象是组织共用流程基线，先逐项标注可裁剪项与不可裁剪项，不可裁剪项写明合规、安全、质量或合同依据。
- 用项目类型、需求不确定性、交付风险、合规要求、团队成熟度等维度组合判定流程等级，并把等级差异落到活动、评审、文档和角色上。
- 裁剪按申请、审批、记录、变更重评四步执行，结果写入项目流程文件或裁剪记录表，保证可追溯。
- 流程负责人、项目经理、质量或合规角色、评审角色分工明确，审批与执行分开，避免裁剪成为口头约定。
- 用完成检查清单核对基线、规则、闭环记录、不可裁剪控制点和评审复盘，缺一项即说明机制存在断点。
裁剪前先定基线：共用流程与可裁剪边界
裁剪的对象是组织共用流程基线，并非每个项目各自现写的流程。基线的作用是提供一套默认做法，让项目在它之上做减法或调整，避免每个项目从零设计流程、口径互不一致。没有基线，裁剪就失去参照，容易变成凭经验随意删减。
一份可用的共用流程基线通常包含五类要素：阶段划分、阶段内的活动、评审点、交付物、承担职责的角色。基线应描述到“谁在什么阶段做什么、产出什么、经过哪次评审”的程度，才能支撑后续裁剪判断。
在基线之上，需要把要素划分为可裁剪项与不可裁剪项。划分依据主要有四条：
- 合规要求：法律法规、行业监管或客户合同中明确规定的活动、评审和记录，属于不可裁剪项。
- 安全要求：涉及安全设计、安全测试、上线前安全检查的活动，通常不可裁剪。
- 质量底线：关键设计评审、代码评审、测试准入与准出条件等直接影响交付质量的控制点，应保留。
- 客户合同：合同约定的交付物、验收节点和报告义务，按合同执行，不因项目内部裁剪而取消。
可裁剪项一般是内部管理性质的活动的合并、简化或频次调整，例如小项目合并部分评审、简化内部周报、缩减非关键文档的篇幅。不可裁剪项则是外部约束或质量底线对应的控制点。基线清单应逐项标注“可裁剪/不可裁剪”，并写明不可裁剪项的依据来源，形成一份可直接引用的裁剪边界清单。
裁剪维度与分级规则怎么设计
裁剪不能靠项目经理凭感觉决定，需要一套可判定的规则：先选维度，再把维度组合映射为流程等级，最后规定每个等级在活动、评审、文档和角色上的差异。
常用裁剪维度及判定口径如下表：
| 维度 | 判定口径示例 | 对流程强度的影响 |
|---|---|---|
| 项目类型 | 新产品研发、定制交付、维护升级 | 新产品研发通常需要更完整的评审；维护升级可简化 |
| 需求不确定性 | 需求是否已确认、变更频率高低 | 不确定性高时保留需求评审与变更控制 |
| 交付风险 | 影响范围、故障后果、上线影响用户规模 | 风险高时提高评审层级和测试要求 |
| 合规要求 | 是否受监管、是否涉及合同约定证据 | 涉及合规时相关控制点不可裁剪 |
| 团队成熟度 | 团队是否熟悉该流程、历史交付质量 | 成熟度低的团队宜采用标准或严格等级 |
把维度组合映射为流程等级，常见做法是设轻量、标准、严格三级。等级差异应落到具体要素上，例如：
| 流程等级 | 活动 | 评审 | 文档 | 角色 |
|---|---|---|---|---|
| 轻量 | 合并部分内部活动，减少非关键检查 | 保留关键设计评审与上线评审 | 核心文档保留，内部记录从简 | 项目经理兼部分协调职责 |
| 标准 | 按基线执行，允许个别活动合并 | 按基线评审点执行 | 按基线交付物清单执行 | 按基线角色分工 |
| 严格 | 在基线基础上增加专项检查 | 增加评审层级或外部评审 | 增加证据留存要求 | 设置独立的质量或合规审核角色 |
规则要写成可判定的条件，例如“涉及监管合规的项目一律不低于标准等级”“影响生产环境且用户规模超过约定阈值的变更按严格等级执行”。条件写成可核对的事实判断，审批人才能按同一口径复核，避免口头裁剪和事后争议。
裁剪申请、审批与记录的操作步骤
规则确定后，裁剪要变成有输入、有动作、有输出的流程动作，完成标志是裁剪结果被写入项目流程文件并可被追溯。
第一步：提交裁剪申请。申请输入包括项目基本信息、按维度判定的适用流程等级、拟裁剪的具体条目（对应基线中的活动、评审或文档编号）以及裁剪理由。理由应指向具体维度，例如“需求已确认且变更频率低，申请合并两次内部评审”。
第二步：审批判定。审批人依据等级规则和不可裁剪项清单逐条核对：拟裁剪项是否属于可裁剪范围、裁剪后是否仍满足该等级的最低要求、不可裁剪控制点是否全部保留。审批结论分为同意、调整后同意、驳回三种，并写明依据。
第三步：记录裁剪结果。审批通过后，将裁剪结果写入项目流程文件或流程裁剪记录表，内容包括裁剪项、裁剪方式（删除、合并、降频）、生效阶段和责任人。记录表与项目流程文件应保持一致，避免两处口径不同。
第四步：变更时重新评估。项目范围、风险或合规要求发生变化时，原裁剪结论可能失效，需要重新提交评估并更新记录，保留变更前后的版本，形成完整留痕。
裁剪结果需要随项目流转并被评审环节看到。在 ONES 中，可以把裁剪记录作为项目文档与流程文件一并管理，将裁剪后的活动、评审点对应到工作项和阶段节点，使评审时能直接对照项目实际执行情况核对裁剪是否落实。
角色分工与各环节交付物
裁剪机制要持续运行，需要明确谁定规则、谁申请、谁审批、谁执行、谁检查。角色不清，裁剪容易退化为无人负责的口头约定。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 流程负责人 | 维护共用流程基线、裁剪维度与等级规则 | 基线清单、可裁剪项清单、等级对照表 |
| 项目经理 | 提出裁剪申请，对裁剪后流程的执行负责 | 裁剪申请、项目流程文件中的裁剪说明 |
| 质量或合规角色 | 审核不可裁剪项是否被保留，判断合规风险 | 审批意见、合规核对记录 |
| 评审与检查角色 | 在阶段评审中核对裁剪执行情况 | 阶段评审记录、偏差与整改项 |
分工的关键在于把“审批”和“执行”分开：项目经理提出申请并对执行结果负责，审批角色独立判断裁剪是否越界。流程负责人定期汇总各项目的裁剪情况，发现规则与实际不符时修订基线或等级规则，使裁剪机制随实践迭代。
示例：一个项目如何完成裁剪
以下为演示情景，用于说明裁剪的完整过程，不代表真实项目案例。
项目背景与等级判定。某内部管理系统升级项目，需求已在立项前确认，变更频率低，上线仅影响内部用户，不涉及监管合规。按维度表判定为轻量等级。
拟裁剪项与理由。项目经理提交申请：合并需求评审与设计评审为一次联合评审；内部周报改为双周；非关键模块的详细设计文档缩减为设计要点说明。理由分别对应需求不确定性低、团队成熟度较高、交付风险有限。
审批结论与记录。质量角色核对不可裁剪项清单，确认上线前安全检查、代码评审和测试准出条件均保留，同意申请，但要求联合评审须有测试角色参加。裁剪结果写入项目流程文件，记录裁剪项、方式和生效阶段。
阶段评审验证。在开发完成评审时，评审角色对照裁剪记录检查：联合评审是否按约定召开且有测试角色参与、双周报是否按期提交、设计要点说明是否覆盖关键模块。发现一处设计要点缺失，登记为整改项并跟踪关闭。
完成检查：裁剪是否有效的核对项
裁剪机制建立后，可用以下清单逐项核对是否真正运行：
- 共用流程基线已发布，且逐项标注可裁剪与不可裁剪，不可裁剪项写明依据来源。
- 裁剪维度与等级规则已发布，每个等级对应到具体的活动、评审、文档和角色差异。
- 等级判定条件可核对，审批人能按同一口径复核，不依赖个人经验。
- 裁剪申请、审批、记录形成闭环，每个项目的裁剪结果都能在项目流程文件中查到。
- 项目范围或风险变化时，裁剪结论经过重新评估并保留变更记录。
- 不可裁剪控制点在每个项目中均被保留，质量或合规角色有核对记录。
- 阶段评审和项目复盘中检查裁剪执行情况，偏差有整改和关闭记录。
- 流程负责人定期汇总裁剪情况，规则与实际不符时有修订记录。
清单中任何一项缺失，都说明裁剪机制存在断点：缺基线则裁剪无参照，缺可判定规则则审批无依据，缺记录则执行无法追溯，缺评审检查则裁剪可能停留在纸面。按清单补齐断点，裁剪才能真正起到让流程强度匹配项目风险的作用。
常见问题
小项目人手紧张，能不能直接跳过裁剪申请，按轻量流程执行？
不建议跳过申请环节。轻量等级本身就是规则的一部分，项目仍需要先按维度判定等级，再在申请中列明拟简化的条目。这样做的价值在于两点：一是审批人能核对不可裁剪项是否被保留，例如上线前安全检查、代码评审和测试准出条件；二是裁剪结果有记录，阶段评审和项目复盘时能对照检查。人手紧张时可以把申请表单做短，只保留项目信息、适用等级、拟裁剪项和理由四项，减少填写负担。
项目进行到中途，需求范围或风险发生变化，原来的裁剪结论怎么处理？
需要重新评估并更新记录。原裁剪结论基于当时的项目特征，范围扩大、上线影响用户规模上升或新增合规要求，都可能使适用等级提高。操作上由项目经理提交变更说明，写明变化内容和受影响的裁剪项，审批角色按新等级规则重新核对，更新项目流程文件中的裁剪说明，并保留变更前后的版本。阶段评审时以最新版本为准核对执行情况。
不可裁剪项清单由谁维护，业务部门提出豁免时怎么处理？
不可裁剪项清单通常由流程负责人维护，质量或合规角色参与确认依据来源。业务部门提出豁免时，应回到依据本身判断：如果对应的是法律法规、行业监管或客户合同义务，豁免需要走合同或合规变更渠道，不能由项目内部裁剪审批放行；如果对应的是内部质量底线，则由质量角色评估风险并给出结论，结论和理由记入审批记录。清单依据发生变化时，流程负责人同步修订清单并通知相关项目。
裁剪记录和项目流程文件分开维护，容易出现口径不一致，怎么避免？
建议确定一处为准。常见做法是以项目流程文件为执行依据，裁剪记录表作为审批留痕，两者在审批通过后同步更新，并在记录表中标注对应的流程文件版本。项目发生裁剪变更时，先更新记录表，再同步修改流程文件，避免只改一处。定期检查时可以抽取若干项目，比对记录表与流程文件中的裁剪项、生效阶段和责任人是否一致，发现差异及时修正。
裁剪机制运行一段时间后，怎么判断规则本身是否需要修订？
可以从三个信号判断：一是审批中频繁出现“调整后同意”，说明等级规则与实际项目特征不匹配；二是阶段评审反复发现同类偏差，说明某类活动的裁剪条件设置过宽或过窄；三是项目复盘反映流程负担集中在某些环节，说明可裁剪项划分需要调整。流程负责人定期汇总各项目的裁剪申请、审批结论和评审偏差，据此修订基线、维度或等级对照表，并保留修订记录，使规则随实践迭代。
