IPD阶段评审怎么做？TR技术评审与DCP决策评审的闭环清单

在制造业推进 IPD（集成产品开发）时，阶段评审几乎是绕不开的一环。但很多企业真正落地后会发现：TR、DCP 都设置了，会议也按节点开了，研发风险却没有明显减少。

常见情况是，技术问题和商业决策混在一场会上；评审结论只有一句“原则上通过”；会上提出十几个问题，会后却没人持续跟踪。久而久之，阶段评审从原本应该发挥作用的“质量与投资闸门”，变成项目计划里的一个会议节点。

IPD 阶段评审真正要解决的，不是“有没有开会”，而是两个问题：技术成熟度是否足以支持项目继续推进？商业价值是否足以支持企业继续投入？因此，做好阶段评审的第一步，就是把 TR 技术评审与 DCP 决策评审分开。

要点速览：IPD阶段评审到底应该怎么做？

IPD阶段评审的核心，是将TR技术评审与DCP决策评审分开，并通过“准入条件→评审证据→会前预审→正式评审→标准化结论→问题整改→验证关闭→决策归档”形成完整闭环。其中：

• TR（Technical Review）回答“技术上能不能做、成熟度够不够”，重点检查需求、技术方案、设计、验证结果及技术风险；

• DCP（Decision Check Point）回答“商业上要不要继续做、是否值得继续投入”，重点判断市场机会、成本、收益、资源投入和整体风险。

ONES 的 IPD 方案也按照概念、计划、开发、验证、发布等阶段组织研发过程：例如计划阶段通过 TR2&TR3 验证总体技术方案及子系统设计，通过 PDCP 决定后续开发与资源投入；验证阶段由 TR6 确认技术状态，再由 ADCP 综合市场准入、生产成熟度和合规要求作出商业化发布判断。

一、先分清：TR技术评审和DCP决策评审有什么区别？

虽然不同企业对 TR、DCP 的编号、名称和数量会有不同设计，但管理逻辑大致可以归纳为两条线。

所以，一个非常重要的原则是：不要把 DCP 开成一场“级别更高的 TR”。

TR 要先把技术事实讲清楚：需求有没有遗漏？方案是否成立？接口是否稳定？关键验证有没有完成？目前还有哪些高风险问题？

DCP 则不需要重新讨论大量设计细节，而应基于 TR 形成的技术事实判断：市场机会是否仍然成立？继续投入多少资源？项目收益目标是否还能实现？当前风险是否值得企业继续承担？

这与阶段门管理中的基本逻辑也是一致的：管理层在 Gate 节点依据交付物和统一标准，决定项目 Go、Kill、Hold 或 Recycle，并同步确定下一阶段资源投入。

TR一定是TR1～TR6，DCP一定有固定数量吗？

不一定。

企业真正需要复制的，是技术质量评审和商业投资决策相互分离的机制，而不是某一家企业的固定编号。

例如，青岛鼎信通讯在 2025 年年度报告中披露，其搭建了“6 个阶段、5 个 DCP 决策评审点、7 个 TR 技术评审点”的研发流程，并设置“TR 未通过不得进入 DCP”的门禁机制。

九号公司则在 2025 年可持续发展报告中披露，其引入 IPD 阶段门控机制，设置 TR 技术评审与 DCP 决策评审点，并结合 DFMEA、质量需求清单和标准化评审检查单识别风险，对评审发现的问题建立整改闭环。

因此，企业可以根据产品复杂度、行业监管要求、研发周期和组织成熟度，对 TR/DCP 数量进行裁剪。

二、一套完整的IPD阶段评审闭环，要做好7件事

1. 设置评审准入条件：不是时间到了就开会

很多项目的问题，是把“评审日期”当成“评审条件”。

计划里写着周五开 TR，到了周五，不管材料齐不齐、验证做没做完、重大问题有没有解决，都必须把会开掉。结果往往只能得到一个模糊的“原则通过”。

更合理的方式，是为每一个阶段门设置明确的准入条件，例如：关键交付物是否齐套？需求是否达到基线要求？上一轮重大问题是否已经关闭？关键技术验证是否完成？成本、进度和风险数据是否更新？

NASA 的系统工程评审实践同样将 Entrance Criteria 和 Success Criteria 作为生命周期及技术评审的重要机制，并强调根据项目规模、风险和复杂度进行裁剪。

