DCP决策评审是IPD体系中在研发关键节点上，由跨部门团队判断项目是否继续投入、调整方向或终止的正式评审。它回答“这个项目还值不值得往下走”，产出继续、有条件继续、暂停或终止的阶段性结论，范围限于阶段投入决策，不替代发布审批、质量门禁或单个需求的确认。
要点总览（TL;DR）
- DCP决策评审是IPD体系中由跨部门决策团队在阶段节点上，对项目是否继续投入资源作出继续、有条件继续、暂停或终止判断的正式评审。
- 它只管阶段投入的存续，单次发布许可归发布审批与质量门禁，单个需求的确认归需求评审，三者不能互相替代。
- 运行上分为准备输入、召开决策会议、记录结论、传递到下一阶段四个动作，结论需写清决策类型、依据、附带条件和责任人。
- DCP节点数量不固定，企业按产品复杂度和管理成熟度裁剪，常见覆盖概念、计划、验证等阶段。
- DCP与一般阶段评审、技术评审的差别在决策层级和对象，前者偏投资取舍，后两者偏专业判断，可作为DCP的输入。
DCP决策评审的直接定义
DCP的中文常译为“决策评审点”，英文全称为Decision Check Point。它指在产品或项目研发推进到某个阶段性节点时，由承担投资责任的跨部门决策团队，对项目下一阶段是否继续投入资源作出正式判断的评审活动。这个定义包含四个要素：谁决策、决策什么、依据什么、得出什么结论。
决策主体是跨部门决策团队，通常由产品、研发、市场、财务、供应链、服务等职能的代表组成，由其中一位对投资结果负责的人牵头。单一职能部门可以准备材料、提出建议，但继续投入或终止的判断需要由这个团队共同作出，因为阶段投入牵涉市场机会、技术可行性和财务回报等多个维度，任何单一视角都不足以独立承担投资决策责任。
决策对象是阶段性的项目投入，具体表现为下一阶段的资源预算、人员配置、时间窗口和业务计划。评审要回答的问题包括：前一阶段的目标是否达成，市场和技术假设是否仍然成立，下一阶段的投入产出是否值得，风险是否在可接受范围内。结论通常分为继续、有条件继续、暂停或终止四类，有条件继续意味着需要先完成若干整改事项再放行。
用一句话复述：DCP决策评审是IPD流程中由跨部门决策团队在阶段节点上，对项目是否继续投入资源作出继续、有条件继续、暂停或终止判断的正式评审。
它管什么、不管什么：DCP的边界
DCP的职责集中在阶段投入的取舍上。它决定项目是否进入下一阶段、是否按原计划追加资源、是否需要调整方向、是否应当暂停或终止。判断依据是阶段目标的达成情况、业务计划的可行性以及投资回报预期。围绕这些问题的讨论和表决属于DCP的范畴。
单次发布许可不属于DCP。产品能否对外发布、发布范围多大、发布节奏如何安排，归发布审批和相关质量门禁管理。质量门禁关注的是产品是否达到预设的质量标准，发布审批关注的是发布动作是否被授权，两者都针对具体交付物或具体发布批次，而DCP针对的是项目整体的阶段投入。
单个需求的评审与确认也不属于DCP。需求是否成立、优先级如何、实现方案是否合理，属于需求评审与确认环节的工作。需求评审处理的是“这个需求要不要做、怎么做”，DCP处理的是“这个项目还要不要继续做下去”，两者在对象和决策层级上都不同。
边界模糊时可以用一个判断口径：看决策影响的是资源投入的存续，还是具体交付物的放行。影响项目是否继续获得下一阶段资源的，归DCP；影响某个版本、某个需求或某次发布能否通过的，归对应的评审或审批机制。同一个项目里两类评审可以并存，但各自回答不同问题，不能互相替代。
| 问题类型 | 是否属于DCP | 归属机制 |
|---|---|---|
| 项目是否进入下一阶段、是否继续追加投入 | 属于 | DCP决策评审 |
| 项目是否暂停、调整方向或终止 | 属于 | DCP决策评审 |
| 某次产品发布是否获得许可 | 不属于 | 发布审批 |
| 产品是否达到质量放行标准 | 不属于 | 质量门禁 |
| 单个需求是否成立、优先级如何 | 不属于 | 需求评审与确认 |
DCP在IPD流程中如何运转
DCP的运行可以拆成四个动作：准备输入、召开决策会议、记录结论、传递到下一阶段。每个动作都有明确的产出物，缺少任一环节，决策就容易变成口头表态而难以追溯。
评审输入材料通常包括阶段目标达成情况、业务计划更新、市场与竞争分析、技术与质量验证结果、财务测算、风险清单以及下一阶段的资源需求。材料由项目团队提前准备并提交，决策团队成员在会前阅读，会议现场聚焦分歧点和关键假设，避免把时间花在通读材料上。
决策会议的角色构成一般包括决策团队、项目经理或产品经理、核心职能代表。项目经理负责陈述进展与请求，职能代表就本领域问题提供判断，决策团队负责形成结论。议事方式可以是共识决策，也可以由牵头人综合意见后拍板，具体规则由企业流程设计决定。会议需要形成明确的结论，而不是停留在讨论层面。
结论记录要写清四件事：决策类型、决策依据、附带条件、后续动作与责任人。有条件继续时，条件项应转化为可跟踪的整改任务，明确完成时间和验证方式。结论记录既是下一阶段的授权依据，也是后续复盘和审计的凭据。
结论落地后进入下一阶段：继续则释放下一阶段资源并启动计划；有条件继续则先完成条件项再放行；暂停则冻结投入并设定重新评估的触发条件；终止则启动资源回收和项目收尾。节点数量并不固定，不同企业会按产品复杂度、行业监管要求和自身管理成熟度裁剪DCP节点，有的设置四到五个，有的更少或更多，关键节点通常覆盖概念、计划、验证等阶段。
在评审材料和结论记录的管理上，团队需要让输入文档、会议结论和整改任务保持可追溯。ONES可围绕项目计划、阶段推进、任务协同和研发过程管理，帮助团队建立更清晰的IPD项目管理方式；评审材料以文档形式归集，结论和条件项转为工作项跟踪，阶段推进状态在项目中同步，便于下一阶段交接时查得到依据、看得见责任人。
DCP与阶段评审、关口评审的区别
DCP与一般阶段评审的差异在决策层级和结论性质。一般阶段评审可以是对阶段工作质量的检查，输出的是问题清单和改进建议，评审通过意味着工作达到要求；DCP输出的是投资层面的取舍结论，评审通过意味着资源继续投入。前者偏专业判断，后者偏投资判断，二者可以先后进行，但结论不能互相替代。
DCP与技术评审的分工在评审对象。技术评审针对设计方案、架构、测试结果等技术内容，由技术专家判断技术方案是否可行、是否满足要求；DCP不深入技术细节，而是把技术评审的结论作为输入之一，结合市场、财务和风险信息作出阶段投入判断。技术评审回答“做得对不对”，DCP回答“还值不值得做”。
DCP与投资决策的关系体现在授权机制上。DCP是投资决策在研发流程中的落地形式，把一次性的立项投资拆成若干阶段的滚动决策，每个节点都是一次小型的投资复核。立项审批解决的是“要不要启动”，DCP解决的是“启动之后每一段还要不要继续”。
名称不同但机制相近的情形在实务中很常见。有的企业称其为阶段决策评审、关口评审、业务决策评审，有的按阶段命名为概念决策评审、计划决策评审、验证决策评审等。名称差异不影响判断标准：只要是在阶段节点上由跨部门团队对项目继续投入与否作出正式结论，就属于同一类机制。
| 概念 | 评审对象 | 典型结论 | 与DCP的关系 |
|---|---|---|---|
| DCP决策评审 | 阶段性的项目投入 | 继续、有条件继续、暂停、终止 | 本体 |
| 一般阶段评审 | 阶段工作完成质量 | 通过、有条件通过、整改 | 可作为DCP输入 |
| 技术评审 | 技术方案与验证结果 | 技术可行、需修改、不可行 | 可作为DCP输入 |
| 发布审批 | 具体发布批次 | 准许发布、推迟发布 | 不同机制，不互相替代 |
| 立项审批 | 项目是否启动 | 批准立项、不批准 | DCP是其后的滚动复核 |
一个具体例子与常见误解
以下为演示情景，用于说明判断过程，不代表任何真实企业案例。某制造企业的一个新产品项目进入计划阶段末期，项目团队提交DCP评审材料：概念阶段验证了核心功能的技术可行性，市场分析显示目标客户群有明确需求，但关键物料的供应周期比预期长两个月，财务测算显示若按原计划投入，回本周期将延长。决策团队评审后认为市场需求和技术路线仍然成立，供应风险可以通过备选供应商缓解，于是作出“有条件继续”的结论：批准进入开发阶段，同时要求采购在四周内完成备选供应商认证，未完成则暂停开发投入。这个结论既不是简单放行，也不是终止，而是把条件写清楚、把责任落到人。
常见误解一：DCP等于走签字流程。签字只是结论确认的形式，DCP的实质是决策团队基于材料作出判断。如果会议只是逐页签字、没有人对假设提出质疑、结论没有附带条件或后续动作，这个评审就没有起到决策作用。
常见误解二：DCP等于发布审批。发布审批决定某个版本能否对外交付，DCP决定项目是否继续获得投入。一个项目可以通过多次DCP，但每次发布仍需单独走发布审批；反过来，发布审批通过也不代表下一阶段投入自动获得批准。
常见误解三：DCP只在立项时做一次。立项审批是起点，DCP是在研发推进过程中按节点反复进行的滚动决策。项目越复杂、投入越大，越需要在阶段节点上重新审视假设是否成立，及时暂停或终止不再值得投入的项目，把资源释放给更合适的方向。
把这三个误解放在一起看，可以提炼出一条使用原则：DCP的价值在于让阶段投入的取舍有明确的责任人、依据和记录。团队在落地时，可结合自身产品研发流程、组织分工和管理要求进行方案规划，逐步形成适合自身的IPD管理体系，节点设置和结论类型也应按实际管理需要确定。
常见问题
DCP决策评审的结论有哪几种，有条件继续怎么落地？
常见结论分为继续、有条件继续、暂停和终止四类。有条件继续意味着先完成若干整改事项再放行，落地时要写清三件事：条件项具体是什么、由谁负责、何时完成以及如何验证。条件项应转化为可跟踪的任务，完成情况作为下一阶段放行的依据，避免条件停留在会议记录里无人跟进。
企业应该设置几个DCP节点？
没有统一数量。节点设置取决于产品复杂度、行业监管要求和企业管理成熟度，有的企业设置四到五个，有的更少或更多，关键节点通常覆盖概念、计划、验证等阶段。落地时可结合自身研发流程、组织分工和管理要求进行方案规划，逐步形成适合自身的IPD管理体系，节点数量按实际管理需要确定。
DCP评审没通过，项目是不是就直接终止？
不一定。结论类型包含暂停和终止两种不同处理。暂停是冻结当前投入，设定重新评估的触发条件，条件满足后可再次提交评审；终止则是启动资源回收和项目收尾。决策团队也可给出有条件继续，要求先解决特定风险再进入下一阶段。选择哪种结论取决于阶段目标达成情况、关键假设是否成立以及风险是否可控。
DCP会议和技术评审的先后顺序怎么安排？
通常技术评审在前，DCP在后。技术评审针对设计方案、架构、测试结果等技术内容给出专业判断，DCP把技术评审结论作为输入之一，再结合市场、财务和风险信息作出阶段投入判断。顺序反过来容易导致决策团队在技术细节尚未澄清时就要对投资取舍表态，判断依据不足。
评审材料和结论记录用什么方式管理比较稳妥？
关键是让输入文档、会议结论和整改任务保持可追溯。评审材料以文档形式归集，结论和条件项转为工作项跟踪，阶段推进状态在项目中同步，下一阶段交接时能查到依据、看到责任人。ONES可围绕项目计划、阶段推进、任务协同和研发过程管理，帮助团队建立更清晰的IPD项目管理方式，具体配置需结合企业流程规划。
