产品经理工程评审反面教材

今天本来抱着学习的态度去听产品同事的工程评审，没想到听了一个典型的方面教材。

产品同事A第一个错误是工程评审没先找前端、后端主管们过方案，导致方案一投影，所有人都没看过。前端主管提醒以后要先跟研发大致过完方案后再工程评审，但可以明显看出已经对A有意见了。更糟糕的是A的需求还是一个相对比较复杂的需求，没有提前看文档的诸位研发非常懵逼。

第二个错误上来直接讲细节。一般评审一个需求，要先讲需求概述，描述一下为什么做这个需求，这个需求主要流程和功能是什么，让研发们先有一个大概的了解。

工程评审其实也是一次演讲/PPT展示，A这方面也有比较明显的问题。A在讲解时对着笔记本屏幕指点，看着自己的屏幕跟大家说，而忽视了投影的大小和鼠标的移动，出现跟大家不同步、交流少的情况。

产品经理应该比所有都了解自己的需求。A在评审的时候，多次出现了对文档不熟悉的情况，比如不知道对应的页面的位置，念文档的时候不流利，感觉文档不是自己写的。A的解释是这个文档是两个月前写的，但是评审前必然要先复习文档，完全读熟把握细节再进行评审。

产品经理应该相信自己是对的，除非别人提出了合理的质疑。A在评审过程中，对自己的需求表现出了自我否定、不确定的状态，“这个落地页上线后很有可能被封”，“竞对是这么做的”。如果你自己都无法相信自己做的事情是对的，凭什么动员研发们为你的需求全力以赴呢。

不过在评审过程中，我也犯了一些错误，就是作为产品经理对A提出了一些疑问。工程评审应该是视为产品评审后的一个环节，是需求已经过产品内部达成一致、与研发进行的评审。产品在这个场合提出疑问是不合适的。