IPD双闸门评审：TR六道闸门、查核点与追溯链设计

简介：面向产品研发、项目管理与质量注册团队的IPD评审要素模板，围绕集成产品开发流程梳理从项目立项、任命书、原始需求、技术概念到规格、总体方案、设计成果、样品测试、批量试制及发布等环节的评审要求。文档以阶段评审要素对应表为主线，列明评审查核要点、评审点对应的文档或交付物、资料提供部门与资料评审负责人，并覆盖TR1至TR6及各DCP决策评审节点，便于团队在评审前核对材料、明确责任分工与跟踪风险。包内共1个docx文件，约33KB，适合直接作为流程支持性文件或模板参考。已有2698人学习，可用于研发流程宣贯、评审准备清单编制和跨部门协作对齐，帮助读者快速理解各阶段该评什么、由谁提供、谁来评审，提升评审组织的完整性与可操作性。

1. 评审不是开会：IPD 的 TR 阶段为什么被切成六道闸门

一份 31 条查核点的 TR1 清单摆在桌上，多数团队的第一反应是“要素太多、根本评不完”。但真正决定这套 IPD 评审能不能跑起来的，不是这 31 条写了什么，而是每条后面跟着的那三列：交付物编号、资料提供部门、资料评审负责人。

查核点只是问题，后三列才是约束——它回答的是“这个问题由谁拿什么材料来回答、答不上来算谁的责任”。搞懂这套约束怎么把一个 TR 阶段从“开会”变成“闸门”，比背下 TR1 到 TR6 的名字有用得多。

2. 双闸门机制：TR 收敛技术不确定性，DCP 收敛投资不确定性

2.1 TR1 到 TR6：六次把不确定性兑换成证据

把六个技术评审连起来看，会发现它们不是六个检查站，而是六次兑换——每次兑换之后，下一阶段能拿来当“已知条件”的东西就换了一批。

TR1 手上没有实物，能评审的只有论证：需求描述、患者规模、创新性、上市时间与定价、需求时效性、$APPEALS 分析、样件分析、概念设计方案、产品分类、注册可行性、专利避险、竞争分析、可靠性、可测试性、可制造性、加工成本、环境影响。这一阶段本质上是在回答“这事值不值得做、做不做得出来”。

TR2 把需求翻译成规格：产品型号与关键设计参数、外观、包装、材料、灭菌、关键特性的测试方法与测试标准。灭菌规格和材料规格这两条一旦定死，后面几乎不可逆——这是整条链上最贵的一次翻译。

TR3 把规格翻译成资源：研发成本预算、外协计划、资源投入、进度、开发周期风险、开发成本风险，以及设计需求与包装需求的风险控制计划。

TR4 把方案翻译成可制造的图纸与工艺：关键尺寸与部件、图纸审核、设计变更历史、工装检具刀具的设计审核、工序与设备、工艺重点难点、生产与采购计划。

TR5 用数据替换判断：工厂加工意见、样品质检结果、样品测试报告、测试实施标准、测试数据、测试设备状态。

TR6 用批量替换样品：批量试制意见、批量质检结果、临床测试结果、成本核算、量产工艺、量产计划、量产确认。

这张表里最值得盯的不是名字，是条数分布：TR1 有 31 条，TR2 和 TR3 各只有 8 条。差距不是随手写的——TR1 阶段手上没有实物，能评审的只有推理，所以只能把推理拆成尽可能细的问题去拷问；到了 TR4、TR5，有图纸、有样品、有测试数据，一条要素就能挂一份硬证据，要素数量自然掉下来。查核点的密度和证据的硬度是反比关系。反过来说，如果你手上某个阶段的要素表特别长，八成说明那个阶段的结论主要靠“大家觉得行”，那才是风险最集中的地方。

2.2 概念评审、计划评审、发布评审：DCP 到底在决策什么

