简介：面向IPD产品开发流程管理者的阶段评审要素说明文档，以TR1至TR6六个技术评审点为骨架，系统梳理各阶段需查核的评审要素、对应文档或交付物，并逐一标明资料提供部门和评审负责人。内容覆盖项目立项、概念设计、法规注册、规格分解、总体方案、设计成果、样品测试及批量试制等多个关键环节，并以表格形式细化到TR1-1至TR6-8等具体查核编号，相当于一份可直接对照使用的评审清单，可帮助产品经理、研发经理、项目经理快速明确各阶段输入输出与责任分工。资源为单个docx文件，共1份，压缩包大小约29KB，内容为完整表格化文本，便于复制修改为内部评审模板。该资源已有2374人学习下载，适合正在推行IPD流程或需要完善TR评审规范的企业团队参考。
1. TR1到TR6评审要素说明：IPD流程里最难落地的不是流程，是评审
做了七八年产品开发，我最怕的不是需求变更，不是进度延期，而是评审会开完，问题一个没拦住，等到量产了再翻车。IPD这套框架在国内研发团队里用得越来越多，但绝大多数团队把TR评审做成了“过场签字”——要素表打开，逐条念一遍，打几个勾，会议结束。真正的问题在于，大部分人手上没有一份把TR1到TR6每个阶段评审要素讲清楚的说明文档。这份《TR1——TR6产品开发各阶段评审要素说明.docx》解决的就是这件事：它把六个技术评审点的输入、输出、评审要素和检查方法拆成了可执行的清单，让评审会从“走过场”变成“真拦截”。适合正在推IPD但卡在评审落地环节的研发管理者、项目经理和QA。
2. 读懂IPD评审框架：六个评审点各自卡什么，要素边界在哪里
2.1 TR1到TR6的定位：技术评审不是为了打分，是为了提前暴露风险
IPD里的TR评审，和财务评审、投资决策评审（DCP）是两套并行机制。DCP管“做不做、投不投”，TR管“技术上行不行、能不能往下走”。很多团队把TR评审结果直接当成立项或砍项目的依据，这是理解偏差。TR评审判断的是技术成熟度和风险状态，不是商业价值。评审要素说明文档里反复强调的也是这一点：每道TR关口都要回答“当前技术状态是否支持进入下一阶段”，而不是回答“这个产品值不值得做”。
六个评审点的定位大致是这样：TR1看概念和机会，TR2看需求和规格，TR3看总体方案，TR4看详细设计和样机，TR5看系统验证和量产准备，TR6看上市后的表现。每道关口之间有明确的前置条件，前置不满足，评审就不该开。文档里把每个TR的输入项列得很细，比如TR2的输入必须包含经过评审的客户需求清单和产品包需求规格初稿，如果需求还没冻结就进入TR2，后面TR3、TR4一定返工。
2.2 要素说明文档在流程里的位置：它连接了流程文件和实际操作
大部分公司的IPD流程文件写得很宏观，告诉你“要做TR4评审”，但不告诉你TR4具体看什么、谁来审、怎么判。而详细到“每张表单怎么填”的作业文件又往往缺失。这份说明文档恰好补了中间这一层：它把流程文件里“做TR4评审”这句话，拆解成“八大类要素、三十多个检查项、每个检查项的判定标准和数据来源”。我拿到的这个版本里，每个TR都列了要素类别、序号、要素内容、验证方式、评审结论要求，基本可以直接搬进公司的评审检查表里用。
文档组织方式对使用者很友好。它不是把所有阶段的要素混在一起，而是按TR1到TR6分章，每一章内部再按要素类别分小节。比如TR4章节里，详细设计完整性、可制造性、可测试性、物料风险、供应链准备度是分开评审的，任何一个类别的要素没过，可以单独打“未通过”并给出整改要求，不需要整场评审一票否决。
提示：不要把这文档当成“评审细则”那么简单。它更大的价值是帮你对齐评审尺度——团队里每个人对“设计完成”的理解不一样，要素表把判断标准落到条，争议就少一大半。
2.3 要素表的判定方式：有数据给数据，没数据给方法，不许拍脑袋
这份文档里每个评审要素后面都挂了“验证方式”列，常见的有三类：文档评审、检查表核查、试验或仿真验证。比如TR2阶段“需求可测试性”这个要素，验证方式是逐条核查需求条目是否包含量化指标和测试方法；TR4阶段“关键模块性能达成度”的验证方式则是样机实测数据对照规格。这个设计很关键——它把“感觉差不多”“应该没问题”这类主观判断直接挡在评审会外。
如果团队刚导入IPD，我建议从这张表里挑“文档评审”类的要素先做起来，这些对环境和设备要求低，推进成本最小。试验和仿真类的要素涉及实验室资源，建议提前一个季度做计划，否则TR4、TR5评审时大概率因为没有实测数据而卡住。
3. TR1、TR2、TR3前期评审：概念、需求与方案，要素怎么逐条核对
3.1 TR1概念评审：市场和技术的第一次握手，最容易变成PPT汇报
TR1评审在IPD流程里是技术评审的起点，评审对象是产品概念和初步业务计划。很多团队把这个会开成“产品经理讲PPT”，讲完市场机会、讲完竞争对手，然后草草散会。但按评审要素表来核，TR1至少有七个方面要给出结论：市场机会与需求初步分析、产品包初步概念、技术可行性初步评估、风险识别、专利与合规初步排查、项目初步估算、对现有产品线的影响。每个方面都有明确输出物要求。
实际执行时最常被忽略的是“技术可行性初步评估”这一条。它要求开发代表给出基于现有技术储备的初步判断，区分“已有成熟方案”“需要攻关的新技术”“存在较大不确定性的技术点”三类。我经历过一个模拟项目X，TR1评审时技术可行性几条全是“成熟方案”，结果TR3阶段发现其中一个模块需要定制算法，整个进度被拖了三个月。事后复盘，TR1时负责该模块的工程师没参会，技术判断是产品经理代填的。要素表没问题，执行出了偏差。
3.2 TR2需求评审：需求条目化是基础，双向追踪是门槛
TR2评审的核心对象是产品包需求规格（PRS）。要素说明文档里，TR2的检查项核心围绕这几组问题：需求是否完整、需求之间是否一致、需求是否可测试、需求是否与客户需求双向可追溯、需求基线是否受控。这五个问题里，最容易出问题的是“双向可追溯”。很多团队做到了“客户需求到产品包需求”的单向追踪，但倒过来查“每条产品包需求对应哪条客户需求”时，答案经常是“这条来源丢了”。
评审要素表里对追溯性的验证方式是抽样核查：从产品包需求里随机抽十到十五条，逐条找到原始客户需求来源，找不到就判不通过。这个做法成本低但非常有效。另一个容易被忽视的要素是“需求优先级排序”。产品包需求里哪些是必须有（Must）、哪些是应该有（Should）、哪些是最好有（Nice to Have），没有排序的话，后面TR4、TR5一旦资源紧张，需求取舍就没有依据。某项目在TR2时没有明确定优先级，TR4阶段硬件资源冲突，开发团队只能临时开会讨论砍哪些功能，评审节奏全被打乱。
3.3 TR3总体方案评审：方案粒度不够细，TR4必然翻车
TR3评审看的是系统总体方案，核心要素包括：系统架构设计、模块划分、关键技术选型、关键接口定义、可制造性可测试性可服务性初步设计、技术风险与备选方案。三性设计（可制造性、可测试性、可服务性）在这里特别要盯紧。很多开发团队在TR3时只关注功能实现方案，对工艺、测试和服务考虑很少，等到TR4详细设计时返工。
我一般建议评审时重点看两点：第一，模块划分是否支持并行开发。文档要求模块间的接口定义必须明确到“接口类型+数据格式+时序要求”，做不到这一层级，后面集成阶段就会一直出现联调扯皮。第二，备选方案不是空话。要素表里明确要求“每个关键技术点至少要有一个备选方案或降级策略”，TR3评审如果发现备选方案栏全是“暂无”，基本可以直接打回。备选方案的价值不在于是不是最优，而在于当主方案失败时团队知道自己还有退路。
注意：TR3评审结束意味着方案冻结，后续变更要走变更控制流程。很多团队省了这一步，直接在TR4阶段随意改方案，结果评审要素里“方案与TR3基线一致性”这一条永远过不了。评审被卡是小问题，开发返工是大代价。
4. TR4、TR5、TR6中后期评审：设计细节、实测数据与量产准备，要素核什么
4.1 TR4详细设计评审：要素最杂、周期最长，最容易漏的是供应链
TR4是六个评审点里要素量最大的一个，覆盖详细设计文档完整度、原理图和PCB评审、结构设计评审、软件架构评审、器件选型与物料风险、可制造性评审、可测试性设计评审、供应链准备度评估等多个维度。文档里特别把“物料风险评估”单独列了一组要素，判断标准是长周期物料、独家供应物料、即将停产物料是否全部识别并给出应对计划。
这里有个血泪经验：TR4评审时物料清单（BOM）还没有最终冻结，但器件选型的风险必须提前暴露。某项目就栽在这上面——TR4评审时电源芯片用的是一颗独家供应的型号，评审时没人提风险，TR5阶段该芯片交期拉长到二十周，项目被迫换料重做EMC测试。后来我再看要素表，发现“独家供应器件必须有替代料或提前备货”这条一直写在里面，只是当时评审时没人真正拿BOM逐颗核过。做TR4评审，一定要带着最新版BOM去会议室，逐项过。
4.2 TR5系统验证评审：实测数据说话，漏测项比失败项更可怕
TR5评审发生在系统验证和Beta测试之后，量产准备之前，核心要素包括：测试用例执行完成率、缺陷收敛趋势、已知缺陷对用户的影响评估、性能指标达成度、可靠性测试结果、量产工艺验证结果、售后与服务准备度。这里最容易出现争论的是“缺陷收敛趋势”怎么算。文档里的定义是用“新增缺陷数随测试轮次下降、修复缺陷数稳定上升”来判断收敛，单纯看缺陷总数没有意义。
TR5评审还有一个容易吵起来的问题：已知缺陷还能不能发版。要素表给了一个可操作的判定框架——按严重性和发生概率把缺陷分四档，只有“严重且必现”和“严重且大概率的缺陷”才必须全部关闭才能过TR5，中等缺陷可以带病上市但要制定解决计划。这个框架的价值是让评审讨论有边界，而不是不同人对“要不要延期”各执一词。实测数据方面，可靠性测试（老化、温度循环、振动等）如果报告缺失，我一般不建议放行，因为这类数据一旦到量产出问题，成本会是测试成本的几十倍。
4.3 TR6上市后评审：性能表现、问题闭环、与预期对比，后评估的价值
TR6是IPD流程里常被跳过的关口，很多团队产品上市后就直接进入维护模式，不再做正式评审。但这恰是要素文档里做的比较细的一块：产品上市后的实际性能与TR2定义的规格对比、客户问题闭环率、重大质量事故复盘、产品退市或切换计划完备性、生命周期成本分析。这些要素的价值是给下一代产品提供输入，不是走形式。
我见过某团队做TR6时发现实际功耗比规格高15%，但因为这个指标在TR2之后没有人回看，版本已经量产了大半年。做TR6评审时拿着实测数据回看当初的需求规格，很多“当初拍脑袋定的指标”会暴露出来，这些信息对下一代平台的指标定义非常有用。文档里TR6还有一个容易被忽略的要素叫“经验教训归档完整性”，包含技术、流程、管理三个维度的复盘结论，建议评审时逐条确认是否已写入组织知识库，而不是散落在各项目组成员的个人笔记里。
5. 评审要素落地的三个避坑点：要素表看着全，用起来却漏项
5.1 避坑点一：要素全勾“通过”，评审结论却写了“有条件通过”，自相矛盾
现象：项目组拿着要素表逐条核对，所有检查项都打了勾，但评审结论里又写了好几条整改意见，会议纪要看不清到底通没通过。
原因：执行评审时把“要素项”和“整改项”混为一谈。要素表里的每一项都要求有明确的判定证据，如果某项没完成，就不能勾“通过”。但实际操作中很多参会者觉得“差不多了”“后面还能改”，就顺手勾了通过，同时口头提了修改意见。这导致从系统上看，评审结论是全部通过，但实际风险一条没少。
解决：评审开始前先定规则——要素表的结论只有“通过”和“不通过”，没有中间档。整改意见必须挂到具体要素项下面，写清责任人和完成时间。凡是评审提出整改意见的要素项，一律视为“不通过”，必须在规定时间内闭环后再做一次记录确认。从那以后我每次主持评审，第一页PPT就写这句话：“有整改意见=该项不通过，请现场确认。”
5.2 避坑点二：TR评审和DCP决策混在一起开，技术问题被商业问题带偏
现象：评审会上产品经理在讲市场占有率，销售在讲客户反馈，技术问题讨论十分钟就结束，两个小时的会有一半时间在聊商业模式。
原因：TR评审会没有被明确限定在“技术评审”范畴内。很多公司用一场会同时覆盖TR和DCP，参会人员既管技术又管商业，议题天然会被拉偏。更常见的情况是TR评审没有独立主持人，由项目经理或产品经理兼任，他们没有技术评审的强制力，控不住场。
解决：把两种会议在流程上彻底分开。TR评审由系统架构师或技术负责人主持，参会者限定在技术相关角色——开发、测试、工艺、供应链的代表，商业决策相关的人不进会场。DCP决策单独开会，TR评审结论作为DCP的输入材料之一。要素表文档里的每个评审项都应该有“证据提供角色”这一列，提前指定谁来讲、讲什么，避免参会人员现场发散。
5.3 避坑点三：TR文档版本不锁定，评审用的是旧版，整改时看的是新版
现象：TR4评审刚开完，质量工程师拿着评审记录去跟踪整改项，发现文档已经更新了两版，当初评审时的版本和当前版本对不上，整改项都不知道对应哪个模块。
原因：没有在评审启动前锁定评审基线。IPD流程里TR评审的输入文档必须冻结版本，但实际操作中，很多团队的文档库没有版本控制意识，工程师随时在更新文档。评审会上一人拿一版，大家讨论的根本不是同一份方案。
解决：在评审通知发出时就锁定评审基线，所有评审输入文档统一归档到一个评审基线目录，目录只读，任何人不能修改。评审结束后如需变更，走正式变更控制流程，同时在要素表里更新“变更影响评估”记录。这一点是血的教训换来的——某项目TR5评审时元件选型文档在会前两小时被更新了一版，评审结论说器件全部可用，实际上新版文档里换了一颗料，量产时才发现，损失超过六位数。
6. 把TR评审挂到IPD流程上：要素文档怎么裁剪，评审效率怎么提
拿到这份要素说明文档，不要整篇套用。最简单的办法是按阶段裁剪成评审检查表——TR1和TR2用第一组要素，TR3用第二组，TR4、TR5、TR6分别用对应的章节。裁剪的原则是：只保留与本项目技术要求相关的要素，无关的删掉，并在表头注明“本项目不适用项及原因”。比如纯软件项目，硬件相关的工艺、物料、EMC要素可以直接标记为不适用，不用浪费时间逐条读。但要注意，“不适用”不是“不评审”，要写明判断依据。
执行层面我给三条具体建议。第一，评审材料至少提前三个工作日发到所有评审专家手里，要素表里每个要素项对应哪个文档的哪一节，提前标好页码，让参会者在会前完成预审。评审会上只对有争议的要素展开讨论，不需要从第一条念到最后一条。第二，给每个要素项指定责任人，评审时责任人负责汇报该项的证据和结论，其他专家只做质询，“谁主张、谁举证”的原则在这里同样适用。第三，整改项的闭环不要靠人追，把TR评审输出物做成一张整改跟踪表，每条整改项有责任人和验收标准，挂在项目的周例会里过一遍即可。
我个人养成的习惯是每个TR评审会后花十五分钟时间对比本次评审要素表和上次的差异——如果某类要素连续两次评审都出问题，就说明这块能力在团队里是真短板，要在项目组之外推动专项建设，而不是等着下一次评审再暴露一次。这套做法帮我在多个项目上提前堵住了设计隐患。要素表是死的，评审方法是活的，关键是让每次评审都留下能被追踪的记录，希望帮到你。
本文还有配套的精品资源，点击获取
