IPD评审要素表：TR/DCP双轨制与阶段门风险收敛

简介：面向产品研发管理者与项目团队成员的IPD评审要素速查文档，围绕集成产品开发全流程，把各阶段评审该看什么、由谁提供材料、由谁负责审核讲清楚，适合作为研发流程落地、评审会前自查与新人培训的参考。包内为1个docx文件，约33KB，以表格形式组织内容，按阶段列出评审要素、评审点对应文档或交付物、资料提供部门与评审负责人，便于打印或直接套用为公司模板。文档覆盖项目立项任务书、开发任命书、原始需求报告、技术概念、法规注册评估、市场分析、技术与生产可行性、风险管理，以及规格评审、总体方案评审、设计成果评审、样品测试与批量试制评审等环节，并将TR1至TR6与概念、计划、发布等决策评审点对应起来，能帮助读者快速核对交付物是否齐全、责任是否落到部门与岗位。该资源已有2698人学习，适合需要建立或完善IPD评审机制、规范阶段交付物清单的团队参考使用。

1. 一张评审表为什么能卡住产品立项：IPD 评审的真相

很多团队第一次接触 IPD 评审，都会冒出同一个反直觉的疑问：产品能不能往下走，凭什么是几张填好的表格说了算？把 IPD 评审当成流程负担的人，通常只盯着会签页，没看到这套机制真正解决的问题——需要回答的核心问题是「谁在什么证据面前、对什么结论负责」。TR 阶段负责限时冻结技术风险，DCP 负责限时放行商业资源。前者怕漏，宁愿反复；后者怕拖，必须有人拍板。两种节奏硬凑到一个会上，技术会被预算绑架，商业会被细节淹没。搞懂这张要素表的结构，本质是搞懂一个组织怎么把「拍脑袋」拆成一条可举证的判断链。

2. DCP 与 TR 双轨制：商业决策和技术评审为什么必须分家

先摆结论：TR 评审回答「这东西在物理、法规、工艺上到底能不能做出来」，DCP 决策回答「还值不值得继续投人投钱」。两句话都以「继续 / 不继续」结尾，但判断依据、参与角色、失败模式完全不同。技术评审的失败模式是「漏」——一个没被发现的工艺难点，会在半年后变成一批报废样品；所以它要穷尽、要深挖、允许反复。商业决策的失败模式是「拖」——一个迟迟不批的项目，会把整条产品线的资源占死；所以它要有截止、要投票、要有唯一担责人。

把这两种判断混在一起，会同时坏掉两边。技术专家坐在决策会上，很容易用「技术上能做」替代「商业上值得做」，于是资源被技术可行性绑架；反过来，商业决策者被拉进图纸和灭菌验证的细节里，评审会开成技术汇报会，最后的结论往往是「再研究研究」。IPD 的拆法是：TR 生产证据，DCP 消费证据，中间用「评审记录」这个实物挂钩，而不是靠口头汇报。

2.1 TR1 到 TR6：六个技术闸门各自在拦什么

TR1 技术概念评审是整条链上要素最多的一道闸门，31 条查核要点，来自五个不同部门，最后由 IPMT 一次性判断。按提供部门拆开看结构就清楚了：产品部交 TR1-1 到 TR1-7 的需求证据（产品定位、适应症患者规模、创新性、上市时间与定价目标、需求时效性、$APPEALS分析、需求要素分析）以及 TR1-18 到 TR1-21 的竞争分析；注册办交 TR1-12 到 TR1-16 的法规与专利证据（配套器械分类、注册信息、注册可行性与方案、法规风险与管理计划、专利可行性含避险）；研发部门交 TR1-8 到 TR1-10 的样件与概念设计证据、TR1-22 到 TR1-26 的技术可行性证据（设计可实现性、可靠性、可测试性、技术风险、可制造性）；产品开发部交 TR1-27 到 TR1-29 的加工成本、环境影响、生产风险；项目经理收口 TR1-30 全方面风险分析及控制计划和 TR1-31 风险管理负责人确认。

这套分工的机制含义很直接：产品经理不能替研发签「技术可实现」，研发经理也不能替注册办签「注册路径可行」。$APPEALS这类需求分析框架常见做法是把客户需求拆成价格、可获得性、包装、性能、易用性、保证、生命周期成本、社会接受度八个维度逐项打分，打分本身不难，难的是让打分结果和后面的产品定义对得上。TR1-7「产品或器械是否能解决所提出的适应证、如何满足需求」就是逼着把打分落回具体需求要素，防止八维分析做完只留下一张雷达图。

