需求评审通过规范

主要是一些产品经理的总结，大家可以一一参考

软件需求是软件开发最重要的输入，需求风险也常常是软件开发过程最大的一个风险。降低需求风险的重要手段就是需求评审。但是需求评审是所有的评审活动中最难的，也是最容易被忽视的一个评审。在需求评审中常见的如下问题有以下几种：

1、需求报告很长，短时间内评审中根本就不能把需求报告读懂，想清楚

2、没有做好前期的准备工作，需求评审的效率很低

3、需求评审的节奏无法控制

4、找不到合格的评审员，与会评审员无法提出深入的问题

做好需求评审的建议：

建议一：分层次评审

用户的需求时分层次的，一般而言可以分成以下三种层次。

1、目标层需求：定义了整个系统需要达到的目标

2、功能层需求：定义了整个系统必须完成的任务

3、操作层需求：定义了完成每个任务的具体的人际交互

目标层需求是高层管理员所关注的，业务层需求是中层管理员所关注的，操作层需求是具体操作人员所关注的。不同的层次的需求，其描述形式是有区别的，参加评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，很容易导致“捡了芝麻，丢了西瓜”。

如果让高层管理人员去评审操作性需求，无疑是一种资源的浪费或者出现高层管理者拒绝参与的情形。

建议二：正式评审与非正式评审相结合

1.正式评审是指通过召开评审会议，组织多个专家，将需求涉及人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。

2.非正式评审不需要这周严格的组织形式，一般不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至网络聊天等多种形式进行评审。

3.两种形式各有利弊，往往非正式评审比正式评审效率更高，更容易发现问题。一次在评审时，应该灵活地利用这两种方式。

建议三：分阶段评审

1.应该在需求形成的过程中进行分阶段评审，而不是在需求最终形成后再进行评审。

2.分阶段评审可以将原本需要进行大规模评审拆分各个小规模的评审，降低了需求返工的风险，提高了评审的质量。

3.比如可以在形成目标性需求后进行一次评审；在形成系统的初次概要需求后再进行一次评审，当再概要需求细分成几个部分后，对每个部分进行评审，最终对整体的需求进行评审。

建议四：精心挑选评审员

需求评审可能涉及的人员包括：需求方高层管理人员，中层管理人员，具体操作人员；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方领域专家等。

2.这些人员由于所处立场不同，对于同一个问题的看法是不同的。有些观点和系统的目标有关系，有些则关系不大，不同的观点可能想成互补的关系。

为了保证评审的质量和效率，需要精心挑选评审员。首先保证不同类型的人员都要参与进来，否则很容易漏掉很重要的需求；其次要在不同类型的人员中选择那些真正与系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率低下或者最终不切实际地修改了系统的范围。

建议五：对评审员进行培训

1.对评审员（很可能是领域专家而不是评审活动专家）进行培训，使其掌握评审的方法、技巧、过程等

2.对评审主持人进行培训，以便参与的人员仅仅围绕评审的目标进行讨论，能够控制评审的节奏，提高评审的效率。

3.培训氛围加单培训和详细培训两种。简单的，可能是十几分钟或几十分钟，需要对评审过程中需要把握的基本原则，需要注意的常见问题说清楚。详细的评审可能要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时间，是一个独立的活动。

4.需要和足以的是，被评审人员也是要被培训（谁是被评审人员）

建议六：充分利用需求评审检查单

1.需求检查单是很好的评审工具。需求检查单可以分为两类：需求形式的检查单和需求内容的检查单。

2.需求形式的检查可以由QA人员负责，主要检查需求文档的格式是否符合质量的标准。

3.需求内容的检查由评审专家用来检查需求内同是否达到了系统的目标、是否有遗漏、是否有错误等，这是需求评审的重点

4.检查单可以帮助评审人员系统全面地发现需求中的问题，检查单也是随着过程财富的积累逐渐丰富和优化的

建议七：建立标准的评审流程

1.对正规的需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。

2.比如在评审流程定义中可能规定了评审的进入条件，评审需要提交的资料，每次评审会议的人员职责分配、评审的具体步骤、评审通过的条件等。

建议八：做好评审后的跟踪工作

1.在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正，并给出充分客观的理由和证据。

2.当确定需要纠正的问题后，要修改需求文档进行复审。

3.切忌评审完毕后，没对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。

建议九：充分准备评审

1.评审质量的好坏很大程度上取决于评审前的准备活动。

2.常见的问题是，需求文档在评审前没有提前发给参与评审的人员，没有流出充分的时间让参与评审的人员阅读需求文档。

3.更有甚者，没有执行需求评审的准入条件，在评审文档中存在大量的低级错误，或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率很低，质量很差。

4.对评审工作的准备也应当定义一个检查单，在评审之前对照检查单落实每项准备工作。

作者：007er1117俞莉敏
链接：https://www.jianshu.com/p/489a82fd3dbc
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

刚加入现在的创业团队的那段时间，需要组织大家进行需求评审，团队内部没有固有流程，加上自己本身经验不足，我将原型文档及标注准备的差不多之后，就『胆大妄为』的拿着这些内容组织大家进行需求评审。

评审会上，拿出原型稿，开始抑扬顿挫的直奔主题，跟大家讲流程、功能和规则。讲完后大家一脸懵逼的看着我的演讲终于要落下帷幕了，然后『听讲的人』开始毫不留情的把各种问题仍过来。比如：

