需求评审主要要点

       作为产品经理，评审时常态，无论大小需求，只要提交到开发，就必须经过评审，一般评审分为两个部分：内部评审、技术评审。

业务评审：关注用户体验

        业务评审参与人员一般有：产品部代表、技术不代表、运营部代表，客服部代表。需求提出方。一般需求提出方可能是运营团队、客服团队，也有可能是销售团队。一般销售团队不参与运营和客服提的需求的需求评审，对于运营、客服团队提出的需求，销售团队只在乎结果，即最后做成什么 样子，什么时间做出来，但是运营和客服团队会关心销售团队提出的需求是否真的是在真实场景中遇到的。

        一般内部评审大家关注用户体验，重点考虑实现方案是否真的能满足需求方的需求，实现方案推入市场是否真的能带来正面反馈。一般运营、客服、销售团队更贴近用户，所以在该步骤评审过程中不需要讲解过多的实现细节，只需要说一下大致的实现方案和操作流程即可，客服团队会站在用户的角度，给出用户在使用改产品时可能遇到的坑，运营团队会站在产品推广的角度判断改方案是否符合新用户推广。

        专业的人做专业的事情，业务评审得出反馈应该是用户角度的。

技术评审：关注实现逻辑

        技术评审参与啊的人员主要是项目组成员，一般有：后台，前端（移动端/web端）、测试，前端中移动端和web端不一定同时有，具体要看方案是在什么地方实现的，如果没有App 的内容，不需要叫移动端的同学，或者没有网页的设计内容，则不需要叫web端的同学，但是如果两端都有涉及，则需要叫上两端的同学。

        一般技术评审大家关注的是实现逻辑，重点考虑这个需求怎么实现，后台考虑实现逻辑，前端考虑交互逻辑，测试考虑测试用例。所以在需求评审前，产品经理一定要单独把这几个方向考虑到，如果有某个方案考虑得不够到位，会当场被相应的同学指出来的。

        技术评审不在于产品经理考虑得有多么全面，而是思考过程有多么缜密，产品经理缜密的逻辑思维会考虑得更加周全。在技术评审的过程中，如果思考过程有过多的欠缺，那么会呗开发提出很多意见，如果产品经理不经思考直接接受这些意见，那么产品最后做出来的不会是最初的那个样子，会更加偏向实现层而不是用户层。所以产品经理在技术评审的时候如果第一次被指出很多问题，不要惊慌，也不要害怕，没有人是一次成功的，把问题收集起来，回去整理归类一下问题，再针对问题做一次全盘思考。

        技术评审的时候，会抛出很多问题，产品经理一定要保持初心，不要为了尽快提交开发而做出过多让步，毕竟产品经理的目标不是提交开发，而是为用户提供更好的服务。

        评审的时候遇到问题并不可怕，可怕的时候产品经理没有过多思考问题背后的意义，作出过多的让步。无论什么时候，产品已经一定要站在用户的角度，保持初心，为用户创造更多更好的产品。