高效需求评审：需要用点“小心思”

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

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

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

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

一、请正视需求评审

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

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

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

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

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

二、**前：准备你的武器

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

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

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

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

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

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

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

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

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

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

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

三、**中：注意控制场面

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

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

1. 围绕主题讨论

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

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

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

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

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

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

四、**后：跟进跟进跟进

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

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

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

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

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

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

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

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

题图来自Unsplash，基于CC0协议

给作者打赏，鼓励TA抓紧创作！

**赏

1人打赏