IPD集成产品开发软件的评审机制怎么设计：DCP与TR的分工

推IPD的团队常遇到同一个尴尬：流程文件印了一摞，评审点按时开了，会议纪要也写满了，可到中试阶段才发现性能不达标、成本超预算。回头翻流程，每个评审点都顺利通过，却没有一处写清楚什么情况下不能通过。

问题往往不在态度，而在机制设计：把商业决策和技术评审放进同一个会场，用同一套标准要求两类完全不同的人。在IPD集成产品开发软件里落地评审机制，第一步是把两类评审分开定义：DCP（Decision Check Point，决策评审点）回答该不该继续投入，TR（Technical Review，技术评审）回答技术上够不够格。前者是投资决策门，主持人要有权调动预算和资源；后者是技术成熟度检查点，由技术专家判断。把这条边界立清楚，评审点的数量、参会人选和材料清单才有讨论的基础。

一、评审体系的三层结构：DCP、TR与PR各管什么

IPD的评审体系通常分三层：DCP在最上层做商业决策，TR在中间层确保技术方案可行并为DCP提供输入，PR（Peer Review，同行评审）在最下层保证单个工作产品的质量。三层各管一段，缺一层，评审的可信度都会打折。

1. DCP：把产品开发当作投资的决策门

DCP的评审对象是投资机会，不是技术细节，核心问题只有一个：基于当前信息，这个项目值不值得继续投入公司资源。参与者要有权拍板预算和资源，通常由IPMT（集成组合管理团队）主持，PDT（产品开发团队）经理代表团队汇报。DCP的结论直接决定项目是继续还是终止。

2. TR：判断技术成熟度的技术门

TR关注技术交付物的完整性和成熟度：需求有没有闭环、设计能不能实现、测试数据够不够、风险是否可控。TR输出的是技术状态是否达到退出标准的结论，它不能决定项目终止，却是DCP做投资判断的事实依据。IPD中团队与阶段的划分，可参考IPD集成产品开发体系全景解析。

3. PR：容易被省略的底层评审

PR针对单个工作产品，比如一份需求说明、一份测试报告，由同级专家做小范围检查，价值在于把细节问题拦在TR之前。只保留DCP和TR的团队，常见结果是TR议程被文档细节占满，真正的技术风险没人讨论。

二、DCP与TR的分工边界

两类评审的差异集中在六个维度，可以先看这张对照表。

最容易被混淆的是结论权限：TR的结论不能直接终止项目，DCP的结论也不能替代技术判断。

1. 三条不能越的边界

技术结论不能替代投资决策。TR通过只说明技术条件具备，市场、成本与竞争格局仍需决策团队判断。

决策团队不裁定技术方案。DCP若开始讨论架构选型，说明评审层级已经错位。

两类结论不能相互替代。上一阶段遗留问题未闭环就通过DCP，风险会带进下一阶段。

2. 材料与节奏怎么对齐

DCP的输入通常需要包含TR的结论，因此TR要排在DCP之前，并留出问题闭环的时间。常见做法是TR结论在DCP前冻结，遗留问题区分决策前必须关闭与可带入下一阶段两类，后者需写明风险与应对措施。DCP材料重点回答市场机会、投入产出与下一阶段资源需求三个问题。

分工与节奏确定之后，下一步是把评审点落到具体阶段。

三、双轨怎么排：六个阶段里的评审点设计

IPD把产品开发分为概念、计划、开发、验证、发布、生命周期六个阶段，评审点按阶段双轨排布。以IPD管理模型为例，一个项目通常设置四个决策评审点和六个技术评审点（来源：禅道官网帮助文档《禅道IPD版的核心流程》）。

1. 概念与计划阶段：技术结论支撑前两个决策点

概念阶段设置TR1（产品包需求和概念评审），确认需求与业务方案是否成立，阶段末尾由CDCP（概念决策评审）决定是否继续投入。计划阶段先有TR2（需求分解和规格评审）与TR3（总体方案评审），TR3通过意味着项目计划被确认，随后进入PDCP（计划决策评审）。

2. 开发与验证阶段：技术评审控风险，决策评审把关上市

开发阶段不设决策评审点，大额投资决策在前一阶段已完成，这一阶段依靠TR4（模块与系统评审）与TR5（样机评审）控制技术风险。验证阶段的TR6（小批量评审）确认可制造性，ADCP（可获得性决策评审）通过，产品才具备大批量上市的条件。

3. 发布与生命周期阶段：评审点按复杂度裁剪

发布阶段以市场与上市准备为主，通常不再单独设置评审点，放行依据来自ADCP的决策结论。产品上市之后，LDCP（生命周期结束决策评审）判断退市是否与公司及产品线战略一致。评审点数量并非固定不变：技术不确定性越高，评审点往往拆得越细；决策点越少授权越充分，但过少会失去对风险的控制。另外，评审点还需与既有体系衔接：若企业同时运行CMMI，两套体系的评审点要对齐，避免重复评审，可参考CMMI与IPD的分工。

四、机制落地的四个控制点

体系设计清楚之后，机制能否起作用取决于执行细节，以下四点可以直接作为检查项。

1. 准出标准要写成可核验的清单

每个评审点都要预先定义退出标准，例如需求基线是否冻结、设计文档是否评审通过、测试数据是否覆盖关键指标、风险清单是否更新。标准要能判断通过与否，而不是基本完成这类模糊表述，同时写明不允许通过的情形。

2. 材料提前开放与预读要求

评审会开成汇报会，多半是材料到会上才第一次被看到。一般建议提前2～3个工作日把评审材料开放给评审人，先预读、再带着问题清单进会，会议只处理分歧项。

3. 决策权与资源权保持一致

DCP的参会人建议同时拥有预算权和资源调配权。只能签字、不能承诺人力和费用的参会人，会让评审变成形式化流程：承诺资源的人不在场，会后资源落不了地。

4. 结论要闭环到需求、任务与Bug

评审结论不落到具体条目，就会停留在会议纪要里。每个未通过项都建议转成有责任人和截止时间的任务或Bug，并约定复评时间。在IPD集成产品开发软件中，这套机制需要系统承载。禅道IPD版提供IPD项目管理、TR评审与决策评审等功能，立项环节支持Charter评审并记录评审结果与纪要，详见禅道IPD版的核心流程。

五、常见问题

1. 需求中途变更，已经通过的评审要重做吗？

看变更的影响范围。触及需求基线、总体方案或关键指标的变更，建议回到对应的技术评审点复核；只涉及局部实现细节的变更，按变更流程由相关责任人评估批准即可，不必重跑全部评审点。

2. 评审签字意味着个人担责吗？

评审记录的意义是留存判断依据，而不是事后追责工具。建议在记录中写清当时掌握的信息、判断依据与保留意见，既方便决策复盘，也能避免用最终结果倒推责任。

3. 技术评审专家按什么标准选定？

按交付物涉及的专业领域选，而不是按行政级别选。同一交付物涉及的领域专家应到场，跨领域专家可以按评审点轮换，但系统工程师等角色建议保持稳定，避免不同评审点的技术判断缺少统一口径。