研发流程裁剪的起点是组织共用流程基线，再按项目类型、风险等级和交付约束设定可裁剪的维度与判定条件，由流程负责人和项目角色共同评审，形成可追溯的裁剪说明并随阶段复核。裁剪的产物应写明保留、简化、增加的活动及理由，避免停留在口头约定。
要点总览（TL;DR）
- 裁剪从流程基线出发：先列出阶段、活动、评审点和交付物，逐条标注可裁剪与不可裁剪，并写明基线版本号。
- 裁剪维度控制在三到五个，每个维度配可判定的分类或阈值；维度冲突时按不可裁剪项、客户要求、风险等级的优先级处理。
- 裁剪按申请、评审、批准记录、执行中变更四步推进，结论分为批准、有条件批准、退回修改三类。
- 裁剪说明至少写明基线版本、维度判定、逐条活动清单、理由、替代措施、证据要求、审批人和复核时点。
- 裁剪记录落到项目文档与评审工作项中，阶段复核时逐项核对，确保每条简化或增加的活动都有理由和证据责任人。
裁剪前先定基线：哪些流程活动不能动
裁剪的前提是有一份明确的流程基线。基线描述组织在常规情况下要求所有项目遵循的流程框架，通常由四个层次构成：阶段划分、阶段内的活动、活动之间的评审点、每个评审点要求的交付物。基线越具体，裁剪时的讨论越容易落到“哪一条活动保留、哪一条简化”上，而不是泛泛地谈流程轻重。
基线清单需要同时标注两类信息：活动是否允许裁剪，以及裁剪需要满足什么条件。不可裁剪项一般来自外部约束和内部质量底线，常见识别依据包括：法规与行业标准明确要求的活动、涉及安全与合规的评审门、组织设定的强制质量门、客户合同约定的交付物。把这些活动在基线中单独标记，可以避免裁剪讨论中被误删。
基线本身要有版本。每次组织调整流程、新增评审点或修改交付物要求，都应发布新的基线版本，并记录变更内容和生效时间。项目裁剪时引用的是某一具体版本的基线，裁剪说明中写明基线版本号，后续复核才能判断裁剪是否仍然成立。基线版本管理可以与流程文件发布流程合并，不必单独建设一套机制。
完成这一阶段的标志是：形成一份流程基线清单，逐条标注可裁剪与不可裁剪，并明确当前有效版本。这份清单是后续所有裁剪申请的共同参照。
裁剪维度与判定条件怎么设
裁剪维度回答“按什么区分项目”，判定条件回答“满足什么情况可以裁剪到哪一步”。两者需要一起设计，只列维度不写判定条件，裁剪就会退回到逐个项目临时讨论。
常用裁剪维度包括项目类型、项目规模、风险等级、交付周期和客户要求。维度数量控制在三到五个较为实用，过多会导致组合爆炸，评审时难以快速判断。每个维度需要给出可观察的分类或阈值，例如风险等级按是否涉及安全相关功能、是否涉及外部接口、是否涉及多地协作来划分，而不是用“高、中、低”这类需要主观解释的标签。
| 裁剪维度 | 判定条件示例 | 对应裁剪影响 |
|---|---|---|
| 项目类型 | 新建产品、版本迭代、缺陷修复、技术预研 | 决定阶段划分是否合并，预研类可简化部分评审点 |
| 风险等级 | 是否涉及安全相关功能、是否涉及外部接口变更 | 高风险项目保留全部质量门，低风险项目可合并评审 |
| 交付周期 | 交付周期短于四周的紧急版本 | 允许合并部分评审，但不可裁剪项仍需完成 |
| 客户要求 | 合同或客户规范中明确指定的活动与交付物 | 客户指定项进入不可裁剪范围 |
维度组合时需要约定优先级。常见做法是：不可裁剪项优先于一切裁剪结论；客户明确要求优先于组织内部维度；风险等级优先于项目类型和交付周期。当两个维度给出冲突结论时，按优先级高者执行，并在裁剪说明中记录冲突和处理依据。这样评审时不必每次重新争论规则。
完成这一阶段的标志是：形成裁剪维度表，每个维度有可判定的分类或阈值，并写明组合时的优先级规则。
裁剪操作步骤：从申请到批准
裁剪按申请、评审、批准记录、执行中变更四步推进，每一步都有明确的输入、动作、输出和完成标志。
第一步：提出裁剪申请
输入是项目基本信息、适用的基线版本和初步的维度判定结果。项目经理或项目指定的流程对接人填写裁剪申请，逐条列出拟裁剪的活动，写明裁剪方式（保留、简化、增加）、裁剪理由、替代措施，以及替代措施如何满足原活动的目的。完成标志是申请内容完整，每条裁剪都有对应理由和替代安排。
第二步：组织评审
输入是裁剪申请和基线清单。评审由流程负责人组织，参与角色通常包括项目经理、质量或评审角色，涉及安全与合规内容时加入相应负责人。评审依据是基线中的不可裁剪项、维度判定条件和优先级规则。结论分为三类：批准、有条件批准、退回修改。有条件批准需要写明附加条件，例如补充某项证据或增加一次复核。完成标志是形成评审记录，包含参与人、评审依据、结论和条件。
第三步：批准与记录
输入是评审结论。批准后形成裁剪说明，字段至少包括：项目名称、基线版本、维度判定结果、逐条活动清单（保留、简化、增加）、裁剪理由、替代措施、证据要求、审批人和审批日期、复核时点。裁剪说明归档到项目文档中，与项目计划关联。完成标志是裁剪说明可被项目成员查阅，且与评审记录一一对应。
第四步：执行中的变更
项目推进中出现新的约束时，可能需要在原裁剪基础上追加裁剪或撤销某项裁剪。追加裁剪走同样的申请与评审流程，撤销裁剪则记录撤销原因和恢复的活动。两类变更都更新裁剪说明的版本，保留历史记录。完成标志是变更后的裁剪说明版本清晰，项目成员按最新版本执行。
角色分工与各自交付物
裁剪过程中的职责需要落到具体角色，避免出现申请无人评审、评审结论无人记录的情况。下表给出常见分工，组织可根据规模合并角色，但职责本身不宜空缺。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 流程负责人 | 维护流程基线与版本，审核裁剪维度与判定条件，组织裁剪评审 | 基线清单、维度表、评审记录 |
| 项目经理 | 提出裁剪申请，组织项目内执行，发起追加或撤销裁剪 | 裁剪申请、更新后的裁剪说明 |
| 质量或评审角色 | 核对不可裁剪项是否被误裁，检查替代措施的证据要求是否可验证 | 评审意见、证据核对结论 |
| 项目成员 | 按裁剪说明执行活动，提交替代措施对应的证据 | 阶段交付物、证据材料 |
交付物归属需要明确到人。裁剪说明由项目经理维护，评审记录由流程负责人归档，复核结论由复核责任人填写。三者存放在同一项目空间内，便于阶段复核时对照检查。
示例：一个中等风险项目的裁剪说明
以下为演示情景，用于说明裁剪说明的填写方式，非真实客户案例。
项目背景：某业务系统的版本迭代项目，涉及一个对外接口变更，不涉及安全相关功能，交付周期为十周。维度判定结果：项目类型为版本迭代，风险等级为中，客户无额外指定要求，适用基线版本为 V3.2。
| 活动 | 裁剪方式 | 理由 | 替代措施与证据 |
|---|---|---|---|
| 需求评审 | 保留 | 涉及对外接口变更，需求需确认 | 评审记录归档 |
| 概要设计评审 | 简化 | 变更范围集中在接口层 | 以接口设计说明替代完整设计文档，由架构负责人书面确认 |
| 安全评审 | 保留 | 属于不可裁剪项 | 安全评审结论归档 |
| 集成测试 | 增加 | 接口变更需要额外验证 | 增加接口联调用例集，测试报告归档 |
| 上线前全量回归 | 简化 | 变更范围可控 | 执行受影响模块回归，回归范围清单经质量角色确认 |
审批结论：有条件批准，条件为接口设计说明需在开发启动前完成架构负责人确认。复核时点：概要设计完成后复核一次，上线前复核一次，复核责任人为项目经理，质量角色参与。
裁剪记录如何落到协作工具里
裁剪说明、评审记录和复核结论需要在项目中长期可查，并与阶段交付物对应。把这三类内容放进研发管理工具，可以减少版本散落和口头传递。
裁剪说明适合作为项目文档维护，与项目空间关联，每次变更形成新版本，项目成员从项目入口即可查阅当前有效版本。评审与复核适合作为工作项流转：提出裁剪申请时创建评审工作项，指定流程负责人和质量角色，评审结论和附加条件记录在工作项中，完成后关闭。复核时点可以设置为阶段节点上的检查工作项，到期提醒责任人执行。裁剪结果与阶段交付物的对应关系，可以在裁剪说明中逐条标注活动对应的交付物，并在阶段评审时核对交付物是否齐全。
ONES 提供项目管理、知识库、工单管理、资源管理、测试管理、效能管理等模块组合，可用于承载项目文档、评审工作项和阶段交付物的关联管理；其方案表述中提到支持研发全生命周期流程活动与跨域协作的可追溯性。裁剪申请与审批的具体模板需要结合组织流程在工具中配置，工具本身不预设裁剪规则。
完成检查：裁剪是否做到位
裁剪工作结束时，用以下清单逐项核对，全部满足才视为完成。
- 基线版本已确认，裁剪说明中写明了引用的基线版本号。
- 不可裁剪项已逐条核对，没有出现被简化或删除的情况。
- 裁剪说明字段完整，每条裁剪都有方式、理由和替代措施。
- 替代措施有可验证的证据要求，证据责任人和提交时点明确。
- 评审记录齐全，包含参与角色、评审依据、结论和附加条件。
- 审批人已签署，有条件批准的条件已落实到具体活动。
- 复核时点已安排，复核责任人和参与角色已指定。
- 裁剪说明已归档到项目空间，项目成员可查阅当前有效版本。
- 执行中的追加或撤销裁剪已按流程更新版本，历史记录保留。
这份清单可以在每次裁剪评审结束时作为收尾核对，也可以在阶段复核时作为检查依据。裁剪做到位的判断标准是：任何一条被简化或增加的活动，都能在裁剪说明中找到理由和证据要求，并且有人对复核负责。
常见问题
项目已经启动，还能补做流程裁剪吗？
可以补做，但需要把已执行的活动纳入裁剪说明，避免出现“实际做法与记录不一致”的情况。补做时先对照当前基线版本，逐条核对已完成的活动是保留、简化还是缺失；对缺失的不可裁剪项，评估是否需要补做或采取补救措施，并在评审记录中写明。补做的裁剪说明同样需要审批和复核时点，复核重点放在剩余阶段的活动安排上。
裁剪申请被退回修改，常见原因有哪些？
常见原因集中在三类：一是裁剪理由停留在“时间紧”“范围小”这类笼统描述，没有对应到维度判定条件；二是简化或删除的活动缺少替代措施，或替代措施无法验证；三是触碰了基线中的不可裁剪项，例如安全评审、合规交付物。退回时评审记录应写明具体缺项，项目经理补充后重新提交，不必重走全部评审环节。
多个维度给出冲突结论时，以哪个为准？
建议在裁剪维度表中预先写明优先级，常见顺序是：不可裁剪项优先于一切裁剪结论，客户合同或规范明确要求的活动优先于组织内部维度，风险等级优先于项目类型和交付周期。冲突处理依据要写进裁剪说明，评审时按既定规则判断，减少逐个项目重新争论。若冲突涉及基线本身未覆盖的情形，应交由流程负责人决定是否修订基线。
裁剪说明和评审记录分别由谁维护？
裁剪说明通常由项目经理维护，随项目推进更新版本；评审记录由流程负责人归档，包含参与角色、评审依据、结论和附加条件；复核结论由复核责任人填写。三者存放在同一项目空间，阶段复核时对照检查。组织规模较小时可以合并角色，但每类记录仍要有明确的责任人。
裁剪记录放在协作工具里，需要配置哪些内容？
需要配置三类承载：裁剪说明作为项目文档，与项目空间关联并按版本更新；裁剪申请、评审和复核作为工作项流转，指定流程负责人和质量角色，记录结论与附加条件；复核时点设置为阶段节点上的检查工作项，到期提醒责任人。ONES 提供项目管理、知识库、工单管理、资源管理、测试管理、效能管理等模块组合，可用于承载项目文档、评审工作项与阶段交付物的关联管理，具体裁剪模板需结合组织流程配置。