TR2 规格评审只有 8 条，却承担了整条链上最硬的一次冻结：TR2-3 产品型号设计及关键设计参数、TR2-4 外观设计、TR2-5 包装规格、TR2-6 材料规格、TR2-7 灭菌规格，加上 TR2-8 关键产品特点的测试方法、测试标准及关键指标，以及 TR2-1 法规评审（引用更新后的 Phase0-5 法规注册评估报告）和 TR2-2 注册计划评审。这组要素的共同点是对外承诺——对供应商承诺材料，对注册机构承诺性能，对客户承诺包装和灭菌方式。承诺一旦发出，撤回就要重做验证，所以它必须冻在图纸之前。

TR3 总体方案评审是唯一一道塞满钱和人的技术闸门：TR3-1 各工程要素整合能力、TR3-2 研发成本预算、TR3-3 外协计划、TR3-4 资源投入计划、TR3-5 明确的进度计划、TR3-6 开发周期风险评估、TR3-7 开发成本风险、TR3-8 设计需求与包装需求及设计参数的风险控制计划。它由项目经理和产品经理共同负责而不是纯研发，原因就在这里——「方案可行」不只是技术可行，还包括「在你手上这点资源和这段时间里可行」。很多团队把 TR3 当形式，结果 DCP 计划评审时被投资组合和资源匹配两条打回，问题其实早在 TR3 就埋下了。

TR4 设计成果评审把制造准备直接拉进设计冻结：TR4-1 满足概念设计要求、TR4-2 关键尺寸和部件、TR4-3 图纸审核、TR4-4 设计变更历史记录是否完整这四条归研发；TR4-5 工具刀具检具工装的设计审核、TR4-6 设计方案工艺确认、TR4-7 工序设备工艺装置是否明确、TR4-8 工艺重点难点是否解决、TR4-9 生产计划含采购计划、TR4-11 器械加工需求是否明确归产品开发部；TR4-10 详细测试计划归研究院。设计能不能造出来，不应该等到样品做不出来才发现，所以工艺和工装要跟图纸同一道闸门过。

TR5 样品测试评审开始，证据从文档切换到实物：TR5-1 工厂加工意见反馈、TR5-2 样品质量检验结果、TR5-3 样品测试报告、TR5-4 测试实施标准、TR5-5 测试数据、TR5-6 测试设备使用状况、TR5-7 批量试制任务确认、TR5-8 注册计划更新、TR5-9 批量试制与采购计划确认。能摸到东西，才说明设计真的落地了。

TR6 批量试制评审里三条直接跟钱有关：TR6-4 费用和预算平衡对应项目成本核算表，TR6-5 人力资源等成本核算，再加上 TR6-6 批量生产工艺、TR6-7 量产与外购件采购计划、TR6-8 量产确认。批量试制是用真金白银验证工艺，出来的成本数据才是发布评审定价的底稿。

2.2 DCP 三个决策点：IPMT 到底在看什么

概念评审 11 条，第一条是「对 TR1 评审结果的审查」，交付物是 Phase0-12，由项目经理提交、IPMT 评审。后面十条才进入商业判断：产品性能与标准是否明确、知识产权问题是否有解决办法、需求目标客户需求量是否明确、市场情况分析、研发技术与资源及竞争对手情况是否明确、生产线及生产能力确认、市场营销策略是否可行、市场经济效益评估认定、风险识别与响应计划，最后一条概念评审-11 落到项目概算、沟通计划、里程碑事件、团队职责是否确认，交付物 Phase0-13。

计划评审只有 5 条，前两条又是审查 TR2 和 TR3 的评审结果，剩下三条才是决策内容：规格对供应链成本的影响、投资组合管理、开发资源匹配的优化。发布评审 12 条，前三条同样是审查 TR4、TR5、TR6 的评审记录，之后才是成本核算与收益评估、资源使用情况评价、市场营销战略与推广培训计划、预估销售额、宣传资料、培训计划、发布产品验收标准、销售任务书、产品上市后跟踪计划。

