需求评审总是被怼？强烈推荐你试试这三招

产品人Cris 2023-08-05 05:46:43

前段时间和一个合作部门的产品新人沟通需求，结束的时候，他问了我一个问题，“你在产品新人阶段，最害怕做的事情是什么”？

我不假思索的回答说，“需求评审，是曾经最不想面对的环节，甚至在评审之前几个小时就开始心跳加速了。当然这也是产品修炼路上的必经之路，其实只要掌握正确的方法，那你会发现一切尽在掌握中。”

每一次需求评审，可以称得上是对产品经理的一次毒打，心理素质好的产品经理，每次经历完需求评审，都能够客观的面对各方的质疑和挑战、认真反思，逐渐做到游刃有余；而玻璃心的产品经理，会感觉遭遇了一场“人身攻击”，真的有可能萌生退意。

不夸张的说，如果你想劝退一名准备入行的产品经理的话，那就带他去参加一次需求评审会吧。

对于产品新人，或者是刚刚加入一个新团队的产品经理来说，第一次需求评审不仅仅会决定团队对你的第一印象，更能决定你未来评审的过程是否顺利。

我们来想象下这样一个画面，如果你第一次评审准备充足，需求合理，问题对答如流，那研发、UI、测试不但会心甘情愿的满足你这个需求，更是对你的专业能力比较认可，那未来在面对你的需求时候，可能就会更宽容很多。

但如果在评审过程中，需求不合理，解答不清晰，收益不明确，被研发怼的体无完肤，那你在他们心目中的第一印象就不太好了，可想而知后面的日子肯定不好过，要知道改变第一印象是不容易的。

我在经历数十次需求评审之后，从最初面对需求评审的瑟瑟发抖，到现在能够从容的应对各方的“刁难”，这篇文章就和大家分享下我的故事，手把手教你如何准备一场需求评审，让你和大家“和谐相处”，顺利的把需求推进下去。

一、需求评审的意义

为什么有需求评审这个环节呢？需求评审的意义到底是什么呢？

盲人摸象的故事大家都知道，如果没有需求评审，那这个需求就变成了没有经过多方推敲的需求，只是从产品的视角评估的单一维度的需求，很难发现整个需求的全貌。

下面结合了我自己的初入职场的血泪史以及在工作中看到的一些案例，和大家分享两个没有经过评审造成的后果，希望大家不要重蹈覆辙。

1. 双方信息理解不一致，造成二次开发，影响和研发之间的关系

一般这种不经过评审的需求往往是涉及的联动方不多，或者团队内部可以搞定需求，大家出于能节省时间，所以简单沟通下就行动起来了，但往往这个时候最容易出问题。

产品和研发之间往往是有认知差异的，你传达的信息研发不一定能接收完整且准确，然后就按照自己的理解照做了，到了上线之后，你却发现这不是我想要的呀，而研发说你就是这么说的呢。

这样带来的后果就是，不但没有节约时间，甚至还要返工重做，降低了开发效率，影响了产研同事间的信任关系。

2. 喜提“背锅侠”，在领导心目中的形象大打折扣

需求重新开发，必定会造成研发资源的调整，那大概率会惊动产研的领导，会被问起为什么会这样，这种情况下，产品的责任自然是最大的，这对你在领导以及业务方心目中的印象会很减分的。

无论都是简单或者紧急的需求，都不要省去需求评审的这个环节，哪怕就是拉上研发，对着文档1V1过一遍细节，就能很大程度上避免“浪费时间、消耗信任、增加隔阂”这类情况发生。

所以，需求评审有以下三点重要意义：

能够有效的传递需求准确性和评估需求可行性。
在多方之间达成需求的共识，做事留痕，明确权责利，避免背锅和甩锅。
能够在开发阶段高效的推进需求，防止相互扯皮，提高需求的开发效率。

那么，如何准备一场好的需求评审呢？下图就是评审前、评审中以及评审后应该注意的要点，接下来从这三方面展开和大家聊聊具体应该怎么做。

