第3章评审角色与职责

第三章：评审角色与职责——主持人、记录员、作者、评审员、决策者的分工

一场需求评审会，说白了就是一群人坐在一起找茬。但要是角色不清，就容易变成「谁嗓门大谁说了算」的混乱场面。我经历过太多次这种评审了——有人抢着说话，有人全程沉默，最后散会了才发现关键问题一个没解决。

所以今天咱们聊聊，这五个角色到底该怎么分工。嗯，这里要注意，角色不是职位，而是职责。一个人可以身兼多职，但每个角色的边界必须清晰。

主持人不是来提需求的，也不是来挑毛病的。他的任务只有一个：让评审会高效推进。

我个人习惯，主持人最好由项目经理或测试负责人担任。为什么？因为他们相对中立，不会在技术细节上跟作者吵起来。

主持人的核心职责：

我在项目中遇到过最典型的情况：评审会开了两小时，还在争论某个字段该用下拉框还是输入框。这时候主持人就得果断喊停——「这个问题我们会后单独讨论，先过下一个功能点。」

小技巧：主持人可以准备一个「停车场」列表。凡是跑偏的话题，先记下来，会后单独处理。这样既不会打断节奏，也不会遗漏问题。

记录员这个角色，很多人觉得就是打字员。其实不然。好的记录员能帮团队省下大量返工时间。

你想想看，评审会上大家七嘴八舌，说了几十个问题。如果没人记下来，散会后就全忘了。我见过最惨的一次，评审会开了三小时，结果第二天作者说「你们提的那些问题我记不清了」——得，白开了。

记录员要记什么？

注意：记录员不要参与讨论。一旦开始争论，记录就会中断。我建议让测试人员或实习生担任记录员，他们更关注细节，而且不会因为技术立场影响记录客观性。

作者就是写需求文档的那个人。他的心态很关键——是来接受批评的，不是来辩护的。

我曾经见过一个开发经理，自己写的需求文档，评审会上别人提一个问题他反驳三个。结果呢？评审会变成了辩论赛，最后什么问题都没解决。

作者的正确姿势：

避坑指南：我曾经犯过一个错误——评审会上当场修改文档。结果改到一半发现逻辑不通，整个会议节奏全乱了。后来我学乖了：会上只记录问题，会后统一修改。效率高得多。

评审员是核心角色。他们负责从不同角度挑毛病。我一般建议至少包含以下角色：

说白了，评审员就是「找漏洞」的。但要注意，找漏洞不是找茬。我见过有些评审员喜欢挑语法错误、排版问题——这些其实应该会前就解决，别浪费大家时间。

我的建议：评审员会前至少花30分钟通读文档，列出自己的问题清单。会上直接提问，效率最高。别在会上现看现想，那是对所有人的时间不尊重。

决策者通常是项目经理或产品负责人。他的职责不是参与讨论，而是在讨论陷入僵局时做决定。

为什么会需要决策者？因为有些问题没有标准答案。比如「这个功能到底要不要做？」——开发说做不了，产品说必须做。这时候就需要决策者拍板。

决策者的工作：

注意：决策者不要过早表态。我见过一个领导，评审会刚开始就说「我觉得这个方案挺好的」。结果呢？其他人都不敢提反对意见了。等上线后才发现一堆问题。所以决策者最好先听，最后再说。

这五个角色不是各干各的，而是有明确的协作顺序：

嗯，这个流程看起来简单，但执行起来容易出问题。我见过最典型的场景：评审员在会上提了问题，作者说「我回去改」，然后就没有然后了。所以主持人一定要在会后跟踪，确保每个问题都有闭环。

总结一下：

角色清晰了，评审会才能高效。你想想看，如果每个人都知道自己该干什么，不该干什么，那会议质量自然就上去了。