2. ASPICE中的架构评审角色与职责

说到架构评审，很多人第一反应是「找个技术大牛来把把关」。其实没那么简单。我在多个项目里见过评审会开成「技术辩论赛」，最后谁嗓门大听谁的。为什么会这样？因为角色没分清，职责没划明白。

今天我们就来聊聊，ASPICE评审中四个关键角色——评审员、架构师、项目经理、质量保证人员——到底该干什么，不该干什么。

2.1 评审员：不只是「找茬」的

评审员这个角色，最容易被人误解。我刚开始做评审员时，也以为就是挑毛病。后来吃过亏才明白，评审员的核心价值是「独立判断」。

我个人习惯，评审前会先看三样东西：需求文档、架构设计说明、以及上一个版本的评审记录。不看这些就开评审会，基本是在浪费时间。

评审员要特别注意一点：你不是来写架构的。你指出问题，但不需要替架构师改设计。这个边界一旦模糊，后面就乱了。

2.2 架构师：设计者，也是「被挑战者」

架构师这个角色，说白了就是「扛雷」的。架构设计得好，项目顺风顺水；设计得不好，后面全是坑。

在ASPICE评审中，架构师的主要职责是：

• 呈现设计思路——不是念PPT，而是讲清楚「为什么这么设计」
• 接受质疑——评审员问的问题，要正面回答，别绕弯子
• 记录评审结论——哪些要改、哪些可以不改，都得记下来
• 跟踪整改——评审不是开完就完了，改完才算完

我记得有一次，评审员问我一个模块的接口设计为什么这么复杂。我当时有点不服气，觉得对方不懂。后来冷静下来一看，确实可以简化。嗯，这件事教会我一个道理：别把评审当成「批斗会」，它其实是帮你避坑的。

2.3 项目经理：不是来「监工」的

项目经理在评审中的角色，很多人搞错了。他们以为自己是来「盯着进度」的。其实不然。

项目经理的核心职责是：

• 确保评审流程合规——该有的角色有没有到场？评审标准有没有提前发？
• 协调资源——架构师需要额外支持？评审员时间冲突？这些是项目经理该管的
• 把控评审节奏——讨论跑偏了，要及时拉回来
• 推动决策——有些问题需要拍板，项目经理不能含糊

你想想看，如果项目经理在评审会上只顾着问「什么时候能改完」，那架构师和评审员还怎么安心讨论技术问题？

我建议项目经理在评审会上的发言比例，不要超过20%。你的角色是「主持人」，不是「主演」。

2.4 质量保证人员：流程的「守门员」

质量保证人员，简称QA。这个角色在ASPICE里特别重要，但也特别容易招人烦。为什么？因为QA总是问「流程对不对」，而工程师更关心「技术行不行」。

QA在架构评审中的具体职责：

职责项	具体说明
流程合规检查	评审计划、评审 checklist、评审报告是否齐全
角色确认	评审员是否独立？有没有利益冲突？
证据收集	评审记录是否完整？整改是否闭环？
过程改进	这次评审有什么可以优化的？下次怎么做得更好？

我曾经遇到一个QA，每次评审会都坐在角落里，一句话不说，会后发一封长长的邮件，列出一堆流程问题。说实话，这种方式效果很差。好的QA应该在评审过程中适时提醒，而不是事后「算账」。

2.5 四个角色的协作关系

这四个角色不是各干各的。他们之间有一个微妙的平衡。

我画个简单的图给你看：

架构师（设计者） ←→ 评审员（验证者）
    ↑                    ↑
    |                    |
项目经理（协调者）    QA（流程守护者）

说白了，架构师和评审员是「技术对线」，项目经理和QA是「流程保障」。两对之间要互相配合，但不能互相替代。

我见过最糟糕的情况是：项目经理替QA做了流程检查，QA替评审员做了技术判断。结果呢？评审会开成了「四不像」，谁都不满意。

2.6 常见误区与避坑

最后，我总结几个常见误区，都是我在项目里踩过的坑：

• 误区一：评审员必须是技术最强的——不一定。评审员需要的是独立判断能力，不是技术天花板。有时候一个「懂业务但不写代码」的人，反而能发现架构师忽略的问题。
• 误区二：架构师不能反驳评审员——当然可以。评审是讨论，不是命令。架构师有权利解释自己的设计，只要理由充分。
• 误区三：项目经理可以缺席评审——千万别。项目经理缺席，评审会很容易变成「技术沙龙」，没人管时间、没人做决策。
• 误区四：QA只负责挑流程毛病——QA更重要的价值是「帮助团队把流程跑顺」，而不是「抓违规」。好的QA是团队的伙伴，不是警察。

嗯，差不多就这些。角色分清楚了，职责划明白了，架构评审就成功了一半。剩下的，就是大家能不能放下「面子」，真正为产品质量负责了。