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