你确定考虑清楚要这样做了吗？
这里为什么要这样设计？
高保真设计稿还会在原型稿基础上大改吗？
你这里是啥意思，说的太笼统了
这样做会有xx问题，老版本怎么考虑？

那时候才去公司没多久，大家都比较客气，不会直接喷过来。偶尔也被吐槽一下，那段时间还写了篇文章：每个产品大概都被技术吐槽过吧。而更大的问题是，因为有时对需求的拿捏不够准，或很多特殊情况未考虑到，需求评审期间跟大家沟通不够清晰详细，等开发进行到一半后又拉着技术改需求，设计师改页面，然后导致项目延期。

那段时间感觉很糟糕，尤其是需求评审前人很焦虑，担心哪里没准备充分，哪里又没思考清楚，怕被问到问题时回答补上来。。。

我意识到这个问题很严重，陆续找研发同学沟通，让他们提出问题并给出建议，比如文档需要准备多详细；拿捏不住的需求在初期可以跟他们先讨论可行性；他们在开发过程中，不确定的地方会直接跟我讨论，确定方案，不按照自己想的做等。之后也找了一些资料和书籍阅读。经过几个月的磨合，一直在调整各种评审会姿势，到现在为止，最明显的感知是：
1.临时改需求的情况显著减少；2.项目延期有减少；3.大大减少了技术的吐槽机会~

这期间大概半年时间左右，也终于能比较坦然的组织需求评审了。然后趁着周末，我又完整梳理了一遍需求评审的流程和细节，也找了一些外部资料，整合了一篇关于需求评审的说明文。

1、为什么要需求评审？

需求到产品经理那儿之后，经过对需求的调研、分析，到确定要做之后，需要多个部门的同事配合才能完成，比如设计师、开发使得整个需求上线，而运营负责对其进行推广、包装给用户使用等。那么，产品经理完成他前期工作之后，需要让大家周知整个需求的『来龙去脉』。所以需求评审的目的基本如下：

-让团队所有人（相关成员）明确需求背景和目的；
-确认需求的规则及实现方案；
-确定整个项目的周期和内容；
-让相关人员了解自己所需负责的内容；
-确定需求上线时间规划；

2、哪些人需参加？

一般情况下，一次需求评审中，参与的人包括：产品、设计、研发、运营，大团队可能还有测试、客服等其他岗位的人。为什么这些人要参加？

产品。这里的产品是除了需求负责人外，可能还有该业务的其他产品经理或公司内部上下游产品同事，他们一般是为了解业务变更情况，甚至要配合做一些调整。比如，前台业务变更时，后台产品经理可能需配合调整后台的逻辑及设计。

设计。设计师通过需求评审，了解需求逻辑和规则，尤其是原型设计逻辑，并提出问题，方便后续产出设计稿。

研发。前后端、客户端的研发等成员通过需求评审，了解需求的流程和规则，提出问题，沟通好细节方案，以便后续开发。

运营。运营同学通过需求评审，了解需求的背景、目的及流程，方便后续准备运营方案。

3、如何组织需求评审？

把整合需求评审会分为3个周期，一共有3个阶段：1）前期准备2）评审会期间3）评审之后

1）前期准备

准备越充分，评审效果越好，被吐槽的机会也越小。几个小技巧如下：
-完成需求文档撰写。包括流程图、原型、标注等。然后反复多次推演，看是否有漏洞，尽量把能考虑到的问题都准备好。

-同核心人员小范围沟通，确保没有大问题。这一招效果很好，提前沟通好，有大问题提前找出来并解决，避免在评审会期间出现大问题，甚至可能导致整个方案都无法执行。

-提前同相关参与同学协调好评审时间。不要临时组织评审，不仅可能人无法到齐，大家手头有其他工作也会受到影响，心里也不爽。

-提前将需求文档发给大家。让大家有时间提前了解基本信息，提高评审会效率。当然，提前发了可能也有人不会看，想办法引导一下呗~

3.2 评审会期间

不要一上来就讲功能，大致按照以下流程一步步说明需求信息：

-先讲需求背景。让大家知道为什么要，做了对用户和我们自身有什么价值。这样大家心里才明白参与到这个项目的价值，后面才有动力听下去。

-讲功能模块。说明这个需求本身需要哪些功能来满足，其中这一期先做哪些，后续迭代的时候再做哪些。

-讲业务流程。说明整个需求的业务流程和数据流转。

-讲原型和交互。这一步终于可以拿出原型稿了，详细的说明页面布局、交互逻辑及规则等详细信息；

-讲数据指标。沟通清楚需要哪些数据，在哪些地方埋点，数据如何可视化；

-需要谁支持。有哪些人需要投入到这个需求的项目中，以及负责的内容是什么，上下游配合的人员是谁等；

-预计上线时间。需求排期，可以让每个功能对应的负责人估时，确定测试时间及预计上线时间。

基本上到这一步为止，需求评审会就结束了。另外，期间可能会有抛出一些问题，需要记录下来。

3.3 评审会后

评审结束后，大家回去开始干活了，这时候最核心的是要push整个项目的进度，保证在预期时间上线。

-确认排期，追进度。固定周期组织大家开会同步进度，其他时间可私下追问进度。确保一切顺利进展，若有问题也能提前了解。

