需求评审，到底如何有效进行

每个做产品经理都会经历需求评审。

在需求评审中会涉及到业务方、研发人员、运营人员、设计师、甚至有的还有领导参加。而需求评审随着公司规模和产品研发流程不同，需求评审的次数会有不同。

那我们做需求评审如果利用一套有效的打法是可以提升评审的效率的。

1.需求评审的准备工作：降低误差

比如在疫情阶段很多公司都不得不变成了线上办公、远程办公。但疫情结束后，互联网公司还是会回归到线下集中办公。就拿需求评审来说，远程办公带来的沟通时间差、需求理解度往往严重拖垮了项目进度。比如我就亲身经历过因为网络的问题，导致需求评审直接被迫延期，极差的网络环境连需求说什么都听不清。

还要常见的问题有工作消息没看到、要么就是难以理解对方的问题。

所以需求评审的准备工作至关重要。

在需求评审里，根据产品需求的属性，产品经理要提前准备好业务流程图、ER图（数据关系图），正确快速的在需求评审会里展示系统之间的关系和功能逻辑。

我建议产品经理要花至少60%的工作在评审开会前做准备。提前和解需求的开发、算法同学沟通参与主要是解决下面2个问题

• 这个需求技术上能不能实现

• 技术上能实现，则技术成本和时间

• 当前需求在产品设计上是否有遗漏
  

举个列子，当我们在做消息通知这个功能的时候，产品经理首先要清楚其本身技术实现的原理和逻辑。比如消息通知是同步通知、还是异步通知，每个消息的通知数、通知触达时间，是需要和开发技术进行评估。

如果消息通知的时间太慢，用户点击后，需要给出对应的消息通知打开、已读、和未读与发送状态。这就是通过提前需求准备，来进一步完善产品设计方案。

2.搞清楚需求文档和需求评审的关系

需求文档是在需求评审后产生的。

根据需求的复杂层度的不同，所产出的需求文档内容有极大的区别。

比如有的需求只时一个功能优化，有的需求则是从0到1完全重新做。当功能比较复杂的时候，则需求文档就会非常长。

需求评审确定了需求的大体实现可行性成本、技术难度的评估、以及同步了当前的需求背景和预计框架目的。

3.在需求评审的指南针：权利和利益

在需求评审的时候，我们要注意需求背后的提起人和需求本身关系的利息。很多需求一旦上线就是永久的新增工作量，甚至是逐渐独立成一个新产品。

很多需求会涉及到跨部门合作，如果本身要想偷懒或者抱大腿，就是靠着通过联合需求评审来完成甲方的功能，上线后给自己输送资源。这样本身自己的系统业务就被发展起来了，所谓树大好乘凉。

因此需求评审里要拿捏住对自己产品有利的需求点，尽快满足这类需求

4.需求评审是有攻击性的

在需求评审的过程里，会有很多的意见和收集。相比头脑风暴，在这一阶段产品经理要做到一针见血的原则。不管会议是开1个小时还是2个小时，要知道本次需求评审的目的是非常明确的。

严格守住需求的方向口子，不能被开发、业务方绕弯。在这里会存在很多撕逼、争执情况，因为稍微不注意需求会被修改甚至是需求被减少。

所以在需求评审开始前，产品经理一定要提前准备下演示和做需求讲解。把核心的功能做展示，这样才能完成。

以上就是需求评审的意义了，因此千万不要小看需求评审，但也不要过度依赖需求评审，优秀的产品经理往往在需求评审开始前就把需求的问题解决了，走个流程和同步会就可以了。

今天的分享就在这

今日Bonus：加我好友 pmtalk001，领取直播原型部件库，同时还有运营模版，带你了解快速提升产品运营进阶