国产研发管理平台实践：如何支撑 IPD 与敏捷双模研发

不少企业把双模研发理解成两套流程并行：IPD 管立项和评审，敏捷管迭代和交付。系统上线后却发现，阶段门是一套表，迭代看板是另一套表，需求变更在两边各改一次，评审记录与交付证据对不上。问题不只在流程本身，还在平台能否把决策、需求、执行和验证放在同一条数据链上。本文以禅道 IPD 版为样本，基于公开资料讨论国产研发管理平台支撑双模的能力框架与落地顺序，不代表客户案例结果。

一、双模研发的难点，不在两套流程同时存在

IPD 把产品开发当作投资来管理，用阶段门、决策评审 DCP 和技术评审 TR 控制方向与风险。阶段门是阶段末的评审与决策点，DCP 判断继续、调整还是终止投入，TR 判断技术方案与交付物是否达到要求。敏捷解决的是既定边界内如何小步交付、快速反馈。两者管理的并不是同一个问题。《中国石化》杂志 2025 年第 10 期夏忠毅的文章提到，华为把敏捷理念和实践融入 IPD 结构化流程，按项目级、版本级、产品级、商业级逐步推进。双模的难点不是选边，而是让两种节奏基于同一份研发数据。

实际落地时，断点通常出现在三处。决策与执行脱节：DCP 开成技术讨论会，TR 又被要求回答商业投入问题。需求与基线脱节：阶段门冻结的版本和迭代里正在做的需求不是同一份。项目与团队脱节：项目集看里程碑，团队看看板，测试和 Bug 又落在另一套记录里。

先把两类治理的分工摆清楚，后面的平台能力才有判断标准。

两者不是二选一：IPD 提供阶段边界和投资决策点，敏捷提供阶段内的迭代与反馈。平台要做的，是让同一份需求、同一个评审结论、同一条测试证据不被复制成两套。

二、平台能不能支撑双模，先看四层能力

治理层：阶段门、DCP 与 TR 是否分开设置，评审结论能否作为阶段出口依据，评审记录能否留痕。只看流程图，判断不了治理能力。

需求层：需求池能否统一收集和分层拆分，需求矩阵能否关联市场需求、产品需求和研发任务，基线后的变更是否有评审规则。

执行层：同一平台或同一产品下，能否同时管理阶段型项目和迭代型项目，Scrum、看板、瀑布和融合模式能否组合，任务、工时和依赖是否落到一处。

质量与度量层：用例、测试单、Bug 和发布能否关联到需求，度量口径是否一致。质量层缺失时，阶段门看到的完成可能只是任务关闭，不是可交付证据。

四层缺一层，双模很容易退化成两套对不上的记录。

三、禅道如何把阶段门与迭代放进同一套项目结构

禅道 IPD 版的官方资料给出的思路是先立项目结构，再谈流程配置：项目集做组合，产品承载需求与路标，项目承载交付，执行承载迭代或阶段。需求池、立项和需求矩阵放在产品侧，IPD 或敏捷项目放在项目侧，任务和看板落在执行侧。

1. 先定项目结构，再谈流程

禅道的 IPD 模型支持产品研发、预研、平台、定制四类项目，阶段可按串行、并行或裁剪设置。同一平台也提供 Scrum、看板、瀑布、融合敏捷和融合瀑布模型。2026 年 9 月 17 日发布的 IPD 版 5.6 将规模化敏捷能力整合进通用版本，可以在同一系统内贯通项目集、规划和团队交付。

这意味着双模不必建两套产品库。一个产品下的同一需求可以关联到 IPD 项目，也可以关联到敏捷项目，不需要复制两份；项目集看组合，项目看阶段或版本，执行团队看看板，数据仍在同一套结构中。

2. 让 DCP、TR 与迭代评审各就其位

项目结构定了，评审点才能落到具体阶段。DCP 回答继续、调整还是终止投入，TR 回答技术方案是否成熟，两者不能互相替代，迭代评审也不替代阶段出口。禅道 IPD 版把 TR 与 DCP 挂到项目阶段，评审记录和过程信息可留在系统内，具体先后关系可按企业流程配置。具体运作可参考官方的 DCP 决策评审与 TR 技术评审说明。

