TR评审出现技术争议或遗留项时，处理方式取决于它是否影响阶段继续或终止的决策：影响决策的当场升级，由评审组长或决策层给出临时结论；不影响决策的登记为遗留项，按统一字段记录并跟踪到关闭。本文给出分流规则、记录字段、跟踪步骤、角色分工和一份完整示例，适用于采用阶段评审机制的硬件与软硬件结合研发团队，具体评审标准和升级时限可按企业流程文件确定。
要点总览（TL;DR）
- TR评审遗留项按“是否影响阶段继续或终止决策”分流：影响决策的当场升级并记录临时结论，不影响决策的登记为跟踪项。
- 每个遗留项统一记录问题描述、影响范围、责任人与期限、关闭判据、升级路径五项字段，评审结论分为有条件通过、暂缓决策、不通过三类。
- 会后由评审秘书维护清单并按周核对状态，责任人提交可验证的关闭证据，经原评审组确认后关闭，逾期未关闭按升级路径上报。
- 闭环完成以记录完整、证据对应判据、确认人留痕、逾期已升级、风险接受有书面记录、记录可追溯为验收标准。
先分清哪些遗留项必须当场升级
TR评审会上的争议并不都需要当场解决，但也不能全部推到会后。分流的判断标准只有一条：该问题是否影响本次评审对“阶段继续、暂缓还是终止”的决策。影响决策的问题留在会上处理，不影响决策的问题登记后进入跟踪。
技术争议未达成一致时，评审组长应在会议结束前将问题升级到有决策权的层级，例如产品线技术负责人或阶段决策会议。升级时需说明争议焦点、各方观点、可选方案及各自风险，由升级对象给出临时结论。临时结论要落到书面记录中，写明结论内容、生效条件和复核时间，避免口头同意后续无人认账。
不影响阶段决策的遗留项，例如文档格式待补充、非关键接口参数待确认、测试用例覆盖待完善，登记为跟踪项即可，不必占用会议决策时间。判断边界模糊时，按“影响决策”处理，宁可多升级一次，也不把可能改变结论的问题留到会后。
升级时限建议在会议规则中明确：影响决策的争议在本次会议结束前完成升级并记录临时结论；升级对象无法当场决策的，约定不超过约定工作日的答复时限，并在遗留项清单中标注“待决策”状态。
| 判断维度 | 升级类 | 跟踪类 |
|---|---|---|
| 对阶段决策的影响 | 直接改变继续、暂缓或终止的结论 | 不改变本次评审结论 |
| 典型情形 | 关键技术方案存在路线分歧、接口一致性无法确认、重大风险无应对措施 | 文档待补充、非关键参数待确认、测试覆盖待完善 |
| 处理时点 | 会议结束前 | 会后按计划跟踪 |
| 处理人 | 评审组长升级至决策层 | 指定责任人 |
| 记录要求 | 临时结论、生效条件、复核时间 | 五项字段完整登记 |
遗留问题记录的五个必备字段
遗留项能否被有效跟踪，取决于记录是否完整。建议每个遗留项统一填写五项字段，缺一项就视为记录不合格，由评审秘书在会后检查时退回补充。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 问题描述 | 用一句话说明问题事实，避免只写“待确认” | 主控板与电源板接口电平定义不一致，3.3V与5V混用 |
| 影响范围 | 说明影响哪些子系统、阶段或交付物 | 影响TR4样机联调，涉及主控、电源两个子系统 |
| 责任人与期限 | 指定一名责任人，期限写到具体日期 | 责任人：硬件接口负责人；期限：某月某日前 |
| 关闭判据 | 写明可验证的完成标准，而非“处理完成” | 接口电平定义文档更新并经双方签字确认，联调测试通过 |
| 升级路径 | 写明逾期或受阻时的上报对象 | 逾期未关闭升级至评审组长，再逾期升级至项目决策层 |
评审结论按三类记录：有条件通过，需写明通过所附条件及条件完成时间；暂缓决策，需写明暂缓原因和再次评审的时间；不通过，需写明不通过的主要依据和整改要求。条件与风险接受必须书面记录，由提出条件的评审方和接受风险的决策方分别确认，仅口头同意不构成闭环依据。
填写时注意两点：关闭判据要可验证，能对应到具体文档、测试记录或签字确认；升级路径要写到具体角色，避免只写“上报领导”。这两项决定了遗留项在会后能否被独立跟踪，而不依赖记录人的记忆。
从评审会到关闭的跟踪闭环步骤
会后跟踪的核心是让每个遗留项有明确的状态和下一步动作。建议按以下步骤执行，每一步都有输入、动作和输出。
- 会后整理清单。评审秘书在会后一个工作日内，将会议记录中的遗留项录入统一清单，补齐五项字段，标注初始状态为“待处理”。输入是会议记录，输出是完整的遗留项清单。
- 按周核对状态。评审秘书每周核对一次清单，确认责任人是否更新进展、期限是否临近。输入是责任人反馈，输出是更新后的状态和风险提示。
- 责任人提交关闭证据。证据应能直接对应关闭判据，例如更新后的文档版本、测试报告、签字确认记录。仅写“已完成”不视为有效证据。
- 原评审组确认关闭。由原评审组指定确认人核对证据，确认满足关闭判据后将状态改为“已关闭”。确认方式可采用会签或评审组内书面确认，需留下确认人和确认时间。
- 逾期自动升级。超过期限未关闭的遗留项，按记录中的升级路径上报；升级后仍无进展的，提交决策层处理，由决策层决定延期、调整方案或书面接受风险。
状态流转建议统一为“待处理—处理中—待确认—已关闭”，另设“已升级”和“风险已接受”两个终态。风险已接受表示决策层书面同意带着该问题进入下一阶段，需记录接受人、接受时间和接受理由，不能与正常关闭混为一谈。
当遗留项数量较多、跨多个评审组时，清单的维护和状态流转需要有统一的承载方式。ONES 支持以工作项记录遗留项、以文档承载评审结论，并通过状态字段和流转记录保留每次变更的责任人与时间，便于评审秘书按周核对和原评审组确认关闭；具体字段配置可按企业流程调整。
角色分工与各环节交付物
闭环能否运转，取决于每个角色清楚自己交付什么。下表按环节列出职责与产出，避免记录、跟踪、确认三个动作集中在同一人身上。
| 角色 | 职责边界 | 输入 | 输出 |
|---|---|---|---|
| 评审组长 | 主持分流，决定哪些问题当场升级，给出或推动给出临时结论 | 会上争议与评审材料 | 分流决定、临时结论记录 |
| 评审秘书 | 维护遗留项清单，按周核对状态，组织关闭确认，触发逾期升级 | 会议记录、责任人反馈 | 遗留项清单、状态周报、升级提醒 |
| 责任人 | 按关闭判据推进处理，提交可验证的关闭证据 | 遗留项记录 | 处理结果与关闭证据 |
| 原评审组确认人 | 核对证据是否满足关闭判据，确认关闭 | 关闭证据 | 关闭确认记录 |
| 决策层 | 处理升级事项，决定延期、调整或书面接受风险 | 升级说明与风险评估 | 决策结论、风险接受书面记录 |
决策层书面接受剩余风险，通常出现在两种场景：遗留项不影响阶段核心目标，但短期内无法关闭；或关闭成本明显高于风险本身。此时应由决策层写明接受的风险内容、影响范围和后续监控方式，并明确该接受不替代后续阶段的整改要求。
一个TR评审遗留项闭环示例
以下为演示情景，用于说明各环节如何衔接，不代表真实项目数据。
背景与争议点。某硬件项目在TR4评审中，评审组发现主控板与电源板的接口电平定义不一致，联调测试中出现通信异常。硬件团队认为可按现有设计继续，测试团队认为需先统一接口定义，双方未达成一致。
当场升级与临时结论。评审组长判断该问题影响样机能否进入联调阶段，属于影响决策的争议，当场升级至产品线技术负责人。技术负责人给出临时结论：本次评审为“有条件通过”，条件是在约定日期前完成接口电平定义统一并补充联调测试；责任人指定为硬件接口负责人，关闭判据为接口文档更新并经双方签字、联调测试通过，逾期升级至项目决策层。结论与条件当场记入会议记录。
会后跟踪与证据提交。评审秘书在会后一个工作日内将该项录入遗留项清单，状态为“待处理”。责任人更新接口定义文档并组织联调，在期限前提交更新后的文档版本和测试报告作为关闭证据，状态改为“待确认”。
关闭确认与归档。原评审组确认人核对文档签字和测试结果，确认满足关闭判据，将状态改为“已关闭”，记录确认人和确认时间。评审秘书将遗留项清单、会议记录和关闭证据一并归档，作为后续阶段评审的输入。
闭环完成检查清单
判断遗留项是否真正闭环，可逐项核对以下内容。任一项不满足，说明闭环尚未完成。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 记录完整性 | 五项字段是否齐全 | 问题描述、影响范围、责任人与期限、关闭判据、升级路径均有内容 |
| 记录完整性 | 评审结论是否分类记录 | 结论属于有条件通过、暂缓决策或不通过之一，条件写明 |
| 关闭证据与确认 | 证据是否对应关闭判据 | 证据可逐条对应判据，非仅文字说明 |
| 关闭证据与确认 | 是否经原评审组确认 | 有确认人和确认时间记录 |
| 升级与风险接受 | 逾期项是否已升级 | 按升级路径上报并有处理结论 |
| 升级与风险接受 | 风险接受是否有书面记录 | 写明接受人、时间、风险内容与监控方式 |
| 归档与可追溯 | 清单与证据是否归档 | 可按评审批次检索到完整记录 |
| 归档与可追溯 | 状态是否与实际情况一致 | 清单状态为已关闭或风险已接受，无长期滞留的待处理项 |
检查频率可与周核对合并：评审秘书每周核对状态时同步检查记录完整性，阶段评审前做一次全量检查。对长期滞留的遗留项，应重新评估其是否仍影响后续阶段决策，必要时提交决策层重新定性。
常见问题
遗留项在会后跟踪中一直无法关闭，应该怎么处理？
先核对关闭判据是否本身不可验证或范围过大，必要时由原评审组重新明确判据。若判据清晰但受阻，按记录中的升级路径上报评审组长，再逾期则提交决策层。决策层可决定延期、调整方案，或书面接受该风险进入下一阶段；书面接受需写明接受人、时间、风险内容和后续监控方式，并与正常关闭区分记录。
评审结论为“有条件通过”时，条件未按期完成，评审结论是否自动失效？
是否失效取决于企业流程文件的规定，建议在记录条件时同步写明未完成的处理方式。常见做法是条件到期未完成即触发升级，由原评审组或决策层重新判定阶段状态，可能转为暂缓决策。无论采用哪种口径，条件完成时间与复核人都应写入遗留项清单，避免条件长期悬空。
遗留项的责任人与关闭确认人能否是同一人？
建议分开。责任人负责推进处理并提交证据，关闭确认由原评审组指定确认人完成，两者分离可以保证关闭判据被独立核对。团队规模较小时，可由评审组长兼任确认人，但确认动作仍需留下确认人和确认时间记录，便于后续阶段评审追溯。
跨多个评审组的遗留项，清单由谁统一维护？
通常由阶段评审的评审秘书统一维护，各评审组按同一套字段提交遗留项。若企业设有多个并行项目，可在项目层指定一名清单负责人，汇总各组遗留项并按周核对状态。关键是字段口径和状态定义保持一致，使跨组交接时不需要重新解释记录内容。
遗留项数量多时，如何避免清单变成只登记不跟踪的台账？
把周核对与阶段评审前的全量检查固定下来，每次核对都要求责任人更新进展或提交证据，长期无变化的项标记风险并触发升级。对已不影响后续阶段决策的遗留项，由决策层重新定性或书面接受风险，避免待处理项无限累积。清单的价值在于推动状态变化，登记本身不构成闭环。
