ASPICE GP 通用实践当中明确对工作产物评审提出要求，各类需求、架构、测试等工作产物，需要开展正式评审，留存对应的证据。项目里技术研讨、方案沟通非常频繁，很多工程师分不清研讨和正式评审的边界。技术会上大家讨论方案可行性、交换想法，但没有按照评审流程执行，会后直接把这份会议记录当做 ASPICE 评审记录。到 ASPICE 评估访谈的时候会发现，参会人员只是开展技术交流，没有履行评审角色，没有给出正式评审结论，造成 PA2.2 工作产品管理出现弱项。
实际项目当中经常出现几类典型误区。将日常技术沟通、方案研讨的纪要直接拿来当做正式评审记录，没有区分会议性质。评审没有明确的评审对象、参与角色，分不清作者、评审人、决策者。没有明确的评审结论，分不清工作产物是通过、带条件通过还是不通过。评审发现的问题只写在会议纪要，没有形成问题条目，不跟踪闭环。事后补写评审记录，参会人员实际并未参与本次评审，访谈和文档证据互相矛盾。
技术研讨目的是交换想法、讨论技术难点；正式评审目的是对工作产物做系统性审查，给出正式接纳或者有条件接纳的结论，二者用途不一样，不能互相替代。
开展 ASPICE 认可的正式工作产物评审，要具备几个关键要素。第一，明确待评审的工作产物版本，锁定对应的基线；第二，区分角色，工作产物作者、独立评审人员、决策人；第三，评审过程识别缺陷与疑问，记录所有评审发现；第四，输出明确评审结论：全部通过、带条件通过（写明待整改项）、不通过；第五，评审发现的问题录入 SUP.9 问题解决管理，跟踪整改闭环；第六，完整的评审记录归档，作为 ASPICE 评估证据。
技术研讨、方案会商可以正常开展，用来攻克技术难点，但这类产出物只作为参考材料，不能直接充当正式评审证据。如果研讨之后需要升级为正式评审，要按照评审流程重新组织，补齐上面提到的全部要素。
内部预评估核查评审证据的时候，重点分辨是正式评审记录还是普通技术会议纪要，查看评审角色、明确结论、问题闭环记录，识别拿研讨记录顶替评审的情况。
很多 ASPICE 评估出现 GP 相关弱项，并不是没有开会讨论，而是混淆研讨和正式评审。分清楚技术研讨与正式评审，按要求产出评审结论并跟踪问题闭环，收集真实有效的评审证据，满足 ASPICE 评估当中 GP 通用实践的要求。