-整理遗留问题，并尽快给出解决方案。评审会期间的问题及时解决，并将方案同步到相关的人员。

-若需求有调整，更新需求文档并发给大家。

以上是这半年多来的一些亲身经历和总结，晚安~

作者：涂涂小排屋
链接：https://www.jianshu.com/p/989ff4a4a2b4
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

想起前段时间组织的一次产品需求评审会，那是我第一次完全由我组织的产品需求评审会。从入行时的参与者，然后到协助组织者，最后到整个会议的组织者，中间经过的时间虽然说不长，但是体会颇多。

在亲自组织需求评审会之前，因为之前参与过的需求评审会基本上boss组织的，所以对产品需求评审会的印象并没有太深，也没那么正式，与大神们分享的需求评审会有所不同。而这次有幸被委托重任，让我再次全权负责一个产品的从0到1，所以需求评审会也是有我来负责。需求评审会，整个过程从理论到实践，让我更加懂得其意义和重要性。

需求评审的4个问题
在此之前，我们需要了解一下需求评审会的4个问题：

何为需求评审会？
需求评审会相当于对问题的解决方案的可行性分析，是产品正式进行开发前的重要一环，是产品相关的人员在会议上对产品需求进行分析和审查，论证需求是否可实现、可验证、可测试，并最终确定一个目标，号召大家往一个产品目标进发。

为什么要进行需求评审会？
进行需求评审会有以下原因：

为了让与会人员了解产品背景、产品业务、产品需求以及产品目标等。
让开发工程师对产品方案有具体的了解，以确保后续开发可以高效的进行。
让与会人员明确自己在整个方案所处的位置、职责，然后对自身在项目中所需要的工作有个心理预期。
评估产品方案的技术实现难度及实现周期，对产品体验进行权衡与评估。
获取项目所需要的资源等。
需求评审会的目标用户是谁？
参加需求评审会的常客有研发人员、测试人员、UI/UE/UX、运营人员、测试人员、市场人员和产品经理等等。

什么时候举行需求评审会？
需求评审会一般会在正式开发前的3~5天，因为一般需求评审会是很难一次把需求完全确定好，在需求评审会中发现的问题，需要产品经理需要在会议之后重新进行优化和总结，然后再与相关人员讨论，必要时可能需要二次评审，所以要预留会后优化产品方案的时间。

会议前的准备
为了确保会议能够顺利的进行，所以在开会之前，我对上面的问题已经有了深刻的了解和研究，再加上之前对产品需求做了比较详细的分析以及对行业、竞品的分析，把会议所需要的资料准备充足，剩下的就是对整个会议流程进行规划，以免开会时演讲缺乏逻辑那就尴尬了。把以前在产品经理社区里看过于需求评审相关的文章都复习了一遍，然后又根据实际情况，把会议的流程及模块用脑图先总结一般，如下图

需求评审会流程
同时为了保证开会的时候大体按流程走，便根据流程制作了一个简单的PPT，PPT的内容不多，只是对模块标题进行展示，保证会议的主线按正确的方向进行下去。同时需要把握一些演讲的技巧，刚好那段时间看了《产品经理那些事儿》，其中讲到一些演讲技巧，在此时就发挥作用了。其中的技巧有：开会前要与与会人员聊聊以增加自己会议中的筹码，然后开会时要站着演讲以增加自己对场面的控制力，还有演讲时最好加点故事案例之类的来进行说明，观众都是喜欢听故事的....

当把这些都印在脑子里之后，会议所需要的准备做好了。

会议前通知
记得在会议的前一天，我会把会议前所需要的资料先发给与会人员，所需要的资料有：

产品原型图
流程图
产品功能列表
PRD
把这些资料先通过邮箱发给与会人员主要是让大家先对产品有个大概的了解，不会因为在当天的会议上因信息量太多而导致难以发现问题。当我把资料发出去之后，一个开发人员了解后问了我一个问题：“这个产品主要是做什么的，我一点都不了解”，这个问题让我迫切地明白需求评审会的重要性。

会议开始
会议是在周五下午3点中举行的，大家也刚从午休中缓过来，精神状态比较好。在会议临开始前的15分钟，我当面提醒了与会人员15分钟后进行需求评审会，以确保大家都能准时参加。然后我就提前到会议室准备了，再一次把整个流程在脑海里过一遍。

15分钟后，大家都陆续上来了，因为在会议室，大家都略显严肃，气氛有点尴尬，与会人员恰好有两位新同事，我便趁大家都就坐了的时候问大家对新同事都认识了吗，然后大家就顺势的做了自我介绍，我从中插些话开开玩笑，大家的表情没那么严肃了，气氛也缓和了很多。

熄灯，打开投影，会议正式开始...

业务介绍
因为这次与会人员大部分都是开发人员，外加两个设计师，一般情况下对公司的主流业务并不是特别熟悉，所以会议开始的第一部分，我向大家用10分钟左右的时间介绍了一下公司的主流业务。

会议流程
公司的主流任务介绍完毕之后，就向大家陈述一下会议的整个流程安排，让大家对整个会议安排有个心理预期。

会议目的
产品规划
开发时间估算
会议总结
会议目的
这是会议的第一部分，会议的目的主要有以下几个：

阐述产品开发目的
确定最终需求和功能
确定功能排期
确定项目的开发周期
先通过说明会议的目的，让与会人员心里面对会议有个明确的方向。