需要明确边界：系统承载的是评审流程和证据，不替代 IPMT、PDT 或技术专家的判断。IPMT 负责投资决策，PDT 负责产品开发交付。如果企业把 DCP 开成技术会，评审很容易流于形式。

3. 用基线与追溯链守住变更

双模常见的风险是阶段门已冻结，迭代仍在改需求。基线是经过确认、后续变更需要受控的需求或版本。禅道 IPD 版提供交付物、评审、基线和项目变更管理；影响基线范围或交付承诺的变更走变更评审，迭代内的普通调整由团队按约定处理。变更时可结合需求矩阵和关联对象查看影响范围。

需求详情页可以查看相关用例执行结果，需求列表能跳转到相关任务、Bug 和用例，形成从需求到发布的追溯链。在实际项目中，发布前的测试单、Bug 收敛和用例执行结果，更适合作为阶段门评审使用的交付证据，而不只是任务完成率。

四、三类组织，三种双模切分方式

双模没有统一比例，三类场景的治理边界不同，平台配置也不同。

场景一要把阶段评审与迭代里程碑对齐，避免硬件等软件交付、软件等阶段评审。

场景二保留需求基线、投资决策和阶段出口即可，不必复制全套 IPD 文档。

场景三重点在项目集排序和跨团队依赖，而不是给每个团队再加一套看板。

五、上线顺序与验证信号

双模上线不宜一次全量铺开，更稳妥的顺序是：先打通需求、任务、Bug、测试到发布的闭环，再叠加 IPD 阶段门、TR/DCP 和基线，最后推进项目集与规模化敏捷。每一步都要用业务信号验证，而不是用功能上线数量验收。

验证信号可以落到抽样检查：随机抽取一批需求，检查能否追到用例与发布；变更评审行动项是否有责任人和截止时间；阶段评审是否按计划完成。第一步的需求还靠 Excel 补录，第二步就不要急着开 DCP；变更后找不到影响的任务和用例，第三步的组合看板也容易掩盖真实问题。先让一条链路真实跑通，再复制到更多产品线。

六、国产研发管理平台的选型边界：平台不能替代什么

对需要私有化部署、数据可控和本地服务的组织，国产平台往往更容易匹配这些约束；是否适用仍要看具体产品、版本和服务能力。禅道 IPD 版的官方资料显示，其支持国产信创环境；具体操作系统、芯片和数据库组合，仍需在项目中做兼容性验证。不能把适配清单直接当成上线承诺。

平台也有替代不了的部分。它不能替 IPMT 做投资判断，不能替 PDT 定义产品，也不能自动把跨部门职责理清。如果阶段门的出口条件、评审责任人和变更规则没有在组织内达成一致，系统很可能只是把模糊流程固化下来。选型演示时，用自己的一条真实产品线走一遍需求关联、基线冻结、变更评审和测试结果回写到需求；演示能跑通，比功能清单更有说服力。

七、FAQ

IPD 阶段门会不会拖慢敏捷迭代？ 阶段门评审主要看投资与阶段出口条件，不负责每个迭代的排期。迭代评审留给团队，阶段门评审重点看需求基线、关键风险和交付证据；如果阶段门评审连任务排期都要审，迭代很容易被拖慢。

需求基线后还能改吗？ 可以，但要先做影响分析。不影响阶段出口的迭代内调整，由团队按约定处理；影响范围、成本或交付承诺的变更，走变更评审并记录影响。关键不是禁止变更，而是让变更可见、可评估。

国产化替代，先换工具还是先改流程？ 先明确评审责任、阶段出口和变更规则，再做工具映射。工具能固化流程，但不能替组织决定谁对阶段结果负责；顺序反了，常见结果是新系统沿用旧问题。

双模上线先看哪几个指标？ 先看三个可核验的指标：抽检需求能否追到用例与发布；变更评审行动项是否有责任人和截止时间；阶段评审是否按计划完成。不要一开始追求大而全的度量大屏。

国产研发管理平台要支撑 IPD 与敏捷双模研发，靠的不是把两套方法都做成功能列表，而是让同一份需求、同一个评审结论、同一条测试证据在不同节奏下不被复制。选型时用四层能力去对照，落地时从一个产品线和一个闭环开始，双模才不容易变成两套对不上的记录。