简介：这份《IPD集成产品开发各阶段评审要素说明》模板面向产品经理、项目经理、研发与质量管理人员，以及需要搭建IPD评审体系的团队，用于梳理从立项、概念、计划到设计成果、样品测试、批量试制与发布等环节的评审要求。资源为1个docx文档，压缩包约33KB，核心是按阶段展开的评审要素表，把评审点、对应文档或交付物、资料提供部门与评审负责人逐一对应，覆盖Phase0-1至Phase0-13及TR1—TR6、概念评审、计划评审、发布评审等节点。内容突出DCP/TR评审中需求、注册、市场、技术、生产、成本与风险等查核项，便于建立评审清单、明确职责分工、检查交付物完整性。已有2697人学习，适合作为IPD流程落地与评审模板参考。

1. 从一张 31 条要素的 TR1 清单说起：评审要素表要解决的是“谁来证明”

第一次把 IPD 集成产品开发各阶段评审要素说明铺在会议桌上时，我数了一下：TR1 有 31 条查核要点，概念评审 11 条，TR2 到 TR6 加起来又是三十多条，最后还有一道 12 条的发布评审。TR 阶段在这里的角色是先把“这个产品值不值得继续投钱”翻译成一条条能被证据回答的问题，用清单把证据固定下来。这套东西适合两类人：一类是要在课程设计或毕业设计里交出一份完整研发流程文件的学生，另一类是从研发岗转到项目管理岗、第一次负责把评审会开起来的从业者。它最直接的价值不是让人多开几次会，而是让每一条结论都能追到一份文件、一个部门和一名签字人。

2. 评审体系设计：三道 DCP 闸门与六道 TR 的技术分层

IPD 里的评审从来不是一种会。把 DCP（决策评审点）和 TR（技术评审点）混在一起开，是很多团队一开始就踩进去的坑：技术问题还没说清，决策层已经在问预算；或者决策层已经拍板放行，回头发现图纸还没审。这套要素说明把两类评审拆开——TR 负责回答“技术上成立吗、证据够吗”，DCP 负责回答“投不投、给不给资源、能不能上市”。两条线在同一个阶段节点上对齐，但会议内容、参与人和输出物完全不同。

2.1 阶段骨架：Phase0 到 Phase3 的推进条件

整份说明按四个阶段组织。Phase0 概念阶段做需求收集、概念设计、法规与专利初判、技术和生产可行性评估；Phase1 计划阶段锁定规格、确定总体方案、测算成本与资源；Phase2 开发验证阶段出图纸、做样品、跑测试、走批量试制；Phase3 发布阶段做上市准备、培训和文档归档移交。每个阶段都不是“干完活就往下走”，而是必须拿到出口评审的明确结论。

这张表的作用是给项目经理一个硬约束：任何一个阶段的出口条件没满足，下一阶段的启动会就不该开。现实里最常见的情况是 Phase2 已经在做样品，Phase1 的 TR3 还挂着一堆待办——这种“带病推进”最后都会在发布评审上集中爆发。

2.2 DCP 与 TR 的分工：决策评审看投入，技术评审看证据

DCP 由 IPMT（集成产品管理团队）主持，关注的是经营层面的三件事：这个产品还值不值得投、资源要不要继续给、能不能按计划上市。所以概念评审、计划评审、发布评审这三道闸门的要素数量都不多——概念评审 11 条、计划评审 5 条、发布评审 12 条——但每一条都需要跨部门负责人在场表态。

TR 则完全由技术侧主导，主持人通常是项目经理或对应职能经理，参与人是各模块的评审负责人。TR 的要素颗粒度要细得多，TR1 就拆到 31 条，细到“产品可靠性要求是否能够满足”“加工成本和相关费用的估算”这种可以直接拿文件对照的程度。两类评审共用一套阶段节点，但会议纪要、结论形式和后续动作是分开的：TR 输出的是技术结论与遗留问题清单，DCP 输出的是决策结论与资源承诺。

提示：如果一场会里既有 TR 要素又有 DCP 要素，说明阶段节点没拆干净。通常的做法是把 TR 放在前一周开完，把遗留问题闭环情况作为 DCP 的输入材料之一。

2.3 要素编号与交付物绑定规则

这份说明最值得直接抄的部分是编号体系：技术评审用 TR1 到 TR6 编号，每个评审点下的要素用“TRn-m”二级编号，比如 TR4-7 表示设计成果评审下的第 7 条；决策评审用“概念评审-1”“计划评审-3”这种形式。编号不是装饰，它的价值在于每一条要素都能被引用——会议纪要里写“TR5-3 未通过”，所有人都知道指的是样品测试报告那一条。