产品规划
产品开发背景与目的
对于产品规划的第一模块，就是产品开发背景的描述，主要是讲当前公司的发展状况、为什么需要开发这款产品以及这款产品给公司能带来什么价值，给市场、用户带来什么价值。

产品所属行业行情
这部分内容，前期的工作十分重要。行业行情实际上也就是行业分析报告。首先我们需要确定目标行业、市场，然后通过第三方调研平台的行业报告、竞品分析等手段确定市场规划、市场发展趋势，然后确定市场的竞争格局、市场的痛点来判断我们是否还有机会进入该市场，并且在什么时机进入该市场。这里通过详细的数据说明分析的准确性，增加内容的说服力。

产品规划
在这个模块中，我们需要向与会人员阐明产品以下几点：

产品定位
目标用户
使用场景
商业模式
此时观察大家，感觉大家不怎么感兴趣。恩，这里的与会人员的性质很明确，都是开发人员...虽然说这些不是他们工作的重点，但是了解这些可以加深对业务逻辑的理解。

需求说明
到这里，开始进入会议的主要内容了，此时会议室还是挺安静的，但这是需求评审会开始“热闹”起来的地方了。这里会把需求列表和功能列表展示出来，通过业务和需求背景，按照需求列表的顺序，先想大家介绍每个需求的背景和用户痛点，然后在对应起功能列表里的功能项。我小心翼翼地把需求一个个过完，但是台下并没有太多的声音。什么鬼，与我印象中的“撕逼”大战不一样！当我把需求列表都讲完了之后，台下的声音开始多了起来，大家都有一两个问题，基本上都是“为什么做这个需求”比较多，不过因为我在此之前对这种问题已经做好的充分的准备，所以大部分我都能即时回答，只有极少部分没有考虑到的就记录下来，会后再讨论。不过讨论的情况并没有想象中激烈，难道是之前是自己想象力修炼技能满格了？并不是，只是事后才发觉，因为与会人员基本上是开发人员，对需求背后的含义不需要深度的理解，他们只是把不懂的地方弄清楚就够了，所以我的回答都能满足他们的期望，所以这部分并没有带来太多的争论。

主要功能线说明
回想起来，这部分才是这个会议的高潮部分。
在前面介绍完产品的背景目的以及需求之后，接下来就是通过交互原型图来展示功能。我是通过产品的主要功能以及模拟用户使用的流程进行功能的介绍与描述。在展示交互原型的时候，屏幕右侧还有每个页面的备注，对一些重要的功能、字段以及交互方式进行详细说明。我们产品有4个主要业务流程线，我在介绍的每一个流程时，台下的“观众”都异常活跃，“这个模块的字段是否有明确的归类？”、“这个页面怎么进入，使用怎样的交互形式？”、“你这个页面设计的请求方式太多，实际实现效果不太好”....这些问题的蜂拥而上，此时我思绪有点乱了，因为问题一下子上来，也开始有点“战争”的感觉了。我先让大家安静一下，然后让有问题的与会人员一个个发表问题，如果可以当场解答的，便会表述清楚，如果难度较大的或者表述内容较多的，则会后再详细说明。

通过几个回合的“战斗”之后，发现的问题也不少，但是在预料范围之内。

功能优先级
上述流程过完之后，我会把之前就安排好了功能优先级展示给大家看，然后想大家阐述自己这样排列优先级的原因，然后咨询大家的意见再权衡怎么优化优先级列表。

开发时间预估
关于开发时间的预估，对于一些有经验的开发人员来说，他们给出的时间相对较准确，经验尚浅的则需要项目经理参与辅助预估。因为这里展示的功能较多，开发们一时之间也没办法预估，所以我提出了一个方案，就是开发小组会后针对每个功能、自己所属的模块进行功能开发时间的精细化预估，然后在填写到云表格中，然后由我这边再结合实际情况给出一个合理的开发周期。

会议总结
经过两小时的讨论和演讲，大家对产品已经有了明确的认识，需求也十分的明确，然后我便汇总整个会议讨论和明确的需求、结果向大家再次阐述一遍，再次明确产品目标，并号召大家往目标奋斗。

会后把问题的解决方案和会议的最终结果通过邮件的方式发送给大家，大家确定没有问题了，这样整个项目的需求就明确了。

总结
这是第一次完完全全有自己组织并主持的一个需求评审会，虽然有一定工作量，但是不可否认的是有一定的收获，对自身的组织能力、前期需求的分析能力、演讲能力与执行能力都有一定的提升。不过这次举办的需求评审会与大公司的有着明显的差异，就是我们这次会议是已经明确了团队成员，不需要去和上级领导争取资源，如果需要和争取资源的话，估计会议就没那么顺利了。

需求评审会前一定要做好准备工作，所需材料都准备完善，这样才能让会议顺利进行。

作者：kimson
链接：https://www.jianshu.com/p/e11d0ce9fa3e
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

关于「需求评审会」的个人目标

产品经理需要明确自己在这次「需求评审会」的个人目标是什么。这个目标是制定给自己的，而非给团队制定的，说白了就是通过「需求评审会」达到什么效果。

比如：让开发团队、测试团队的同学能认同自己本次迭代的产品方案，这是一个非常务实的目标。

比如：让开发团队、测试团队知道自己和设计师在产品策划阶段尽了多大的努力和尝试，这是一个展示设计团队的目标。

