对于产品新人而言，日常最头疼的会议就是需求评审。

在做产品的这几年，笔者开过上百场需求评审会，曾经被研发在会上怼哭过一次，也遇到过研发和产品大吵半小时、最终有一方摔门而出的情况。

但这都是刚开始一段时间的惨案了，那时一想到要一个人面对近10个研发就战战兢兢瑟瑟发抖。而如今，几乎每一次的需求评审都变得相当顺利，时间和结果都能达到预期，甚至都不需要太多额外的准备。

很多产品新人担心自己怼不过研发，但事实上，「怼」这个词就把自己和研发置于了对立面。很多需求评审中的争吵和争论在会后看来是没必要的，大多都源自于信息差和沟通能力的问题。

因此，今天想和大家分享下如何做好需求评审、不再怕被怼。本文将从产品、研发和团队等多个角度来谈，以下为目录，希望大家能提前在心里有一个框架：

• 需求评审的意义到底在哪？
• 一次标准需求评审的阶段和流程
• 如何很好地进行需求评审的会议管理
• 需求评审会上，前端、后端和测试分别都关注什么？
• 3个压箱底的需求评审技巧！

一、需求评审的意义到底在哪？

直接用一堆正确的话来告诉大家需求评审的意义，可能并不会有太深刻的体会。所以我们不妨另辟蹊径，一起来试想一下：如果一次迭代没有任何需求评审、研发完全按照产品需求文档进行开发，会有什么样的结果？

看起来貌似节约了大量的沟通时间，也避免了团队内的争论和争吵，但实际开工之后呢？

一方面，在开发过程中，研发发现出现了部分需求遗漏、有些看似一句话的需求实现起来成本反而非常高、有些需求未考虑到数据修复、数据查询量过载的风险等，这时候，经验丰富一些的研发会主动找到产品进行讨论并要求进行需求变更，而另外一些研发新人可能就埋头照做了，到真正上线后才发现实际有一大堆问题，甚至可能造成不可挽回的损失。

另一方面，产品上线之后，销售和售后部门的同事发现需求是满足了，但却一点都没法用，这时候，客户也接二连三的反馈系统怎么越改越难用了，根本没法解决他们的问题！

这样看来，省去了需求评审之后，产品经理的工作虽然「单纯」了很多，但却很难兼顾全局，也无形中将所有的风险和压力担在了自己一个人身上，浪费了团队的智慧和经验。

因此，一场好的需求评审能够帮助我们很好地管理需求方（业务/销售/售后部门）的预期，同时也能通过一次次评审和纠偏，帮助整个产研团队就需求场景和优先级达成一致，及早进行风险评估及查缺补漏，有效提升团队开发效率和产品可用性。

那么，接下来我们就来看看一次完整的需求评审是怎样的？

需求评审的本质分为2个维度：其内容是用于需求评审，其性质则是有组织的连续性会议。因此我们把需求评审拆解为：需求评审+会，即需求评审流程和会议管理2个方面来讲。

二、需求评审流程

不同公司不同业务不同客户的需求评审流程都有所不同，有些只有1次，有些要开3、4次。但是，无论开几次，其本质都是在主要和2类人开会：需求方和研发。

B端产品经理的需求方一般是老板、甲方爸爸、业务部门、销售部门和售后部门等，无论你们公司具体业务如何，需求评审的第一步都是要和需求方确定5W1H中的为什么做（why）、什么时候做（when）以及大致做什么（what）。

第二步则是先和研发部门同步前面讨论好的why、when和what，再和大家一起讨论具体做什么（what）、谁来做（who）和怎么做（how）。

那么，下面提供一个较为通用的标准评审模板，分为范围评审、低保真评审和方案评审3次。

01 范围评审

评审目标：明确需求范围，难点在于明确不做什么

文档准备：内容需要包含需求场景、需求清单、客户调研报告、竞品调研报告等

参会人员：产品、需求方（业务、销售、售后、老板等）

评审产出：达成一致的需求范围清单

（Axure页面列表）

（通过用例图描述需求场景）

02 低保真评审

评审目标：初步明确大致的样式交互及业务逻辑方案，难点在于做好需求和成本间的衡量

文档准备：低保真稿（包含核心业务逻辑说明及核心页面交互）

参会人员：产品、需求方、研发（前端、后端）、UI/UE

评审产出：就核心业务逻辑及核心页面交互达成一致

（低保真稿）

03 方案评审（或称高保真评审）

评审目标：关注粒度更细的方案细节，难点在于逻辑覆盖的全面程度

文档准备：高保真稿（包含全部业务逻辑说明和页面样式交互说明），是可以直接开始研发的终稿

参会人员：产品、研发（前端、测试）、UI/UE

评审产出：理想状态下，就全部业务逻辑和页面交互达成一致

以上就是较为常见的3次需求评审流程。但是需求评审只是一个里程碑，产品经理大部分的时间都花在每两次会议之间的文档准备中，要不是在和需求方掰头，要不就是在和研发掰头。

三、如何很好地进行会议管理？

