简介面向产品研发、项目管理及IPD流程落地人员的评审要素参考文档聚焦集成产品开发中DCP与TR各阶段“评什么、看哪些交付物、由谁提供和负责”的问题。资源包内含1个docx文件约33KB以表格化清单组织便于直接查阅并裁剪为团队模板。内容覆盖Phase0-1至Phase0-13的项目立项、任命书、原始需求、技术概念、法规注册、市场分析、技术/生产可行性、风险管理、概念与规格及总体方案评审并延伸至TR1TR6、概念评审、计划评审和发布评审。每项要素对应相关文档或交付物、资料提供部门及评审负责人可帮助读者建立阶段门评审检查表统一研发、注册、质量、产品与财务等角色的评审口径也可用于内训和流程审计。已有2700人学习。1. 一张评审地图IPD 的八十多条查核要点是怎么串起来的IPD 集成产品开发里最容易背混的是把“阶段”和“评审点”当成同一条线。把这份各阶段评审要素说明摊开其实是三条线拧在一起Phase 0 到 Phase 3 是时间轴TR1 到 TR6 是技术评审卡点概念评审、计划评审、发布评审这三场 DCP 是投资决策卡点。每一条查核要点后面都挂着三样东西——对应的文档或交付物、资料提供部门、资料评审负责人。所以真正要记的不是编号而是“哪一关、看什么、谁交、谁判”这个四元组。适合已经上手带项目、却被评审表压得抬不起头的人拿它当一张自查地图。2. TR 六道门槛从概念到量产的查核要点与交付物2.1 每个 TR 的通用骨架交付物打底要素提问记录收口把 TR1 到 TR6 并排看会发现它们长着同一副骨架。左边是一个 Phase 编号指向一份或多份具体交付物比如 Phase0-3 对应原始需求报告、Phase2-19 对应图纸中间是一串查核要点也就是评审要素表里的“查核要点”列右边是评审结论与评审记录。评审当天的动作顺序是固定的提供部门先把交付物交上来评审负责人对着要素逐条问问完留下评审记录和遗留问题清单再决定放行、有条件放行还是打回。要素本身不产生结论要素只是把“你觉得这个方案行不行”这种主观判断拆成一条条能回答是或否的问题。这里有个很容易被忽略的结构特征同一条要素它的交付物可能来自很早的阶段。比如 TR2-1 法律法规评审用的还是 Phase0-5 那份法规注册评估报告只是在规格评审时更新了一版。所以看要素表不能只看 TR 编号要顺着“评审点对应的文档或交付物”这一列往回找源头否则评审会上就会出现“资料还没出”的尴尬。2.2 TR1三十一条要点按责任部门切成七组TR1 是整张表里最厚的一关三十一条要点横跨产品、研发、注册、制造、财务多个口子。硬背编号几乎不可能按责任部门分组之后就好记多了。分组要素编号查核要点关键词对应交付物提供部门评审负责人需求与市场TR1-1TR1-7产品定位、目标人群规模、创新性、上市时间与定价、需求时效性、$APPEALS 分析、需求要素分析Phase0-3 原始需求报告产品部产品经理概念设计TR1-8TR1-11参考样件分析、概念设计方案、概念阶段风险与应对、产品分类Phase0-4研发部门研发经理法规与专利TR1-12TR1-16配套器械分类、注册信息、注册可行性与方案、法规风险与管理计划、专利可行性Phase0-5 法规注册评估报告注册办注册办副经理组合与竞争TR1-17TR1-21是否符合产品组合规划、竞品分析是否全面、综合竞争性、竞争风险管理、是否满足市场需求Phase0-6、Phase0-7产品部产品经理技术可行性TR1-22TR1-26设计可实现性、可靠性、可测试性、技术风险计划、可制造性技术方案、工装、设备、人力Phase0-8 技术可行性评估报告研发部门研发经理制造与成本TR1-27TR1-29加工成本与费用估算、环境影响评价、生产风险与管理计划Phase0-9 生产可行性评估报告产品开发部产品开发部部门经理全面风险TR1-30TR1-31全方面风险分析与控制计划、风险管理负责人确认Phase0-10 风险管理计划项目经理项目经理这张表的价值在于它把“概念评审要准备什么”变成“七个部门各交一份东西”。实际开会时最常见的拖延是产品经理把七份材料全揽在自己身上结果法规和制造两块永远缺。按分组去催比按编号去催有效得多。另外注意 TR1-1 到 TR1-7 这七条共用同一份原始需求报告说明需求评审内部是有层次的先看定位对不对TR1-1再看人群规模够不够TR1-2再看创新性和时效性TR1-3、TR1-5最后才是 $APPEALS 这种结构化拆解TR1-6和需求要素能不能落到产品上TR1-7。顺序反了就会变成拿着 $APPEALS 表格硬套一个还没想清楚卖给谁的产品。2.3 TR2 与 TR3把需求翻译成参数把方案翻译成计划TR2 规格评审只有八条但它是整条链上性质变化最大的一关——从“要不要做”转成“做成什么样”。前七条集中在规格上TR2-1 法律法规评审沿用 Phase0-5 更新版、TR2-2 注册计划评审、TR2-3 产品型号设计及关键设计参数、TR2-4 外观设计、TR2-5 包装规格、TR2-6 材料规格、TR2-7 灭菌规格统一由研发部门提供、研发经理负责交付物是 Phase1-15。TR2-8 单独拎出来要求“关键产品特点的测试方法、测试标准及关键指标予以说明”交付物是 Phase1-16责任落在研究院。这一条最容易被当成附属品。规格评审真正要回答的是你写下的每个参数将来用什么方法、按什么标准、测到多少算合格。参数没有配套的测试方法TR5 样品测试那天就一定翻车——测试做不出来或者做出来了但没人认。TR3 总体方案评审八条重心从“东西长什么样”转到“怎么把它做出来、要花多少钱、要多久”。TR3-1 各个工程要素整合能力的评审、TR3-2 研发成本预算、TR3-3 外协计划、TR3-4 资源投入计划、TR3-5 明确的进度计划、TR3-6 开发周期风险评估、TR3-7 开发成本风险、TR3-8 设计需求、包装需求和设计参数的风险控制计划交付物是 Phase1-17责任人是项目经理和产品经理。把 TR2 和 TR3 放一起对照区别就清楚了维度TR2 规格评审TR3 总体方案评审回答的问题产品要做到什么指标用什么资源、多少钱、多长时间做出来主要交付物Phase1-15 规格文件、Phase1-16 测试标准Phase1-17 总体方案主导角色研发经理项目经理 产品经理典型风险参数没测试方法进度和成本估得太乐观缺了会怎样TR5 测不出来计划评审过不了资源批不下来TR3-1“各个工程要素整合能力”是这八条里最抽象的一条也是最难糊弄的一条。它问的是结构、电子、软件、工艺、注册这些口子的方案能不能拼成一个整体而不是各自都成立。评审时如果只让每个模块负责人自述本模块这条基本等于没审。2.4 TR4 到 TR6图纸、样品、量产三级放大下半场的三个 TR本质是同一个东西在三种放大倍数下的检查。TR4 设计成果评审十一条交付物集中在 Phase2-19 图纸、Phase2-20 样品生产工艺、Phase2-21 样品、Phase2-18 样品、Phase2-22 器械采购申请表或委托加工单。要点分两段TR4-1 到 TR4-4 是设计口径的是否满足概念设计要求、关键尺寸和部件、图纸审核、设计变更历史记录是否完整TR4-5 到 TR4-9 是工艺口径的工具刀具检具工装的设计审核、设计方案工艺确认、工序设备工艺装置是否明确、工艺重点难点是否解决、生产计划与刀具等采购计划是否清晰可行TR4-10 详细测试计划由研究院出TR4-11 器械加工需求由产品经理确认。TR4-4“设计变更历史记录是否完整”是一条常被跳过的要素。它不产出任何新东西只查旧账所以最容易被“这次先过、下次补”打发掉。但变更记录一旦断链后面 TR5 测出问题时就无法回溯是哪一版改坏的这就是典型的没有后悔药。TR5 样品测试评审九条画风完全变了——从“设计对不对”变成“数据说话”。TR5-1 收集工厂对样品的加工意见Phase2-23 样品加工意见反馈表、TR5-2 样品质量检验结果样品质检报告质量部、TR5-3 样品测试报告、TR5-4 测试实施标准、TR5-5 测试数据、TR5-6 测试设备使用状况以上四项均由研究院出、TR5-7 批量试制任务确认批量试制订单产品部、TR5-8 注册计划更新Phase0-5 更新版注册办、TR5-9 批量试制计划与采购计划确认Phase2-24 批量试制采购计划书。TR5-4 和 TR5-5 要连起来看测试标准是尺子测试数据是读数。标准没定就出数据数据再漂亮也没法判合格。TR5-6“测试设备使用状况”更细它问的是设备本身的状态是否可信——设备没校准前面所有数据都要打问号。TR6 批量试制评审八条落点是钱和产能TR6-1 收集批量试制意见Phase2-26、TR6-2 批量试制质量检验结果质检报告质量部、TR6-3 临床测试结果Phase2-27 临床评估报告产品部、TR6-4 费用和预算平衡Phase2-28 项目成本核算表财务部门、TR6-5 人力资源等成本核算、TR6-6 批量生产的生产工艺Phase2-29 量产生产工艺、TR6-7 量产计划与外购件采购计划Phase2-30、TR6-8 量产确认Phase2-31、Phase2-32产品部。TR6 里第一次出现财务经理作为评审负责人TR6-4、TR6-5这是个信号到了这一关技术已经不是主要矛盾能不能赚钱才是。很多团队在 TR6 还在纠结工艺细节把成本核算放到发布评审再说结果发布评审直接卡在收益评估上。三级放大串起来看就是一句话TR4 看图纸和工艺能不能对上TR5 看数据和标准能不能对上TR6 看产能和成本能不能对上。3. DCP 三场决策评审IPMT 到底在批什么3.1 DCP 与 TR 的分工一个判技术一个判投不投TR 和 DCP 最容易被混为一谈因为它们的资料大量重叠。概念评审的第一条就是“对 TR1 评审结果的审查”计划评审的前两条是 TR2、TR3 评审结果的审查发布评审的前三条是 TR4、TR5、TR6 评审记录的审查。这个设计说明 DCP 不是重新做一遍技术评审而是拿技术评审的结论去做投资判断。TR 的评审负责人是各部门经理研发经理、产品经理、注册办副经理、质量部经理、财务经理DCP 的评审负责人统一是项目经理和 IPMT。人换了问题也就换了——TR 问“这个方案技术上站不站得住”DCP 问“这笔钱还投不投、投多少、什么时候要回报”。理解这一点准备材料的方式就完全不同。TR 材料要往细里做参数、图纸、测试数据越实越好DCP 材料要往整合方向做一页纸说清技术结论、市场结论、财务结论三者的关系。3.2 概念评审十一条把技术结论翻译成投资结论概念评审十一条编号概念评审-1 到概念评审-11大致可以分成四块。第一块是承接概念评审-1 对 TR1 评审结果的审查交付物是概念评审的记录责任人项目经理与 IPMT。第二块是产品与知识产权概念评审-2 产品相关介绍性能、产品标准是否明确、概念评审-3 涉及到的知识产权问题是否确定解决办法。第三块是市场与效益概念评审-4 需求目标、客户、需求量是否明确概念评审-5 市场情况分析概念评审-6 研究与开发的技术、资源、竞争对手情况是否明确概念评审-7 生产线及生产能力确认概念评审-8 是否制定了切实可行的市场营销策略概念评审-9 市场经济效益评估认定。第四块是风险与立项可行性概念评审-10 是否识别了风险、制定了风险响应计划概念评审-11 概念阶段评估项目立项可行性项目概算、沟通计划、里程碑事件、产品开发团队及职责是否确认。概念评审-11 是这一场的收口条它把五样东西一次性问完概算、沟通计划、里程碑、团队、职责。这五样里最容易缺的是沟通计划和里程碑——大家都在算钱和排人没人写“出问题找谁、什么时候必须汇报”。这也是后面项目延期时最常被追责的一项。注意概念评审-2 到概念评审-7 的资料很多是 TR1 阶段各组的汇总不是新写的。所以概念评审的准备重点不是“再写一遍”而是“把 TR1 七组交付物浓缩成 IPMT 能看懂的版本”。3.3 计划评审五条与发布评审十二条一次比一次更看钱计划评审只有五条但每条都直指资源计划评审-1 对 TR2 评审结果的审查、计划评审-2 对 TR3 评审结果的审查、计划评审-3 规格对供应链成本的影响评审、计划评审-4 投资组合管理、计划评审-5 开发资源匹配的优化。除前两条是承接后三条全部是资源配置问题责任人均为项目经理与 IPMT。计划评审-3 值得单独说。它要求评审“规格对供应链成本的影响”用的还是 Phase1-15 那份规格文件的更新版。含义很直接你在 TR2 定下的每个规格都会变成采购价格。规格定得过严供应商找不到成本飙升定得过松产品竞争力不够。这一条把技术决策和财务后果第一次明确绑定在一起是整套评审里最有含量的一条。发布评审十二条是整张表里最杂的一场从审查到销售全覆盖发布评审-1 至 -3 分别审查 TR4、TR5、TR6 评审结果交付物为对应的评审记录项目经理与 IPMT发布评审-4 成本核算与收益评估项目成本核算表更新版财务经理发布评审-5 资源使用情况评价Phase3-33发布评审-6 市场营销战略和营销策略Phase3-34 新品市场推广培训计划产品部发布评审-7 预估销售额、发布评审-8 宣传资料、发布评审-9 培训计划发布评审-10 发布产品验收标准Phase3-35产品开发部发布评审-11 销售任务Phase3-36 销售任务书产品部发布评审-12 产品上市后跟踪计划Phase3-37 产品上市跟踪计划产品部。十二场评审收尾的动作写在最后一行发布阶段产品文档归档移交责任人项目经理。这一行没有编号却决定了整个项目能不能被下一个产品复用。评审记录、变更历史、测试数据、成本核算表如果散落在各人手里下一个项目基本等于从零开始。三场 DCP 连起来看重心迁移非常清楚决策点核心问题主要资料主导方概念评审这事值不值得立项TR1 结果 市场 效益评估项目经理 IPMT计划评审资源给不给、给多少TR2、TR3 结果 供应链成本 投资组合项目经理 IPMT发布评审能不能上市、怎么卖TR4、TR5、TR6 记录 成本收益 销售任务项目经理 IPMT 财务经理4. 要素表四个字段交付物、提供部门、评审负责人怎么落4.1 交付物字段评审能不能开成的入场券要素表里“评审点对应的文档或交付物”这一列实际作用远超一个备注。它决定了评审会能不能按时开。判断方法很简单开会前一天把当次评审涉及的所有交付物列一遍逐个确认是否已出、是否是最新版。TR1 对应 Phase0-3 到 Phase0-10 一共八份TR5 对应 Phase2-23、样品质检报告、样品研究院的四份报告、批量试制订单、Phase0-5 更新版、Phase2-24谁缺一份对应的要素就无法回答。更要命的是“更新”两个字。表里明确标了更新的至少有四处TR2-1 用 Phase0-5 法规注册评估报告更新、计划评审-3 用 Phase1-15更新、计划评审-4 用 Phase0-12更新、计划评审-5 用 Phase1-17更新TR5-8 用 Phase0-5更新、发布评审-4 用项目成本核算表更新。更新版没交等于这条要素用的是半年前的旧结论。提示把带“更新”的交付物单独列一张小表标上原始 Phase 编号和本次更新的触发原因评审时逐条对照能省掉大量来回。4.2 部门与负责人谁交和谁判是两个字段“资料提供部门”和“资料评审负责人”看着像同一件事其实是两个独立维度。部门是可以换人的责任人不能换。举个表里能直接看到的例子TR1-27 到 TR1-29 的提供部门是产品开发部评审负责人是产品开发部部门经理TR1-22 到 TR1-26 的提供部门是研发部门负责人是研发经理。这两组在技术上高度相关可制造性和加工成本是一体两面但责任主体完全分开。如果评审时只叫了研发经理制造那三条就没人能签字。再看注册相关的几条TR1-12 到 TR1-16、TR2-1、TR2-2、TR5-8提供部门都是注册办负责人都是注册办副经理。这是一个贯穿四个阶段的角色从概念一路跟到样品测试。这类“跨阶段同一负责人”的要素实际执行时最容易断——人在 TR1 参与了到 TR5 换了岗交接没做资料就断了。表里还有一类特殊条目Phase0-1 项目立项任务书和 Phase0-2 产品开发任命书标注的是“非评审内容”。意思是这两份东西是流程的起点输入不作为评审要素被逐条追问。但它们依然是交付物缺了它们TR1 就失去了立项依据。把“非评审内容”理解成“不用准备”是这张表里最典型的误读。4.3 把要素表变成可校验的结构要素表条目多、跨阶段引用多靠 Excel 手工维护很容易出现“某条要素没写交付物”或“某条没写负责人”。用一段结构化的定义加一个自检函数能把这类问题在开会前筛出来。# 一条评审要素 编号 所属评审点 交付物来源阶段 交付物 提供部门 评审负责人 REVIEW_ITEMS [ {id: TR1-1, gate: TR1, phase: Phase0-3, deliverable: 原始需求报告, dept: 产品部, reviewer: 产品经理}, {id: TR1-12, gate: TR1, phase: Phase0-5, deliverable: 法规注册评估报告, dept: 注册办, reviewer: 注册办副经理}, # 同一份交付物在后续评审点被复用用 revision 记录版本不另开新行 {id: TR2-1, gate: TR2, phase: Phase0-5, revision: 2, deliverable: 法规注册评估报告, dept: 注册办, reviewer: 注册办副经理}, {id: TR6-4, gate: TR6, phase: Phase2-28, deliverable: 项目成本核算表, dept: 财务部门, reviewer: 财务经理}, ] def check_before_review(items, gate): 开评审会前的自检返回该评审点里字段缺失或交付物重复挂靠的条目 problems [] for it in items: if it[gate] ! gate: continue # 缺交付物或缺负责人评审当天一定卡住 missing [k for k in (deliverable, dept, reviewer) if not it.get(k)] if missing: problems.append((it[id], 缺字段: ,.join(missing))) return problems print(check_before_review(REVIEW_ITEMS, TR1))这段代码逻辑有三处值得说明。gate对应 TR1TR6 或三场 DCP用来按评审点切片phase指向交付物产生的阶段允许同一个 phase 被多个 gate 引用这正是“更新版”的建模方式revision只在复用时出现没有就是首版。check_before_review返回的是问题清单而不是真假值因为实际使用中你需要的不是“能不能开”而是“缺哪几条、谁去补”。参数的取法也有讲究dept和reviewer必须分开存不能用部门名字符串去匹配负责人否则一旦换人全表都要改。4.4 用 Phase 编号做主键做归档发布评审的最后一行动作是产品文档归档移交。归档最容易犯的错是按评审点建文件夹TR1、TR2、TR3……结果同一份 Phase0-5 法规注册评估报告在 TR1、TR2、TR5 三个文件夹里各躺一版谁也说不清哪版是最新的。正确的组织方式是以 Phase 编号为主键Phase0-5 下面挂版本TR1 里放引用TR2 和 TR5 里放的是同一个 Phase 的新版本加变更说明。这样任何一次评审要查资料只需要知道 Phase 号不用记是第几次评审用过它。变更历史也就自然串起来了——TR4-4 要求的设计变更历史记录完整靠的正是这套以 Phase 为主键的目录结构而不是各人手里的备忘录。5. 五个易错点评审要素表最容易被用歪的地方5.1 易错点一把“风险分析”当成“风险管理计划”易漏点TR1-10 概念设计中的风险及应对措施、TR1-25 技术的风险分析管理计划、TR1-30 全方面风险分析及控制计划、TR1-31 风险管理负责人确认这四条在很多人眼里是一件事于是只交一份风险清单就草草了事。为什么漏四条要素分属三个不同交付物——TR1-10 在 Phase0-4、TR1-25 在 Phase0-8、TR1-30 和 TR1-31 在 Phase0-10 风险管理计划责任人从研发经理一路换到项目经理。当成一件事做就只会有一个人在做。怎么补按“识别—分析—控制—责任”四段拆。识别和分析可以分散在各阶段的交付物里但控制和责任人必须收敛到 Phase0-10 那一份风险管理计划并且 TR1-31 明确要求“风险管理负责人确认”这一条没有签字就不算完成。5.2 易错点二跳过标注“非评审内容”的立项任务书与任命书易漏点Phase0-1 项目立项任务书、Phase0-2 产品开发任命书表里标注“非评审内容”于是被理解成不用准备。为什么漏字面意思容易被读成“不需要评审”实际含义是“不作为查核要点被逐条追问”。但它们是 TR1 全部三十一条的立项依据——没有任务书TR1-17“产品是否符合整体产品组合规划”就没有判断基准没有任命书TR1-31 的“风险管理负责人确认”就无从确认。怎么补把这两份归到“流程前置输入”单独管理在 TR1 材料清单里固定放在第一页评审开始前用一分钟确认已签批。成本极低但缺了会让整场评审的合法性受质疑。5.3 易错点三把带“更新”的交付物当成一次性材料易漏点Phase0-5 法规注册评估报告在 TR1、TR2、TR5 三次出现且都标更新Phase1-15 规格文件在 TR2 和计划评审-3 出现Phase1-17 在 TR3 和计划评审-5 出现项目成本核算表在 TR6-4 和发布评审-4 出现。为什么漏表格里“更新”两个字太小做计划时按行数排期很容易把同一份文件当成三份不同材料分别安排或者反过来只做一次就不再维护。怎么补单独建一张“跨评审点复用交付物”清单列三栏Phase 编号、被哪几个评审点引用、每次更新要补什么。法规注册评估报告在 TR2 要补注册计划在 TR5 要补批量试制前的注册进度两次更新的内容并不相同。5.4 易错点四DCP 材料直接拿 TR 材料顶易漏点概念评审-1、计划评审-1、计划评审-2、发布评审-1 至 -3 都是“对上游评审结果的审查”于是把 TR 的全套材料原样搬到 IPMT 会上。为什么漏交付物确实写的是“评审记录”看起来搬过去就满足了。但 IPMT 要做的判断和 TR 完全不同——TR 关心技术是否成立DCP 关心投资是否继续。怎么补TR 记录作为附件另外准备一页整合结论技术结论一句话、市场结论一句话、财务结论一句话、本次请求的资源与放行条件。概念评审-11 列的五项概算、沟通计划、里程碑、团队、职责就是这一页的骨架照着填不会跑偏。5.5 易错点五混淆“提供部门”与“评审负责人”易漏点TR1-27 到 TR1-29 由产品开发部提供、产品开发部部门经理评审TR1-12 到 TR1-16 由注册办提供、注册办副经理评审。同一部门既交又判看起来是一个人可以搞定。为什么漏中小团队里一人多岗很常见写着两个字段实际操作时合并成一个人短期看不出问题。怎么补坚持两个字段分开填并在评审记录上区分“资料提交人”和“评审结论签署人”。同一人兼任时至少在记录上留两行注明本次由谁代行另一职责。这个动作看着形式主义但等到出现质量争议、需要追溯是谁判的放行时它就是唯一的凭据。6. 复习清单把八十多条要素压成三遍能过完的表真要把这套东西记牢靠通读一遍表格没用。我的做法是把八十多条要素压成三遍能过完的清单每遍只盯一个维度。第一遍过“关口—交付物”。只看两列这个评审点对应哪些 Phase 编号。目标是合上表能默写出 TR1 到 TR6 各自的主要交付物尤其是那几个跨阶段复用的Phase0-5 出现在 TR1、TR2、TR5Phase1-15 出现在 TR2 和计划评审-3Phase1-17 出现在 TR3 和计划评审-5项目成本核算表出现在 TR6-4 和发布评审-4。这四组记不住排期一定出问题。第二遍过“责任部门”。按部门反向索引看每个部门被点名几次提供部门主要覆盖的要素首次出现的评审点产品部需求、竞品、批量试制任务、销售任务、上市跟踪TR1研发部门概念设计、规格参数、图纸、工艺TR1注册办法规注册评估、注册计划TR1研究院测试方法标准、测试报告与数据、详细测试计划TR2产品开发部加工成本、生产工艺、量产工艺、验收标准TR1质量部样品质检报告、批量试制质检报告TR5财务部门项目成本核算、费用预算平衡TR6项目经理全面风险、研发/开发成本风险、概念与计划评审TR1这张反向表能立刻暴露短板比如质量部第一次出现是在 TR5意味着前四关完全没有质量口子参与TR1 的“可测试性要求”和 TR4 的“检具设计审核”实际上是研发自己在判。意识到这一点就会主动在 TR1 阶段把质量部拉进来。第三遍过“易错点”。把第 5 章那五条写成五个自测问句每句只答是或否风险相关内容我是否分清了识别、分析、控制、责任人四个层次立项任务书和任命书我是否已签批并放在材料第一页带“更新”的交付物我是否列了单独清单并写明每次补什么DCP 材料我是否准备了一页整合结论而不是搬 TR 全套每条要素的提交人和签署人我是否在记录上分了两行五问里有一个否就去对应章节回查。最后给一个我认为最省时间的动作把要素表按“评审点 × 交付物”做一次透视凡是同一份交付物被两个以上评审点引用的全部标红。整张表里这样的条目不超过十份但它们贡献了绝大部分的资料返工。把这十份管住评审会的准备时间能砍掉一半。这些都是实际踩过坑之后才总结出来的。最早我做评审准备习惯从 TR1 第一条开始往下捋一条条勾勾到第三十条已经忘了第一条写的是什么开会时被问到“这份资料哪一版”还得现场翻。从那以后我每次开评审会前都强制先把当次要审的要素行按交付物去重、按部门分组、把带更新的单独拎出来三件事做完再排会议日程。这套动作重复几次之后就变成肌肉记忆了希望帮到你。本文还有配套的精品资源点击获取