比如：向开发团队、测试团队展示自己严谨的思维逻辑和出色的产品设计能力，这是一个偏个人的目标。

虽然出发点不同，但这些都算是一个前置条件。

关于「需求评审会」的原则

一、「不要试图将自己的想法移植到别人的大脑中」

首先产品经理需要明确一点，我们召开「需求评审会」不是为了「移植想法」到别人的大脑中，而是通过「引导」和「讨论」磨合得出大家都认可的产品方案。

我参加过不少「需求评审会」，产品经理们都是抱着「移植想法」、「说服你」的态度在进行需求宣讲，产品经理绞尽脑汁把自己的想法「移植」到开发、测试同学的大脑中，可想而知这个过程是多么的痛苦;双方又为了「说服」彼此，必然会找出自己经历过的项目中比较极端的案例来支撑自己观点，可想而知这个过程又是多么的火爆。

其实产品经理和开发团队、测试团队应该是一个「配合」的过程，也就是说在产品经理的基础方案上，不断的优化和调整的过程，如果开发同学有更好的想法，产品经理就应该去采纳。可现实情况是，很多产品经理碍于「面子」问题，总觉得必须听我的，别人说的「对」或者「不对」我都不管，一直在单方面的坚持自己。这就很没必要了，对吧?

二、「不要在不同观点上过于纠结，浪费时间」

我们本着「求同存异」的观点来进行问题的「讨论」，也就是说大方向相同，小细节可以有不同观点，并且鼓励大家表达出自己的观点，产品经理的「开放」心态是很重要的。

在整个需求评审的过程中一定有不少大大小小的问题，对于彼此认可的地方我们确认完毕后快速带过，对于彼此不认可的地方我们不再纠结，如果讨论了5分钟以上仍然没有结论，产品经理就记下这个问题，先进行后面的内容，最后再掉回头来讨论之前有争议的问题。

我经历过一场很煎熬的「需求评审会」，从下午13：30一直持续到19：00左右仍未结束，原因就是由于产品经理没有控制好问题讨论的时间，以及细节讨论的颗粒度，导致需求评审的战线拖的很长，而且效果非常一般，大家苦不堪言。

三、「要给所有人明确本次需求评审会的背景及目标」

很多产品经理在「需求评审会」刚开始的时候就讲交互流程，功能feature，这是大忌。大家都还没有摸清状况呢，怎么会进到你的流程中呢?又怎么能找到里面的细节问题呢?又怎么会认可你的方案呢?

所以产品经理在最开始需要给大家「调频」，让大家都到一个频道上来。其实就是需要产品经理在「需求评审会」开始后先别急着讲交互和功能，而是给大家介绍一下我们这个版本要「做什么」，「为什么做」，「有什么价值」这三个方面(其实也是做产品规划时需要考虑的)，这也就是所谓的背景和目标。

这里其实也符合「金字塔原理」中的背景→矛盾→问题-解决办法的思维模式，我在曾经的文章中有做详细的描述。你可以点击查看：产品经理必备技能：金字塔思维。

四、「不管现场状况多么恶劣，产品经理不可露怯，不可红脸，不可出言不逊」

在「需求评审会」的现场难免会遇到各种意外的状况，不管发生了任何事，产品经理需要时刻谨记两个字「隐忍」，不管任何观点都要冷静客观的表达出来，千万不要没有控制好自己，把某些观点加上了自己的主观色彩，这样就把一件简单的事变的复杂了。

关于「需求评审」的三个阶段

第一阶段：「需求评审会」前

产品经理在这个阶段需要注意几点。

①提前3天与开发、测试、设计等团队沟通协调时间，确保关键角色都有时间可以参加，最后确定好「需求评审会」的时间安排，订好会议室，发出会议邀请，并拉好RTX工作讨论组周知大家。简单来讲就是：哪个版本、哪些人、在哪、开会。

②提前2天将「产品交互原型」、「产品需求文档」通过邮件及在RTX讨论组发文件的形式发送给与会成员，并严格要求与会成员必须抽时间查阅相关文档，并提出自己的问题。

③提前1天收集大家对于本次评审内容的问题，汇总好问题后逐一解答，以邮件的形式统一回复给大家。根据问题修改文档，最后再次提醒大家「需求评审会」的时间、地点。

这也就是「需求评审会」的黄金72小时。我们要利用好这72小时，提前做好准备，将会大大提高「需求评审会」的效率，而且可以有效降低产品经理被误伤和蹂躏的概率。

第二阶段：「需求评审会」中

「需求评审会」说白了就是一次面对面的「讨论会」，所以「中」这个环节是重中之重，不可怠慢。因为之前我们已经做了充足的准备，所以要放松一点，当成自己的「脱口秀」演讲就好了。

①告诉大家我们这个迭代要为用户讲一个什么故事(做什么)，这个故事是怎么来的(为什么做)，用户看完这个故事能得到什么(有什么价值)。这也是一个标准的背景和目标陈述的方式，切忌上来直接讲交互、讲功能，同时还要回想一下自己对于这次「需求评审会」的个人目标是什么。

②好了，我们进入到真正的主题了，开始讲解这个迭代的功能点、产品交互原型、产品需求文档，每个功能点逐一讲解，事无巨细，不要有任何遗漏。讲解的顺序一定是先从功能点开始，然后讲原型，最后才是需求文档，一个由点及面的过程。

