需求评审：让相关方达成一致的认知

需求评审是需求落地相关的人员审核需求设计结果的过程，用于评审的需求是经过产品经理分析整理后的。需求评审的重要性体现在如下几个方面：

1. 与相关方达成统一认知。任何一个团队想要做好一件事情，都需要所有团队成员达成统一认知，这样才能力出一孔，劲往一块使。

2 需求评审过程本身也是一个知识传递过程，相关人员可以与产品经理一起讨论需求设计的前因后果，这有助于相关人员获得用户需求的前期认识。

3. 需求评审过程中可能发现不明确的或者遗漏的需求，这需要产品经理进行二次确认。

4. 需求评审过程中可能发现某些间接需求或隐藏的问题，参与评审的相关人员可以群策群力共同思考解决问题的方式。

5. 当局者迷、旁观者清。再有经验的产品经理也可能犯错或思考不全面，评审人员可以提出更合理或者更有建设性的想法供产品经理参考。

需求评审会的相关参与方

通常会包含如下人员：

1、业务方代表或用户代表，即需求提出人员或*终的使用人员。业务部门直接提出的需求，需要业务方代表进行评审确认；业务部门间接提出的需求（如A部门提的需求*终是B部门使用），则需要功能使用人员进行评审确认。一般来讲比较难邀请到用户代表，用户沟通会也不会和需求评审会议放在一起，因此以业务方代表为主；

若是产品经理自发产生的需求，则邀请*终功能使用人员进行评审。若是直接面向用户的，可以考虑邀请对应的运营人员参与。

2、开发人员，包括系统设计人员、实际开发人员，需求范围较大的情况下，可以叫上开发团队的各级负责人一起参与评审；

3、测试人员，*终参与测试的成员和测试团队的负责人；

4、相关的产品经理，如跨产品线或产品的，业务有关联的产品经理；

5、项目经理，若有；

6、运营人员，若是面向用户的功能需求，需要上线后负责运营的相关人员参与。

需求评审的重点是明确需求背景和实现的价值

在需求评审的开始阶段，首要讲解的不是具体的需求设计结果和功能点，而是要让参与评审的相关人员先明确需求产生的背景。要让大家知道需求产生的来龙去脉，这有助于大家建立初步的认知。从用户那边收集过来的，老板提出来的，业务部门提出来的，还是产品经理团队自己发掘出来的，以及需求产生的过程。

其次要让大家知道需求实现的价值，这时更多都是预估的，若有相关的数据分析支撑，会更有说服力。价值能够量化的情况下尽量量化，用相对科学的方式去计算预估。不能量化的情况则需要定性的描述，把实现的目标和完成的标志说明清楚，这样大家就清楚的知道去实现的意义，价值越大，实现的必要性越高。

需求评审的目的是让大家达成统一的认知

需求评审的过程和普通的开会没什么区别，产品经理陈述需求设计结果，评审人员思考或者提问，以取得对需求设计结果有一致的理解，这是一个互动的过程，可以适当的营造轻松的氛围，有助于大家充分思考。

需求评审很多时候也是一个迭代过程，很多情况下不能一步到位，事实上，这并不是什么坏事。我们都知道，需求失真发现的越早，修复成本越低。评审人员在多次迭代的评审过程中，或许能够发现解决现实问题更好的方案，而且他们对每次评审中出现的情况也比较清楚，知道哪些问题导致评审不通过，哪些需求可能还会有进一步变更等等。

对系统设计人员、开发人员来说，需求理解的越透彻，开发实现的完成度就越高，越不容易偏离需求设计结果。只不过产品经理要控制一下进度，不能无限制的召开多次评审会，要用*快*有效率的方式完成评审，这就需要产品经理在前期需求设计时要充分考虑各方面的影响。

需求评审的过程需要尽量高效

需求评审过程的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后面越马虎。要适当的控制需求评审的节奏，让大家集中注意力进行评审。

需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。

开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。

开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而当争议变为争吵时就是坏事了，争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。争吵还会导致各方分不清楚自己究竟是“坚持真理”还是“固执己见”，毫不妥协或者轻易妥协都不是好办法。

我们应当养成良好的沟通习惯，不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。

总之，需求评审环节是衔接需求设计结果和需求实现过程的桥梁，需求评审环节的好坏，会影响实际需求实现的完成度和实现偏差，产品经理一定要在需求评审环节让大家达成统一的认知。