对企业而言，可以把它转化成一个简单规则：关键准入项没有满足，就不进入正式评审。

2. 把“评审材料”升级成“评审证据包”

阶段评审不是评 PPT，而是审证据。

例如在概念阶段，需要看到产品需求、市场可行性、技术及生产可行性；计划阶段需要进一步检查总体技术方案、子系统设计、接口、DFMEA、技术验证和研发计划；进入验证阶段后，还要关注测试、认证、生产成熟度、量产准备和遗留质量问题。

因此，一个完整的评审证据包至少应该回答几个问题：本阶段承诺交付什么？实际完成了什么？哪些指标已经满足？哪些没有满足？关键判断有什么数据支撑？还有哪些风险没有关闭？

ONES 的 TR 实践也强调通过 Entry/Exit、证据包和行动项闭环，把阶段评审从“听汇报”变成基于证据的关口判定。

3. 明确主审人和责任角色，不要让“所有人共同负责”

制造业产品研发通常涉及产品、系统、硬件、软件、结构、工艺、测试、质量、采购等多个职能。

如果一张评审表发给所有人，让大家一起检查，最后很容易变成“每个人都参加了，但没人对评审效果真正负责”。

更好的做法是提前定义：主审人、专业评审角色、被评审责任人和最终决策角色。

例如，需求完整性由产品或系统角色判断；架构和接口由系统工程师负责；可制造性由工艺和制造角色检查；测试覆盖和验证结果由测试角色确认。

主审人的职责也不只是主持会议，而要负责判断评审是否准备充分、意见是否有依据、重大分歧是否处理，以及最终结论是否完整。

4. 会前完成预审，正式会议只解决关键问题

如果所有评审人员进入会议室后才第一次看到材料，那么评审会大概率会开成一场项目汇报会。

更高效的方式是：在正式评审前，把评审要素和证据分别推送给相应角色，提前完成检查并提交意见。

正式会议集中解决三类事情：重大技术风险、跨专业意见冲突、必须由管理层拍板的问题。

这样，评审会的价值才会从“同步信息”转向“形成判断”。

5. 标准化评审结论，尤其管好“条件通过”

TR 不能只有“通过”和“不通过”。

复杂产品研发中，经常会出现整体方向没有问题，但少量事项还需要整改的情况。因此可以设计：通过、条件通过、重新评审、不通过。

真正容易失控的是“条件通过”。

条件通过绝不能等于“先往下做，问题以后再说”，而应同时明确五项内容：遗留问题是什么、谁负责、什么时候关闭、谁验证、关闭前限制哪些后续活动。

DCP 同样需要形成明确决策：项目是继续、调整、暂停还是终止？如果继续，下一阶段的范围、目标、预算和资源承诺是什么？

没有明确输出的 DCP，只能算项目汇报，不能算决策评审。

6. 评审问题必须转成任务，而不是留在会议纪要里

这是阶段评审最容易断链的地方。

会上发现十几个问题，项目经理整理一份纪要发到群里。过几周再问整改情况，才发现有人忘了，有人认为不是自己负责，还有的问题已经“口头解决”，但没有任何验证证据。

正确的方法，是把评审问题转成可跟踪对象，至少包括：问题描述、严重级别、责任人、截止时间、解决方案、验证人、验证结果和关闭证据。

如果问题关联具体需求、设计、测试或缺陷，还应该建立上下游关联。会议结束并不代表评审完成，最后一个关键行动项验证关闭，才代表这次评审真正闭环。

7. 把评审结果沉淀成可复用的决策资产

阶段评审不仅要服务当前项目，也应该为后续版本和下一代产品积累经验。

一场完整的评审至少应该沉淀四类内容：评审时的基线、最终结论、问题及关闭记录、关键决策依据。

这样半年后出现质量问题时，团队才能快速回溯：这个风险当时有没有识别？为什么选择当前技术路线？哪些问题曾经被条件放行？当时依据什么做出的决定？

这些数据也可以反向用于优化下一轮的设计规范、检查清单和评审标准。

三、不同IPD阶段，TR和DCP重点看什么？

企业不需要机械照搬这张表，但每个阶段至少要说清楚五件事：谁来评、评什么、依据什么、形成什么结论、问题如何关闭。

四、用 ONES 把 TR/DCP 变成可追踪的管理对象

当 TR/DCP 主要依赖 Excel、邮件、网盘和线下会议时，即使企业已经设计了一套不错的制度，随着项目增多，也很容易重新退化成“靠项目经理催”。

