TR技术评审是研发阶段末端的继续或终止决策机制：由技术负责人牵头，对照本阶段交付物、技术成熟度、风险与遗留问题，给出通过、有条件通过或不通过的结论，并明确后续动作、责任人和关闭时间。本文按准备、判定、闭环三个环节展开，给出可直接套用的入口条件、判定口径、角色分工与完成检查清单。
要点总览（TL;DR）
- TR技术评审是阶段末端的继续或终止决策：先核对入口条件，再按技术方案完整性、验证充分性、风险可控性、遗留问题可接受性四个维度逐项判定，结论落到通过、有条件通过、不通过三档。
- 评审前由项目管理人员汇总材料、技术负责人确认可评审状态，评审组提前预读并提交书面意见；材料缺失或关键数据存疑时先补充，再排期开会。
- 有条件通过的附加条件要写成含内容、责任人、截止时间、验证方式的行动项；到期由验证人确认关闭，下一阶段启动前复核未关闭项的影响。
- 角色分工遵循判定与验证分离：领域专家给维度判定，质量与测试代表独立核查证据，项目管理人员统一跟踪行动项。
- 完成标志是评审记录可追溯、行动项可跟踪、下一阶段启动有明确依据，三者同时成立才算闭环。
TR技术评审要回答什么：入口条件与决策口径
TR要回答的问题只有一个：本阶段的工作是否足以支撑进入下一阶段。评审组依据本阶段交付物和技术成熟度，判断继续投入还是终止或返工。这个判断发生在阶段末端，结论直接影响下一阶段的资源投入，因此需要明确的入口条件和统一的结论口径，避免评审沦为进度汇报。
TR与相邻的评审活动有清晰分工。发布审批关注产品能否对外交付、市场与合规条件是否满足；需求评审关注单个需求是否被正确理解和确认；TR关注的是阶段技术状态是否达到继续推进的条件。三者可以共享部分材料，但决策对象和结论用途不同，不能用一次会议同时承担多种决策。
入口条件清单
评审启动前逐项核对以下条件，全部满足才排期；存在缺项的，先补齐再开会，否则评审只能得出“材料不足、无法判定”的结论，浪费评审组时间。
| 入口条件 | 核对内容 | 满足标志 |
|---|---|---|
| 交付物齐套 | 本阶段规定的设计文档、验证报告、变更记录是否齐全且为最新版本 | 材料清单逐项打勾，版本号与基线一致 |
| 关键指标达标 | 本阶段设定的技术指标、验证通过率等是否有数据支撑 | 指标数据可追溯到测试记录或分析报告 |
| 遗留问题已登记 | 未解决问题是否全部进入问题清单，含影响范围与临时措施 | 问题清单完整，无口头遗留事项 |
| 评审组已确认 | 各维度判定人是否确定并完成预读 | 预读意见已回收，无重大异议 |
三档结论判定口径
结论必须落到三档之一，每档对应明确的后续动作，避免出现“基本通过”“原则同意”这类无法执行的表述。
| 结论 | 适用情形 | 后续动作 |
|---|---|---|
| 通过 | 交付物齐套、关键指标达标、遗留问题风险可接受 | 进入下一阶段，遗留问题按计划跟踪 |
| 有条件通过 | 主体满足要求，但存在必须在限定时间内关闭的条件项 | 条件项写入行动项，明确责任人与截止时间，到期验证 |
| 不通过 | 关键交付物缺失、指标未达标或存在不可接受的风险 | 返回本阶段整改，重新确定评审时间 |
评审范围限于本阶段技术状态的继续或终止判断。发布许可、单需求确认、供应商商务条款等事项不在TR内决策，需要时另行组织对应评审，避免议题混杂导致结论失焦。
评审前准备：材料清单、评审组与议程
准备工作的质量决定评审会能否在一到两小时内得出结论。准备工作由项目管理人员统筹汇总，技术负责人确认材料是否达到可评审状态，各材料责任人按清单提交。
材料清单
- 设计文档：架构说明、接口定义、关键设计决策记录，标注版本与基线对应关系。
- 验证材料：测试计划、测试报告、缺陷统计与趋势，说明覆盖范围和未覆盖项。
- 风险与问题清单：当前风险等级、应对措施、遗留问题及临时方案。
- 变更记录：本阶段的需求变更、设计变更及其影响分析。
- 上阶段行动项关闭情况：逐项说明关闭证据，未关闭的说明原因。
评审组构成与分工
| 角色 | 入选依据 | 会前准备 |
|---|---|---|
| 技术负责人 | 对本阶段技术状态负总责 | 确认材料可评审，主持评审并签发结论 |
| 领域专家 | 覆盖本阶段涉及的专业方向 | 预读材料，形成维度判定意见 |
| 质量与测试代表 | 掌握验证证据 | 核查测试覆盖与缺陷数据真实性 |
| 上下游接口人 | 受本阶段输出影响 | 确认接口一致性与交接条件 |
| 项目管理人员 | 掌握计划与问题台账 | 汇总材料、记录结论、建立行动项 |
议程与预读机制
议程按“材料确认—逐维度判定—结论形成—行动项确认”四段安排，控制在90分钟左右。材料在评审前至少两个工作日发出，评审组成员完成预读并提交书面意见；预读中发现材料缺失或关键数据存疑的，由项目管理人员汇总后反馈材料责任人补充，补充完成前不进入正式评审。预读意见构成会上判定的起点，会议时间主要用于处理分歧，而非逐页宣讲。
评审中怎么判：逐维度判定与证据记录
评审会按固定维度逐项判定，每个维度先看证据、再给结论，判定结果当场记录。主持人控制节奏：汇报只讲结论和证据位置，评审组直接质询，避免把评审开成汇报会。
四个判定维度
| 维度 | 判定问题 | 证据形式 |
|---|---|---|
| 技术方案完整性 | 本阶段要求的设计内容是否全部完成，接口是否一致 | 设计文档、接口对照表、设计评审记录 |
| 验证充分性 | 关键指标是否经过测试验证，覆盖范围是否足够 | 测试报告、缺陷统计、未覆盖项说明 |
| 风险可控性 | 剩余风险是否有应对措施和触发条件 | 风险清单、应对方案、责任人确认 |
| 遗留问题可接受性 | 未关闭问题是否影响下一阶段启动 | 问题清单、影响分析、临时措施 |
每个维度的判定结论记为“满足”“有条件满足”“不满足”，并附证据出处。证据无法当场提供的，该维度不判定为满足，记入待补事项。
有条件通过的写法
附加条件要写成可验证的行动项，包含四要素：条件内容、责任人、截止时间、验证方式。例如“接口文档补充异常场景定义，由架构负责人于某日期前提交，由测试代表核对后关闭”。条件项数量不宜过多，只保留影响下一阶段启动的关键项，其余转入常规问题跟踪。
分歧处理与升级路径
评审组对某维度结论存在分歧时，先由技术负责人组织现场澄清证据；澄清后仍无法达成一致的，按预设规则处理：涉及技术路线选择的，提交上一级技术决策会议裁定；涉及资源或进度取舍的，提交阶段决策会议裁定。分歧和裁定结果一并记入评审记录，不停留在口头共识。
评审后闭环：结论落地、行动项跟踪与下阶段入口复核
评审结论在会后一个工作日内形成正式记录，由技术负责人签发，知会评审组、项目组及下一阶段相关接口人。记录包含各维度判定、结论、行动项清单和下次复核时间，作为阶段推进的依据。
行动项字段
| 字段 | 填写要求 |
|---|---|
| 行动内容 | 描述可交付的成果，而非“继续跟进”类表述 |
| 责任人 | 单一责任人，对关闭结果负责 |
| 截止时间 | 具体日期，与下一阶段启动时间挂钩 |
| 验证方式 | 说明由谁、依据什么材料确认关闭 |
| 关联结论 | 标注属于通过后的跟踪项还是有条件通过的条件项 |
关闭验证与入口复核
有条件通过的条件项到期后，由验证人依据约定材料确认关闭，关闭证据附在行动项下。下一阶段启动前，项目管理人员对照行动项清单复核：条件项全部关闭的，正常启动；存在未关闭条件项的，由技术负责人判断是否影响启动，影响启动的暂缓进入下一阶段，不影响的可带项进入但需设定新的关闭节点。复核结果记录在阶段入口检查中，形成可追溯的闭环。
在研发管理工具中承载这套流程时，评审材料、判定记录和行动项可以放在同一项目空间内：ONES可围绕项目计划、阶段推进、任务协同和研发过程管理支持团队建立清晰的阶段管理方式，评审结论转为工作项后按责任人、截止时间跟踪，阶段入口复核时直接查看未关闭项。具体配置结合企业自身的流程定义进行规划。
角色与交付物分工：谁牵头、谁判定、谁跟踪
TR涉及多个角色，职责边界不清会出现“都参加、都不负责”的情况。下表按角色列出核心职责与对应交付物，评审启动前据此确认分工。
| 角色 | 核心职责 | 交付物 |
|---|---|---|
| 技术负责人 | 牵头组织评审，裁定技术分歧，签发结论 | 评审结论记录、技术裁定意见 |
| 领域专家 | 对所负责维度给出判定意见和依据 | 维度判定意见、预读意见 |
| 质量与测试代表 | 核查验证证据的完整性与真实性 | 验证证据核查结论、未覆盖项说明 |
| 项目管理人员 | 汇总材料、组织议程、记录结论、跟踪行动项 | 材料清单、会议记录、行动项跟踪表 |
| 上下游接口人 | 确认接口一致性与交接条件 | 接口确认意见 |
职责划分遵循一条原则：判定与验证分离。给出维度判定的人不负责验证自己维度的证据，验证人独立核查后反馈，减少自证自判带来的偏差。行动项跟踪由项目管理人员统一维护，责任人只对关闭结果负责。
示例：一次TR评审从准备到关闭的完整过程
以下为演示情景，用于说明各环节的输入、动作与输出，不代表真实客户案例。
背景与阶段目标。某硬件产品完成设计阶段，目标是确认设计基线可转入样机试制。阶段交付物包括系统设计说明、关键模块测试报告、风险清单和变更记录。
准备阶段。项目管理人员按材料清单汇总，提前三个工作日发出。预读中，测试代表指出一项关键指标的测试样本量不足，材料退回补充；补充测试数据后重新发出，预读通过，评审按期召开。
评审会上的判定。技术方案完整性判定为满足，接口对照表齐全；验证充分性判定为有条件满足，样本量补充后覆盖范围达标，但极端工况未覆盖，列为条件项；风险可控性判定为满足，剩余风险均有应对措施；遗留问题可接受性判定为有条件满足，两项结构件问题需在试制前关闭。综合结论为有条件通过，共形成三项条件项，均明确责任人与截止时间。
跟踪与关闭。三项条件项在行动项表中跟踪，到期后由验证人依据补充测试报告和问题关闭记录逐项确认。下一阶段启动前复核，三项全部关闭，阶段正常推进。
可迁移的规律。这个示例的关键在于：预读阶段拦下了材料缺陷，会上判定基于证据而非汇报，条件项写成可验证的行动。该做法适用于有明确阶段划分和交付物定义的研发项目；阶段划分较粗或交付物定义不清晰的团队，需要先补齐阶段定义，再套用本流程。
完成检查：TR评审是否做到位的核对项
评审结束后按下表逐项核对，全部满足方可认为本次TR达到要求。任一阻断项未满足的，评审结论不生效。
| 检查类别 | 核对项 | 是否阻断 |
|---|---|---|
| 入口与材料 | 入口条件逐项核对并有记录；材料清单齐套且版本与基线一致；预读意见已回收处理 | 材料缺失为阻断项 |
| 判定与证据 | 四个维度均有判定结论；每个结论附证据出处；分歧已记录并有裁定结果 | 维度缺判为阻断项 |
| 结论与行动项 | 结论属于三档之一；条件项含内容、责任人、截止时间、验证方式；结论已签发并知会 | 结论口径不清为阻断项 |
| 关闭与复核 | 条件项到期完成验证；未关闭项已评估对下一阶段的影响；入口复核结果有记录 | 条件项未验证即启动下阶段为阻断项 |
完成标志是：评审记录可追溯、行动项可跟踪、下一阶段启动有明确依据。三项同时成立，本次TR才算真正完成闭环。
常见问题
TR评审和发布审批、需求评审的边界怎么划？
三者决策对象不同：TR判断本阶段技术状态是否足以进入下一阶段；发布审批判断产品能否对外交付、市场与合规条件是否满足；需求评审判断单个需求是否被正确理解和确认。它们可以共享部分材料，但结论用途不同，建议分别组织会议，避免一次会议承担多种决策导致结论失焦。
评审组对某个维度的结论争执不下时怎么办？
先由技术负责人组织现场澄清证据，把判定依据摆到桌面上。澄清后仍无法达成一致的，按预设规则分流：涉及技术路线选择的，提交上一级技术决策会议裁定；涉及资源或进度取舍的，提交阶段决策会议裁定。分歧内容和裁定结果都要写入评审记录，不停留在口头共识。
有条件通过的条件项应该设多少、怎么定截止时间？
条件项只保留影响下一阶段启动的关键项，其余转入常规问题跟踪，避免条件项过多导致跟踪失效。截止时间与下一阶段启动时间挂钩，写成具体日期，并明确验证人和验证依据。到期未关闭的，由技术负责人判断是否影响启动，影响启动的暂缓进入下一阶段。
阶段划分较粗、交付物定义不清的团队能直接套用这套流程吗？
建议先补齐阶段定义和交付物清单，再套用本流程。TR的入口条件和判定维度都依赖“本阶段应交付什么”这一前提；阶段划分过粗时，评审容易退化为整体进度汇报。可以先从一个边界清晰的阶段试点，把材料清单和判定表跑顺，再逐步推广到其他阶段。
评审材料和行动项放在研发管理工具里有什么实际好处？
把评审材料、判定记录和行动项放在同一项目空间，可以减少材料版本对不齐、行动项散落在会议纪要里的情况。以ONES为例，可围绕项目计划、阶段推进、任务协同和研发过程管理建立阶段管理方式，评审结论转为工作项后按责任人和截止时间跟踪，阶段入口复核时直接查看未关闭项。具体配置需结合企业自身的流程定义规划。