二、需求评审之前

这里我们主要讨论在业务逻辑上是合理的需求，那理所应当是可以进入到需求池的。那些和产品定位有冲突的需求，如果是这些需求，是需要我们产品提前识别出来，扼杀在萌芽当中，我们对这部分本次不做展开。

凡事预则立，不预则废。所以，在面对一场需求评审的时候，一定要做好充足的准备。

1. 准备一份需求文档

需求文档里面需要描述清楚这次需求具体要实现哪些功能、达到什么目的。

这里需求文档不需要太复杂，只要描述清晰、重点突出即可，往往不同的公司都有对应的需求文档模板，或者提前和研发沟通，输出让他们看着最舒服的样式即可。

不同类型的需求文档差异还是比较大的，不过一般的需求文档是要包括这六部分内容的，需求背景（现状、问题）、需求目标（预期收益和价值）、业务流程、竞品分析和调研结果、本次具体实现功能以及埋点管理。

2. 进行需求预沟通

预沟通这个环节非常重要，能够帮助我们再次确认需求理解是否有误、以及需求逻辑和实现上有没有问题。

这里包括两个沟通方，第一个沟通方是业务方，带着需求文档和提需求的业务方进行需求的二次确认，作为过来人，一定要养成习惯，不要漏掉这个过程。

因为我们肯定遇到过这样的情况，需求上线后兴高采烈的给业务方验收，结果业务方生气的说，“这和我提的需求不太一样呀，我要的口径是这样的，你这个是按照那样实现的，不满足我的需求，再重新做一下吧”，然后潇洒的转身离开了，只留下在风中凌乱的你。

很多时候业务觉得他表达清楚了，你也觉得你听懂了，但是毕竟大家的视角不同，认知上有差异。而且业务往往是不懂技术的，只表达自己想要什么。

所以一定要把需求以文字的形式展示给需求方，花上几分钟反讲下需求，这几分钟带来的收益，很有可能会给你带来数倍的回报。

另一个沟通方就是约上这次需求的主研发or研发负责人，需要一起明确以下三个问题。

1）这个需求的逻辑有没有问题？

需求的逻辑正确与否，是这个需求到底做不做的决定性因素，如果需求方案很好，但是逻辑上根本行不通，那就是理想很丰满，现实很骨感，这个方案不能实际落地。

举个例子，比如你承接了来自某视频app的用户增长部的一个需求，要求减少视频片头广告时间甚至去掉广告，如果只站在业务方的角度去看没有什么问题，但是这个需求会员部会答应吗？

的确减少广告时长或者去掉广告，大概率能够带来一定的用户增长，但是也会大幅的减少收入，显然这个逻辑站在全局的视角来看是行不通的。

2）这个需求能不能实现？

当明确的逻辑没问题之后，要明确需求能不能实现，也就是开发量的问题。

比如这个需求确实不错，收益也预计很高，但是研发水平或者人力有限，可能半年都做不完，那就需要考虑下这个需求的ROI了，这时候就需要向上升级，让领导了解基本情况，至于是先实现MVP版本，还是申请额外资源全力开发，这是领导层来决定的问题。

比如需求背景中提到的搭建自动化营销系统，这个需求各方都很认可，但是技术上实现比较复杂，涉及到用户画像的构建、商品的个性化定价以及营销系统性能的提升。

最后也是按照功能的优先级和实现的难易程度，分期完成的。所以一个需求有时候并不能一次性就搞定，毕竟各个方向都是多线并行的，难免有资源的冲突。有了预计能够实现的部分，也要及时同步业务方，让其有个心理预期，千万不要等到交付的时候才告知砍了需求，这是很不职业的行为。

3）如果实现会不会有什么负面影响或者影响其他方向？

在逻辑和实现都没问题的前提下，那也要让研发帮忙评估会有没有负面影响，如果是优化1个问题出现了3个新问题的需求，那也是没必要做的。

