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

正文

请到「今天看啥」查看全文

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

需求评审会的黄金原则

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

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

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

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

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

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

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

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

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

其他注意事项

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

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

请到「今天看啥」查看全文