这时候我们普遍会遇到这几种状况。

第一种：你认可我的方案，这种是最理想的状况，也是产品经理最期望的状况，撸起袖子开工就好了。

第二种：你认可我的方案，但你有更好的想法，这也是一个非常和谐的状况，整个屏幕满满的充满了爱，优化细节，只会让产品逻辑和策略变的更加完整，这种状况甚至要好过第一种。

第三种：你不认可我的方案，你有更好的想法，OK，我们在这个状况下先讨论下关于背景和目标，这些你是否认可呢?如果认可目标，那我们来听下你的方案，如果确实可行，我来调整，然后撸起袖子开干。如果不认可目标，我需要不断的说服你(这里需要控制时间)，让你认可这个目标，然后再撸起袖子开干，只不过这种很少见到。

第四种：你不认可我的方案，但你也没有更好的想法，这个…你确定这个人不是无间道吗?这种情况也非常少见。

③经历了暴风雨后，我们已经可以看到了一些曙光了，稍安勿躁，胜利是属于我们的。这时候「需求评审会」其实已经接近尾声了，只是要提一句，关于细节讨论颗粒度的问题，讨论双方必须站在同一个层面讨论，已经下结论的地方不再重复，只讨论同一个纬度的问题，不能我还在跟你讲功能需求，你已经在跟我讨论代码的指针应该放在哪里。

噢，对了，所有讨论的问题记得都写在本子上。

第三阶段：「需求评审会」后

①会后及时输出会议纪要，罗列清楚问题或者争议点，已经形成结论的地方就不再赘述，待确定的问题继续找相关负责人进行讨论，直到得出最后的结论。

②最后的最后，一封华丽丽的邮件周知给全部与会成员，邮件内容包括需求评审的争议点和结论，最最最重要的是要将更新后的需求文档发出来给大家。

③最后的最后的最后，督促开发、测试同学评估开发、测试周期，给出时间节点。

以上，一次费心费力的「需求评审会」终于完成了，从开始组织到最后的确认邮件，无一不饱含产品经理的汗水和泪水，但是一次好的「需求评审会」是会为产品的健康成长增加助力的，所以再多的付出都是值得的。

从目前实践来看，产品经理在「需求评审会」上最好的开场就是自我总结，并且送上酸奶。一般比较复杂的迭代，在开场的时候我都会先总结一下自己在上个版本中作为产品经理，自己的过失有哪些，不要琢磨这么做是不是丢面儿了，其实开发和测试同学也都非常关心产品，所以想知道产品层面决策有哪些是对哪些是错。而这种态度，是非常能够得到他们认可的。我们不是经常说，产品如人品吗?就是这个意思。

本文链接: http://www.yixieshi.com/22080.html (转载请保留)

作者：四姑娘山的稻城
链接：https://www.jianshu.com/p/a2c0b1aa1772
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