绑定规则有四条，我一般会写进流程文件的第一页：一条要素只归属一个评审点，不允许在 TR3 和计划评审里重复出现；一条要素必须挂至少一份交付物，没有交付物的要素不进评审清单；每份交付物有唯一编号和版本号，更新后版本号递增；评审负责人不能是交付物的提供人。最后这条是最容易被忽略的一条，也是评审能不能真正起到把关作用的分水岭。

3. 要素表落地：从 TR1 到 TR6 的查核要点与交付物映射

拿到一份要素表之后，真正难的不是把表填满，而是搞清楚每一组要素背后要什么证据。同样是“通过”，有的是交一份文件，有的是交一批测试数据，有的是要看到实物和第三方报告。按证据强度分层看这些要素，会发现 TR1 到 TR6 其实是一条证据链在逐步加码：越往后，光有文档已经不够了。

3.1 TR1 技术概念评审：31 条要素怎么拆给三个部门

TR1 的 31 条要素不是让项目经理一个人扛。按内容可以切成六组：需求组（TR1-1 到 TR1-7）归产品部，产品经理负责；技术概念组（TR1-8 到 TR1-11）归研发部门，研发经理负责；法规注册组（TR1-12 到 TR1-16）归注册办，注册办副经理负责；市场组（TR1-17 到 TR1-22）归产品部；技术可行性组（TR1-23 到 TR1-26）归研发部门；生产可行性与成本组（TR1-27 到 TR1-29）归制造开发部；风险组（TR1-30、TR1-31）归项目经理。

需求组里最容易被糊弄过去的是 TR1-6 的 $APPEALS 分析。这个工具的作用是把“客户想要”拆成八个维度：价格、可获得性、包装、性能、易用性、保障、生命周期成本、社会接受度。做课程设计时经常看到有人把这一条写成一句“已做需求分析”，评审时被追问一句“八个维度里哪几个是差异化的”就答不上来。正常的做法是在原始需求报告里附一张 $APPEALS 打分表，标出竞品对比和自身目标值，哪怕数据是估算的，也要有推导过程。

技术可行性组的 TR1-26 是个硬骨头：可制造性要求要从加工技术方案、工装、加工设备、人力资源四个方面分别给结论。我在项目里见过最省事的写法是直接写“可制造”，结果 TR4 阶段发现关键工序没有对应设备，返工重做工艺方案。比较稳的处理方式是让制造开发部在 TR1 就出一页工序能力对照表，把每道关键工序对应到现有设备和人员技能等级上。

3.2 TR2 与 TR3：规格锁定和总体方案的三个账本

TR2 规格评审只有 8 条，但它的分量不轻：法规评审、注册计划、型号设计与关键参数、外观设计、包装规格、材料规格、灭菌规格、关键产品特点的测试方法与标准。这 8 条过完，意味着规格基线冻结。之后任何参数改动都要走变更流程，而不是在图纸上随手改。很多项目在 TR4 阶段发现材料选型不合适，根子就在 TR2 没有把材料规格和测试标准对齐。

TR3 总体方案评审的 8 条要素，本质上是让项目经理交三个账本。第一个是钱的账本：TR3-2 研发成本预算和 TR3-7 开发成本风险，一个讲计划花多少，一个讲超支的可能性在哪。第二个是人的账本：TR3-3 外协计划和 TR3-4 资源投入计划，前者说明哪些活外包、外包到什么程度，后者说明内部投多少人、投多久。第三个是时间的账本：TR3-5 进度计划和 TR3-6 开发周期风险。TR3-1 的“各个工程要素整合能力”是这三本账能不能对上的总检验——结构、电子、软件、工艺、注册几条线的计划如果互相打架，在这一条就会被看出来。

资源投入计划通常按角色而不是按人名来写，表格字段包括角色、投入比例、投入周期、关键交付节点。比如“结构设计 1.5 人月，Phase1 至 Phase2 前期”“注册专员 0.3 人月，全程支持”。这样写的好处是人员变动时不用重做整张表，只换名字。

3.3 TR4 到 TR6：设计成果、样品测试、批量试制的证据加码

TR4 设计成果评审有 11 条，核心是把概念阶段说过的设计落到图纸和工艺上。TR4-1 到 TR4-4 看的是设计本身：是否满足概念设计要求、关键尺寸和部件、图纸审核、设计变更历史是否完整。TR4-5 到 TR4-9 看的是制造准备：工装检具的设计审核、设计方案的工艺确认、工序设备与工艺装置是否明确、工艺重点难点是否解决、生产计划与采购计划是否可行。TR4-10 和 TR4-11 回到测试与加工需求。这一组要素的特点是“设计”和“能不能造出来”必须同时成立，只有图纸漂亮但工艺走不通，TR4 不该给通过。

