一篇文章带你称霸需求评审会！

前几天有同学在老K的知识星球写了需求评审，我觉得这个话题很有意思。

需求评审，别称撕逼大战，指一群心怀鬼胎的人在固定的战场进行多轮PK，最终脸上笑嘻嘻心里MMP达成暂时性一致意见并时刻准备着下次战斗的“友好”交流形式。

在我漫长的职业生涯中，参与需求评审大概经历了3个阶段：

• 第1阶段是冲锋陷阵，作为需求评审的绝对主角，带着职业假笑拉着一群平级和上级开会，一顿舌战群儒之后，强行给他们安排工作，或者被他们骂回去加班改需求。

• 第2阶段是悠闲旁观，端着咖啡刷着微博悠闲的听产品经理1Vn，然后在产品弱势的时候，凭借着自己的title、资历以及常年和CEO谈笑风生转化来的社交货币果断出手护犊子，以保证产品部门工作的顺利开展。

• 第3阶段是不闻不问，需求评审会都不去参加了，只在会后听产品经理做简明扼要的结果汇报，结果满意就好，如果砍了我的核心需求，立即拉着技术老大出门按照江湖规矩1V1单挑，撕出结果之前，递来的烟都不接。（撕出结果也不接烟，毕竟老K不吸烟~

根据我多年的实战经验，给大家聊聊，怎么称霸需求评审会。

明确需求评审的目的

需求评审，这个没找到百度百科之类的定义，那就说我的理解：产品经理的职责是去迭代产品，我们会通过很多途径收集需求，经过自己的思考之后，形成产品需求文档，在文档变成功能之前，你需要说服很多人来支持你，包括：老板或者上级总监、开发测试设计同学等等。这个不择手段的说服的过程，就是需求评审。

所以，需求评审会的目的，就是说服团队的人，至少是关键的人，支持认同你的产品迭代决定，并一起去完成产品迭代的开发上线工作。

找到关键人物

很多同学对需求评审会都有一个误解，就是你要说服团队所有的人。其实没必要，你只需要说服关键人物。

一个典型的产品开发团队包括：老板、产品经理、开发、设计、测试。其他的市场运营客服等，对产品迭代不具有决策权，甚至连发言权都没有，只有上线前被邮件通知的知情权。

在这个团队中，有两个关键角色：老板和技术老大。老板决定产品的方向，你的所有尝试，必须符合这个方向，否则会被一巴掌拍晕。技术老大有一票否决权，一句“需求通不过技术评估”就让产品经理无fuck说。

所以，说服这两个关键人物支持你，需求评审也就成功了90%（惊喜）。

需求评审会的黄金原则

我在第一阶段时，觉得产品经理都是最聪明最牛X的，什么人情世故策略技巧，全都一边去，哥是凭实力说话的好吧。

需求评审会的基调就是简单粗暴，经过用户调研和自己绞尽脑汁的分析取舍，输出一份自认为很完美的需求文档，然后直接拉所有人开会。结果呢，就是会议经常卡在需求是否刚需和技术实现上，还没讲到具体功能就已经开始口吐芬芳。

你们一群写代码的，跟我扯刚需高频？你们一群写代码的，连技术实现都搞不定！年少的我是这样想的，大家有同感吗？

后来到了第二阶段，我对团队里的产品经理都有一个要求，画原型写文档之前，先跟我沟通你的想法和你要做的需求方向，确认没问题之后你再去做具体的事儿，免得做无用功。

在这个阶段我也明白了，为什么在产品经理嘴里有那么多的SB老板，本质原因是二者出发点就不一样，一个看重付出的回报率，另一个则不管不顾的代表用户向天请命。

我也渐渐明白，要达到需求评审的目的，关键一步就是说服核心人物：你的老板、技术老大。最好是在需求评审会之前完成这一步，把需求评审会当成确认需求细节后的产品迭代启动会。

所以需求评审会的黄金原则就是，在会议前，跟老板/总监沟通需求本身，确保对方认同你的需求；跟技术老大沟通需求的技术实现，同时说明需求的业务目的，在确保技术实现没问题的同时，让技术负责人也认同你的需求本身。

最后，需求评审会上，老板/总监在场的话是你的靠山，有技术同学出于本能（科普一下，技术和产品会不经思考条件反射的反对彼此的观点，这叫本能）给你挑刺时，不需要过多言语，一个怀疑其领导水平和威信的眼神看向技术老大，他大概率会跳出来制裁小弟。

需求评审会最终也就走个过场，确认一下需求细节，正式启动一次产品迭代。

其他注意事项

即使在会前已经搞定了关键人物，需求评审会对产品经理还是非常重要的，这是一次难得的表现自己的舞台，是一次向整个团队表明你是一个非常专业、牛X、甚至幽默风趣的产品经理的机会。一次次成功的需求评审会会提高同事对你的信任甚至钦佩，对以后工作的顺利开展很有帮助。

需求评审会一定要注意以下几个方面：

会前：至少提前2天与整个团队约定会议时间、预定会议室，并将产品原型、需求文档等资料通过协作工具发给每个人。

会中：讲具体功能之前，先讲需求背景、业务目的，告诉大家我们要做什么、为什么要做、以及做了之后有什么价值。

讲功能时要系统条理，对照产品原型、需求文档，确保每一个细节都讲到。

会后：及时输出会议纪要，包括会议结论、争议点和解决方案（暂时没有方案的，备注出方案的deadline），然后邮件所有人，记得在邮件的最后要求开发测试设计同学评估工作量和大概工时。

然后总结需求评审会中的争议点，重新输出解决方案，如果有必要，可以拉二次会议进行确认。

遇到分歧怎么办？

因为需求是会前就确认过的，所以这里的分歧多是细节方面，比如交互细节、文案细节等。

如果对方有更好的建议，果断采纳，并趁势带着职业假笑舔一波：“你的建议真是太棒了，我学习了，会后马上改！”这样有助于拉进你和狗开发的距离。

如果对方指出了你的错误，特别是接手新产品时，老开发往往比新产品更懂产品细节，开发指出你的需求与产品有冲突，这个时候切记要冷静，不要脸红露怯，风轻云淡的微微一笑，用一切尽在掌握之中的语气说一句：产品交接时没说明这一点，多谢**指出，问题我记下了，会后重新调整需求。

如果对方不认同你的方案，提出了另一个你不认同的方案，这种情况往往会陷入无尽的撕逼，让一场原本40分钟能结束的会议拖到2个小时。所以这时你不要想着马上就能说服他，很难！最优解决方案是记下争议，会后解决。

总结一下，其实很多事情，我们看到的都只是个形式，关键步骤在这个形式之前已经完成了。

比如表白是胜利的凯歌而不是冲锋的号角，要确保表白之前就已经获得了妹子的心，否则容易尴尬…

再比如上市敲钟，公司的业绩发展、财务审计才是关键，敲钟只是个形式。

所以对需求评审也是一样的，把最后的需求评审会做成一个形式，关键的步骤会前完成，既能保证工作的顺利进行，又能在会上保持产品经理该有的风度和潇洒，结果要好，过程也要帅！

最后祝愿所有产品经理都能制！霸！需！求！评！审！会！