刚加入现在的创业团队的那段时间，需要组织大家进行需求评审，团队内部没有固有流程，加上自己本身经验不足，我将原型文档及标注准备的差不多之后，就『胆大妄为』的拿着这些内容组织大家进行需求评审。
评审会上，拿出原型稿，开始抑扬顿挫的直奔主题，跟大家讲流程、功能和规则。讲完后大家一脸懵逼的看着我的演讲终于要落下帷幕了，然后『听讲的人』开始毫不留情的把各种问题仍过来。比如：
你确定考虑清楚要这样做了吗？
这里为什么要这样设计？
高保真设计稿还会在原型稿基础上大改吗？
你这里是啥意思，说的太笼统了
这样做会有xx问题，老版本怎么考虑？
那时候才去公司没多久，大家都比较客气，不会直接喷过来。偶尔也被吐槽一下，那段时间还写了篇文章：每个产品大概都被技术吐槽过吧。而更大的问题是，因为有时对需求的拿捏不够准，或很多特殊情况未考虑到，需求评审期间跟大家沟通不够清晰详细，等开发进行到一半后又拉着技术改需求，设计师改页面，然后导致项目延期。
那段时间感觉很糟糕，尤其是需求评审前人很焦虑，担心哪里没准备充分，哪里又没思考清楚，怕被问到问题时回答补上来。。。
我意识到这个问题很严重，陆续找研发同学沟通，让他们提出问题并给出建议，比如文档需要准备多详细；拿捏不住的需求在初期可以跟他们先讨论可行性；他们在开发过程中，不确定的地方会直接跟我讨论，确定方案，不按照自己想的做等。之后也找了一些资料和书籍阅读。经过几个月的磨合，一直在调整各种评审会姿势，到现在为止，最明显的感知是：
<b>1.临时改需求的情况显著减少；2.项目延期有减少；3.大大减少了技术的吐槽机会~</b>
这期间大概半年时间左右，也终于能比较坦然的组织需求评审了。然后趁着周末，我又完整梳理了一遍需求评审的流程和细节，也找了一些外部资料，整合了一篇关于需求评审的说明文。
1、为什么要需求评审？
需求到产品经理那儿之后，经过对需求的调研、分析，到确定要做之后，需要多个部门的同事配合才能完成，比如设计师、开发使得整个需求上线，而运营负责对其进行推广、包装给用户使用等。那么，产品经理完成他前期工作之后，需要让大家周知整个需求的『来龙去脉』。所以<b>需求评审的目的</b>基本如下：
<b>-让团队所有人（相关成员）明确需求背景和目的；
-确认需求的规则及实现方案；
-确定整个项目的周期和内容；
-让相关人员了解自己所需负责的内容；
-确定需求上线时间规划；</b>
2、哪些人需参加？
一般情况下，一次需求评审中，参与的人包括：<b>产品、设计、研发、运营</b>，大团队可能还有<b>测试、客服</b>等其他岗位的人。为什么这些人要参加？
<b>产品。</b>这里的产品是除了需求负责人外，可能还有该业务的其他产品经理或公司内部上下游产品同事，他们一般是为了解业务变更情况，甚至要配合做一些调整。比如，前台业务变更时，后台产品经理可能需配合调整后台的逻辑及设计。
<b>设计。</b>设计师通过需求评审，了解需求逻辑和规则，尤其是原型设计逻辑，并提出问题，方便后续产出设计稿。
<b>研发。</b>前后端、客户端的研发等成员通过需求评审，了解需求的流程和规则，提出问题，沟通好细节方案，以便后续开发。
<b>运营。</b>运营同学通过需求评审，了解需求的背景、目的及流程，方便后续准备运营方案。
3、如何组织需求评审？
把整合需求评审会分为3个周期，一共有<b>3个阶段：1）前期准备2）评审会期间3）评审之后</b>
1）前期准备
准备越充分，评审效果越好，被吐槽的机会也越小。几个小技巧如下：
<b>-完成需求文档撰写。</b>包括流程图、原型、标注等。然后反复多次推演，看是否有漏洞，尽量把能考虑到的问题都准备好。
<b>-同核心人员小范围沟通，确保没有大问题。</b>这一招效果很好，提前沟通好，有大问题提前找出来并解决，避免在评审会期间出现大问题，甚至可能导致整个方案都无法执行。
<b>-提前同相关参与同学协调好评审时间。</b>不要临时组织评审，不仅可能人无法到齐，大家手头有其他工作也会受到影响，心里也不爽。
<b>-提前将需求文档发给大家。</b>让大家有时间提前了解基本信息，提高评审会效率。当然，提前发了可能也有人不会看，想办法引导一下呗~
3.2 评审会期间
不要一上来就讲功能，大致按照以下流程一步步说明需求信息：
<b>-先讲需求背景。</b>让大家知道为什么要，做了对用户和我们自身有什么价值。这样大家心里才明白参与到这个项目的价值，后面才有动力听下去。
<b>-讲功能模块。</b>说明这个需求本身需要哪些功能来满足，其中这一期先做哪些，后续迭代的时候再做哪些。
<b>-讲业务流程。</b>说明整个需求的业务流程和数据流转。
<b>-讲原型和交互。</b>这一步终于可以拿出原型稿了，详细的说明页面布局、交互逻辑及规则等详细信息；
<b>-讲数据指标。</b>沟通清楚需要哪些数据，在哪些地方埋点，数据如何可视化；
<b>-需要谁支持。</b>有哪些人需要投入到这个需求的项目中，以及负责的内容是什么，上下游配合的人员是谁等；
<b>-预计上线时间。</b>需求排期，可以让每个功能对应的负责人估时，确定测试时间及预计上线时间。
基本上到这一步为止，需求评审会就结束了。另外，期间可能会有抛出一些问题，需要记录下来。
3.3 评审会后
评审结束后，大家回去开始干活了，这时候最核心的是要push整个项目的进度，保证在预期时间上线。
<b>-确认排期，追进度。</b>固定周期组织大家开会同步进度，其他时间可私下追问进度。确保一切顺利进展，若有问题也能提前了解。
<b>-整理遗留问题，并尽快给出解决方案。</b>评审会期间的问题及时解决，并将方案同步到相关的人员。
<b>-若需求有调整，更新需求文档并发给大家。</b>
以上是这半年多来的一些亲身经历和总结，晚安~