TR5 样品测试评审的 9 条要素，证据类型明显变了：样品加工意见反馈、样品质检报告、样品测试报告、测试实施标准、测试数据、测试设备使用状况。前六条里有一半是记录类证据，不是说明类文件。评审时要能看到测试原始数据，而不是一份写着“测试合格”的结论页。TR5-7 到 TR5-9 把批量试制任务、注册计划更新、试制采购计划拉进来，意味着样品阶段一通过，量产准备就要同步启动。

TR6 批量试制评审的 8 条要素里，TR6-3 的临床或试用评估结果、TR6-4 和 TR6-5 的费用与预算平衡、人力成本核算，是整条链上第一次把“做出来”和“划不划算”放在一起评。TR6-6 到 TR6-8 的量产工艺、量产采购计划、量产确认，则是发布评审的前置条件。

3.4 三道决策评审的审查清单

概念评审的 11 条要素，前两条是程序性的：审查 TR1 评审结果、确认产品介绍是否明确。中间几条是实质性的：知识产权问题有没有解决办法、需求目标和客户信息是否明确、市场情况分析、技术与资源及竞争对手情况、生产线与生产能力、营销策略、经济效益评估。最后两条回到项目本身：风险是否识别并制定响应计划、项目立项可行性是否成立（概算、沟通计划、里程碑、团队职责）。

计划评审只有 5 条，但每一条都是对前面工作的复核：TR2 结果审查、TR3 结果审查、规格对供应链成本的影响、投资组合管理、开发资源匹配的优化。第 3 条特别值得注意，它要求把规格变更和供应链成本挂起来看——一个包装规格的调整可能带来采购成本的整体上浮，这种事只有在这个位置才会被拿出来讨论。

发布评审的 12 条要素跨度最大：TR4、TR5、TR6 三次评审结果的审查，成本核算与收益评估，资源使用情况评价，市场营销战略与推广培训计划，预估销售额，宣传资料，培训计划，产品验收标准，销售任务，上市后跟踪计划。这一道闸门过完，产品就从项目转成交付物，文档归档移交也在这里完成。

4. 责任矩阵与评审台账：谁提供、谁评审、谁签字

要素表能不能跑起来，取决于两件事：每条要素是不是有明确的人负责，每次评审是不是留下了可查的记录。这两件事听起来简单，实际项目里翻车的概率很高——不是因为大家不愿意做，而是因为责任边界没写死，评审记录又散在各个人的电脑里。

4.1 交付物清单与提供部门映射

把要素表倒过来读，就是一张交付物清单。这张清单比要素表更适合发给各部门，因为它直接告诉每个部门“你要交什么、什么时候交、交给谁审”。核心交付物大致是这些：立项任务书和产品开发任命书（产品部提供）；原始需求报告（产品部，产品经理评审）；法规注册评估报告（注册办提供，注册办副经理评审）；技术可行性评估报告（研发部门提供，研发经理评审）；风险管理计划（项目经理提供并评审）；设计图纸、样品生产工艺、量产生产工艺（研发部门与制造开发部分别提供）；样品测试报告与测试数据（研究院提供，研发经理评审）；项目成本核算表（财务部门提供，财务经理评审）；新品市场推广培训计划、销售任务书、产品上市跟踪计划（产品部提供）。

这张映射表最有价值的地方是暴露了“提供方即评审方”的风险点。比如风险管理计划由项目经理提供、项目经理评审，这条在实操中通常要加一道复核——由 IPMT 在概念评审时对风险识别的完整性再做一次确认，否则风险管理计划很容易写成一份模板文档。

4.2 评审负责人设置：提供方和评审方必须分开

评审负责人的设置有一套朴素逻辑：谁离证据最近，谁负责评审。质检报告由质量部经理评审，成本核算表由财务经理评审，法规相关由注册办副经理评审，技术方案由研发经理评审。这样安排的好处是评审人有专业判断力，坏处是容易出现“自己审自己”的嫌疑，所以每条要素的提供部门和评审负责人要显式写出来，接受跨部门质询。

项目经理在这个体系里的角色比较特殊：既是多条要素的提供人，又是 TR 会议的主持人。我一般会建议把“主持人”和“评审人”两个身份分开表述——项目经理主持流程、汇总结论，但对具体技术要素不投评审票，技术结论由对应职能经理给出。这样会议纪要上的签字才有意义。

4.3 评审台账的字段设计与归档

评审记录散落是通病。比较稳妥的做法是建一张评审台账，把所有要素的评审结论、证据位置、整改项统一登记。下面这张表结构可以直接拿去改成 Excel 或轻量系统表：

