【6000字长文】需求评审总是被怼？强烈推荐你试试这三招

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

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

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

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

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

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

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

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

一、需求评审的意义

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

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

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

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

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

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

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

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

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

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

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

1、能够有效的传递需求准确性和评估需求可行性；