ONES 的 IPD 方案将阶段、计划、技术评审和决策评审放在同一研发管理流程中。例如计划阶段通过 TR2&TR3 和 PDCP 形成“技术验证—阶段决策”的衔接；开发阶段用 TR4&TR5 对原型、需求符合性和试产条件进行验证；验证阶段通过测试、问题闭环、TR6 和 ADCP 判断产品是否具备商业化发布条件。

在实际落地时，可以把阶段评审拆成四类对象：

第一类是评审模板。预先配置 TR/DCP 类型、评审要素、责任角色、流程和结论状态，一个新项目启动后直接复用。

第二类是评审证据。把需求、任务、Wiki 文档、测试结果、风险和阶段交付物关联起来，评审时能够直接回到事实依据，而不是临时到多个系统找资料。

第三类是整改任务。评审产生的问题直接转换为工作项，明确负责人、期限和关闭标准；整改状态与阶段评审状态形成关联。

第四类是决策记录。最终评审结论、条件通过事项、重大风险以及后续资源决策统一沉淀，保证项目过程可追溯、可复盘。

ONES Wiki 可以通过模板、版本记录以及文档与项目任务的关联承载评审证据和纪要；ONES Project、TestCase 等模块则可以进一步关联需求、任务、测试和缺陷，使“评审—整改—验证”的链路持续在线。

系统化的关键并不是“把 Excel 搬到线上”，而是让企业随时能够回答：

哪个项目还没有达到评审条件？哪个专业还没完成评审？哪些问题还没有关闭？哪次评审属于条件通过？为什么当时选择继续投入？

只有这些问题能够持续被回答，阶段评审才真正从会议机制变成研发治理机制。

五、关于IPD阶段评审的4个常见问题

1. TR通过以后，才能做DCP吗？

TR 通常是 DCP 的重要技术输入，但企业是否设置强制门禁，需要结合自身流程。

对于高复杂度、高安全性或者质量风险较高的制造产品，可以明确要求关键 TR 不通过就不能进入对应 DCP。鼎信通讯公开披露的研发流程，就采用了“TR 未通过不得进入 DCP”的机制。

2. TR条件通过后，可以直接进入下一阶段吗？

要看遗留问题的等级。

一般问题可以在明确责任人、期限和验证方式之后并行关闭；但涉及安全、法规、核心性能或者关键技术路线的问题，通常不应该因为“条件通过”就自动放行。

因此，条件通过最重要的不是“条件”两个字，而是把风险承诺和关闭规则显性化。

3. DCP应该由研发负责人来决策吗？

DCP 不只是研发决策。

它解决的是“是否继续投资”的问题，因此通常还需要产品、市场、财务、供应链以及企业管理角色参与。

研发团队负责回答“技术上做到什么程度、还有什么风险”，管理决策团队则基于技术事实和商业事实决定“还要不要继续投”。

4. 中小制造企业也必须完整复制TR1～TR6和所有DCP吗？

没有必要。

产品相对简单、团队规模较小的企业，可以合并部分阶段和评审点；高可靠、高监管或者系统复杂度较高的产品，则可以设置更细的门禁。

真正不应该裁掉的是四个基本要素：

明确的评审标准、真实的评审证据、清晰的决策结论、可验证的问题闭环。

结语

IPD 阶段评审真正要解决的，不是“项目有没有按流程把会议开完”，而是两个更加重要的问题：

技术成熟度是否透明？继续投入是否有依据？

TR 技术评审负责把需求、方案、设计、验证和技术风险讲清楚；DCP 决策评审负责基于市场、成本、收益、资源和风险做经营取舍。两者再通过准入条件、评审证据、责任角色、标准化结论、整改任务和关闭证据连接起来，才能形成真正的阶段评审闭环。

对于正在推进 IPD 数字化的制造企业，ONES 可以将 TR/DCP 与项目阶段、需求、计划、任务、文档、测试和问题管理进一步打通，让评审从一次会议变成一个持续可跟踪的管理过程。

系统不能替代专家做技术判断，也不能替代管理层做商业决策，但它可以让已经确定的规则真正执行下去，让每一次阶段评审都有标准、有证据、有结论、有责任人，也有完整的闭环。

最终，企业需要建立的不是“更多的评审会”，而是一套可执行、可追踪、可复盘、可持续优化的 IPD 阶段评审机制。