TR技术评审出现技术争议、评审组无法达成一致时，处理重点在于把分歧转成可裁决、可跟踪的决策事项：会上确认争议焦点和双方证据，能当场关闭的当场关闭；不能关闭的写成书面遗留项，按预设路径提交上一级技术决策人或DCP决策会裁决，并把结论回写评审记录、纳入跟踪清单直至关闭。本文给出争议分类、升级步骤、角色职责、记录模板和闭环检查表，适用于IPD体系中TR节点的阶段性继续或终止决策，具体通过标准与权限划分按企业流程确定。
要点总览（TL;DR）
- 先判断争议性质：评审组有决策权且证据充分的可当场关闭；涉及阶段继续或终止、重大风险接受、资源追加或证据有效性分歧的，转为书面遗留项并升级。
- 升级路径一般为评审组→上一级技术决策人→DCP决策会，路径应在评审启动时约定并告知参会人，避免争议发生时临时找人。
- 裁决结论归入继续、有条件继续、暂缓、终止四类，由记录人回写TR评审记录，遗留项登记到跟踪清单并注明责任人、关闭条件和时限。
- 遗留项按周更新、在下一评审节点前集中复核；逾期未关闭的按规则再次升级，涉及阶段继续判断的遗留项逾期时阶段状态回到暂缓。
- 在ONES中可将争议与遗留项登记为工作项并关联TR评审，评审文档承载裁决结论与证据附件，便于在DCP决策会上查看争议处理状态。
争议升级前先判断：哪些分歧需要升级
并非所有分歧都值得占用上级决策资源。评审主持人需要在会中快速判断争议性质，把技术讨论与决策权限问题分开处理。判断的核心是两条：评审组是否具备对该事项的决策权，以及现有证据是否足以支撑结论。两条中任一不满足，就应转入升级流程。
技术争议的常见类型
TR评审中的争议通常集中在四类，不同类型的处理方式不同：
- 技术方案取舍：多个设计方案各有优劣，评审组对选型意见不一致。此类争议往往需要补充对比验证数据或由更高层级技术负责人拍板。
- 指标与验证结论分歧：对测试数据、验证方法或指标是否达标存在不同解读。此类争议优先通过补充证据解决，证据充分后多数可当场关闭。
- 风险接受度分歧：一方认为风险可控可继续，另一方认为风险不可接受。此类争议涉及风险偏好，通常超出评审组的决策权限。
- 资源与进度约束冲突：技术方案要求与项目资源、进度承诺冲突。此类争议需要项目管理层与技术决策人共同裁决。
可当场关闭与必须升级的区分标准
可当场关闭的争议具备三个特征：争议事项在评审组决策权限内、双方证据已在会上充分呈现、结论不改变本阶段的继续或终止判断。典型情况包括文档表述歧义、验证方法细节、不影响阶段结论的次要设计选择。
必须升级的争议则相反：涉及阶段是否继续、是否追加资源、是否接受重大风险，或评审组内部对证据有效性本身存在分歧。此时继续在会上争论只会消耗时间，应尽快转为书面遗留项并启动升级。
升级触发条件
| 触发条件 | 判断依据 | 建议处理 |
|---|---|---|
| 证据不足 | 关键指标缺少验证数据，或双方引用的数据口径不一致 | 转为遗留项，明确补充证据要求和时限，到期后重新评审 |
| 决策权限超出评审组 | 争议涉及阶段继续/终止、重大资源投入、风险接受 | 按升级路径提交上一级技术决策人或DCP决策会 |
| 影响阶段继续或终止 | 争议结论直接改变TR节点的通过判断 | 必须升级，并在裁决前明确阶段状态为暂缓 |
| 多方意见持续对立 | 会上讨论两轮以上仍无收敛趋势 | 主持人终止讨论，记录双方观点后升级 |
需要说明的是，升级不等于否定评审组的工作。把超出权限的争议及时上交，是让评审结论保持可信的必要动作；反之，勉强在会上形成没有权限支撑的结论，会在后续阶段反复。
升级决策的操作步骤与各级职责
升级流程可以拆成五个动作：确认焦点、形成遗留项、按路径提交、作出裁决、回写记录。每个动作都有明确的输入、输出和负责人，评审主持人负责前两步并把控节奏，技术决策人和DCP决策会负责裁决，评审记录人负责回写与跟踪。
第一步：会中确认争议焦点并记录双方证据
主持人应在争议出现时暂停自由讨论，用一句话复述争议焦点，例如“当前分歧是样机在高温工况下的性能指标是否满足规范要求”。随后请双方各自陈述观点、引用证据，记录人同步记录：争议描述、甲方观点及证据、乙方观点及证据、已排除的分歧点。这一步的输出是一段结构化的会议记录，完成标志是双方对“争议焦点是什么”没有异议。
第二步：形成书面遗留项
无法当场关闭的争议转为书面遗留项，至少包含四项内容：问题描述、责任人、所需补充证据、关闭时限。责任人应是能够推动证据补充或方案完善的具体人员，而非笼统的“评审组”。关闭时限应结合下一评审节点或阶段决策时间倒推，避免遗留项无限期挂起。
第三步：按升级路径提交裁决
升级路径一般为：评审组 → 上一级技术决策人 → DCP决策会。评审组内部无法达成一致的，提交技术决策人；技术决策人认为超出自身权限或涉及阶段决策的，提交DCP决策会。企业可按自身治理结构裁剪层级，但路径应事先约定并在评审启动时告知参会人，避免争议发生时临时找人。
第四步：作出裁决并明确结论类型
裁决结论应归入四类之一，便于后续跟踪和阶段状态管理：
- 继续：争议已解决或风险可接受，阶段按计划推进。
- 有条件继续：阶段推进，但附带必须完成的整改项和验证条件，条件未满足时回到评审。
- 暂缓：证据不足或风险待评估，阶段暂停，待遗留项关闭后重新裁决。
- 终止：方案不可行或风险不可接受，阶段终止或方案重新设计。
第五步：结论回写评审记录并进入跟踪清单
裁决结论由记录人回写到TR评审记录，同时把遗留项登记到跟踪清单，注明责任人、关闭条件和时限。评审记录与跟踪清单应保持关联，使后续查看评审结论时能直接看到遗留项状态。
| 步骤 | 负责人 | 输入 | 输出 |
|---|---|---|---|
| 确认争议焦点 | 评审主持人 | 双方观点与证据 | 结构化争议记录 |
| 形成书面遗留项 | 主持人、争议双方 | 争议记录 | 遗留项条目（描述、责任人、证据要求、时限） |
| 提交升级 | 主持人或项目技术负责人 | 遗留项及支撑材料 | 升级申请与裁决请求 |
| 作出裁决 | 技术决策人 / DCP决策会 | 升级申请、评审材料 | 裁决结论（继续/有条件继续/暂缓/终止） |
| 回写与跟踪 | 评审记录人、遗留项责任人 | 裁决结论 | 更新后的评审记录与跟踪清单 |
升级决策的记录模板与示例
记录模板的作用是让裁决过程可追溯、可复核。字段设计围绕“争议是什么、双方依据什么、谁裁决、裁决了什么、什么条件下关闭”展开，避免只记结论不记依据。
争议升级记录字段
| 字段 | 填写要求 |
|---|---|
| 争议编号 | 按TR节点与序号编排，如TR4-C01 |
| 所属TR节点 | 注明评审节点及评审日期 |
| 争议描述 | 一句话写清分歧对象与分歧点 |
| 双方观点与证据 | 分列甲方、乙方观点及引用的数据、文档、测试报告 |
| 升级层级 | 记录提交至技术决策人或DCP决策会 |
| 裁决人 | 具体人员或决策会名称及日期 |
| 裁决结论 | 继续、有条件继续、暂缓、终止之一 |
| 关闭条件 | 遗留项关闭所需完成的验证或整改 |
| 时限 | 关闭截止日期及复核节点 |
完整填写示例
以下为演示情景，用于说明字段填写方式，不代表真实项目数据。
争议编号：TR4-C01；所属TR节点：TR4原型验证评审，评审日期按项目计划填写。争议描述：样机在高温工况下的连续运行性能指标是否满足需求规范。甲方观点：现有测试数据表明指标达标，引用测试报告编号及测试条件；乙方观点：测试样本量不足且未覆盖极限工况，认为结论不成立，引用测试计划与样本记录。升级层级：评审组无法就证据有效性达成一致，提交技术决策人；技术决策人认为涉及阶段继续判断，提交DCP决策会。裁决结论：有条件继续——补充极限工况测试，样本量按验证计划执行，测试通过后阶段推进。关闭条件：补充测试报告经技术决策人确认。时限：设定为下一评审节点前，逾期未关闭则阶段状态回到暂缓。
结论与遗留项的区分记录
裁决结论记录在评审记录主体中，回答“本阶段是否继续”；遗留项记录在跟踪清单中，回答“还有哪些事没做完、谁在做、何时完成”。两者通过争议编号关联，避免把“有条件继续”的附带条件散落在会议纪要里而失去跟踪。
结论跟踪与闭环检查
裁决之后，争议管理的重心从“作决定”转向“盯关闭”。跟踪不到位的典型表现是遗留项长期挂起、关闭条件被口头确认、到期无人复核。闭环机制要解决这三类问题。
跟踪清单的维护责任与更新节奏
跟踪清单由评审记录人或项目管理人员维护，遗留项责任人负责更新进展。更新节奏建议与项目例会或阶段评审节奏对齐：责任人按周更新状态，主持人在下一评审节点前集中复核一次。清单应包含争议编号、责任人、当前状态、关闭条件、时限和最近更新日期。
关闭条件与证据要求
遗留项关闭需要满足两个条件：关闭条件中列明的验证或整改已完成，且支撑证据已归档到评审记录。仅凭责任人声明“已解决”不构成关闭依据，证据可以是测试报告、设计变更记录、评审确认意见等。关闭动作由主持人或指定复核人确认，确认后状态改为已关闭并记录关闭日期。
未按期关闭时的再次升级规则
遗留项超过时限未关闭的，按预设规则再次升级：第一次逾期由主持人提醒责任人并更新预计完成时间；第二次逾期提交技术决策人，评估是否调整阶段状态；涉及阶段继续判断的遗留项逾期，阶段状态应自动回到暂缓，直到关闭条件满足。再次升级同样记录在案，形成完整的处理轨迹。
完成检查清单
- 本次TR评审产生的争议是否全部有明确结论，无悬而未决事项；
- 每条裁决结论是否写明结论类型（继续/有条件继续/暂缓/终止）；
- 每个遗留项是否有唯一责任人、关闭条件和时限；
- 遗留项是否在时限内关闭，逾期项是否已按规则再次升级；
- 关闭证据是否已归档并与争议编号关联；
- 评审记录中的阶段状态是否与遗留项实际状态一致。
用ONES承载争议记录与闭环跟踪
上述流程落到工具上，核心是把“争议”和“遗留项”变成可跟踪的工作项，把“裁决结论”沉淀在评审文档中，并让两者保持关联。在IPD场景下，ONES可围绕项目计划、阶段推进、任务协同和研发过程管理支持团队建立更清晰的管理方式，企业可结合自身研发流程与组织分工进行方案规划。
争议与遗留项登记为工作项并关联评审
每条争议升级记录可以登记为一个工作项，字段对应争议编号、所属TR节点、争议描述、责任人、关闭条件和时限。工作项关联到对应的TR评审任务或评审文档，使查看评审时能直接看到由该评审产生的全部争议与遗留项。技术评审在IPD计划阶段用于验证整体技术方案与子系统设计的可行性、接口一致性和风险可控性，这些评审产生的分歧正适合以工作项方式沉淀。
评审文档记录裁决结论与证据附件
TR评审文档承载会议记录与裁决结论，争议双方的证据材料作为附件归档在同一文档下。裁决结论按继续、有条件继续、暂缓、终止四类填写，并注明裁决人与日期。这样评审文档既是决策依据，也是后续复核的入口。
遗留项状态流转与时限提醒
遗留项工作项按“待补充证据—待裁决—整改中—待复核—已关闭”的状态推进，责任人更新状态时同步填写进展说明。时限字段用于提醒责任人和主持人，逾期项在跟踪视图中突出显示，便于按再次升级规则处理。验证阶段强调建立闭环问题管理机制确保缺陷有效修复，遗留项的状态流转与这一要求方向一致。
评审结论与阶段决策的关联查看
TR评审的裁决结论与阶段决策评审相互衔接：阶段决策评审基于评审结果作出，TR中“暂缓”或“有条件继续”的结论应能在阶段决策查看时一并呈现。ONES可将评审任务、争议工作项与阶段推进计划关联，使决策者在DCP决策会上看到争议处理状态，判断阶段是否具备继续条件。具体功能配置与版本支持情况，建议结合企业实际部署方案确认。
常见问题
评审组内部对争议焦点本身就有分歧，主持人该怎么处理？
主持人先暂停自由讨论，用一句话复述争议焦点，请双方确认“争议对象是什么”。如果双方对焦点描述仍有分歧，说明分歧可能不止一个，应拆成多条记录分别处理，每条写清对象、分歧点和各自证据。焦点无法收敛时，主持人可直接把“焦点界定”本身作为遗留项提交上一级技术决策人，由裁决人明确需要裁决的问题范围，再回到评审组补充材料。
技术决策人裁决后，评审组仍有不同意见，是否可以再次升级？
可以，但需要满足条件：提出方应提交新的证据或指出裁决依据中的事实性错误，而不是重复原有观点。再次升级按原路径向上一级或DCP决策会提交，并附上前一次裁决记录与新增证据。企业应在流程中约定再次升级的次数上限和最终裁决层级，避免同一争议反复往返。最终裁决生效后，评审组按结论执行，不同意见记录在案即可。
“有条件继续”的附带条件没有按期完成，阶段状态怎么处理？
“有条件继续”的附带条件应作为遗留项登记，写明关闭条件、责任人和时限。条件逾期未完成时，按再次升级规则处理：第一次逾期由主持人提醒并更新预计完成时间；第二次逾期提交技术决策人评估，涉及阶段继续判断的，阶段状态回到暂缓，直到关闭条件满足并经复核确认。阶段状态与遗留项实际状态应保持一致，避免评审记录显示继续而条件实际未满足。
争议升级记录和会议纪要是什么关系，需要各记一份吗？
两者用途不同。会议纪要记录评审过程与参会情况，争议升级记录聚焦单条争议的焦点、双方证据、裁决结论和关闭条件。实践中可在评审文档中设争议记录章节，按争议编号逐条填写，会议纪要引用争议编号即可，避免同一内容在两处重复维护。裁决结论写入评审记录主体，遗留项进入跟踪清单，两者通过争议编号关联。
用ONES承载争议记录时，哪些内容适合放工作项、哪些适合放文档？
需要跟踪状态和时限的内容适合放工作项，例如争议编号、责任人、关闭条件、时限和当前状态；需要留存完整依据的内容适合放评审文档，例如双方观点、证据附件、裁决人与裁决日期。工作项关联到对应的TR评审任务或文档，查看评审时能同时看到结论与遗留项状态。具体字段配置、状态流转和提醒方式，建议结合企业实际部署方案确认。
