IPD决策评审是研发投资的分层决策机制：在概念、计划、开发、验证、发布等关键节点，由跨部门决策团队依据交付物和证据，对项目作出继续、调整、暂停或终止的决定。本文按“定层级—跑节点—分角色—备材料—抓闭环—做检查”的顺序，给出可直接执行的操作步骤、角色职责表、材料模板要点与落地检查清单，适用于正在建立或优化IPD决策评审机制的产品线与项目管理团队。
要点总览（TL;DR）
- IPD决策评审是研发投资的分层决策机制，在概念、计划、开发、验证、发布等节点由跨部门决策团队依据证据作出继续、有条件继续、暂停或终止的结论。
- 落地顺序是定层级、跑节点、分角色、备材料、抓闭环、做检查：先明确公司级、产品线级、项目级的决策权限，再按阶段固化输入材料、会议动作、输出结论与完成标志。
- 决策评审与技术评审分工不同，技术评审结论是决策评审的输入证据，决策会应把时间留给投资判断而非设计细节。
- 决策材料应把请求决策事项前置，区分事实、假设与待验证项；纪要需写明结论、附加条件、责任人与时限，并在下次评审固定回顾。
- 机制有效性可用节点触发、材料齐备、结论明确、行动闭环等检查项核对，常见失效点是评审会变成汇报会、权限不清、结论无跟踪。
IPD决策评审的核心机制与分层结构
IPD决策评审解决的是“这个项目值不值得继续投钱、投人、投时间”的问题。它把研发投入拆成若干可撤回的节点，每个节点由有权限的决策团队基于证据作出判断，从而在资源大规模投入之前保留调整空间。理解这套机制，先要分清三类评审的分工，再明确谁有权在什么层级上作决定。
决策评审、业务决策与技术评审的分工
业务决策关注投资回报与市场机会，回答“做不做、投多少”；决策评审（DCP）是业务决策在研发项目上的制度化载体，按阶段节点召开，输出对项目的正式处置结论；技术评审（TR）关注技术方案是否成熟、设计是否满足要求，回答“做得对不对、能不能过”。三者不能互相替代：技术评审通过不等于项目应当继续投入，业务决策也不能绕过技术评审直接放行。
两类评审的衔接方式是：技术评审先形成技术结论，作为决策评审的输入证据之一；决策评审在技术结论基础上，叠加市场、财务、资源、风险等维度作出投资判断。实践中常见的错误是让决策会承担技术评审的职责，会上大量讨论设计细节，导致决策者没有时间处理投资问题。
分层决策：公司级、产品线级、项目级的权限划分
分层授权的目的是让决策发生在掌握信息且承担后果的层级。公司级决策团队通常负责跨产品线的资源分配、重大投资和战略性项目的终止；产品线级决策团队负责本产品线内项目的阶段放行与资源承诺；项目级则由项目经理在授权范围内处理执行层面的变更与调整。下表给出一种常见的权限对照，企业应结合自身规模与治理结构裁剪。
| 决策层级 | 典型决策主体 | 决策范围 | 适用条件 |
|---|---|---|---|
| 公司级 | 公司经营层或公司级投资决策委员会 | 重大投资额度、跨产品线资源调配、战略项目终止、产品线级无法达成一致的事项 | 投资规模超过设定阈值，或涉及多条产品线协同 |
| 产品线级 | 产品线决策团队（常称IPMT） | 本产品线各阶段DCP结论、产品包范围与上市节奏、资源承诺 | 产品线内常规项目，在授权额度内 |
| 项目级 | 项目经理及核心组 | 执行层变更、非关键路径调整、评审材料准备与预审组织 | 不改变产品包范围、不突破已批准资源与预算 |
决策结论的四种基本类型
每次决策评审必须落到明确结论，避免“原则同意、继续完善”这类无法执行的表述。常用四类结论是：继续，即按计划进入下一阶段并释放相应资源；有条件继续，即放行但附加必须限期完成的条件，条件未满足则自动回到暂停状态；暂停，即暂不投入新资源，保留项目待补充证据后复议；终止，即停止投入并释放资源，明确收尾与知识归档要求。四类结论都应当对应资源动作，否则决策无法落地。
各阶段决策评审的输入、动作与输出
阶段决策评审的可执行性取决于三件事：输入材料是否齐备、会上动作是否聚焦决策、输出是否有明确完成标志。下表按节点给出操作要点，企业可据此裁剪出符合自身产品形态的评审节点。
| 评审节点 | 输入材料 | 会议动作 | 输出结论 | 完成标志 |
|---|---|---|---|---|
| 概念决策评审 | 市场机会分析、初步商业论证、产品包需求初稿、技术可行性初判、粗略投入估算 | 确认机会真实性、需求覆盖范围与商业价值，判断是否值得进入计划阶段 | 继续进入计划阶段、有条件继续、暂停或终止 | 决策纪要签发，计划阶段资源与责任人明确 |
| 计划决策评审 | 产品包需求基线、开发计划与里程碑、资源与预算承诺、风险清单、业务计划书 | 确认需求基线、计划可行性与资源承诺，批准业务计划书 | 批准业务计划书并放行开发，或退回补充 | 业务计划书完成基线化，开发资源到位 |
| 开发阶段关键评审 | 开发进展与偏差分析、关键风险变化、需求变更记录、下一阶段资源需求 | 检查计划执行偏差是否在可接受范围，处理重大变更与风险升级 | 继续、调整计划、暂停或终止 | 偏差处理方案与资源调整决定形成书面记录 |
| 验证阶段决策评审 | 验证结果、市场准入条件、生产或交付成熟度、合规性材料 | 综合评估是否具备商业化发布资格 | 批准发布、有条件发布、推迟发布或终止 | 发布资格判定结论明确，遗留问题有责任人与时限 |
| 发布决策评审 | 上市准备度评估、销售与服务准备、放量条件、发布后跟踪计划 | 确认上市准备度与放量节奏，决定发布范围与时点 | 按计划发布、分阶段放量、推迟发布 | 发布决定与放量条件写入纪要，跟踪指标确定 |
开发与验证阶段之间是否再设独立决策节点，取决于项目复杂度与风险等级。高风险项目可增加节点，低风险项目可合并，但合并需在机制文件中写明触发条件，避免临时决定导致评审缺失。每个节点的完成标志都应可核验，例如“纪要签发”“计划基线化”“资源到位确认”，而不是“会议已召开”。
决策团队与支撑角色的职责分工
评审会变成汇报会，通常是因为角色职责没有分清：决策者只听取信息不作判断，汇报者把材料当成工作展示，职能部门到会但不作资源承诺。下表以RACI方式给出常见分工，A为最终负责，R为执行，C为被咨询，I为被通知。
| 活动 | 决策团队 | 产品经理/项目经理 | 职能部门 | 评审秘书 |
|---|---|---|---|---|
| 确定评审节点与议程 | A | C | I | R |
| 准备决策材料 | I | A/R | R（提供本领域输入与资源承诺） | C |
| 材料预审与齐备性检查 | I | R | C | A/R |
| 会上汇报与质询应答 | C | R | C | I |
| 形成决策结论 | A/R | I | I | C |
| 纪要发布与行动跟踪 | I | R（执行行动） | R（执行本领域行动） | A/R（跟踪与催办） |
决策团队的表决方式应在机制文件中事先约定。常见做法是到会成员对结论逐项表态，由决策团队负责人汇总形成结论；出现分歧时记录不同意见与保留事项，由负责人裁定或升级到上一层级。产品经理或项目经理承担汇报责任，需对材料中的事实与假设负责，不能把未经确认的数据作为决策依据提交。
角色缺席与授权代行需要规则：关键决策成员缺席时，应提前书面授权代行人，代行人具备同等表决权；汇报人缺席时，评审应改期或由熟悉项目的副手代汇报，不得由不掌握细节的人员临时顶替。授权记录随纪要归档，避免事后争议。
评审材料与汇报模板的编写要点
决策材料的唯一目的是让决策者在有限时间内作出判断。建议统一结构：业务目标与当前阶段目标、进展与偏差、风险与对策、资源与收益预测、请求决策事项。其中“请求决策事项”应放在材料前部，明确本次需要决策团队决定什么，而不是让决策者自行归纳。
材料中的数据与证据要区分三类：已确认的事实、基于假设的推演、尚待验证的事项。事实附来源与口径，假设写明成立条件，待验证项给出验证计划与时间点。风险呈现建议采用“风险描述—影响—概率—应对措施—剩余风险”的结构，并为重大风险准备备选方案，说明备选方案对进度、成本和范围的影响。
汇报时长建议控制在决策会总时长的一半以内，把时间留给质询与决策。汇报重点放在偏差、风险和请求决策事项上，背景信息放入附录供查阅。材料应在会前设定时间提交预审，预审不通过则会议改期，这一规则能显著减少会上补材料的情况。
决策结论的记录、传达与执行跟踪
决策评审的价值在会后体现。纪要应在会后短时间内发布，包含结论类型、附加条件、每项行动的责任人与时限、下次回顾节点。有条件继续的附加条件要逐条列出验收标准与截止时间，并指定跟踪人；条件到期未完成时，按机制自动触发复议，而不是等待下次例会顺带提及。
决策变更与复议需要明确触发条件：出现重大市场变化、关键技术路线失败、资源承诺无法兑现、附加条件逾期未满足等情形时，由产品经理或项目经理提出复议申请，说明变化事实与建议方案，提交原决策层级或授权层级重新决策。复议结论同样形成纪要，并注明对原结论的替代关系。
执行跟踪的常见做法是在下次评审议程中固定安排“上次决策回顾”环节，逐项核对行动完成情况，未完成项说明原因与新的时限。决策、行动与项目状态在同一处记录，能减少信息分散带来的遗漏。在工具承载上，ONES 研发项目管理平台遵循 IPD 的理念和方法，通过市场管理与需求管理的流程支撑，并支持从需求挖掘、收集、结构化到开发决策、研发落地的全流程管理；团队可将评审材料、决策结论与行动项关联到对应的工作项与文档，使回顾环节有据可查。具体配置方式需结合企业自身流程规划，逐步形成适合自身的 IPD 管理体系。
示例：一次计划决策评审的完整过程
以下为演示情景，用于说明流程串联方式，不指向具体企业案例。
评审前。某产品线项目完成概念阶段后进入计划阶段，项目经理按模板组织材料：产品包需求基线、开发计划与里程碑、资源与预算承诺、风险清单、业务计划书草案。材料在会前五个工作日提交评审秘书，秘书核对清单齐备性后分发给决策团队，并组织预审。预审发现资源承诺部分缺少某职能部门的书面确认，材料退回补充，会议按规则顺延三个工作日。
会议中。项目经理用二十分钟汇报，重点说明需求基线范围、关键里程碑、两项高优先级风险及备选方案，并明确提出请求：批准业务计划书并释放开发阶段资源。决策团队就需求覆盖是否完整、资源承诺是否可靠、风险应对是否充分提出质询，职能部门现场确认资源投入。决策团队形成结论：有条件继续，条件是某项关键技术验证在开发阶段第一个里程碑前完成，逾期则回到暂停状态。
会议后。评审秘书当日发布纪要，列明结论、附加条件、责任人与时限，并将行动项分派到对应责任人。项目经理将条件验证任务纳入开发计划，跟踪人按周检查进展。
下次评审。在开发阶段关键评审开始时，议程第一项回顾上次决策：附加条件已完成并附验证记录，其余行动项按计划关闭。决策团队确认条件满足，项目继续按计划推进。
决策评审机制的落地检查与常见失效点
机制是否有效，可以用一张清单逐项核对。建议每季度检查一次，并在机制运行半年后做一次系统复盘。
- 评审节点是否按计划触发，是否存在未经评审直接进入下一阶段的情况。
- 会前材料是否齐备并通过预审，退回补充的比例是否过高。
- 每次评审是否形成明确结论，四类结论的使用是否与实际资源动作对应。
- 纪要是否包含条件、责任人、时限，行动项是否在下次评审中被逐项回顾。
- 决策权限是否清晰，是否存在越级决策或该决策而未决策的事项。
- 授权代行是否有书面记录，关键角色缺席是否影响决策有效性。
常见失效点有三类：评审会变成汇报会，表现为会上时间主要用于展示进展、决策事项不明确；决策权限不清，表现为该终止的项目反复上会、无人敢作决定；结论无跟踪，表现为纪要发出后行动项无人核对。对应的改进方向分别是压缩汇报时间并把请求决策事项前置、在机制文件中写明各层级权限与升级路径、把上次决策回顾固定为议程第一项。
决策质量与决策效率可以观察几个指标：决策结论与后续实际结果的偏差情况、有条件继续的附加条件按期完成率、评审从提交材料到形成结论的周期、因材料不齐导致的会议改期次数。机制运行一段时间后，结合这些观察调整节点设置、材料要求与参会范围，使评审强度与项目风险相匹配。
常见问题
决策评审会上出现意见分歧，应该怎么处理？
分歧处理规则应在机制文件中事先约定，而不是每次开会临时协商。常见做法是到会成员对结论逐项表态，由决策团队负责人汇总形成结论；存在不同意见时，把分歧点与保留事项写入纪要，由负责人裁定，或按升级路径提交上一层级决策。需要避免的是用“原则同意、继续完善”这类表述掩盖分歧，导致会后无人对结论负责。
如果分歧集中在事实层面，例如市场数据口径不一致，应先补充证据再复议，而不是在会上强行表决。
项目已经进入开发阶段，还有必要补做前面的决策评审吗？
补做的价值在于补齐决策依据，而不是补一套形式。可以针对当前项目做一次回溯：确认产品包需求基线是否明确、资源承诺是否有书面记录、主要风险是否有应对方案。若这些基础缺失，先补齐再进入下一个正式节点，比在后续节点反复返工更可控。
补做时应在机制文件中说明适用范围与时限，避免形成“随时可以补”的惯例，削弱节点的约束力。
有条件继续的附加条件到期没完成，怎么处理？
按机制自动触发复议，而不是等下次例会顺带提及。附加条件应逐条写明验收标准、责任人与截止时间，并指定跟踪人；到期未完成时，由产品经理或项目经理提出复议申请，说明未完成原因、影响与建议方案，提交原决策层级重新决策。
复议结论同样形成纪要，并注明对原结论的替代关系。若条件涉及关键技术验证，还需评估延期对后续里程碑和资源计划的影响。
小团队或项目数量少的产品线，可以简化决策评审吗？
可以裁剪节点，但要保留决策的实质。低风险项目可合并开发与验证阶段的评审节点，前提是在机制文件中写明合并的触发条件与判断标准，避免临时决定导致评审缺失。决策团队规模也可以缩小，但决策权限、结论类型和纪要跟踪这三项建议保留，否则评审容易退化为进度汇报。
裁剪的依据是项目风险与投资规模，而不是团队人数本身。
决策评审的结论和行动项，用什么方式承载更便于跟踪？
关键是让决策、行动与项目状态记录在同一处，减少信息分散。团队可将评审材料、决策结论与行动项关联到对应的工作项与文档，下次评审时直接调取回顾。ONES 研发项目管理平台遵循 IPD 的理念和方法，通过市场管理与需求管理的流程支撑，支持从需求挖掘、收集、结构化到开发决策、研发落地的全流程管理，可作为承载评审与跟踪的工具选项之一。
具体配置方式需结合企业自身流程规划，逐步形成适合自身的 IPD 管理体系。
