平台项目和派生项目共用同一套IPD主干，流程裁剪的起点却不同：平台项目围绕可供多产品复用的能力建设来裁剪，派生项目围绕既有平台或基线产品上的差异交付来裁剪。本文按同一组维度对照两类项目的裁剪对象、保留节点、可弱化阶段与审批依据，并给出按项目类型设计裁剪策略的落地步骤。裁剪模板与审批记录需要承载在研发管理平台中，ONES的IPD方案覆盖概念到发布五个阶段，可作为落地时的参考载体。
要点总览（TL;DR）
- 平台项目与派生项目共用IPD主干，裁剪对象不同：平台项目裁“能力怎么建、建成什么标准”，派生项目裁“在既有标准上改什么、改到什么程度”。
- 平台项目应保留平台架构评审、平台技术评审与平台发布决策，概念与需求阶段可按平台规划节奏合并，单一客户定制诉求转入派生项目处理。
- 派生项目应保留需求差异分析、变更影响评估与验证确认，概念与架构阶段可引用基线成果做适用性确认，差异触及架构边界时升级为平台变更。
- 落地时先写项目类型判定规则，再为两类项目各建裁剪模板与保留节点基线，裁剪申请按类型由对应角色评审，结论记录并纳入复盘。
- 判断信号：派生项目频繁出现基线功能回归多为裁剪过度，派生项目仍完整走概念与架构评审多为裁剪不足，多个派生项目重复相同改动说明回流机制缺失。
平台项目与派生项目的裁剪差异一览
两类项目的裁剪差异，可以先归纳为一句话：平台项目裁的是“能力怎么建、建成什么标准”，派生项目裁的是“在既有标准上改什么、改到什么程度”。前者保留架构与技术决策节点，后者保留差异分析与验证确认节点。下表按五个维度横向对照。
| 对照维度 | 平台项目 | 派生项目 |
|---|---|---|
| 裁剪对象与起点 | 面向多产品复用的平台能力建设，起点是平台规划与架构定义 | 既有平台或基线产品上的变型交付，起点是客户或市场需求与基线的差异 |
| 保留的关键决策节点 | 平台架构评审、平台技术评审、平台发布决策 | 需求差异分析评审、变更影响评估、验证与确认评审 |
| 可弱化或合并的阶段 | 单一客户需求响应、单产品概念论证可按平台规划节奏合并 | 从零开始的概念与架构阶段可引用基线，做简化确认 |
| 裁剪决策依据与审批角色 | 依据平台规划与技术路线，由平台负责人、架构师与产品决策组织评审 | 依据基线版本与差异清单，由产品经理、基线维护方与质量角色评审 |
| 变更与复用管理重点 | 平台能力变更对下游派生项目的影响评估与通知 | 差异是否回流平台、是否形成新基线的判断 |
这张表给出的整体判断是：两类项目的裁剪都不能动IPD的阶段主干，差异体现在保留哪些决策节点、哪些阶段可以引用已有成果。裁剪方案一旦确定，应形成书面记录，作为后续评审和复盘的依据。
平台项目的IPD裁剪：围绕复用能力保留哪些节点
平台项目的交付对象是可供多条产品线复用的能力，包括架构、接口、公共组件和技术标准。这类成果一旦定型，下游派生项目会长期依赖，因此裁剪时必须保证架构决策和技术评审的完整性，把流程重心放在“建得对、建得稳”上。
必须保留的节点
- 平台架构评审：确认平台的分层结构、接口边界与扩展方式，这是下游复用的前提。
- 平台技术评审：对关键技术方案、性能指标与风险进行验证。ONES IPD方案在计划阶段设置技术评审（TR2&TR3），对整体技术方案和各子系统设计进行验证，确保技术可行性、接口一致性及风险可控性，这类节点在平台项目中不宜裁剪。
- 平台发布决策：平台能力对外发布前，需要确认版本基线、配套文档与支持范围，避免下游引用未定型的能力。
可以合并或弱化的阶段
平台项目通常不针对单一客户交付，概念与需求阶段可以按平台规划节奏合并：把多个产品线的共性需求汇总为平台需求包，一次论证，不必为每个潜在使用方单独走一遍概念评审。单一客户的定制诉求应转入派生项目处理，不占用平台项目的裁剪空间。
裁剪方案的评审与依据
平台项目的裁剪方案应由平台负责人提出，架构师、产品决策组织与质量角色共同评审，依据是平台规划、技术路线图以及下游产品线的复用需求清单。裁剪结论要说明哪些节点保留、哪些合并，以及合并后由哪个评审兜底。
平台变更对下游的影响评估
平台能力发生变更时，需要评估对已引用该平台的派生项目的影响，明确变更通知范围、兼容性处理方式和迁移要求。这项评估应作为平台变更流程的固定环节，而不是事后补做。
派生项目的IPD裁剪：围绕差异交付保留哪些节点
派生项目的起点是已经存在的平台或基线产品，交付内容是在此基础上的配置调整、局部适配或小范围变型。这类项目的风险集中在“改了什么、影响到哪里”，因此裁剪的重心从架构定义转向差异识别与验证确认。
必须保留的节点
- 需求差异分析：逐条比对客户需求与基线能力，明确哪些由配置满足、哪些需要改动、哪些无法满足，形成差异清单。
- 变更影响评估：对需要改动的部分评估对基线功能、接口和已验证特性的影响，判断是否需要回归验证。
- 验证与确认：差异部分的验证不能省略。ONES IPD方案在验证阶段通过技术评审（TR6）对产品技术状态进行最终确认并完成技术定型，派生项目可以按差异范围确定验证深度，但差异涉及的验证项应完整执行。
可以引用基线的阶段
概念与架构阶段可以大幅简化：直接引用基线产品的概念论证与架构设计成果，派生项目只做适用性确认，说明本次差异是否触及架构约束。若差异触及架构边界，应升级为平台变更或新项目处理，不留在派生项目内消化。
验证节点的简化边界
简化验证的前提是差异范围清晰且影响评估结论为低风险。当差异涉及安全、合规、核心接口或已发布特性的行为变化时，验证应按完整范围执行。简化的是验证项的选择，不是验证记录本身。
派生结果回流平台的条件
派生项目中形成的通用改进，在满足以下条件时可考虑回流平台：该改进被多个派生项目重复使用、不依赖特定客户环境、经过验证且不影响既有接口兼容性。回流决策应由平台负责人与基线维护方共同确认，并纳入平台版本规划。
按项目类型设计差异化裁剪策略的落地步骤
把上述差异转成可执行的流程，需要先有项目类型判定规则，再有裁剪模板和审批机制，最后靠记录与复盘持续校准。以下步骤可按顺序推进。
第一步：定义项目类型判定规则
判定规则要能回答两个问题：交付成果是否面向多个产品复用，起点是否已有可引用的基线。两个问题都答“是”偏向平台项目，起点已有基线且交付围绕差异展开的偏向派生项目。规则应写成可核对的条目，避免凭经验归类。
第二步：建立裁剪模板与保留节点基线
为两类项目各建一套裁剪模板，模板中列出IPD各阶段节点，并标注“必须保留”“可合并”“可引用基线”三种状态。保留节点基线一经确定，单个项目的裁剪只能在此基础上收紧或按审批放宽。
第三步：明确裁剪申请的提出、评审与批准角色
- 项目负责人在立项时提出裁剪申请，说明项目类型、拟裁剪节点与理由。
- 平台项目由架构师与平台负责人评审，派生项目由基线维护方与质量角色评审。
- 涉及跨类型的裁剪（如派生项目要求跳过验证），需提交更高一级的产品决策组织批准。
第四步：记录裁剪结果并纳入复盘
裁剪结论、审批意见与执行情况应记录在项目工作项中，与阶段评审关联。项目结束后复盘裁剪是否合理：被弱化的节点是否出现过质量问题，保留的节点是否产生实际决策价值。复盘结论用于修订下一版裁剪模板。
第五步：对齐平台与派生项目之间的裁剪口径
两类项目并存时，最容易出现口径冲突：平台项目认为某能力已定型可复用，派生项目却按新需求重新论证。解决方式是在平台发布时同步发布复用说明，明确可引用范围与引用条件，派生项目的裁剪申请以此为输入。ONES支持企业结合自身产品研发流程、组织分工和管理要求进行方案规划，逐步形成适合自身的IPD管理体系，裁剪模板与审批记录可在其项目与流程配置中承载，具体配置方式需结合企业实际流程确认。
适配场景与选择建议
实际判断时，先看平台能力是否稳定，再看差异集中在什么位置。以下场景给出对应的裁剪选择。
平台能力尚未稳定时
当平台架构、接口或关键技术指标仍在调整，优先按平台项目裁剪：保留架构评审与技术评审，暂缓对外承诺复用范围。此时若把工作放进派生项目，容易出现多个派生项目各自绕开平台约束、重复建设的情况。
已有基线、差异集中在配置与适配时
基线版本已发布且经过验证，客户需求主要通过配置、参数调整或局部适配满足，按派生项目裁剪：保留差异分析与影响评估，验证按差异范围执行，概念与架构阶段引用基线成果。这类项目不宜再走完整的平台论证流程，否则交付周期被无效评审拉长。
两类项目并存时的口径协调
建议以平台发布说明作为共同输入：平台项目在发布时明确能力边界与复用条件，派生项目在裁剪申请中引用该说明。定期召开裁剪口径对齐会议，处理平台变更与派生需求之间的冲突，冲突未解决前不批准相关裁剪申请。
裁剪过度与裁剪不足的识别信号
| 信号 | 可能问题 | 调整方向 |
|---|---|---|
| 派生项目频繁出现基线功能回归问题 | 裁剪过度，影响评估或验证被省略 | 恢复差异影响评估与相关验证项 |
| 平台项目被单一客户需求反复打断 | 裁剪对象错位，定制需求未分流 | 将客户定制转入派生项目 |
| 派生项目仍完整走概念与架构评审 | 裁剪不足，流程成本过高 | 改为引用基线的适用性确认 |
| 多个派生项目重复实现相同改动 | 回流机制缺失 | 评估回流平台并纳入平台版本规划 |
裁剪的本质是按项目类型分配评审资源：平台项目把资源放在架构与技术决策上，派生项目把资源放在差异识别与验证上。两类项目的裁剪结论都应留下记录，并在复盘中用实际质量结果检验裁剪是否恰当。
常见问题
平台项目在裁剪时把单一客户需求一并纳入，会带来什么问题？
平台项目的裁剪空间是按多产品复用能力来分配的，一旦把单一客户需求纳入，架构评审和技术评审的讨论范围会被具体交付细节占据，平台定型节奏被客户时间表牵动。更常见的后果是下游派生项目看到平台在响应个别需求，逐渐绕开平台约束自行改动，复用基础被削弱。处理方式是在项目类型判定阶段就把客户定制诉求分流到派生项目，平台项目只接收汇总后的共性需求包。
派生项目的差异触及架构边界时，应该继续在派生项目内裁剪，还是转出？
应转出。派生项目的裁剪前提是差异集中在配置、参数调整或局部适配，概念与架构阶段可以引用基线成果做适用性确认。当差异涉及接口变更、分层结构调整或已发布特性的行为变化时，基线的架构结论不再适用，继续在派生项目内消化会让影响评估失去参照。此时按平台变更或新项目处理，由平台负责人与基线维护方确认后再决定后续路径。
裁剪结论需要记录到什么程度，复盘时才够用？
记录至少要覆盖三项内容：本次裁剪保留、合并或引用基线的节点清单，审批意见与批准角色，以及裁剪执行后的实际结果。复盘时用实际结果对照裁剪假设，例如被弱化的节点是否出现过质量问题、保留的节点是否产生了实际决策价值。只记录“批准了裁剪”而缺少节点清单和结果对照，复盘时无法判断裁剪是否恰当，模板修订也缺少依据。
平台发布说明在两类项目的裁剪口径协调中起什么作用？
平台发布说明是两类项目裁剪的共同输入。平台项目在发布时明确能力边界、可引用范围与引用条件，派生项目的裁剪申请以此为据，说明本次差异是否落在可引用范围内。缺少这份说明时，平台方认为能力已定型可复用，派生方却按新需求重新论证，口径冲突反复出现。发布说明与裁剪申请关联后，冲突可以在裁剪评审环节暴露，不必等到验证阶段才发现。
裁剪模板确定后，单个项目还能不能调整保留节点？
可以，但要在模板基线上按审批规则调整。保留节点基线确定后，单个项目的裁剪只能在基线上收紧，放宽需要走裁剪申请并由对应角色评审：平台项目由架构师与平台负责人评审，派生项目由基线维护方与质量角色评审，涉及跳过验证等跨类型调整时提交更高一级的产品决策组织批准。调整结论记录在项目工作项中，作为下一版模板修订的输入。