这个「第一条永远是审查上一阶段 TR 结果」的排布，是双轨制最关键的接口设计。它让 DCP 不必重新做技术判断，只做两件事：确认技术闸门真的关了（看评审记录，不听汇报），然后回答资源给不给、组合怎么排、商业上要不要继续。追责路径也随之清晰：产品失败时，先查是 TR 放水还是 DCP 拍板，两本账分开算。发布评审尤其能说明问题——TR4、TR5、TR6 在 Phase2 里已经顺序过完，发布评审在 Phase3 再回头审查这三份记录，它评的不是技术，是「三道闸门的证据是否都闭环、能不能对外承诺」。

3. 评审要素表的三元组：TR-x 编号背后的要素、交付物与责任人

3.1 编号系统里藏着的收敛逻辑

这张表里有两套编号，作用完全不同。TR1-1 到 TR6-8 是评审要素编号，回答「查什么」；Phase0-1 到 Phase3-37 是交付物编号，回答「拿什么来查」。两者是一对多关系：一份 Phase0-5 法规注册评估报告，同时支撑 TR1-12 到 TR1-16 五条要素，之后又在 TR2-1 法规评审、TR5-8 注册计划里以更新版本的形式再次出现。同理，Phase0-10 风险管理计划支撑 TR1-30 和 TR3-6，Phase0-12 支撑概念评审和计划评审-4，Phase1-17 支撑 TR3 和计划评审-5。

编号的真正价值是可追责。评审记录里写一句「TR4-4 不通过」，任何人能顺着编号查到它对应「设计变更历史记录是否完整」，对应交付物 Phase2-19 图纸，对应资料提供部门研发部门、评审负责人研发经理。三个坐标唯一确定一条待办，不需要开会回忆当时说的是哪条。编号不是索引，是坐标。

跨阶段复用的交付物更要看懂它的性质。Phase0-5 出现三次不是偷懒，同一份文档按阶段更新是这套体系的常态——法规注册评估在概念阶段是可行性判断，在规格阶段是注册计划依据，在样品阶段是注册路径复核。评审时该看的是版本和更新日期，不是「有没有这份文件」。

3.2 为什么每条要素都要绑定交付物和责任人

随机抽三行看结构：

三元组缺任何一角都会出问题。有要素没交付物，评审就退化成口头表态，「我觉得差不多了」也能过；有交付物没责任人，出问题时所有人都在说「他在弄」；有责任人没提供部门，跨部门协作时就变成互相等。表格里「资料提供部门」和「资料评审负责人」分成两列，是刻意的：提供部门负责产出证据，评审负责人负责判断证据够不够，交作业的人和打分的人不能是同一个。

把这张表抽象成数据结构，机制会更清楚：

from dataclasses import dataclass from datetime import date @dataclass class ReviewItem: gate: str # 闸门编号，如 "TR4" item_id: str # 要素编号，如 "TR4-4" question: str # 查核要点，必须是可判定的问句 deliverable_id: str # 交付物编号，如 "Phase2-19" owner_dept: str # 资料提供部门 reviewer: str # 资料评审负责人，落到姓名而非部门 version: date | None = None # 交付物最近更新日期 verdict: str = "pending" # pass / fail / conditional def is_ready(self) -> bool: # 五要素齐全才允许进入评审队列 # version 为空意味着交付物从未更新过，直接标红 return all([ self.question.strip(), self.deliverable_id.strip(), self.owner_dept.strip(), self.reviewer.strip(), self.version is not None, ])

is_ready的五个条件对应三件事：可判定、可举证、可追责。question非空保证这条要素能回答是或否；deliverable_id非空保证有东西可以举证；owner_dept和reviewer非空保证出了事有人接；version非空是最容易被忽略的一条，它把「交过」和「这次交的是新的」区分开。实际评审里翻车最多的就是这一条——文件在，版本是三个月前的。

3.3 要素写成问句而不是名词，是这套表最被低估的设计

对比两种写法：「需求分析」和「需求分析（$APPEALS 分析）」，「竞争对手分析」和「竞争对手和竞争产品分析是否全面」，「可靠性评估」和「产品可靠性要求是否能够满足」。名词式要素可以靠念一遍通过，问句式要素必须给出「是 / 否 / 有条件」加证据。TR1-22 到 TR1-26 这五条全是问句：设计可实现性要求是否能够满足、可靠性要求是否能够满足、可测试性要求是否能够满足、可制造性要求是否能够满足。每一条都逼着评审人指向一份具体报告，而不是点头。