产品经理组织的「需求评审会」类似多方会谈，与会人员很容易进入角色后产生「自主」情绪，形成正反两派甚至是多派，最后由「讨论」演变为「辩论」，有点类似「奇葩说」的形式。产品经理在这个「辩论」的过程中，不断展示自己的观点，希望获得更多的认可，可不少产品经理都在这个「辩论」的过程中把自己搞的伤痕累累，十分狼狈。
关于「需求评审会」的个人目标
产品经理需要明确自己在这次「需求评审会」的个人目标是什么。这个目标是制定给自己的，而非给团队制定的，说白了就是通过「需求评审会」达到什么效果。
比如：让开发团队、测试团队的同学能认同自己本次迭代的产品方案，这是一个非常务实的目标。
比如：让开发团队、测试团队知道自己和设计师在产品策划阶段尽了多大的努力和尝试，这是一个展示设计团队的目标。
比如：向开发团队、测试团队展示自己严谨的思维逻辑和出色的产品设计能力，这是一个偏个人的目标。
虽然出发点不同，但这些都算是一个前置条件。
关于「需求评审会」的原则
一、「不要试图将自己的想法移植到别人的大脑中」
首先产品经理需要明确一点，我们召开「需求评审会」不是为了「移植想法」到别人的大脑中，而是通过「引导」和「讨论」磨合得出大家都认可的产品方案。
我参加过不少「需求评审会」，产品经理们都是抱着「移植想法」、「说服你」的态度在进行需求宣讲，产品经理绞尽脑汁把自己的想法「移植」到开发、测试同学的大脑中，可想而知这个过程是多么的痛苦；双方又为了「说服」彼此，必然会找出自己经历过的项目中比较极端的案例来支撑自己观点，可想而知这个过程又是多么的火爆。
其实产品经理和开发团队、测试团队应该是一个「配合」的过程，也就是说在产品经理的基础方案上，不断的优化和调整的过程，如果开发同学有更好的想法，产品经理就应该去采纳。可现实情况是，很多产品经理碍于「面子」问题，总觉得必须听我的，别人说的「对」或者「不对」我都不管，一直在单方面的坚持自己。这就很没必要了，对吧？
二、「不要在不同观点上过于纠结，浪费时间」
我们本着「求同存异」的观点来进行问题的「讨论」，也就是说大方向相同，小细节可以有不同观点，并且鼓励大家表达出自己的观点，产品经理的「开放」心态是很重要的。
在整个需求评审的过程中一定有不少大大小小的问题，对于彼此认可的地方我们确认完毕后快速带过，对于彼此不认可的地方我们不再纠结，如果讨论了5分钟以上仍然没有结论，产品经理就记下这个问题，先进行后面的内容，最后再掉回头来讨论之前有争议的问题。
我经历过一场很煎熬的「需求评审会」，从下午13：30一直持续到19：00左右仍未结束，原因就是由于产品经理没有控制好问题讨论的时间，以及细节讨论的颗粒度，导致需求评审的战线拖的很长，而且效果非常一般，大家苦不堪言。
三、「要给所有人明确本次需求评审会的背景及目标」
很多产品经理在「需求评审会」刚开始的时候就讲交互流程，功能feature，这是大忌。大家都还没有摸清状况呢，怎么会进到你的流程中呢？又怎么能找到里面的细节问题呢？又怎么会认可你的方案呢？
所以产品经理在最开始需要给大家「调频」，让大家都到一个频道上来。其实就是需要产品经理在「需求评审会」开始后先别急着讲交互和功能，而是给大家介绍一下我们这个版本要「做什么」，「为什么做」，「有什么价值」这三个方面（其实也是做产品规划时需要考虑的），这也就是所谓的背景和目标。
这里其实也符合「金字塔原理」中的背景→矛盾→问题-解决办法的思维模式，我在曾经的文章中有做详细的描述。你可以点击查看：产品经理必备技能：金字塔思维。
四、「不管现场状况多么恶劣，产品经理不可露怯，不可红脸，不可出言不逊」
在「需求评审会」的现场难免会遇到各种意外的状况，不管发生了任何事，产品经理需要时刻谨记两个字「隐忍」，不管任何观点都要冷静客观的表达出来，千万不要没有控制好自己，把某些观点加上了自己的主观色彩，这样就把一件简单的事变的复杂了。
关于「需求评审」的三个阶段
第一阶段：「需求评审会」前
产品经理在这个阶段需要注意几点。
①提前3天与开发、测试、设计等团队沟通协调时间，确保关键角色都有时间可以参加，最后确定好「需求评审会」的时间安排，订好会议室，发出会议邀请，并拉好RTX工作讨论组周知大家。简单来讲就是：哪个版本、哪些人、在哪、开会。
②提前2天将「产品交互原型」、「产品需求文档」通过邮件及在RTX讨论组发文件的形式发送给与会成员，并严格要求与会成员必须抽时间查阅相关文档，并提出自己的问题。
③提前1天收集大家对于本次评审内容的问题，汇总好问题后逐一解答，以邮件的形式统一回复给大家。根据问题修改文档，最后再次提醒大家「需求评审会」的时间、地点。
这也就是「需求评审会」的黄金72小时。我们要利用好这72小时，提前做好准备，将会大大提高「需求评审会」的效率，而且可以有效降低产品经理被误伤和蹂躏的概率。
第二阶段：「需求评审会」中
「需求评审会」说白了就是一次面对面的「讨论会」，所以「中」这个环节是重中之重，不可怠慢。因为之前我们已经做了充足的准备，所以要放松一点，当成自己的「脱口秀」演讲就好了。
①告诉大家我们这个迭代要为用户讲一个什么故事（做什么），这个故事是怎么来的（为什么做），用户看完这个故事能得到什么（有什么价值）。这也是一个标准的背景和目标陈述的方式，切忌上来直接讲交互、讲功能，同时还要回想一下自己对于这次「需求评审会」的个人目标是什么。
②好了，我们进入到真正的主题了，开始讲解这个迭代的功能点、产品交互原型、产品需求文档，每个功能点逐一讲解，事无巨细，不要有任何遗漏。讲解的顺序一定是先从功能点开始，然后讲原型，最后才是需求文档，一个由点及面的过程。
这时候我们普遍会遇到这几种状况。
第一种：你认可我的方案，这种是最理想的状况，也是产品经理最期望的状况，撸起袖子开工就好了。
第二种：你认可我的方案，但你有更好的想法，这也是一个非常和谐的状况，整个屏幕满满的充满了爱，优化细节，只会让产品逻辑和策略变的更加完整，这种状况甚至要好过第一种。
第三种：你不认可我的方案，你有更好的想法，OK，我们在这个状况下先讨论下关于背景和目标，这些你是否认可呢？如果认可目标，那我们来听下你的方案，如果确实可行，我来调整，然后撸起袖子开干。如果不认可目标，我需要不断的说服你（这里需要控制时间），让你认可这个目标，然后再撸起袖子开干，只不过这种很少见到。
第四种：你不认可我的方案，但你也没有更好的想法，这个…你确定这个人不是无间道吗？这种情况也非常少见。
③经历了暴风雨后，我们已经可以看到了一些曙光了，稍安勿躁，胜利是属于我们的。这时候「需求评审会」其实已经接近尾声了，只是要提一句，关于细节讨论颗粒度的问题，讨论双方必须站在同一个层面讨论，已经下结论的地方不再重复，只讨论同一个纬度的问题，不能我还在跟你讲功能需求，你已经在跟我讨论代码的指针应该放在哪里。
噢，对了，所有讨论的问题记得都写在本子上。
第三阶段：「需求评审会」后
①会后及时输出会议纪要，罗列清楚问题或者争议点，已经形成结论的地方就不再赘述，待确定的问题继续找相关负责人进行讨论，直到得出最后的结论。
②最后的最后，一封华丽丽的邮件周知给全部与会成员，邮件内容包括需求评审的争议点和结论，最最最重要的是要将更新后的需求文档发出来给大家。
③最后的最后的最后，督促开发、测试同学评估开发、测试周期，给出时间节点。
以上，一次费心费力的「需求评审会」终于完成了，从开始组织到最后的确认邮件，无一不饱含产品经理的汗水和泪水，但是一次好的「需求评审会」是会为产品的健康成长增加助力的，所以再多的付出都是值得的。
从目前实践来看，产品经理在「需求评审会」上最好的开场就是自我总结，并且送上酸奶。一般比较复杂的迭代，在开场的时候我都会先总结一下自己在上个版本中作为产品经理，自己的过失有哪些，不要琢磨这么做是不是丢面儿了，其实开发和测试同学也都非常关心产品，所以想知道产品层面决策有哪些是对哪些是错。而这种态度，是非常能够得到他们认可的。我们不是经常说，产品如人品吗？就是这个意思。
题图：来自爆裂鼓手，一部很燃的电影。