三个决策评审点的第一条要素，暴露了它们的真实定位。概念评审-1 是“对 TR1 评审结果的审查”，计划评审-1、-2 是“TR2、TR3 评审结果的审查”，发布评审-1、-2、-3 是“TR4、TR5、TR6 评审结果的审查”。

注意它们审查的对象是什么：发布评审-1 的交付物栏写的不是图纸，而是“TR4 评审记录”。这个细节很关键——TR 的交付物是文档，DCP 的交付物是记录。文档可以随时改，记录是已经签过字的。决策层拿到的不是一份可以被重新编辑的材料，而是一份“谁在什么时候基于什么材料说了什么”的证词。

再看要素构成。概念评审 11 条里，只有第 1 条和第 2 条沾技术，剩下的是知识产权处置、需求目标与客户与需求量、市场情况、研发资源与竞争对手、生产线及生产能力、市场营销策略、经济效益评估、风险响应计划、项目概算与沟通计划与里程碑与团队职责。换句话说，DCP 问的不是“技术上行不行”，而是“这门生意现在还成不成立”。

计划评审最能说明问题：它只有 5 条，其中“投资组合管理”和“开发资源匹配的优化”跟当前这一个项目毫无关系。它们管的是多个项目抢同一批人、同一笔预算时怎么裁决。这就是 DCP 和 TR 的根本差别——TR 的视野里只有一个项目，DCP 的视野里是一个组合。所以 DCP 的参会者是 IPMT，而不是各专业口的工程师。

发布评审 12 条同样按这个逻辑展开：审查三份 TR 记录之外，是成本核算与收益评估、资源使用情况评价、营销战略、预估销售额、宣传资料、培训计划、产品验收标准、销售任务、上市后跟踪计划。最后单独一行是“发布阶段产品文档归档移交”，责任人落到项目经理——流程收口的那一下，也必须有人签字。

2.3 同一份交付物出现两次三次：版本复活机制

把交付物编号在全表里搜一遍，会发现有些编号反复出现：Phase0-5 法规注册评估报告在 TR1-11 之后被 TR2-1 引用（标注“更新”）、又被 TR5-8 引用（再次标注“更新”）；Phase0-10 风险管理计划在 TR1-30 出现，到 TR3-6 又以“更新”身份出现；Phase1-15 在 TR2-3 和计划评审-3 各出现一次；Phase1-17 在 TR3-1 和计划评审-5 各出现一次。

如果把它当成“重复登记”，会觉得这张表很啰嗦。但换个角度看，这是在给交付物建生命周期：一份文档不是交一次就进档案柜，而是有一条“基线—复活—再基线”的轨道。同一个名字，在三个闸门上的判定标准完全不同——法规注册评估报告在 TR1 是“可行性判断”，在 TR2 是“注册计划确认”，到 TR5 变成“计划与实物的一致性核对”。名字没变，问题变了。

机制上的好处是触发面广：只要规格一改，沿着这几条边就能把下游所有受影响的东西叫醒，不会出现“图纸改了但注册计划还是老版本”这种事。代价是维护成本——改一份文档要同时改多处引用，这也是后面要讲的坑之一。

还有一个反直觉的设计值得单独说：Phase0-1 项目立项任务书和 Phase0-2 产品开发任命书，在表里被明确标成“非评审内容”。这两份东西不做技术评审，只做确认。原因是它们的效力来自授权，不来自论证——硬把它们塞进评审议程，只会稀释真正需要拷问的技术问题。分清“要评审的”和“要登记的”，是这张表里最省力的一笔设计。

3. 要素表的结构：一条查核点为什么要绑四样东西

3.1 查核点、交付物、提供方、签字人：四件套缺一不可

随手抽一条：TR1-11 产品分类，对应 Phase0-5 法规注册评估报告，资料提供部门注册办，资料评审负责人注册办副经理。四样东西咬合在一起，才构成一条可执行的要素。

