简介：IPD技术评审（TR1-TR6）知识分享是一份系统讲解集成产品开发技术评审要点的PDF资料，面向研发管理人员、项目经理及参与IPD流程的产品开发团队，旨在帮助团队把好产品从概念到上市各阶段的技术成熟度与质量关口。内容涵盖TR评审定义、评审计划、各评审点关注重点、TR裁剪原则及各阶段输入材料清单，其中TR1聚焦产品包需求与概念可行性，TR2检查设计规格完备性，TR3确认概要设计，TR4与TR4A覆盖详细设计、构建及系统级测试，TR5评估工程样机质量，TR6验证制造系统与批量生产条件。压缩包内含1个PDF文件，大小595KB，图文页式呈现，便于快速查阅与团队学习。已有4944人学习下载，适合IPD流程落地、技术评审执行及项目风险管理参考，可直接对照裁剪原则和输入要求开展评审准备工作。
1. 为什么IPD技术评审（TR1-TR6）值得逐个击穿，而不是把六个评审会走一遍
IPD技术评审（TR1-TR6）在很多研发团队里被简化成一张项目节点表：到了时间就开会，开会就汇报，汇报完就算评审通过。真把六道闸门拆开看过一遍的人会明白，这套机制的本质是把产品研发里的不确定性逐级转成确定性。TR1解决“值不值得做”，TR2解决“需求对不对”，TR3解决“方案行不行”，TR4解决“模块是否成型”，TR5解决“样机是否达标”，TR6解决“能不能量产交付”。每一道关卡都有明确的输入、输出和放行门槛，不是凭感觉打分。这篇文章适合研发项目经理、产品经理、质量工程师，以及正打算在团队里从零搭建评审机制的从业者。
2. 拆解TR1-TR6评审闸门：审什么、输入输出是什么、放行条件怎么定
2.1 TR1与TR2：先审“值不值得做”和“需求对不对”
TR1在概念阶段早期触发，很多团队把它当成立项汇报会，这是最大的误用。TR1的核心是概念决策评审，重点审三件事：解决的是不是正确的问题、机会规模有没有数据支撑、技术路线在当下是否具备可行性。它不要求完整需求书，但要求团队拿出初步业务计划和产品概念，并回答“如果投入资源，做出来有没有人要”。
TR1的常见输入是市场调研报告、用户问题定义和初步技术方案，输出是产品概念说明、初始业务计划和技术可行性初步结论。放行标准有四条：客户问题定义清晰；市场规模和趋势有初步数据支撑；技术路线与团队能力匹配；没有“已经知道方向但完全不知道怎么做”的硬缺口。我一般会建议在TR1材料里强制加一页“不做什么”，把明确排除的需求写出来，能有效减少后续的需求蔓延。
TR2在概念阶段后期触发，评审对象从“值不值得做”转向“做出来的东西对不对”。评审重点是产品包需求规格，包括功能、性能、可靠性、可服务性、成本限制等。它的输入是客户需求数据、竞争分析和DRM需求分解结果，输出是初始产品包需求PRD、设计需求说明书草稿和技术风险清单。
TR2的放行标准比TR1更严格：需求条目必须可测量、可验证、有优先级；关键非功能需求有明确接受指标；需求跟踪矩阵已经建立，每条需求对应后续验证方法。这里有个常见做法是：把TR2通过的PRD冻结为基线，后边TR3到TR6的测试用例都从矩阵里派生，避免验证时各测各的。
2.2 TR3与TR4：先审“方案行不行”和“模块成没成型”
TR3是系统设计评审，也有人叫总体方案评审。它的目标是确认系统架构、模块划分、接口定义和关键技术路径已经清晰，具备进入详细设计的条件。TR3的输入是系统设计说明书、接口控制文档和系统验证方案，输出是设计基线、验证策略和更新后的风险清单。
TR3最容易出的问题是：设计文档写得像“技术愿景”，架构很美但落不到模块级。所以通过标准里必须有硬性条目：架构设计覆盖TR2全部需求项；模块接口已定义并有接口控制文档；每一个高风险技术点都挂了一个具体验证计划，而不是一句“后续重点研究”。没有验证计划的高风险点，在TR3直接打回。
TR4是详细设计与模块验证评审。有些体系把TR4拆成TR4A和TR4B：TR4A审详细设计完成度，TR4B审模块验证结果。如果你正在落地这套流程，我建议按耦合度决定要不要拆开：硬件和固件强耦合、有大量联调场景时，拆开更安全；并行度不高的小团队，合并成一次TR4也能跑通，但检查单必须同时覆盖设计完成证据和模块测试报告。
TR4的放行条件有一条很关键：模块级测试必须覆盖需求跟踪矩阵里分配到该模块的全部条目。如果关键性能参数仍然依赖估算，而没有模块样件的实测数据，再有经验的评审专家也不该签字。另一个容易被忽略的点是接口联调结果，在TR4阶段至少要做一次模块间接口的集成联测，否则问题会全部堆积到TR5。
2.3 TR5与TR6：先审“样机达不达标”和“能不能量产交付”
TR5是系统集成与样机评审，评审对象是一台看起来像最终产品的样机。它的输入包括样机本身、系统集成测试报告、可靠性测试数据和初版可制造性评估。TR5的焦点不是“样机动起来了”，而是“样机在真实场景下能不能稳定达到目标指标”。
通过TR5通常需要满足四类证据：功能测试覆盖全部需求条目；性能测试数据达到TR2定义的指标；可靠性测试完成预定测试周期；边界条件、异常输入、断网断点恢复等负向用例也有结果。这里有个很常见的反面案例：演示Demo准备得漂亮，评审会上气氛很好，但边界测试报告只有两页，最后TR5通过，量产后天天出兼容性问题。演示只能作为辅助证据，不能替代系统级测试结论。
TR6是量产评审，通常在试产完成之后启动。它的输入是试产总结报告、直通率与不良分析、关键供应商认证记录、售后服务准备方案。TR6放行条件的硬标准包括：试产直通率达到预定目标；关键缺陷归零或已有明确纠正措施；关键物料供应风险受控；备件、维修指南和服务团队就绪。TR6一旦通过，意味着产品正式进入量产爬坡阶段，这个时候再变更设计，成本会明显上一个台阶。
2.4 一张表看全六道闸门的差异
| 评审点 | 评审焦点 | 关键输入 | 关键输出 | 硬性放行条件示例 |
|---|---|---|---|---|
| TR1 | 概念与机会 | 市场研究、产品概念 | 初始业务计划 | 问题定义清晰、市场规模有数据 |
| TR2 | 产品需求 | 客户需求、竞争分析 | PRD、需求跟踪矩阵 | 需求可测量、有优先级、范围受控 |
| TR3 | 系统方案 | 系统设计文档、接口控制 | 设计基线、验证策略 | 架构覆盖需求、高风险点有验证计划 |
| TR4 | 详细设计模块验证 | 详细设计、模块测试报告 | 模块设计基线、联调结果 | 模块验证覆盖需求矩阵、接口联调通过 |
| TR5 | 系统集成样机 | 样机、系统测试报告 | 系统级测试结论 | 性能达标、边界测试完整、风险受控 |
| TR6 | 量产供货 | 试产报告、供应链准备 | 量产放行结论 | 直通率达标、售后就绪、质量问题闭环 |
3. 把TR评审跑起来：评审组怎么配、检查单怎么建、结论怎么下
3.1 评审组角色与选择：不是“谁有空谁上”
落地TR评审，第一件事不是写文档，而是把角色的权责定清楚。一个有效的评审组通常包含四类角色：决策人、评审专家、汇报人、记录人。决策人负责签字放行，评审专家负责逐条核对证据，汇报人负责展示数据和风险，记录人负责把问题、责任和截止日期写进闭环系统。
选择评审专家有两条边界：第一，专家里至少有两到三人不直接从事被评审模块的开发工作，来自周边模块或质量、制造、服务等下游角色，防止“自己审自己”；第二，决策人不负责技术细节纠错，他在评审会上的职责是裁决分歧，而不是陪大家逐行审代码、审图纸。我见过不少评审会低效的例子，就是因为老板全程在抠技术点，反而没人对“是否放行”拍板。
| 角色 | 典型职责 | 不承担的事 |
|---|---|---|
| 决策人 | 下达放行结论、裁决争议 | 不逐行核对设计细节 |
| 评审专家 | 逐项核对检查单、提出疑点 | 不代替项目经理做计划 |
| 汇报人 | 展示证据、说明风险与处理方案 | 不替评审组得出结论 |
| 记录人 | 记录问题、责任人、到期日 | 不参与技术决策 |
3.2 TR检查单：把六道闸门拆成可勾选的条目
没有检查单的TR评审，最后都会沦为“汇报会”。一套可复用的TR检查单至少包含四类条目：设计类、验证类、风险类、边界类。下面是一份可以拿来改的模板：
设计类
- 系统设计文档是否已更新到当前基线版本？
- 模块接口是否全部受控，有没有未经评审的临时接口？
- 设计变更是否走了变更流程？
验证类
- 测试用例是否覆盖需求跟踪矩阵中的全部功能与性能条目？
- 关键性能数据是否来自受控环境，有没有可复现的测试记录？
- 负向用例（异常输入、边界条件、断网断电）是否执行并有结果？
风险类
- 遗留缺陷是否有明确归属人？
- 风险清单是否按发生概率和影响等级更新？
- 是否存在“当前无法验证、但后续会暴露”的待定项？
边界类
- 本轮评审比上一TR多做了哪些验证？差异在哪里？
- 是否有需求范围变更？影响面有多大？
- 是否明确列出“本次不实现/不验证”的内容？
这里有一条铁律：检查单的自评结果必须在正式评审前一天提交。提交材料里只要还有空项，评审会就应该延期，而不是“先开着再说”。推迟一天的代价通常远小于带病开会后返工的代价。
3.3 标准评审流程：预审、正式评审、决策闭环
评审流程可以固定成三步。第一步是预审，会前一到三天把资料包发给评审组，资料包必须包含自评检查单、测试数据和风险清单。每人必须回写至少一条预审意见，没有意见的评审专家默认没有认真看材料。这一步能筛掉很多“开会前才翻PPT”的情况。
第二步是正式评审。时间建议控制在九十分钟到一百二十分钟，前十五分钟由汇报人讲背景和关键结论，之后所有时间用来回应预审意见和检查单里的疑点。禁止汇报人通读文档，也禁止评审专家现场临时翻资料。
第三步是决策闭环。会议结束前必须给出结论：通过、有条件通过、不通过、重新评审。有条件通过和重新评审都必须当场指定责任人和复评时间。很多团队在决策环节含糊，最常见的就是“那先这样吧，大家再跟一下”，这句话一出来，评审就失去了闭环能力。
4. 评审输出物与闭环机制：报告怎么写、问题怎么升级、基线怎么联动
4.1 评审报告的字段设计
评审报告不是会议纪要，它是一份带法律效应的技术决策文件。建议最少包含九个字段：评审编号、评审对象版本、评审时间、评审组成员、评审结论、放行条件清单、遗留问题清单、责任人及截止日期、复评安排。
| 字段 | 填写要求 | 常见误写 |
|---|---|---|
| 评审对象版本 | 必须精确到基线版本号 | 只写“样机V2”不标基线 |
| 评审结论 | 四选一：通过/有条件通过/不通过/重审 | 写“基本通过”这种模糊词 |
| 放行条件清单 | 写明必须满足才能放行的条件 | 漏写，后续无法核对 |
| 遗留问题清单 | 每条写明等级、影响范围、处理方向 | 只写标题没有处理方向 |
| 责任人与截止期 | 对应到具体人和日期 | 只写团队名，无人认领 |
一线经验是：评审报告的签发权限应在决策人手里，记录人负责起草，但不能代签字。报告归档后，项目组要把遗留问题逐条导入问题跟踪系统，每条问题独立编号，后续复评时按编号核对，而不是靠记忆检查。
4.2 遗留问题分级与升级规则
遗留问题含糊不清，是TR评审跟踪失效的根源。推荐把问题分成三级，每一级对应不同的闭环要求：
| 等级 | 定义 | 评审结论影响 | 闭环时限 |
|---|---|---|---|
| A类 | 放行条件不满足，无法接受风险 | 评审不通过 | 立即整改并重评 |
| B类 | 不影响本次放行，但影响后续TR | 可有条件通过 | 7到15个自然日内闭环 |
| C类 | 记录在案，暂不影响结果 | 可正常通过 | 到期跟踪、下次评审复核 |
升级规则必须有自动触发机制：B类问题超过两周未闭环，自动升级为A类并上报项目决策层；同一C类问题在连续两次评审中出现，自动升级为B类。我见过最典型的失控场景，是一个B类问题被“有条件通过”之后，整整两个月没人跟，等到TR6评审时变成量产阻塞项。升级规则不是写给人看的，它是保证问题不腐烂的机制。
4.3 TR与技术基线联动：基线一改，评审就要重开
TR评审通过之后，对应文档就进入基线管理。TR3过后冻结的是系统设计基线，TR4过后冻结的是模块设计基线，TR5过后冻结的是产品验证基线。任何后续变更，只要涉及接口、关键性能指标或系统架构，都必须走技术变更流程，而不是在项目群里发个通知就改。
基线变更的影响评估结果如果落在当前TR的放行条件上，评审必须重开。举个例子：TR4通过后，一个模块换了接口协议，这时候即使设计评审已经通过，也要重新拉出TR4评审组做局部重评，评估影响范围后再决定是否影响TR5计划。为了赶进度略过这一步，大概率会在集成阶段把所有返工成本一次性连本带利还回去。
4.4 用评审数据反哺下一批项目
评审会开完不是终点，数据汇总才是后面越做越轻松的底气。每个TR结束后，把通过率、问题分布、平均闭环周期、以及“上一TR遗留问题暴露在下一TR”的比例统计下来，形成一张评审健康度看板。连续几个项目下来，你会看到自己的评审体系哪里是虚的，哪里是堵住大风险的关键闸口。这比任何专家经验都更有说服力。
5. 避坑指南：TR1-TR6评审中最常见的六个翻车场景，现象、原因、解决办法
5.1 TR1被当成立项材料会，概念没审就冲方案
现象：TR1评审现场，汇报人拿着一堆立项PPT念，“背景、意义、团队情况”占了半小时，产品的目标用户和问题定义反而没讲清楚。 原因：团队把TR1当成“走形式立项”，真正的立项决策早就在私下拍完板，评审会变成补盖章。 解决：TR1材料模式上删掉背景和团队介绍，只留四屏：用户痛点是什么、市场规模数据、技术可行性判断、不做什么。这四屏里任意一屏说不清楚，就让评审会延期，直到数据补齐。把所有评审点定义为不可协商的关口，而不是“走过场”。
5.2 TR2的需求边界没拉齐，后边所有TR都在为需求蔓延买单
现象：TR3的评审会上，设计师不断提出“如果需求再改怎么办”，测试人员问“这个指标到底按哪版算”，会场吵成一团。 原因：TR2放行时没有锁定范围，“不做清单”也没列，后续客户每提一句话都进需求池，设计侧跟着改。 解决：TR2通过时同步发布两条基线：要做的需求清单和明确不做的排除清单。后续任何新增需求都必须走变更流程，先评估对TR3和TR4的影响，再决定是否改设计。没有这一步，后续TR5出现问题时你连责任边界都画不清。
5.3 TR5评审变成功能演示Show，可靠性和边界条件没人看
现象：样机演示很成功，评审专家看得很兴奋，会上顺利通过。结果小批量试产一跑，低概率死机、信号干扰、弱网重连等边界问题集中爆发。 原因：评审聚焦在“正常路径跑通”，负向用例、异常输入、边界测试在检查单里没有位置，演示效果掩盖了数据缺口。 解决：TR5材料里强制要求“负向用例测试报告”独立成册，覆盖断网、断点、低电量、弱信号、非法输入等场景。演示环节压缩到十五分钟以内，其余时间全部用来核对测试数据和缺陷单。好评不是放行依据，测试结论才是。
5.4 “有条件通过”开成了“通过”，条件没人跟踪
现象：评审结论写的是“有条件通过，遗留三个B类问题”，但会后没有任何跟踪动作，三个月后问题还在，项目已到TR6。 原因：有条件通过的决策没有落到书面和问题系统，口头共识在会后被默认理解为“通过了就完事”。 解决：评审结论只能在四个选项里选，有条件通过必须当场写明条件清单、责任人和复评日期，并且由记录人当天录入问题跟踪系统。决策人签字前核对复评日期已排进项目计划，缺一项就不签字。
5.5 评审专家全是项目里的人，自己审自己
现象：评审组里好几位都是被评审模块的直接开发人员，大家平时还在同一个办公区，评审会上基本没人提尖锐意见。 原因：评审专家选择只考虑了“对模块熟”，忽略了独立性和跨部门视角。IPD强调跨部门评审，恰恰是要引入不受项目组利益影响的视角。 解决：组建评审专家库，要求每个TR的评审组里至少有一位来自周边模块、一位来自质量或制造等下游环节。必要时邀请上一TR的评审专家来检查当前TR的承接情况，用“对上一TR负责”的心态拉开视角。
5.6 TR6直通率标准到评审当天才拍板，制造方拒签
现象：TR6评审会开到一半，生产负责人说直通率数据不够，样品数量太少，拒签放行结论，整个评审卡住。 原因：TR6的数据要求没有提前定死，团队以为“试产顺利就能过”，结果到评审时才对齐口径。 解决：TR5通过时就书面写清TR6的数据门槛：验证批次规模、直通率目标、关键缺陷允许件数、供应商认证范围。试产前一天对照这个门槛做“数据预检”，差任何一项就延后TR6，不留到评审会现场再谈判。
6. 把TR评审排进项目节奏：时间触发、决策权、豁免与红线
6.1 评审时间是事件触发，不是日历提醒
TR评审的触发条件是“验证证据完成”，不是“日历翻到了这一天”。但在项目主计划里，还是要提前排好六个TR的建议时间窗口，否则会被其他活动挤没。排期时我一般会预留三段缓冲：TR2到TR3至少隔两周，给系统设计消化需求的时间；TR4到TR5至少隔四周，覆盖模块联调和系统集成；TR6放在试产完成后两周内，等试产数据冷却、缺陷归集之后再评。
6.2 放行权要写进评审通知
每个TR评审通知里必须点名一个决策人，他的角色是最终放行人。这个人在会前就清楚自己拥有一票否决权，在会后要签字确认评审结论。建议把决策人一个人单独放在DACI表里，他是唯一写D的人，其他人都归为C或I。这样能避免评审会开完，还要再去“找领导确认一下”的二轮等待。
6.3 豁免机制可以设，但必须留痕
业务确实紧急时，可以给TR降级或并行，但不能整体删除。我常用的做法是：把TR拆成“必须项”和“记录项”，紧急情况下必须项不能豁免，记录项可以降级为备案。豁免申请必须由决策人单独签署一份书面说明，说明里写清被豁免的评审点、风险接受理由和后续补偿验证计划，这份说明进项目档案，不进评审纪要。一旦后续出问题，它就是复盘时唯一的凭据。
有一年某项目为了赶发布窗口，我在主计划里砍掉了TR5的系统级负向测试，直接进入试产。结果硬件和软件在稳定运行两小时后的同步问题，一直到产线爬坡才暴露出来，返工整改的工时够做两个版本。从那以后，我每次排NPI计划，都会提前和决策人对齐六个TR的触发条件和数据要求，缺一项数据就延后评审，宁愿被说“太较真”，也不带病开评。这个习惯帮我省下的返工成本，远大于延期一天的代价。希望帮到你。
本文还有配套的精品资源，点击获取
