相信每一个经历过需求评审会的产品都有过“脸红心跳，汗流浃背”的感觉。
需求评审会作为敏捷开发流程中每个迭代开始前必不可少的环节，其主要内容是 产品开发对喷，测试看戏 产品将下个迭代要做的功能向开发和测试宣讲，大家有问题就提出来集中讨论。
那么在这个过程中难免会产生一些分歧和摩擦，甚至火药味很浓。至于会议结论，顺利的话，大家你一言我一语达成共识；不顺利的话，产品就会被前端后台甚至测试一起怼；更有甚者，产品的设计有巨大漏洞，被项目负责人驳回也不是不可能。
这时候产品经理的心态就显得尤为重要。在继续这个话题之前，先引入两个概念：
“自尊强有力的影响着人们的期望、行动以及对自己和他人的评价。高自尊的人自我认可程度很高（肯定自己的整体价值），他们往往倾向于接受其他人，甚至包括那些和他们意见相左的人，并且一般具有令人满意的人际关系。”
“与此相反，低自尊的人常常把事情往坏处想，而且付出的努力较少――尤其当任务充满挑战而且费力的时候。通常低自尊的人用不断地批评来胜过他人，因而常常使自己变得孤立。同时，低自尊的人又常常过分专注于这些不被接受和拒绝，这又进一步削弱了他们的自尊，形成恶性循环。低自尊的人会抗拒变化，因为低自尊的人不能接受别人对自己的正面反馈。 ”
还是以上面的场景为例，高自尊的产品面对这种情况，往往能在评审会上虚心听取大家的意见，采纳合理的，驳回不合理的，会后还会告诉自己：
“做产品嘛，被怼很正常，开发当然希望做的功能越少越好，版本越简单越好，可我站在客户这边，一切从业务出发，该做的就得做。”
“人无完人，不可能每次都能把所有细节想到。”
“刚刚开发的意见很正确，回去再想想，顺便复盘一下，以后怎么避免这种情况再次发生。”
而一个低自尊的产品在会上，就会非常紧张，深怕听到反对的声音，对于开发的建议也十分抗拒，会后可能会想：
“为什么大家都针对我，是不是对我有意见。”
“为什么我这个细节都想不到？！也太垃圾了。”
“竟然被驳回重做了，都怪XXX，净找茬，这样一来大家会不会觉得我很菜？”
看到了吗？同样的场景，完全不同的心路历程。到这里相信有些同学已经有代入感了，那么怎样才能避免这样的情况影响到我们呢？
以下是一些小建议：
1. 放平心态。开发怼你并不是针对你，而是就事论事。作为技术人员，他们必须要把逻辑一五一十的弄清楚，因为在开发的世界里，不是0就是1，没有0.5。当然有时候可能态度不好，但也没关系，产品要做的本来就是哄着开发做事情，只要目的达成了，其他的都不重要。
另外，在沟通过程中，多一些包容，尽量用开发的方式来表述，这样也能减少很多摩擦。
2. 保持自信。不要害怕听到反对的声音，不要因为开发质疑你就否定自己，圣人也会犯错，更何况是作为普通人的我们呢？难道真的因为今天这个小细节没想到，就证明你不是一个好的产品吗？并不能。做产品就像盖房子，一颗螺丝钉没拧好，它重要吗？重要，但不致命。
因为你还有下个迭代，下下个迭代，随着时间的推移，个人经验的积累，要相信自己，总会有做得很好的时候。
3. 坚定立场。很多情况下，产品提出来的需求，会被开发challenge：你这个需求可以但没必要，谁会用啊？这种情况下，一旦产品自己不坚定，那就很难在评审会上站住脚。毕竟，连你自己都对这个需求存有疑虑，还怎么去说服开发呢？
这就要求产品在事先就要做好准备，客户过来的不合理的需求，自己先驳回，确保到了评审会上的需求，都是真的能解决用户问题的那些，这样在面对开发的challenge的时候，才会更有底气，更加自信。
4. 提前沟通。在设计某个功能点的时候，可以提前与开发负责人讨论，听听他们的意见和建议，再酌情采纳。这样做一方面是避免重大失误的产生；另一方面，评审会上被其他开发challenge的时候，负责人可以帮助你解释。
不要再陷入自我怀疑的怪圈，自己PUA自己了，要相信自己，你就是最胖棒的！