只有问题没有交付物，评审就变成现场口头答辩，谁嗓门大谁有理，事后无据可查。只有交付物没有问题，评审就变成念稿会，读完文档大家点头，没人知道该盯哪一行。有交付物、有问题，但没有明确的提供方和签字岗，就会出现最经典的那句“我以为这块是他们在管”。

这里有个容易误读的地方：提供部门和评审负责人经常是同一个部门的人，比如 TR1-1 需求描述由产品部提供、产品经理签字，TR1-16 专利可行性分析由研发部门提供、研发经理签字。这不是既当运动员又当裁判，而是两级评审里的第一级——部门自审。签字人是本部门的第一责任人，材料能不能拿出手由他兜底；跨部门的复核发生在闸门会议上，由各口一起裁决。把“谁签字”和“谁裁决”分开，责任才落得下去。

也有真正把口子开在部门之外的地方。TR1-26 可制造性要求写得很细：从加工该产品的技术方案、工装、加工设备、人力资源四个方面分析，交付物是 Phase0-9，提供方是产品开发部而不是研发部门。理由很直白——可制造性不能由设计的人自己判，那句话必须由要把它造出来的人说。

3.2 Phase 编号与 TR 编号是两套坐标系，混用会出事

表里同时存在两套编号：Phase0-x、Phase1-x、Phase2-x、Phase3-x，和 TR1 到 TR6、概念评审、计划评审、发布评审。很多人默认它们是一一对应的，其实不是。

Phase 编号标的是交付物的产出时点和工作包归属，TR 编号标的是评审闸门。一个 TR 会消费多个 Phase 的交付物——TR1 的 31 条要素压在 Phase0-3 到 Phase0-10 这 8 份材料上，其中 Phase0-5 一份报告就要回答 TR1-11 到 TR1-15 这 5 条。反过来，一份 Phase 交付物会被多个闸门消费：Phase0-5 被 TR1、TR2、TR5 三个闸门引用，Phase0-10 被 TR1 和 TR3 引用，Phase1-15 和 Phase1-17 都被 TR 和计划评审同时引用。

混用这两套坐标系的后果很具体：按 TR 排计划，交付物就永远“在路上”，因为 TR 只告诉你什么时候评，不告诉你什么时候写完；按 Phase 排计划，又会出现文档全齐了但没人发起评审，材料在共享盘里躺到发霉。可行的做法是把两套编号当成“行”和“列”，排期按 Phase 走，准入按 TR 卡。

3.3 把这张表写成可校验的数据结构

人肉维护 75 条 TR 查核点加 28 条决策点，出错是迟早的事。把每条要素抽象成一个不可变记录，是让这张表可被程序校验的第一步。

from dataclasses import dataclass @dataclass(frozen=True) class CheckItem: code: str # 查核点编号，如 "TR1-11"，全表唯一，一旦发布不再变 gate: str # 所属闸门："TR1".."TR6" / "概念评审" / "计划评审" / "发布评审" question: str # 查核要点，必须是能判真假的问句，禁止写成"介绍/讨论" deliverable: str # 交付物编号，如 "Phase0-5"，指向文档而不是部门 owner_dept: str # 资料提供部门，负责把文档写到可评审状态 reviewer: str # 资料评审负责人，签字岗位，答不上来由这个岗位兜底 version: str = "v1" # 交付物基线号，更新时递增，旧版本留档不删 TR1_11 = CheckItem( code="TR1-11", gate="TR1", question="产品分类是否已确定", deliverable="Phase0-5", # 法规注册评估报告 owner_dept="注册办", reviewer="注册办副经理", )

几个字段的设计动机值得说明。deliverable存编号而不是文件名，是因为文件名会变（“法规注册评估报告_v3_终版_真的终版.docx”），编号不会；只要编号稳定，跨版本追溯就成立。version挂在要素上而不是文档上，是因为同一个编号在不同闸门上要求的基线不同——TR2 要的是 v2，TR5 要的是 v3，这个差异必须显式记录，否则“更新”两个字就是一句空话。reviewer存岗位而不是人名，是因为人会调岗，岗位不会；表要能活过组织架构调整。

