六、任务只是开完需求评审会

流程图画完了、原型也画完了、需求文档也处理完了，接下来就进入了真正的战场——评审会。对于一直默默无闻、低头画原型的产品经理来说，评审会才是他们真正的战场。没有被评审的需求，不能算真正的需求；没有被开发上线的产品，不能算真正的产品，而需求评审则是这里的关键路径。

产品经理之前所做的一切准备似乎都是为了这一刻，他站在会议室里，竭尽全力取得需求通过的胜利。当然，也有可能失败。但是无论如何，产品经理对需求评审都是极其重视的。

几十页的原型、上百页的需求文档，都在这场会议中被阐述。大部分听众都是不在状态的，可能偶尔有一个认真的听众问上一句：“你这个功能还得再考虑一下，实现倒是能实现，但估计至少得一人两周的工作量。”不过，更多的时候是产品经理在上面专注而又认真地讲解，压根儿不管下面的听众。有的产品经理认为，需求评审会是一定要开的，这是公司的流程，至于台下的听众到底有没有听明白、想清楚，那就与自己无关了。他认为自己该做的都已经做了，开发测试和设计是别人的事情，如果有疑问再来沟通就可以了。

无论如何产品经理在需求评审会上都是最卖力气的，至于效果是不是最好的，不得而知。就这样，需求评审会结束了，产品经理享受着成功的喜悦走出会议室，而台下听众可能还是一脸茫然。

自此以后，产品经理似乎消失了。

研发人员在拿到需求并开始真正执行的那一刻，忽然发现自己有很多不明白的地方，也有很多无法实现的地方。于是，研发人员就会产生疑问：“产品经理到底是做什么的，怎么就不能考虑得更完善一些呢？”他们去问产品经理：“这里的逻辑到底是怎样的？异常情况要如何处理？这个方式实现不了怎么办？”产品经理看着研发人员那困惑的眼神，心想：“你的需求在评审会上怎么不提呢？”

就这样，进度又一次被耽搁。研发人员认为产品经理的需求不靠谱，有很多功能需要花费很长时间才能实现；产品经理认为研发人员根本不用心，而且也不怎么加班；而测试则一方面认为产品经理的需求本身不够严谨，另一方面又认为研发人员写的代码漏洞百出。