本文由@PMColour 授权发布
转载请注明来源于产品100并附带本文链接

作者：游兆
链接：https://www.jianshu.com/p/7f9bcc376a86
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

关于「需求评审会」的个人目标

比如：让开发团队、测试团队的同学能认同自己本次迭代的产品方案，这是一个非常务实的目标。

比如：让开发团队、测试团队知道自己和设计师在产品策划阶段尽了多大的努力和尝试，这是一个展示设计团队的目标。

比如：向开发团队、测试团队展示自己严谨的思维逻辑和出色的产品设计能力，这是一个偏个人的目标。

虽然出发点不同，但这些都算是一个前置条件。

关于「需求评审会」的原则

一、「不要试图将自己的想法移植到别人的大脑中」

我参加过不少「需求评审会」，产品经理们都是抱着「移植想法」、「说服你」的态度在进行需求宣讲，产品经理绞尽脑汁把自己的想法「移植」到开发、测试同学的大脑中，可想而知这个过程是多么的痛苦；双方又为了「说服」彼此，必然会找出自己经历过的项目中比较极端的案例来支撑自己观点，可想而知这个过程又是多么的火爆。

二、「不要在不同观点上过于纠结，浪费时间」

三、「要给所有人明确本次需求评审会的背景及目标」

很多产品经理在「需求评审会」刚开始的时候就讲交互流程，功能feature，这是大忌。大家都还没有摸清状况呢，怎么会进到你的流程中呢？又怎么能找到里面的细节问题呢？又怎么会认可你的方案呢？

所以产品经理在最开始需要给大家「调频」，让大家都到一个频道上来。其实就是需要产品经理在「需求评审会」开始后先别急着讲交互和功能，而是给大家介绍一下我们这个版本要「做什么」，「为什么做」，「有什么价值」这三个方面（其实也是做产品规划时需要考虑的），这也就是所谓的背景和目标。

四、「不管现场状况多么恶劣，产品经理不可露怯，不可红脸，不可出言不逊」

关于「需求评审」的三个阶段

第一阶段：「需求评审会」前

产品经理在这个阶段需要注意几点。

提前3天与开发、测试、设计等团队沟通协调时间，确保关键角色都有时间可以参加，最后确定好「需求评审会」的时间安排，订好会议室，发出会议邀请，并拉好RTX工作讨论组周知大家。简单来讲就是：哪个版本、哪些人、在哪、开会。

提前2天将「产品交互原型」、「产品需求文档」通过邮件及在RTX讨论组发文件的形式发送给与会成员，并严格要求与会成员必须抽时间查阅相关文档，并提出自己的问题。

提前1天收集大家对于本次评审内容的问题，汇总好问题后逐一解答，以邮件的形式统一回复给大家。根据问题修改文档，最后再次提醒大家「需求评审会」的时间、地点。

第二阶段：「需求评审会」中

告诉大家我们这个迭代要为用户讲一个什么故事（做什么），这个故事是怎么来的（为什么做），用户看完这个故事能得到什么（有什么价值）。这也是一个标准的背景和目标陈述的方式，切忌上来直接讲交互、讲功能，同时还要回想一下自己对于这次「需求评审会」的个人目标是什么。

好了，我们进入到真正的主题了，开始讲解这个迭代的功能点、产品交互原型、产品需求文档，每个功能点逐一讲解，事无巨细，不要有任何遗漏。讲解的顺序一定是先从功能点开始，然后讲原型，最后才是需求文档，一个由点及面的过程。

这时候我们普遍会遇到这几种状况。

第一种：你认可我的方案，这种是最理想的状况，也是产品经理最期望的状况，撸起袖子开工就好了。

第三种：你不认可我的方案，你有更好的想法，OK，我们在这个状况下先讨论下关于背景和目标，这些你是否认可呢？如果认可目标，那我们来听下你的方案，如果确实可行，我来调整，然后撸起袖子开干。如果不认可目标，我需要不断的说服你（这里需要控制时间），让你认可这个目标，然后再撸起袖子开干，只不过这种很少见到。

第四种：你不认可我的方案，但你也没有更好的想法，这个…你确定这个人不是无间道吗？这种情况也非常少见。