第二部分就来看看需求评审相关的会议管理内容。

大部分人在做产品经理之前，极少有会议组织的机会和经验，更多都是在被动参会。而一旦入行产品，就需要开始频繁组织各种各样的会议，而需求评审就是其中最不可避免的一类会议。

曾经有同事分享过罗伯特议事规则，也有一类专门做会议组织研究的咨询公司。由此可见，会议组织其实是一门非常高深的学问。

《罗伯特议事规则》（Robert's Rules of Order，RONR）

是一本由美国将领亨利·马丁·罗伯特于1876年出版的手册，搜集并改编美国国会的议事程序，使之普及于美国民间组织，也是目前美国最广为使用的议事规范。

作品内容非常详细，包罗万象，有专门讲主持会议的主席的规则，有针对会议秘书的规则，当然大量是有关普通与会者的规则，有针对不同意见的提出和表达的规则，有关辩论的规则，还有非常重要的、不同情况下的表决规则。

但这里不展开来讲（笔者自己也没有掌握那么深），就只和大家分享一些较为基础的会议管理方法，只要能够很好地服务于需求评审和日常工作即可。

从时间角度来看，一场会议可以分为会前、会中和会后3个阶段。那么每个阶段我们都需要做什么呢？

01 会前准备

• 准备会议资料：需求评审则需要按照评审内容提前准备好文档，并根据实际情况提醒大家提前阅读并做好问题整理
• 创建会议：尽量提前2-3天拉会，给参会人留有充足时间调整其他日程和准备本次会议；并在日程中提前告知会议目标、会议资料地址等信息

02 会中把控

需求评审过程中，最主要的3个点就在于节奏把控、争论处理和情绪管理。

节奏把控

一般而言，产品是会议主持人，那么自然就担当着会议节奏把控和主持的角色。当角色众多时，其实是比较容易出现讨论内容溢出的问题，大家一聊开就上头了，结果导致会议开了足足几个小时都还没有产生定论。

所以，需求评审中产品要做的第一件事就是把控整个会议的节奏，既要及时把聊得起兴的大家拉回评审中，还要尽量按照参会人的精力去做好节奏的规划，让整场会议高效而轻松。

如果你刚刚入门，还不知道怎样能够很好地把控节奏，那么可以尝试提前根据评审内容进行时间和会议内容规划。

例如，前10分钟同步信息和背景，中间10分钟讲权限业务逻辑模块，然后预留5分钟时间讨论，接下来继续讲权限配置的页面交互，再预留5分钟时间讨论等。全程尽量严格按照自己的议程来，看看实际情况和自己规划是否相符，如果出现不符合，那么问题出在哪里？后续怎么进行改进？

多来几次，你就会有不错的节奏把控能力了，甚至于整个会议实际开完的时间和你预期的时间相差不了几分钟。

争论处理和情绪管理

需求评审中出现争吵的原因常见于以下几点：

• 表达或理解不准确，导致出现了信息差
• 情绪管理不佳，一上头就开始对人不对事
• 会前就需求沟通不足，导致会上出现较大分歧

既然是团队中很多角色坐一起评审，每个角色的视角和关注点不同，那么自然会出现很多讨论点甚至于争论点。那么，当会上有2个人产生了争论时（通常是产品经理和其他人），怎样处理才比较妥善呢？

首先最重要的一点，做好自己的情绪管理。

在一场需求评审过程中，产品经理既是会议主持人，又是参会人。如果你自己都乱了，那么整个会就尬在那里没人收场了。所以，一个成熟的产品经理需要尽量顾全大局、摆正自己的心态，尽量以结果为导向、对事不对人。

其次，换位思考，尝试先根据对方表达的看法去梳理他的思路，然后用自己的理解复述一遍，看对方是否认可你的理解。接下来，再根据你的理解去进行判断并阐述自己的观点，看是否能够得到对方的认可。

最后，如果实在在会上没法沟通，那就告知大家：自己会先记录下待讨论的问题，会后再进行讨论，后续的议程继续。「下来再讨论」真的是一句解决会上冲突的万能金句。

03 会后同步和跟进

会议结束之后，确实可以长舒一口气，开始准备下一阶段的工作了，但注意：会后还是需要做好会议纪要、会议同步和后续问题的跟进。

笔者的需求评审会议纪要一般分为3部分：待讨论、待完善、已确认。

• 待讨论：指会上的遗留问题
• 待完善：指会上确认要改的问题，后续自己要完善在文档中
• 已确认：指会上讨论得出要做/不做的结论的点

整理好会议纪要后，及时将内容同步好发给参会同事，如果后续还有待讨论的问题，则与相关人员定一个讨论的待办，避免大家忘记。

这里其实想分享一个笔者和UI小姐姐之间蛮有意思的小故事。

低保真评审时，我们还会顺路确认好UI出图的范围。因为大多数都是产品带电脑投屏，所以自己会顺手记录下UI出图的范围并发给UI小姐姐。本意是为了更好地把控会议后续质量，没想到这个顺手的行为得到了UI小姐姐的肯定。