另外，这个需求也有可能对上下游有潜在的影响，需要多方配合迭代，那就要求我们提前知会相关方，评估需求的影响范围，而不是到了正式评审的时候突然拉着对方来配合，这会让相关方留下对你不好印象，影响后续的合作。

当我们确定好以上三点之后，如果都没有问题，那就可以继续推进需求了，敲定评审时间之后，一定要给各个方向的负责人发会议邀请，至少要提前一天沟通确认会议时间，这样可以让大家有时间准备，可以极大的提高会议效率。

三、需求评审之中

好了，接下来就是进入到正式的需求评审环节了。

那我先问大家一个问题，需求评审这个过程，到底是要参与人员传递哪些信息？仅仅是和相关方同步需求是什么吗？

当然不仅仅是这个，其实这里是有先后逻辑顺序的，需求评审要传递的信息主要是这三个方向，需求的价值和意义、需求具体是什么以及需求如何实现。

不要一上来就说，我要实现什么功能、达成什么目的、这个需求很简单、怎么实现我不管的这类话。

而是在整个评审会过程中，始终释放一个信号，让大家相信这个需求会有收益并且肯定能实现。

那具体怎么做呢？按照这四步走，可以帮助你可以更加从容地面对需求评审会议。

1. 明确需求背景

我参与过一些合作部门的需求评审，发现有不少产品同事会忽略这部分，他们会直接进入需求是什么这部分，这并不是一个好习惯，还也会给研发同事一种被支配的感觉。

所以，开场白应该向大家介绍需求的背景是什么，也就是为什么要做这个需求，而且最好有数据说明现状是怎么样的，预计有多少的收益。这会给研发同事传递出信号，他们会感觉“这个需求是认真评估过的，而不是拍脑袋想出来的”。

举一个我最近组织的需求评审开场的例子，”最近我们和商业分析团队合作，定位了用户流失期间的商品转化变化情况，发现如果用户常买品的下单金额降低25%，那这个商户有84%的概率会流失。所以，经过线下的试点实验，把有流失趋势的用户核心品进行个性化促销，经过半个月的投放，数据表明实验组的流失率降低到37%，效果明显。所以接下来我们计划把这个项目推到全国范围，那就需要建设一个能够识别流失用户核心品，自动化投放营销能力“。

你瞧，有背景、有实验、有数据、有结果、有期望，可以说是有理有据，也能让大家知道这件事的来龙去脉了，只要彼此在认知和价值认可上达成一致，那这件事就好做了，毕竟强扭的瓜不甜，靠内驱和靠外界驱动，最终实现的效果可能是天壤之别。

这也就是所谓的“信息差”，产品经理每天和业务接触，会得到丰富的信息，那就可以多维度的来评估这个需求的合理性。

而参与评审的其他人，之前是没有这些信息或者只有一部分信息的，就好比盲人摸象一样，从他们的视角来看，很有可能觉得这个需求是不合理的。

所以，介绍背景，补齐大家的认知，对于需求评审来说，十分重要。

另外，即使是老板提出的需求，也别直接说“这是老板让做的”，不仅很多研发都很反感这句话，而且大家也会觉得你这个产品经理能力可能不太行，缺乏自己的思考。

所以，遇到这种情况的时候，需要去发掘老板提出需求背后的业务诉求，让大家明白需求有价值。

2. 明确需求范围

当和研发同事在认知和价值层面达成一致之后，那就趁热打铁，开始讲述这个需求到底要做什么。

作为需求评审最重要的一环，这里也是非常讲究技巧的，在阐述需求的过程中，要先说从粗到细，先整体流程，再到具体功能，最后才是交互细节。

我相信大家都有同感，很多人都特别爱抠细节，如果一上来就直接说细节，那可能立刻引发多人的讨论了，反而会极大的降低评审的效率，造成了时间不可控的情况。