这背后是一条很朴素的机制：评审会最容易滑过去的地方，不是没人懂，而是没人被要求举证。把要素从名词改成问句，等于在流程层面强制举证，成本很低，效果比加一轮评审会更好。

4. 阶段门如何收敛风险：Phase0 到 Phase3 的三级冻结

4.1 Phase0 概念阶段：把法规和专利风险前置到最贵的决定之前

TR1 的 31 条要素里，法规和专利占了 6 条（TR1-11 产品分类、TR1-12 配套器械分类、TR1-13 注册信息、TR1-14 注册可行性与方案、TR1-15 法规风险和管理计划、TR1-16 专利可行性含避险），全部由注册办提供、注册办副经理评审。为什么在产品还没画图的时候就做这件事？

因为分类决定注册路径，注册路径决定验证规模和周期，验证规模和周期又反过来决定产品定义和商业模型。在概念阶段发现分类判断错了，改的是一份报告；在设计成果评审时发现，改的是整套设计验证方案，前面几个月的图纸、工装、样品全部要重来。这就是阶段门最核心的经济学：越早的判断越便宜，越早的判断影响越大。概念阶段做的决定最贵，因为后面所有工作都建在它上面。

风险前置不只是法规。TR1 把竞争分析（TR1-18 到 TR1-21）、生产可行性（TR1-27 到 TR1-29）、全方面风险分析（TR1-30）全部塞进同一道闸门，意思是「要不要做这个产品」这个问题，必须在花大钱之前回答完整，而不是边做边想。反过来看，概念评审 11 条里有 8 条是市场、竞争、产线、营销、效益，只有 3 条跟技术沾边——DCP 在概念阶段关心的根本不是技术能不能做，是这门生意成不成立。

4.2 Phase1 到 Phase2：规格、方案、设计的三级冻结

TR2、TR3、TR4 三次冻结，冻结的对象一层比一层具体，代价一层比一层大。TR2 冻的是对外承诺：型号参数、外观、包装、材料、灭菌方式、测试标准。改一项灭菌规格，包装验证、灭菌验证、货架期验证可能全部重做。TR3 冻的是对内承诺：成本预算、外协计划、资源投入、进度里程碑。改一次进度，牵动的是整条产品线的资源排期。TR4 冻的是物理形态：图纸、关键尺寸、变更记录、工装检具、工序工艺。改一张图，可能意味着重开一副模具。

三级而不是一级，是因为三层的变更代价不在一个量级上，而且变更的影响面完全不同——规格变更影响验证，方案变更影响资源，设计变更影响制造。合并成一次冻结，等于把三种完全不同性质的决策压到同一个会上，评审人根本没法同时判断。

TR4 里最值得单独说的是 TR4-4「设计变更历史记录是否完整」。它看起来是一条文档管理要求，实际是整个冻结机制的安全阀。设计冻结的前提是「当前图纸是唯一真相」，一旦变更记录断链，图纸和实物就会分叉，后面 TR5 的样品测试、TR6 的批量试制全部建立在错误基准上。这条要素放在设计成果评审里而不是质量体系里，是因为只有评审这个场合能强制它闭环。

4.3 Phase2 到 Phase3：从样品到量产的证据链，以及发布之后的闭环

TR5 有一个明显特征：九条要素里绝大多数指向实物证据——质检报告、测试报告、测试数据、测试设备使用状况、批量试制订单。这是整条链上从「纸面」切换到「实物」的分界点。TR4 之前审的都是文档，评审人可以靠经验判断；TR5 之后必须有东西可以摸、可以测、可以复现。测试设备使用状况这一条尤其能看出设计者的经验：数据可不可信，先看设备在不在校准有效期内。

TR6 把成本和量产绑在一起审。批量试制的意义不是再做一批样品，是用接近量产的工艺、采购、人力跑一遍，把真实成本跑出来。所以 TR6-4 费用和预算平衡、TR6-5 人力成本核算必须和 TR6-6 批量生产工艺同时出现——工艺定了成本才定，成本定了发布评审的定价才有依据。

发布评审 12 条最后落到四个交付物：Phase3-35 发布产品验收标准、Phase3-36 销售任务书、Phase3-37 产品上市跟踪计划，加上 TR6-8 量产确认。这四样东西的性质完全不同：验收标准是对客户的承诺，销售任务是对公司的承诺，上市跟踪计划是给自己留的后悔药。产品发布不是流程终点，是承诺兑现的起点，所以跟踪计划必须在这里写死，而不是等卖不动了再补。

