简介围绕IPD集成产品开发全流程整理的评审要素说明文档面向产品经理、项目经理、研发与质量管理人员以及需要搭建或规范DCP、TR评审机制的团队。文档以阶段评审要素对应表为主线逐项列出评审点、查核要点、对应文档或交付物、资料提供部门与评审负责人覆盖项目立项任务书、产品开发任命书、原始需求报告、技术概念、法规注册、市场分析、技术及生产可行性、风险管理、概念与规格评审、总体方案、设计成果以及TR1至TR6、计划评审和发布评审等关键节点便于对照建立评审检查表和责任矩阵。包内为1个docx文件约33KB结构紧凑适合直接检索和二次编辑。已有2698人学习可作为研发流程落地、评审会准备和交付物齐套性核查的参考模板。1. 把 IPD 评审从“走过场”拉回来一份 3P 要素表能解决什么很多团队的 IPD 评审之所以最后变成走过场是因为评审会上只有 PPT没有查核清单。评审人凭印象提问项目经理凭记忆补材料TR1 到 TR6 走完一遍交付物却缺了一半到了量产才发现概念阶段的注册可行性根本没评过。这份 IPD 集成产品开发各阶段评审要素说明3P就是来解决这件事的它把 DCP 决策评审和 TR 技术评审每个阶段的评审要素、对应交付物、资料提供部门、评审负责人逐条列成表形成可直接对照的模板。它适合三类人正在搭建或整改研发流程的产品经理、需要主持 TR 评审的技术负责人、以及被要求“补齐评审记录”的质量与注册岗位。核心价值不在于告诉你 IPD 是什么而在于给出 TR1 到 TR6 每一问该拿哪份文档来回答、由谁签字。2. 拆开这张表TR1 到 TR6 的要素结构与责任分配逻辑拿到表之后最常见的问题不是“不会用”而是不知道该怎么读。这份模板的信息密度很高每一行其实是一个四元组评审要素查核要点、对应的文档或交付物、资料提供部门、资料评审负责人。读懂了这四个字段的对应关系你才知道评审会该由谁准备材料、由谁拍板。2.1 四列字段的语义与填写边界先看第一列“评审要素”。这不是议题而是查核点写法必须是可判定的疑问句或断言句比如 TR1-3“需求特点及创新性描述是否清楚”、TR1-22“设计可实现性要求是否能够满足”。如果写成“讨论需求”评审就失去可判定性最后只能靠主持人临场发挥。第二列“对应的文档或交付物”是关键约束。模板里几乎每个要素组都挂了一个 Phase 编号的交付物例如 TR1-1 到 TR1-7 对应 Phase0-3 原始需求报告TR1-8 到 TR1-11 对应 Phase0-4 研发部门输出。这意味着评审不是空口评而是对着具体文档评。实操中我一般要求交付物缺席该要素直接判“不通过”不给“口头说明”留口子。第三列“资料提供部门”决定了会前准备的责任人。模板里出现了产品部、研发部门、注册办、正天产品开发部可替换为你的制造/工艺承接部门、质量部、财务部门等。注意这里不是按汇报关系分而是按“谁产出这份证据”分。TR6-4“费用和预算平衡”落在财务部门因为项目成本核算表只有财务能出产品经理出不了。第四列“资料评审负责人”是签字人不是讲解人。这一列最容易在落地时被删掉删掉之后评审记录就没有责任人追溯时找不到谁确认过。建议保留原样把姓名替换成岗位即可。字段语义常见误填正确做法评审要素可判定的查核点写成议题或工作项用“是否/能否/是否已”句式对应交付物评审的证据载体留空或写“见附件”绑定唯一 Phase 编号文档资料提供部门证据产出方按汇报线填写按文档实际编制部门填写资料评审负责人签字确认人填成会议主持人填对该要素有判断权的岗位2.2 为什么 TR1 要挂 Phase0-3 到 Phase0-10 共八个交付物TR1 技术概念评审是整条链上要素最密的一关模板里从 TR1-1 一直排到 TR1-31横跨需求、概念设计、法规注册、市场、技术可行性、生产可行性、风险七个维度。很多人第一反应是“太重了”但拆开看会发现它其实是在回答一个问题这个产品值不值得继续投钱做概念设计。按交付物归组会更清楚Phase0-3 原始需求报告 → TR1-1 至 TR1-7覆盖需求描述、患者规模、创新性、上市时间与定价、时效性、$APPEALS 分析、适应证匹配度。Phase0-4 研发输出 → TR1-8 至 TR1-11覆盖样件分析、概念设计方案、概念阶段风险与应对、产品分类。Phase0-5 法规注册评估报告 → TR1-12 至 TR1-16覆盖配套器械分类、注册信息、注册可行性与方案、法规风险与管理计划、专利可行性。Phase0-6、Phase0-7 → TR1-17 至 TR1-21覆盖产品组合规划契合度、竞争对手与竞品分析、综合竞争性、竞争风险管理、市场需求满足度。Phase0-8 技术可行性评估报告 → TR1-22 至 TR1-26覆盖设计可实现性、可靠性、可测试性、技术风险计划、可制造性。Phase0-9 → TR1-27 至 TR1-29覆盖加工成本估算、环境影响评价、生产风险计划。Phase0-10 风险管理计划 → TR1-30 至 TR1-31覆盖全方面风险控制计划与风险管理负责人确认。这个分组的实操意义在于会前你可以按交付物分七个包发给七个人预审而不是把 31 条要素丢给全体参会者现场过。TR1-26 可制造性那条模板写得很具体——“从加工该产品的技术方案、工装、加工设备、人力资源方面进行分析”这其实是在提示评审时要有制造方的人到场否则这一条必挂。2.3 DCP 决策评审与 TR 技术评审的分工模板里除了 TR1 到 TR6还夹着概念评审、计划评审、发布评审三个 DCP 节点。两者的区别必须分清否则会出现“TR 评审替 DCP 做投资决策”的错位。TR 是技术评审评的是“方案对不对、证据够不够”由技术线和相关部门评输出是评审记录和问题清单。DCP 是决策评审评的是“继续投、调整、暂停还是终止”由 IPMT 这类投资决策团队评输出是决策结论和资源承诺。看模板的结构就很明显概念评审-1 是“对 TR1 评审结果的审查”计划评审-1、计划评审-2 分别是“TR2 评审结果的审查”“TR3 评审结果的审查”发布评审-1 到发布评审-3 是 TR4、TR5、TR6 评审结果的审查。也就是说DCP 不重复评技术它吃 TR 的结论然后加上投资维度概念评审-11 要评“项目概算、沟通计划、里程碑事件、产品开发团队及职责”计划评审-4 要评“投资组合管理”发布评审-4 要评“成本核算收益评估”。这条分工直接决定了会议怎么排。我的习惯是 TR 提前 DCP 至少三个工作日完成TR 记录作为 DCP 的输入材料随会议包发出。如果两个会背靠背开DCP 就会退化成“给 TR 盖章”投资决策的独立性没了。2.4 责任矩阵落地从部门列到 RACI模板的“资料提供部门 资料评审负责人”两列只解决了谁提供、谁签字但没解决谁主持、谁参与、谁知会。落地时我一般补一张 RACI把它和原表并排放不覆盖原表。# 把评审要素表转换成可跟踪的责任矩阵 # 输入从模板导出的要素清单每条一行 elements [ {id: TR1-3, item: 需求特点及创新性描述是否清楚, doc: Phase0-3 原始需求报告, provider: 产品部, reviewer: 产品经理}, {id: TR1-16, item: 专利可行性分析, doc: Phase0-5 法规注册评估报告, provider: 注册办, reviewer: 注册办副经理}, {id: TR1-26, item: 产品可制造性要求是否能够满足, doc: Phase0-8 技术可行性评估报告, provider: 研发部门, reviewer: 研发经理}, ] # 按交付物聚合生成每个文档的预审包 from collections import defaultdict packages defaultdict(list) for e in elements: packages[e[doc]].append(e) for doc, items in packages.items(): print(f预审包{doc} 共 {len(items)} 项) for it in items: # 责任人 提供方负责编制评审负责人负责签字 print(f {it[id]} [{it[provider]} → {it[reviewer]}] {it[item]})这段脚本干的事不复杂但解决了一个真问题模板是给人看的表评审会需要的是按文档拆好的预审任务单。provider派活reviewer签字doc决定这个包发给谁。实际使用时把elements换成从 Excel 导出的完整清单即可行数在三十到四十之间跑一次就能生成全部预审包。参数上唯一要注意的是要素 ID 必须唯一重复 ID 会导致聚合时串包。3. 把模板变成可执行的评审流程会前、会中、会后的操作步骤表格本身不会让评审变好让评审变好的是围绕表格建立的动作序列。这一章给的是能直接抄的三段式流程覆盖会前备料、会中判定、会后闭环每一步都落到具体动作和产出物。3.1 会前按交付物拆预审包并设准入门槛会前动作分四步顺序不能乱。第一步定评审范围。从模板里摘出本次要评的 TR 节点对应的要素行比如本次是 TR2 规格评审就取 TR2-1 到 TR2-8 共八条加一个 DCP 审查项。不要顺手把 TR3 的要素带进来范围一扩会议就失控。第二步按“对应文档或交付物”聚合。TR2 的八条要素里TR2-1 法律法规评审和 TR2-2 注册计划评审都挂在 Phase0-5 法规注册评估报告更新上TR2-3 到 TR2-6 挂在 Phase1-15 研发部门输出上TR2-7、TR2-8 分别挂在灭菌规格和测试方法说明上。聚合后是四个包。第三步发预审任务。每个包发给对应的资料提供部门附上评审要素原文和交付物清单要求提前两个工作日回传预审意见。预审意见的格式固定为三列要素 ID、结论通过/有条件通过/不通过、依据指向文档的具体页码或章节。第四步设准入门槛。这是最容易省掉也最不该省的一步。我一般设两条硬门槛任一交付物缺席该评审延期预审“不通过”项超过总数的三成评审延期。延期不是惩罚是避免评审会变成补材料现场。# 预审包目录结构按交付物建目录避免材料散在聊天记录里 review/TR2/ ├── 00_要素清单.csv # 本次评审的全部要素行 ├── 01_Phase0-5_法规注册评估报告_更新/ │ ├── 交付物.pdf │ └── 预审意见_注册办.csv ├── 02_Phase1-15_研发输出/ │ ├── 交付物.pdf │ └── 预审意见_研发.csv ├── 03_灭菌规格/ └── 04_测试方法与标准/这个目录结构的用意是把“文档”和“对该文档的预审结论”放在一起评审人打开一个目录就能看到证据和前人判断不用在两处对照。00_要素清单.csv至少包含四列要素 ID、要素描述、交付物路径、预审结论会后直接作为评审记录的底稿。3.2 会中逐条判定而不是逐页汇报会中的节奏是这份模板能不能发挥作用的分水岭。汇报式评审的典型场景是产品经理放四十分钟 PPT讲完大家提几个问题就散会要素表一条没对。正确做法是反过来以要素为最小单元逐条过每条只回答三件事——证据在不在、结论是什么、不通过的话谁在什么时间补齐。具体操作上主持人按要素 ID 顺序推进每条控制在两分钟内。预审已判“通过”的只需确认签字不展开讨论预审判“有条件通过”的现场明确条件内容和验证方式预审判“不通过”或会上新发现问题的直接进问题清单当场指定责任人和关闭时间。这里有个血泪经验不要让资料提供方在评审会上现讲自己部门的那份文档。会前预审已经看过会上再讲一遍既浪费时间又容易把评审带成答辩。评审人要问的是“这条要素你的依据是什么”而不是“请介绍一下你的工作”。判定结论建议只用三档不要用五档。三档是通过、有条件通过条件必须可验证、不通过。五档以上在实际操作中没有区分度评审人分不清“基本通过”和“原则通过”的差别最后全都填通过。3.3 会后把问题清单变成带关闭验证的追踪表评审记录如果只写“本次评审通过”三个月后出了问题没有任何追溯价值。会后产物我要求至少三份。第一份是评审结论页一页纸写清评审对象、时间、参与人、要素总数、三档结论的数量分布、总体结论。总体结论只有四种通过、有条件通过、不通过、延期。第二份是问题清单字段至少包括问题编号、关联要素 ID、问题描述、责任部门、责任人、计划关闭时间、关闭验证方式、实际关闭时间、关闭状态。这里的关键是“关闭验证方式”这一列它决定了问题会不会被假关闭。比如 TR3-3 外协计划评审被打了不通过验证方式应该写成“提交签署版外协计划并核对关键外协件交期与总进度计划一致”而不是“提交外协计划”。第三份是要素级追溯表把每个要素 ID 与本次的结论、依据文档版本、签字人一一对应。这份表是后续 TR 复评和 DCP 审查的直接输入概念评审-1 要“对 TR1 评审结果的审查”审查的就是这张表。# 生成要素级追溯表用于 DCP 审查和后续复评 import csv rows [] with open(00_要素清单.csv, encodingutf-8) as f: for r in csv.DictReader(f): rows.append({ 要素ID: r[id], 结论: r[结论], # 通过 / 有条件通过 / 不通过 依据文档: r[交付物路径], 文档版本: r[版本], # 必须记录版本否则追溯失效 签字人: r[评审负责人], }) # 统计分布作为评审结论页的数据来源 from collections import Counter dist Counter(r[结论] for r in rows) total len(rows) print(f要素总数 {total}, dict(dist)) # 不通过比例超过 30% 时不建议给出“通过”总体结论 fail_ratio (dist[不通过] dist[有条件通过]) / total print(f待关闭比例 {fail_ratio:.0%})这段脚本的重点不在代码本身而在文档版本这一列。要素追溯失效最典型的原因就是只记了文档名没记版本复评时发现文档被改过无法判断当初评的是哪一版。fail_ratio只是给主持人一个参考阈值实际判定还要看问题性质——注册可行性类的“不通过”比外观设计类的“不通过”严重得多不能只看比例。4. 避坑与排查这份要素表落地时最容易翻车的五个地方模板本身没问题翻车基本都发生在落地环节。以下五条是我在不同项目里反复见到的按“现象 → 原因 → 解决”写遇到对应症状可以直接对照排查。4.1 要素被当议题评审会开成讨论会现象评审会开了三小时TR3 的八条要素过了四条剩下时间全在讨论进度计划和资源冲突。会后记录写着“充分讨论原则通过”。原因会前没有把要素转成可判定问题主持人也没有按 ID 推进的意识。参与人把评审会当成了协调会一有分歧就开始拉通。解决会议议程直接印要素 ID 列表每条标注预计时长超时先记问题后跳过。议程上写明“本会只做判定不做方案讨论”方案分歧一律进问题清单另开会。主持人手上必须有预审结论已通过的条目不再展开。4.2 交付物临时补评审变成写作现场现象评审当天上午产品部才把原始需求报告发出来评审人现场翻文档发现 $APPEALS 分析那一节是空的TR1-6 无法判定。原因准入门槛没设或者设了没执行。资料提供部门把“评审前给”理解成“评审开始时给”。解决把交付物提交时间写进评审通知明确提前两个工作日逾期自动延期。延期通知发给资料提供部门的上一级不发给项目经理个人。这条执行两次之后提交时间就不再需要催了。另外TR1-6 这类分析类要素预审时就要核对章节是否存在不能等到会上才发现空白。4.3 责任列被删签字人变成主持人现象用了几个月后有人嫌“资料评审负责人”这一列冗余因为反正都是各部门经理就把整列删了。半年后做流程审计发现 TR4-3 设计图纸审核没有任何签字记录。原因把“谁评审”和“谁主持”混为一谈。主持人组织会议不等于对每条要素的技术判断负责。解决责任列不能删并且要区分“资料评审负责人”和“评审会主持人”两个角色。前者对要素结论签字后者对流程合规负责。TR4-1 到 TR4-4 挂研发经理TR4-5 挂工艺承接部门经理TR4-10 挂研究院研发经理——这些分工是有技术含义的删了就没了。4.4 TR 与 DCP 混开投资决策失去独立性现象TR3 总体方案评审和计划评审安排在同一场TR 结论刚出IPMT 当场就批了资源投入。三个月后开发成本超预算四成。原因DCP 没有独立吃 TR 结论的时间也没有独立的投资维度审查。计划评审-3 要评“规格对供应链成本的影响”、计划评审-4 要评“投资组合管理”这些在混开的会上根本来不及评。解决TR 与 DCP 至少间隔三个工作日TR 记录和问题清单作为 DCP 会议包的必附材料。DCP 上不重复技术讨论只回答投资问题。发布评审同理发布评审-4 成本核算与收益评估、发布评审-7 预估销售额这两条如果和 TR6 混开财务和市场的判断会被技术结论带着走。4.5 要素表不随阶段演进更新后期评审评的是过时证据现象TR6 批量试制评审时评审人拿到的还是 Phase0-5 法规注册评估报告的初版里面的注册方案在 TR2 阶段已经改过两轮。原因模板里多处标注了“更新”比如 Phase0-5 法规注册评估报告更新出现在 TR2、TR5Phase0-12、Phase1-15、Phase1-17 在计划评审里也都标了更新。这些标注在落地时被当成备注忽略了。解决把“更新”当成强制动作写进流程。凡是模板标注更新的交付物对应阶段必须提交新版本并在追溯表里记录版本号变更。TR5-8 注册计划就是典型它直接引用 Phase0-5 的更新版如果版本不对评审的就是一份失效证据。提示这五条里第四条和第五条造成的损失最大因为它们在评审当时不显形要到量产或上市后才暴露属于没有后悔药的那类。5. 进阶用法用要素表做评审有效性度量与跨阶段追溯模板用熟之后可以做一件更有价值的事把它当成度量基准反过来检验评审到底有没有拦住问题。我一般用两个指标一个看单阶段一个看跨阶段。单阶段看“要素关闭质量”。做法是从问题清单里取所有“有条件通过”和“不通过”的项统计其关闭验证方式中可事后核查的比例。比如 TR5-2 样品质量检验结果被打了有条件通过验证方式如果写成“提交质检报告并核对关键指标与 TR2-3 关键设计参数一致”这是可核查的如果写成“已与质量部沟通”这是不可核查的。可核查比例低于七成说明这个阶段的评审在放水条件给得太软。跨阶段看“要素回流率”。具体是指后续 TR 评审中重新打开前序阶段已关闭要素的比例。TR4 设计成果评审里TR4-1“是否满足概念设计要求”如果反复被判不通过说明 TR1 阶段的概念设计要素当初就没评透TR6-6 量产生产工艺如果暴露出工艺可行性问题要回头看 TR1-26 可制造性那条当时是怎么判的。这个指标能定位出流程里最薄弱的评审节点。# 跨阶段要素回流统计定位最薄弱的评审节点 # reopens: 后续阶段重新打开的前序要素记录 reopens [ {from_tr: TR1, elem: TR1-26, reopened_at: TR6, reason: 工艺可行性不足}, {from_tr: TR1, elem: TR1-22, reopened_at: TR4, reason: 设计可实现性偏差}, {from_tr: TR2, elem: TR2-3, reopened_at: TR5, reason: 关键参数与测试不一致}, {from_tr: TR1, elem: TR1-26, reopened_at: TR5, reason: 工装方案变更}, ] from collections import Counter by_elem Counter(r[elem] for r in reopens) by_from Counter(r[from_tr] for r in reopens) print(高频回流要素, by_elem.most_common()) print(回流来源阶段, by_from.most_common())跑出来的结果如果集中在 TR1说明概念阶段评得太粗尤其是 TR1-22 设计可实现性和 TR1-26 可制造性这两条它们是最容易在会上被一句“研发确认可行”带过去的。对应的改法是这两条要素在 TR1 评审时强制要求制造或工艺方到场并单独出具意见不接受研发单方结论。另一个进阶技巧是把要素表和 DCP 的审查项做交叉索引。模板里概念评审-1 对 TR1、计划评审-1 和计划评审-2 对 TR2 和 TR3、发布评审-1 到发布评审-3 对 TR4 到 TR6这个映射关系本身就是一条完整的技术证据链。把它画成一张两列的对照表贴在评审室评审人一眼就能看到当前 TR 的结论会被哪个决策节点引用对要素判定的严肃性会明显不一样。发布评审-10“发布产品验收标准”和 TR5-4“测试实施标准”之间的对应关系也值得单独拎出来核对这两处不一致是上市后质量纠纷的常见源头。我现在每次启动一个新产品的 TR 评审都会先把这张表按本项目裁剪一遍把交付物名称换成项目实际文档名把部门换成实际承接方然后才发会议通知。不做这一步评审人拿到的是通用模板找不到对应的文件最后还是靠口头汇报。裁剪花的时间大概半小时省下的是整场评审的有效性。希望帮到你。本文还有配套的精品资源点击获取