13.5.1 如何提高评审效率

♢选择合适专家；

♢充分准备；

♢PQA要引导会议进程，确保讨论聚焦，会议时不偏离主题和重点；

♢系统工程师SE要善于提炼，适时总结，减少会议过程中的争论；

♢问题修改后及时跟踪；

♢提高和优化评审要素（Checklist）质量；

♢TR会议上不涉及所有技术内容，只讨论SE认为需要提交讨论的要点、分歧点、遗留问题、风险、综合建议和下一步计划。

13.5.2 如何做好评审

♢各位主审人和评审专家，尤其是技术骨干要给予足够的重视，保证有效的投入。有困难时，必须提前与主审人、相关领导协调解决；

♢做好评审/检视计划，在项目组的月度计划中包含评审计划。尽量详细，避免资源冲突，项目经理要特别注意这一点；

♢各阶段和类型的评审以相应的评审要素表、评审操作指导书做指导，并且确保本阶段的主要相关角色负责人都能参与；

♢各类评审、检视过程中由主审人/检视负责人安排各位专家分工检查被审对象是否符合相关的技术规范；

♢各评审专家应按照邮件提示，及时参与评审、反馈意见。预审是非常重要的，不能等到评审/检视总结会上才看资料；

♢评审要素需要定期更新，由专人维护，建议季度更新，积累来自变更、客诉、研发、测试的经验；

♢PDT功能部门代表既不能“左倾”，一味考虑PDT的市场机会而不顾及对功能部门的压力，也不能过“右倾”，一味从本部门利益出发，不愿意帮助PDT经理做出综合的考虑并承担相应的责任和风险。

13.5.3 如何处理功能领域代表和SE、PQA之间的争议

♢这些不同意见都应该作为参考信息记录在TR报告里；

♢对于这些争议，系统工程师SE提出初步决策，并在TR会议后形成TR报告优化稿；

♢如果其他人不同意系统工程师SE的决策，可以在评审报告提交LPDT时提请重新裁决。LPDT对整个评审报告所有建议做出最终裁决，但同时为这些决策造成的后果负责；

♢如果这些决策会影响业务计划，则应该提交由IPMT做出决策；

♢TR报告终稿将会发布到所有相关人员，如果评审通过后因为PDT把关不严造成严重后果，将会启动对该评审的质量回溯。

13.5.4 问题和风险如何界定

“风险”是没有发生但可能发生的“问题”。一个问题，可能会跟随着风险。譬如，在TR4时发现一个单板因为原理图少画一个连线需要飞线才能正常工作。这里的“问题”是原理图错误，导致的“风险”是EMC测试可能无法达标。

13.5.5 PQA有能力实施技术性很强的要素表自检吗

PQA可以实施要素表自检。每条要素表均有对应的关联交付件，是交付件的测试、检视、评审结果，而不是技术文件本身，不存在技术细节。类似于律师找证据（如一些技术机构的报告），必要时可寻求系统工程师SE和PDT功能部门代表的协助。