编辑导语：对产品经理来说，需求评审是一个必须经历的过程。只要工作还在进行，需求还在不断产生，需求评审就要存在。如何高效完成需求评审？这个问题需要在一次次会议中总结经验，也需要用点“小心思”。

开会是产品经理工作中最常见的事情了，比如需求讨论、方案评审、用例评审、项目复盘等等。当你经历了各种会议，相信你一定有所感触。

有的会议高效快捷，有的会议却让人失望，不仅会议频频延时、跑题、还充斥着会而不议、议而不决、决而不行……正确高效的开会是执行能力、表达能力的直观体现，也是职场人的必修课。如何把会议开好却不是件容易的事，需要我们花点小心思~

本文以需求评审会为例，通过会前组织、会中讨论、会后跟进分别来讲解各环节的注意事项。

一、请正视需求评审

当产品经理将需求转化成PRD文档输出后，眼见着就要进入研发阶段了，但是在交付前还需要再把把关。需求评审是向相关方讲解需求解决方案的过程，也是寻找方案漏洞和获取多方认可的过程。

评审会议需要完成3个小任务：

1. 描述需求场景：让相关人员了解需求具体的应用场景，以及需求实现目标和预期获取到的价值是什么。
2. 讲解实现方法：阐明解决方案的功能模块、实现逻辑、功能操作等内容，需要研发等人员达成共识。
3. 确认工时排期：和下游确认对应工作的具体任务和交付时间。

涉及范围较广的需求解决方案一般会经过多轮评审，毕竟经过多次风雨洗礼的方案才会更加“完美”。一稿过的方案除了个人需要准备充分和专业过硬，也需要团队配合度+1。

当我们了解了需求评审的意义和目的，接下来看看在会议中我们应该怎么做。

二、会前：准备你的武器

相信大家都有组织过会议的经验，会前准备工作并不复杂，但是随着会议涉及的部门和人员增多，会前协调工作就显得十分重要。

事先准备没有做好，会议基本就垮了……先看个案例，再看下会前准备事项。最近参加过最离谱的会议是ZQ集团召开的跨组织会议，会与方包含ZQ集团软件部和项目相关的5家供应商公司。

通知参会时主题是“LW工厂仓储软件对接会议”，会上沟通的却是业务实施流程相关内容，完全的文不对题。耗时一天，几无收获，造成项目进程暂停和多方资源的浪费。

大家都很忙，所以会议主题、议题、要达成的结果都需要明确并提前告知。以上述例子为戒，受影响的不仅是进度和资源，也会影响组织人员的人品值。

如果人品值的分数过低，影响的不仅是会议组织，其他工作也很难在团队内开展。

需求评审会议用到的需求文档、原型等资料需要提前准备并整理完成。会上不能只凭一张嘴，其他让大家会上自己意会。

人员和时间是会议的基本要素，只有确认好后才能发出会议邀请。

• 与会人员：需求评审的人员一般包含UI、研发（前后端、移动端）、测试、运营，根据需求涉及的范围，其他相关人员也需要参会。
• 会议时间：随着人员增多，每个人都有自己的事情，这时时间就较难协调。我们先和核心干系人确认出席时间，再协调其他人员时间。

会议邀请一般会通过邮件和微信进行分别通知。邮件通知正式且便于后续事件追溯，但关注度不够。所以邮件通知后，会在微信上再次提醒干系人。

1. 邮件会议邀请注意附上会议资料并对重点标注说明，好让会与人员提前了解信息，如何编写不在此展开。
2. 会议当天或会议开始前1小时再次微信提醒相关与会人员，避免忙于其他事情导致忘记参会。

会议通知前，产品经理先和核心干系人沟通需求评审的事项（如研发对接人），提前消灭大问题，避免会上出现重大事故。

三、会中：注意控制场面

需求评审的场面往往比较激烈，通常大家都会从各自的角度提出各种问题让产品经理来解答。那怎么做才能提高会议的效率和质量，让大家愉快的开个会呢？看过下面的案例，也许就知道该这么做了。

在某次需求评审会上，PM把功能操作逻辑讲解十分清楚，但是研发不理解功能的应用场景；系统操作的步骤是否过于复杂反复讨论；针对某功能实现方式PM和研发争论不止；研发非常认真的要对每个字段的限制都要扣明白……

1. 围绕主题讨论

围绕预设的主题讨论是保障会议效率和质量的前提之一。会议中我们要及时识别当前话题是否还在制定的议题中，如果超出范围，我们需要及时引导回来。针对延伸的话题可以先行记录，在会后再组织相关人员进行讨论。

需求评审一般会跟着PRD的顺序进行讲解，最忌讳一上来就说功能操作，会让人莫名其妙。讲解顺序应当是从概要到详细，层层推进。

顺序参考：需求背景 、方案概述、收益和风险、用户与需求、产品框架、功能模块、操作流程、原型交互、数据指标、所需支持、预期上线时间。

会议时间有限，必须有序的推进会议进程，避免单个问题上占用过多的时间。针对讨论的问题分清轻重缓急，做到“抓大放小”，在细节上不做过多的争论。

如果主流程上出现问题，说明产品没做好准备。此处体现了会前小范围讨论的重要性。讨论的场面可能很热烈，最后必须有确定性的结论，不要光说的热闹，最后议而不决（主题外问题先记录，不做过多讨论）。

好记性不如烂笔头，会议可能长达1~2小时，为了避免会后相关问题的遗漏，一定要及时记录讨论重点。如果来不及写，录音是必要的补充措施。会议记录是针对已确认、待确认、待讨论的关键内容记录，同时标记对应事项的跟进人员和执行时间。只有如此才可能避免“决而不行”。

四、会后：跟进跟进跟进

会上聊的再热闹，会后没有执行等于白说。所以会后的跟进是第一要务。要做哪几件事情呢？先欣赏一个失败的案例吧……

某次需求评审会，经过会上激烈的讨论确认了解决方案调整项若干和待办事项若干，并且会上指定了对应任务的负责人，然后大家心满意足的就散会了，之后各忙各的。两周后再问进度的时候发现进度远低于预期……

会议讨论的事项想要落实，首先要做的是将会议记录整理并发布。

1. 整理的内容包含具体事项、交付物、跟进人、执行时间、完成时间等信息。明确了这些事情才变得可跟进。
2. 通知的人员不仅是与会人员，未参会的相关干系人也要通知到。

需求评审不论是否通过都会根据结论进行下一步的安排。评审通过就跟进上线的排期和进度；评审未通过就及时调整并约定下次会议时间。跟进进度的方式可以采用日报、周报、站会、约定时间等多种方式进行。但是千万不要一直催进度，体现了对对方的不信任，容易让人反感。

会议中涉及需求文档的修改点，在调整后及时更新和通知相关人。再视实际情况组织会议讨论。需要注意一点——会议中一旦确定的事项，除非有颠覆性的影响因素介入，否则不允许修改。否则会议就变得毫无意义。

以上就是组织一场需求评审会需要注意的事项。希望你能开一个高效、愉快的会议~

本文由 @耳目不染 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议