5. 常见问题排查：评审要素表落地后最容易翻车的五处

5.1 五条踩坑记录：现象、原因与解决

第一条，交付物编号复用，版本没更新。现象是 TR2 和 TR5 都引用 Phase0-5 法规注册评估报告，评审时翻开的还是 TR1 时那份。原因是编号复用被理解成了文档复用，没人认领更新责任。解决是在交付物编号后强制挂版本号和更新日期，评审入场先查日期，日期早于上一道闸门的一律退回。

第二条，TR 一路绿灯，DCP 却卡住。现象是 TR1 到 TR3 全部通过，概念评审或计划评审被 IPMT 打回。原因是 TR 只评技术可行性，DCP 评的是投资组合、资源匹配、商业回报，两套语言没对齐。解决是让 TR3 就把研发成本预算、外协计划、资源投入计划做实，DCP 材料直接从 TR3 结论里摘，不再另起一套口径。

第三条，责任人写部门不写人。现象是「资料评审负责人」一栏填的是部门名，出问题找不到具体人。原因是部门签字的心理是集体负责，而集体负责在实操中等同于没人负责。解决是一要素一姓名，部门经理做副签，副签不替代主签。

第四条，设计变更没有回填图纸。现象是 TR4-4 通过了，量产时发现图纸和实物对不上。原因是变更有单子，但单子没回填到图纸版本，图纸标题栏还是旧号。解决是变更单号强制写进图纸标题栏，TR4 现场抽查三条变更，从申请单追到图纸版本再追到实物。

第五条，风险登记册从头到尾只有一份。现象是 TR1-30 做完全方面风险分析及控制计划，到 TR6 还是同一份文件。原因是风险计划被当成一次性交付物，而不是活文档。解决是每道 TR 入口强制刷新风险登记册，新增风险必须带责任人和关闭时间，已关闭风险要写关闭依据。

5.2 怎么判断一场评审是不是在走过场

除了上面五条具体的坑，还有一类更隐蔽的失败：表格全填了，会也开了，但评审本身没发生。三个信号可以快速识别。

信号一，材料包里只有汇报文档，没有交付物原件。评审的对象应该是图纸、报告、测试数据，不是 PPT 摘要。当会上没人翻原件，通过率就会异常地高。

信号二，所有要素的结论都是「通过」，没有一条「有条件通过」。真实的评审一定有取舍，全部通过通常意味着没人真的在判断。有条件通过并要求限期关闭，才是正常状态。

信号三，评审记录里只有结论没有依据。合格的记录应该写清哪条要素、依据哪份交付物、哪个版本、谁签的字。只写「经评审，同意进入下一阶段」的记录，事后无法复盘，也无法追责，等于没评。

6. 评审要素的颗粒度取舍：一份模板该做到多细

要素表做多细，是这类模板最难的地方。太粗，评审时无法判定，会开成表态会；太细，把测试报告的内容搬到评审表里，评审人陷进细节，反而漏掉结构性风险。我的判断标准只有一条：这条要素能不能被第三方独立验证。

合适的颗粒度有三个特征：可判定，能回答是、否或有条件；可举证，指向唯一一份交付物；可追责，落到唯一一个负责人。TR1-24「产品可测试性要求是否能够满足」符合这三条，因为它逼着回答「用什么设备、什么方法、现有条件够不够」，答案要么是一份测试方案，要么是一句「不够，需要外协」。而「技术可行性是否评估」三个条件全不满足，它只能得到一句「评估过了」。

这张表一百多条要素看起来重，实际做的是把评审成本从会议现场转移到会前准备。每条要素绑定交付物，意味着会上不需要讨论「有没有」，只需要讨论「够不够」。会议性质从信息同步变成判断，这才是要素表真正的价值。反过来说，如果你的团队填完表还是要开三小时会吵「这份文件到底谁出」，那不是表太细，是三元组没建起来。

从那以后我每次拿到一份新的评审模板，第一件事不是看它有多少条，而是先数有几条没写交付物编号、有几条责任人填的是部门——那些位置就是将来一定会扯皮的地方，提前补上比事后追责便宜得多。这份从 Phase0-1 编到 Phase3-37、把 TR 要素和 DCP 决策点逐条对齐的模板，正好可以当对照物，拿去逐行比对自己团队的表单，缺哪一角一眼就能看出来。希望帮到你。

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