-- 评审要素台账：一条要素一行，按评审批次追加记录 CREATE TABLE review_gate_item ( id BIGINT PRIMARY KEY, phase VARCHAR(16) NOT NULL, -- Phase0 / Phase1 / Phase2 / Phase3 gate_code VARCHAR(32) NOT NULL, -- TR1 / TR2 / 概念评审 / 发布评审 item_code VARCHAR(16) NOT NULL, -- TR1-6 / 计划评审-3 item_desc VARCHAR(512) NOT NULL, -- 查核要点原文 deliverable VARCHAR(128), -- 对应交付物名称 owner_dept VARCHAR(64), -- 资料提供部门 reviewer VARCHAR(64), -- 资料评审负责人 conclusion VARCHAR(16), -- 通过 / 有条件通过 / 不通过 evidence_url VARCHAR(512), -- 证据文件路径或编号 action_item VARCHAR(512), -- 整改要求 due_date DATE, -- 整改截止日期 closed_at DATE, -- 实际关闭日期 version VARCHAR(16) -- 交付物版本号 );

字段里有三个是关键：evidence_url让结论可追溯，action_item加due_date让整改有主，version让版本混乱有据可查。conclusion建议只保留三个值，不要用“基本通过”这种模糊表述——有条件通过必须同时填整改项，否则台账里会出现一批永远不关闭的条目。

注意：台账不是给人看的报表，是给下一次评审用的输入。每次评审前，上一次的整改项关闭情况要先过一遍，否则会一直累积成黑匣子。

5. 避坑与排查：评审会开成汇报会的五个翻车点

5.1 现象：TR 会开了两小时，全在讲进度

原因通常是把 TR 和项目周会合并了。项目经理习惯性地从里程碑讲到风险，各模块汇报“本周完成了什么”，真正该过的要素一条没碰。解决办法是把会议议程按要素编号排，而不是按部门排：开场先过上次整改项，然后逐条过本次评审要素，每条限时，讲不出证据的直接记为不通过并进入整改清单。进度信息放到会前材料里发，不占会议时间。

5.2 现象：要素表全打勾，一问证据就卡壳

原因是评审结论和证据没有绑定。有人把“是否满足可靠性要求”理解成“我觉得能满足”，于是打勾了事。解决方式是在台账里强制填evidence_url，没有证据文件的要素不允许填“通过”。这条规则执行两三次之后，大家自然会提前把材料准备好。

5.3 现象：同一份交付物在三个评审点出现三个版本

原因是交付物没有版本控制和唯一编号。TR2 更新过的规格书，到 TR4 评审时用的还是旧版，评审结论自然对不上。解决办法是给每份交付物一个编号加版本号，比如“法规注册评估报告 V2.1”，评审材料清单里写明版本，会上发现版本不一致直接中止该条评审。

5.4 现象：DCP 开完了，没人知道结论是什么

原因是决策评审的输出没有结构化。会上大家点头说“可以继续”，散会后既没有决策记录也没有资源承诺。比较稳的做法是三道 DCP 都只允许四种结论：继续、有条件继续、暂停、终止。选“有条件继续”必须写清条件和完成时间，并由 IPMT 指定跟踪人。这样发布评审时回看前两道闸门，能查到每一次决策的原始表述。

5.5 现象：跨部门要素没人认领

典型的是 TR3-1“各个工程要素整合能力”和 TR1-30“全方面风险分析及控制计划”，前者横跨多个部门，后者谁都能说两句。这类要素要在表里显式指定唯一负责人，通常是项目经理，但评审时要拉齐所有相关职能经理共同签字。责任不落一个人的要素，最后往往落空。

6. 验收与答辩：用六个指标证明评审体系真的在跑

一套评审要素表交上去，最怕被问的一句话是“你们这个评审是不是走过场”。答这个问题不能靠描述流程，要靠数据。我在项目里通常用六个指标做验收，都是能从台账里直接算出来的：

前四个指标决定这套体系有没有在运转，后两个决定它运转得贵不贵。变更回流次数这个指标特别值得在答辩时讲，因为它能直观说明“前期多花一天评审，后期少返工一周”这件事不是空话。

答辩或方案汇报时，我建议准备一条“要素全流程演示”：挑 TR1-6 的 $APPEALS 分析，从原始需求报告里的打分表，到 TR1 会议纪要里的结论，再到概念评审引用这条结论做的决策，一条线走完。评委真正想看的不是表格有多全，而是这条链能不能闭合。如果时间允许，再补一个“不通过”的案例，说明整改项是怎么登记、跟踪、关闭的——这比讲十个通过案例更有说服力。

还有一个容易被忽略的准备动作：把所有交付物按阶段编号整理成一个目录，答辩时能在一分钟内翻到任何一份文件。我吃过一次亏，评委问“TR5 的测试原始数据在哪”，我在文件夹里翻了五分钟，最后发现文件名叫“最终版2”。从那以后我每次做评审材料都强制走一遍“编号—版本—目录”三件套，哪怕项目再小也不省这一步。希望这套结构能帮到你，把评审从“必须走的流程”变成真正能挡住问题的闸门。

本文还有配套的精品资源，点击获取