说明：这个系列中可能会涉及到我身边朝夕相处的团队，虽然我会狠心地把我们踩过的坑，犯过的糗事拿出来晒，但这丝毫不影响我对产品经理的高度认可，还有研发团队的感激。实际上这是一支我认为最能体现 One Team 精神的团队。我为身处这样的团队而自豪，当然我们要改进的点还太多太多。
在分享具体的案例之前，让我们先花点时间聊一聊需求评审。
某团队需求评审的故事
1. 安静的需求评审会
某天去参加团队 A 的一个需求评审会，小小的会议室里挤满了十来号人，中间产品经理正在讲解新版本的功能需求。奇怪的是从头到尾几乎没有一个人打断产品经理，问一句：我们到底为什么要做这个功能？这个功能到底命中了用户的哪些痛点？它又是如何解决用户的痛点的？如何判断这个功能实现的效果？用什么指标？
最终需求评审在研发询问产品经理想什么时候上线中结束，多么和谐而高效的评审啊。
但是总有那么一小撮人属于来捣乱的，对此很不满并公开表示研发要多挑战、PK 产品经理。研发带着迷茫的眼神，“可是我们不知道该从哪里 PK 啊？”，“感觉产品经理说得都有道理啊，没什么好反对的啊？”，“我们也不知道数据，想 PK 但说不过人家”
于是这一小撮捣乱的人给研发开了小灶。
2. 开不完的需求评审会
大概一个月后，第二次大版本评审开始。这次产品经理惊奇地发现气氛有点不对。
研发同学几乎是带着打倒一切产品经理提出需求的姿态来开会的，产品经理提出的每一个需求都遭遇了无情的激烈反驳和质疑。每一句话刚说出口就引来若干个问题：理由呢？数据呢？你怎么说服我们做这个呢？
产品经理一脸为难，“同学们，这个功能是新功能，之前没有做过，竞品也没有，你让我给数据我现在也给不了啊！”
“没有数据那就是无法衡量了，那这个需求我们怎么知道该做不该做啊"
“可是你们不做，哪来的数据啊？”
“那你怎么证明这个需求的价值呢？”
。。。。
这研发估计是要造反了吧？—— 躲在角落的幕后指使者心想
最终大版本的需求评审以创记录的接近2.5个小时才开完。而结论是 —— 产品重新回去想。需求延后。
研发同学带着完胜产品的骄傲走出会议室，胜利的喜悦溢于言表。我们终于敢和产品 PK 而且赢了！
幕后指使者看了看表，挠挠头，唉~~~
3. 不知所云的需求评审会
在第二次大版本评审会之后，捣乱分子又不甘心落败，在队伍内部组织了好几次讨论，评审的形式也变化了好几次，终于略有改观。
这日子改好过了吧？Too young too simple，sometimes naive
某日 UI 评审，一屋子的产品、研发、UI。评审开始，UI 先介绍视觉稿，队员甲首先抛出质疑
“我觉得你这个颜色很难激起用户参与的欲望，你觉得呢？”
没等 UI 回复，队员乙又再抛出一个问题。
“你这里面图片太多，会影响性能”。
“我觉得挺好的啊”，UI 松了一口气
“ 就是这个方案用户需要理解你图片的含义，会让用户参与门槛很高啊” 。队员丙冷不防再补一刀。
BlaBlaBla。。。UI 同学的脸色越来越难看。
这个时候幕后指使者实在忍不住了，“我们到底在讨论什么”？
“我们在对 UI 稿进行评审啊”，齐刷刷一致的答复。
好吧~
故事讲完。
我们在谈论什么？答案是我们在讨论：什么是需求评审，以及需求评审的正确姿势。
各位看官，要不你先帮团队 A 把把脉，看看症状是什么？该如何下药？
明天再接着聊，困了。
晚安各位！