frozen=True不是洁癖。评审要素一旦被下游引用（比如 TR4-1“是否满足概念设计要求”实际上在引用 TR1-9 的结论），它就是契约，中途被改会让所有引用静默失效。要改就新建一条并升版本，让变更留下痕迹。

4. 追溯链：TR4 的图纸怎么追回 TR1 的那句话

4.1 需求在六个闸门里怎么不被稀释

需求从 TR1 走到 TR6，要经过五次转手，每一次都有被稀释的风险。表里这条链是断断续续露出来的：TR1-6 的 $APPEALS 分析定下需求维度，TR1-9 的概念设计方案给出实现路径，TR2-3 的关键设计参数把它变成数字，TR2-8 的关键产品特点测试方法、测试标准及关键指标把它变成判据，TR4-2 的关键尺寸和部件把它落到图纸上，TR5-4 的测试实施标准和 TR5-5 的测试数据把它变成可核对的记录，TR6-2 的批量试制质检结果把它变成批量一致性。

每一环的“可测量程度”必须单调递增。TR1-3 问的是“需求特点及创新性描述是否清楚”，这是没法量化的；TR2-3 问的是“关键设计参数”，这就必须有数；TR2-8 问的是“测试方法、测试标准及关键指标”，参数变成了判据；TR5-5 要求的是“测试数据”，判据变成了数字。

这条链上唯一一条显式的“回指”要素是 TR4-1：是否满足概念设计要求。它不检查图纸本身画得对不对，只检查图纸和 TR1-9 那份概念设计方案之间的一致性。这是整张表里少见的、把“追溯”写进查核点的地方。我的理解是，这种回指要素应该更多一些——每到一个新闸门，都该有一条“你还在解决当初那个问题吗”的问题。

4.2 风险是活文档：Phase0-10 的三次出现说明了什么

风险管理计划在表里出现的位置很能说明设计意图。TR1-30 要求“全方面风险分析及控制计划”，TR1-31 单独一条叫“风险管理负责人确认”，到 TR3 又拆成 TR3-6 开发周期风险评估、TR3-7 开发成本风险、TR3-8 设计需求与包装需求与设计参数的风险控制计划，仍然指向 Phase0-10；概念评审-10 再要一次“是否识别了风险、制定了风险响应计划”。

同一条风险线被四个地方拽着，机制上的意思是：风险不是填一张表交上去就完事，而是每次过闸门都要重新基线化——新增了什么、关闭了什么、责任人有没有换人。TR1-31 把“负责人确认”单列成一条查核点，这个做法很反常识：责任人不明确本身就可以判不通过。多数团队栽跟头不是因为没识别出风险，而是识别出来之后没人认领。

4.3 一次闸门完整性校验：找出孤儿交付物和断链要素

有了 3.3 那个结构，就可以对整张表做静态检查。下面这段逻辑针对四类最常见的问题。

from collections import defaultdict JUDGE_WORDS = ("是否", "确认", "明确", "完整", "可行", "已") def audit(items, registered): consumers = defaultdict(set) for it in items: consumers[it.deliverable].add(it.gate) # 1) 孤儿交付物：登记在册，却没有任何查核点引用它 orphans = sorted(set(registered) - set(consumers)) # 2) 单点交付物：只被一个闸门消费，多半是"交完就死"的一次性产出 single = {d: sorted(g) for d, g in consumers.items() if len(g) == 1} # 3) 跨部门要素：提供方与签字方不同部门，必须事先约定会签人 external = [it for it in items if it.owner_dept != it.reviewer_dept] # 4) 无判据要素：查核点里没有判定词，评审时无法给出通过/不通过 vague = [it for it in items <p> <a href="https://download.csdn.net/download/wang_guang/84929697" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>