从这个小故事中，笔者发现，如果日常能够在需求评审中的灰色地带稍微多做一些、多为对方思考一些，那么，整个团队互相之间的信任和协作会越来越nice～😄

四、评审时，前后端/测试都关注什么？

前面和大家分享了完整的需求评审流程，现在就来带大家换个思路，看看前端、后端、测试在一次需求评审中都关注什么？

以下素材来源于笔者和研发同事们的亲身采访：

后端：

• 关注方案可行性的评估，重点在需求逻辑可行性、技术难度、工作量和改动成本上；
• 关注需求逻辑的覆盖度，帮助产品经理做好逻辑的查漏补缺
• 关注研发过程中的实现风险

前端：

• 关注需求场景及业务合理性
• 关注页面样式交互，为产品经理提出一些更合理的样式交互建议
• 关注技术方案和成本评估，尤其关注新页面中交互与已有统一标准组件的评估

测试：

• 关注需求的逻辑性及合理性
• 关注需求描述的准确程度、是否排除二义性等（认为好的需求文档应该是一把标准的尺子）
• 关注整个迭代的质量风险及进度，保证交付的稳定性

从上面的回答中能够很明显的看出不同角色看待需求的视角。当我们要将需求讲给不同的人听时，就要提前站在他们的视角和关注点去思考问题，获得更多沟通的前提信息，从而更顺畅地进行沟通。

五、3个压箱底的需求评审技巧！

从被怼到在现场止不住的哭，再到现在可以轻轻松松开玩笑回怼研发，笔者踩了很多坑、也积累了一些经验。所以，最后就和大家分享3个压箱底的需求评审技巧！

01 先零售沟通，再批发沟通

此处标题来自邱岳《产品训练营》中的内容，指我们在做需求评审的时候，不能把各式各样的问题全部都堆到1-2h的需求评审会上来解决，而是应当先和相关人私下进行讨论（零售沟通），取得共识后再和相关角色统一进行讨论（批发沟通）。

因为，一场需求评审中往往会出现来自不同部门的不同岗位和角色，每个人的关注点都有所不同。如果，所有问题都在会上一并讨论，那么不仅容易范围溢出、干扰讨论，也容易耽误他人时间、让听众失去了耐心。

例如，本次迭代中课次和班级的关系到底应该如何设计？班级和课次是1对n还是n对n的关系？这明显是与后端直接相关的问题，那么，在需求评审前，这类问题就需要提前与后端同学沟通确认好，会上只讨论大家公共关注和需要共同确认的问题。

这样一来，整个会议中大部分时间都在做同步，小部分时间在讨论一些公共问题及小问题，整个会议的效率会得到极大的提升。

02 识别并搞定关键人

项目管理中有一类管理叫做「干系人管理」，指的是我们需要识别项目中的干系人stakeholders，并对他们进行一定的管理。

而我们则可以把需求评审当作一次小型的项目，项目如果要顺利推进，就需要对其中的干系人做好管理。而干系人中，又可以根据话语权及意见影响程度分为关键人和追随者，用一句互联网黑话来形容就是找到关系人中的「抓手」人物。

因为，需求评审中不仅角色众多，人员也很复杂，很难兼顾和满足每一个人的想法。因此，在大方向上，我们就需要提前去搞定关键人，因为他们拥有更多的视野和做决策的信息，某种程度上，也是意见领袖。

如果你的想法和大部分人都不一致，那可以先尝试和关键人进行沟通。在取得关键人认可后，再去推进那些想法摇摆不定或者没有太多主观想法的人，整个过程相对就会顺利一些。

03 适当放权，避免太过独断

不知道大家有没有做过DISC性格测试，笔者身边大多数产品经理都是D型居多，即支配型/控制者Dominance。

D型行为风格的关键词是：积极进取、争强好胜、强势、爱追根究底、直截了当、主动的开拓者、坚持意见、自信和直率。

但是这类人也往往具有以下这些缺点：

不知道你有没有躺枪，D型人格的产品经理在需求评审中一些问题的讨论上难免会有些过于强势。当然，大家都知道天才产品经理乔布斯就是一个极度强势和独断专行的人，但我们大部分人都难以达到那样的高度，如果真的像乔帮主那样处事，可能最后就只能被迫做一个全栈产品了吧。

因此，在需求评审中我们需要对自己的决策做出一些取舍。大方向上一定要坚持自己的想法和意见，而一些优先级低的需求和细节可以适当放权，给予团队一些发挥空间，这也算能够坚持自我想法的一种迂回之策吧。

综上，笔者从价值、需求评审流程、会议管理、研发视角和实用技巧这5个方面给大家分享了一份较为全面的需求评审指南。从战战兢兢到相对游刃有余，经历了上百次的磨练。

当然，有人可能不屑于去认真对待需求评审，认为这是小题大作，但笔者一直是非常欣赏有好的工作习惯和基础扎实的人。越日常的工作，越能日积月累地沉淀出一个人认真做事的能力和态度，而认真和踏实的人必将拥有源源不断的潜力和空间。

---

END