比如，我参与过几次和其他方向的联合评审，主负责的产品经理和设计同学、前端工程师，对于一个图标或者一种动画形式在会上争论不休，而且一旦开始抠细节，就会陷入怪圈，彼此在众人面前就都不愿妥协了，很难达成一致。

其实，这些只涉及到单方向的细节问题，往往可以会后下来再沟通的，这样既可以节省大家的时间，私下彼此的态度也会缓和很多，更容易换位思考，达成共识。

所以，切记，从粗到细，先让大家在脑海中有了需求整体的蓝图，再慢慢的沟通细节即可，而沟通细节这个环节，就可以放到下一环节了。

比如上文提到“实现自动化营销的能力”，首先需要在数据仓库获取流失的用户-商品关系，接下来把对应的数据传输到营销系统，营销系统根据规则进行适当的降价促销，最后再把数据传输到商城的对应模块，前端实现展示。

这就是从整体的流程出发，涉及到数据仓库—营销系统—商城前端，让各个方向相关人员对自己的任务有个认知。

然后再重点和各个方向聚焦对于的细节，比如怎么获取用户-商品关系，按照什么规则进行促销，具体的展示形式是什么样的。

3. Q&A

需求评审往往会遇到很多问题，特别是需要多方合作的这种需求，更是大型”勾心斗角”的场面。

有的会提出自己方向很难实现，有的会说需要依赖其他上游，有的会反馈没研发资源，还有那种直接硬刚质疑需求没意义的。

面对提问，首先不要慌张，也不要剑拔弩张。其实需求评审会议和面试很像，你面试的时候总不能硬怼面试官吧。

所以，能回答的问题认真回答就好，比如需求的必要性、实现的交互、功能的优先级和必要性，都是可以讨论和评估的，以真诚换真心，那很少有人再继续咄咄逼人的。

同时，这里也要集思广益，如果其他人说的更有道理，那就要积极采纳意见，虚心接受。

对于回答不上来的细节问题，或者一时没想清楚的，那就暂时不回答，毕竟我们还有万能的话术：“你说的有道理，这个问题我没考虑到，下来我思考一下，然后再找你单聊”。

千万不要为了面子，强行编造个说辞，那反而会把自己处于更不利的境地，毕竟大家这个场景下，大家带着自己的诉求，出于完善需求的目的，一旦需求有破绽，同事很容易被盯着不放。

切记，在需求评审过程中，产品经理的职责不仅仅是把需求同步给各个方向，另外你还有一个角色是作为会议的主讲人，也要控制整个流程的节奏，杜绝让会议进入一小部分人抠细节、大部分人围观的状态，更不要让会议跑偏，聊一些不相关的内容。

所以，一旦发现有些同学开始抠细节，要及时制止，记下todo，会后小范围单独讨论。如果是跑通了，那更要及时将大家的注意力拉回到需求上来。

4. 达成结论，输出会议纪要

当完成了上面三步之后，如果这个需求没有问题的话，那就要明确以下三点，当面确定好，防止后续扯皮。

第一，哪些事情要做，哪些事情暂时不做？
第二，每个部分的负责人是谁？
第三，大概交付时间是什么时候？

同时，在群里或者邮件的形式再次告知大家需求评审会议结论以及待办事项，一般的会议纪要的形式是这样的，大家可以参考下：

会议纪要—关于自动化营销能力搭建的需求评审

时间：2022年5月10日，14：00-16：00

参会人：C罗、本泽马、贝尔、莫德里奇、克罗斯、卡塞米罗….

结论以及todo：

1. 离线用户-商品关系数据有数据仓库@C罗提供。

2. 营销系统的兼容和规则实现由@本泽马实现。

……

5. 关于前端交互形式的细节待@贝尔@克罗斯讨论后同步，时间在19:00之前。

以上，请各个方向评估产品和技术方案，在5月13日下班前完成内部评审，并同步排期，感谢各位。