IPD阶段评审检查清单围绕决策评审的准入条件组织，通常包含六类检查项：阶段交付物完整性、需求与范围基线一致性、技术与方案成熟度、质量与风险状态、资源与成本承诺、决策材料与角色到位情况。每项需写明通过标准、证据来源、负责人和检查时点，并把缺失关键交付物、未关闭的高等级风险、未落实的资源承诺列为阻断项。本文按使用对象、分阶段检查项、通过标准写法、证据与责任人、阻断条件逐项展开，供评审准备直接套用。
要点总览（TL;DR）
- IPD阶段评审检查清单围绕决策评审准入条件组织，覆盖交付物完整性、需求与范围基线、技术与方案成熟度、质量与风险、资源与成本承诺、决策材料与角色到位六类检查项。
- 检查项按概念、计划、开发、验证、发布及生命周期阶段分别列出，写成可判断完成与否的条目，企业可合并或拆分阶段但保持检查维度一致。
- 通过标准由判定条件、证据形式、判定人三要素构成，需区分“已完成并归档”与“已提交待审”，后者不计为通过。
- 关键交付物缺失、需求基线未冻结、高等级风险无应对方案、资源与预算未承诺、决策材料未按时提交属于阻断项，任一项未通过即不能进入决策评审。
- 清单在评审会前完成自检与预审，会上只处理未通过项；未通过项转为待办任务并登记责任人与关闭时间，供下一阶段复核。
谁在什么时点使用这份检查清单
这份清单服务于阶段决策评审的准入判断，使用对象包括产品经理或项目经理、各领域代表、评审组织者与决策人。产品经理负责汇总自检结果，研发、市场、采购、质量、服务等领域代表负责本领域检查项的证据准备与结论确认，评审组织者负责预审汇总，决策人依据清单结果作出放行或阻断决定。
检查时点安排在阶段交付物提交之后、决策评审会之前若干个工作日。团队先完成自检，再由评审组织者组织预审，把未通过项整理成待决问题清单。决策评审会上只处理未通过项和待决问题，避免把评审会当成第一次检查。清单的定位是决策评审的准入依据，与阶段业务计划、交付物模板配套使用，不替代技术评审和专业领域的详细审查。
| 角色 | 主要动作 | 时点 |
|---|---|---|
| 产品经理/项目经理 | 组织自检，汇总各领域检查结果 | 交付物提交后 |
| 领域代表 | 准备本领域证据，填写通过结论 | 预审前 |
| 评审组织者 | 汇总未通过项，形成待决问题清单 | 评审会前 |
| 决策人 | 依据清单结果判定放行、带条件通过或阻断 | 决策评审会 |
分阶段检查项：从概念到生命周期各查什么
IPD典型阶段可划分为概念、计划、开发、验证、发布，并延伸到生命周期管理。企业可以合并或拆分阶段，检查维度保持一致。以下检查项均写成可判断完成与否的条目，逐项核对即可得出结论。
概念与计划阶段
- 机会与市场假设：目标市场、客户需求、竞争格局的假设已形成书面说明，并标注待验证项。
- 初始业务计划：产品包需求覆盖范围、技术可行性、商业价值已有初步评估结论。
- 需求包与范围初稿：需求包已形成版本，范围边界明确，超出范围的内容有记录。
- 资源与预算框架：所需人力、预算、关键外部依赖已有框架性承诺。
- 总体技术方案与开发计划：系统架构、模块划分、关键节点已输出，技术方案经过对应技术评审。
- 业务计划基线：阶段决策评审所需的业务计划书已形成基线版本，作为后续投入依据。
开发阶段
- 需求基线冻结：需求基线已冻结并有版本号，变更走变更记录。
- 技术方案与关键设计评审：关键设计评审结论已闭环，遗留问题有责任人和关闭计划。
- 采购与供应方案：关键物料、供应商、供应周期已确认，长周期物料有应对安排。
- 质量目标与验证计划：质量目标量化，验证项目、验证环境与判定标准已明确。
- 原型与试产验证：测试样机满足既定需求规范，小批量试产过程与结果符合质量、性能要求。
验证与发布阶段
- 测试与验证结果：功能、性能、质量标准符合性有测试报告支撑。
- 缺陷收敛状态：缺陷按等级统计，高等级缺陷已关闭或有经确认的处理方案。
- 发布与上市准备：定价、渠道、宣传物料、销售培训等上市动作已就绪。
- 服务与支持就绪：备件、服务流程、技术支持文档已准备。
- 市场准入与合规：准入条件、生产成熟度、合规性要求已逐项确认。
生命周期阶段
- 量产与交付表现：交付达成率、质量表现、客户反馈有数据记录。
- 成本与收益复盘：实际成本、收益与业务计划对比，偏差原因有说明。
- 退市或迭代决策输入：退市条件或下一代产品输入已形成结论。
每项检查的通过标准怎么写
通过标准要能被第三方复核，写法包含三个要素：判定条件、证据形式、判定人。判定条件说明达到什么状态算通过，证据形式说明用什么材料证明，判定人说明由谁确认。标准避免使用“基本完成”“大致符合”这类主观描述。
| 检查项 | 通过标准 | 证据形式 | 判定人 |
|---|---|---|---|
| 需求基线冻结 | 需求包已通过评审，变更记录完整，与业务计划一致，基线版本号已发布 | 评审纪要、基线版本记录 | 产品经理 |
| 关键设计评审闭环 | 评审结论为通过或带条件通过，遗留问题均有责任人与关闭时间 | 评审记录、遗留问题清单 | 研发领域代表 |
| 高等级缺陷收敛 | 高等级缺陷全部关闭，或有经决策人确认的处理方案 | 缺陷统计报表 | 质量领域代表 |
| 资源与预算承诺 | 下一阶段人力、预算已由资源负责人书面确认 | 资源承诺记录 | 项目经理 |
需要区分“已完成”与“已提交待审”。交付物已提交但尚未完成评审，不计为通过；只有评审结论形成并归档，才满足判定条件。对于带条件通过的项目，条件本身也要写成可核验的状态，例如“某物料第二供应商已签约”，而不是“供应风险可控”。
证据与负责人如何落到清单上
每项检查在清单上标注负责人和复核人。负责人通常是交付物Owner或对应领域代表，负责准备证据并给出初步结论；复核人由评审组织者或指定领域负责人担任，负责确认证据与结论一致。责任到人后，预审阶段才能快速定位缺口。
- 证据存放：统一存放在约定的文档库或项目空间中，按“阶段—检查项—版本”命名，评审会前集中调阅。
- 预审汇总：评审组织者逐项核对证据，把未通过项整理成待决问题清单，标注缺口和补齐时限。
- 会议记录：决策评审会记录每项结论、遗留项责任人、关闭时间，作为下一阶段跟踪依据。
- 变更留痕：评审后补充或修改的证据保留版本记录，避免用会后材料替代会前结论。
| 检查项 | 负责人 | 复核人 | 证据位置 |
|---|---|---|---|
| 业务计划基线 | 产品经理 | 评审组织者 | 项目空间/计划阶段/业务计划 |
| 测试与验证报告 | 测试负责人 | 质量领域代表 | 项目空间/验证阶段/测试报告 |
| 上市准备清单 | 市场领域代表 | 项目经理 | 项目空间/发布阶段/上市准备 |
阻断项与完成条件
阻断项是会导致决策无法作出的关键缺口，任一项未通过即不能进入决策评审。典型阻断项包括：关键交付物缺失或未完成评审；需求基线未冻结；高等级风险没有应对方案和责任人；关键资源与预算未获承诺；决策材料未按时提交。阻断项数量宜少而明确，避免把所有问题都升级为阻断，导致评审无法推进。
解除阻断的条件是：补齐交付物并完成评审，风险有明确责任人与关闭计划并经决策人确认，资源承诺有书面记录。非阻断项可以带条件通过，但需登记为遗留项，写明责任人和关闭时点，并在下一阶段检查时复核。阶段评审准入通过的完成条件是：全部阻断项通过，遗留项已登记且关闭时点明确。
| 阻断项 | 判定未通过的情形 | 解除条件 |
|---|---|---|
| 关键交付物 | 缺失，或已提交未评审 | 完成评审并归档 |
| 需求基线 | 未冻结，或变更记录缺失 | 基线发布，变更记录完整 |
| 高等级风险 | 无应对方案或无责任人 | 方案与责任人经决策人确认 |
| 资源与预算 | 未获书面承诺 | 资源负责人确认并留痕 |
| 决策材料 | 未按时提交 | 材料齐备并完成预审 |
把检查清单放进评审流程：ONES中的承载方式
清单要在评审流程中持续使用，需要把检查项、证据和结论放到同一套协作记录里。ONES研发项目管理平台遵循IPD的理念和方法，通过市场管理与需求管理的流程支撑，并覆盖概念、计划、开发、验证、发布五个阶段，可作为清单承载的协作环境；具体阶段命名与检查项可按企业自身流程调整。
落地时可按以下方式组织：把各阶段检查项建成工作项或检查表模板，按阶段复用，避免每次评审重新搭建；将交付物文档与评审记录关联到对应阶段工作项，形成从检查项到证据的关联记录；预审未通过项转为待办任务，指定负责人与关闭时间；决策评审结论与遗留项在系统中留痕，供下一阶段跟踪复核。这样，清单的输入是各领域提交的交付物与评审记录，中间经过预审汇总和会上决策，输出是放行结论与遗留项任务，下一阶段评审时可直接调取上一阶段的关闭情况。
需要说明的是，检查清单模板的具体条目、通过标准口径以及阻断规则，应结合企业自身阶段划分和评审制度确定；系统承载的是检查项、证据、责任人与结论的记录和流转，判定标准仍由企业评审规则定义。
常见问题
阶段评审检查清单和技术评审是什么关系，能否互相替代？
两者关注点不同，不能互相替代。技术评审针对技术方案、设计和验证结果做专业判断，输出技术结论；阶段评审检查清单关注决策准入条件，核对交付物是否齐备、基线是否冻结、风险与资源是否落实，为决策人放行或阻断提供依据。实际操作中，技术评审的结论和记录是检查清单的重要证据来源，清单负责确认这些结论已经形成、归档并满足准入要求。
如果某项检查项在评审会前无法完成，应该怎么处理？
先判断它是否属于阻断项。属于阻断项的，需要补齐后再安排决策评审，或由决策人明确同意调整评审时点；不属于阻断项的，可以带条件通过，但要登记为遗留项，写明责任人、关闭时点和复核方式。无论哪种情况，都建议在预审阶段就暴露缺口，避免在会上临时讨论，导致决策依据不完整。
不同产品线的阶段划分不一致，检查清单需要各做一套吗？
不必各做一套。可以保留统一的检查维度，按产品线实际阶段划分调整条目归属和检查时点。例如硬件产品线把试产验证放在开发阶段，软件产品线把发布准备提前，检查项本身仍可复用。关键是每个阶段门都明确查什么、由谁判、什么情况不能放行，阶段名称和数量按企业自身流程确定即可。
检查清单在协作平台中落地时，最容易出现什么问题？
常见问题是清单与证据分离：检查项填了“通过”，但对应的评审记录、基线版本或测试报告散落在不同位置，评审时无法快速核对。建议把检查项建成可复用的工作项或检查表模板，交付物文档与评审记录关联到对应阶段工作项，预审未通过项直接转为待办任务并指定负责人和关闭时间。这样结论、证据和遗留项在同一处留痕，下一阶段评审可以直接调取上一阶段的关闭情况。
生命周期阶段的检查清单和前面几个阶段有什么不同？
生命周期阶段面对的是已上市产品，检查重点从“能否放行”转向“运行表现与后续决策输入”。检查项包括量产与交付表现、成本与收益同业务计划的偏差、客户反馈，以及退市条件或下一代产品输入是否形成结论。这一阶段的结论通常不作为阻断项使用，而是作为迭代规划、退市决策和下一轮业务计划的依据。
