需求评审会常见的结果是，会上点头一片，会后各记各的。开发照着理解做，甲方照着印象等，中间差出来的部分，到验收时才暴露。
评审会开得对不对，不取决于开了几个小时，取决于散会时双方对同一件事的描述是否一致。下面这四条是我们踩过坑之后固定下来的做法。
一、该到的人一个都不能少
评审会最容易犯的错是只来了对接人，实际用系统的人一个没到。对接人往往是办公室或者信息岗，对业务细节的了解不如一线的业务员，会上点头说没问题，等系统上线，一线的人说这不是我们要的。
该到的人有这么几类。每个业务环节的实际操作人员，至少各来一个。业务环节的负责人，他能拍板取舍。甲方的项目对接人。开发方的需求人员和后续要写代码的人，最好是同一个人，避免转述走样。
如果人多不方便，可以分开开，按业务环节一场一场过。宁可多开两场，也别把一线的人跳过。
二、按业务流程走，别按功能清单念
拿着功能清单一条条念，容易念成文档朗读会，大家注意力很快散掉。更有效的做法是按业务从头走一遍。
比如一个报修系统，从住户打电话进来开始走。接线员记录什么，系统给不给自动编号，派给谁，维修工在手机上看得到什么，修完怎么回填，照片必不必须传，回访由谁做，超时了系统怎么提醒。一步一步走，走到哪一步发现这里没想清楚，当场就补上。
走流程还有个好处，能顺带验证角色的分工对不对。哪一步归谁做，在流程里是自然体现的，比在功能清单里看角色表直观得多。
三、有争议的地方当场标出来，别含糊过去
会上最危险的信号是某个问题被一句先按这样来带过。这种含糊的结论，后面必然变成扯皮。
碰到分歧，处理方式有三种，都比含糊过去强。一是当场查规定，如果业务本身有文件依据，翻出来对照一下就能定。二是当场拍板，如果业务负责人在场，让他定，并且记下是他定的。三是记为待定项，写清楚谁在几天内给答复，到期没答复就按某个默认方案执行。
待定项要有数量上限。一场评审会攒下二三十个待定项，说明这个项目还没到能开工的程度，硬开工就是拿开发时间试错。
四、散会前把结论落成文字，双方都看一遍
口头的共识不算共识。评审会结束前，最好当场把结论整理成简版文档，至少包含改动后的功能清单、待定项清单和下一步时间点，发给与会的人确认。
文档不用写得漂亮，一页纸也行，关键是准确。写的时候注意记改动，别只记结论。比如会上把原本的五个审批层级改成三级，要写明改成三级，而不是写审批流程已确认。过两个月回头看，只有改动记录能还原当时为什么这么定。
还有个细节，确认方式最好是回复邮件或者群里回一句确认，而不是默认没意见就是通过。默认通过这种做法，等到出问题的时候，双方对有没有确认过的记忆是不一样的。