需求评审时总是被挑战肿么破

　　前几天有小伙伴给我留言，说自己每次需求评审的时候被各种拍砖，不知道肿么破。
　　先看下这位小伙伴遇到的问题：
　　下面是我的回复：
　　确实，需求被挑战几乎是每个产品经理都会遇到的问题。要想在评审的时候被拍得越来越少，首先得总结下常见的被挑战的问题点有哪些。
　　经常被挑战的问题
　　1、技术层面，实现逻辑的可行性问题
　　需求评审中，常常会被技术同学挑战的问题，多是发现产品经理提出的某个想当然的功能需求点，在技术上是很难实现或存在较大风险。
　　举个例子：
　　如果设计这样一个功能：不论用户是否登录，一进入某个页面就获得n天后的1次抽奖机会。当用户n天后再次进入该页面时，不论是否登录都可以完成抽奖，中奖后再要求用户登录领奖。
　　从用户体验上说，用户在无需登录的情况下就可以进行如此流畅的操作，肯定比一进来就要求登录体验更好。
　　但是在实现上，产品经理得考虑，无需登录的状态下，如何识别用户？抽奖次数记录在哪里？可以记录在本地吗？如果记录在本地，n天后用户再进入该页面，记录还在吗？存在哪些记录丢失的风险？等等。
　　这时，需要跟技术同学做充分的沟通和评估，再做一个技术实现与用户体验的平衡，产出靠谱的产品需求。
　　2、需求层面，考虑不周全
　　经常会被产品经理遗漏的需求包括：
　　该产品流程与其他产品线的产品存在交集，会影响到其它产品的联动修改
　　只考虑到正向、正常产品流程，没有考虑到逆向、异常产品流程如何处理
　　需要描述细节的地方一句话带过，不清晰。例如，展示活动倒计时。那就需要说明活动倒计时从什么时间开始计算？以什么时间为截止时间？活动开始之前如何展示？活动结束之后如何展示？等。
　　在评审前，没有考虑足够细致、全面，也常常是需求被挑战的点。
　　3、业务层面，ROI过低
　　某一个需求功能点的意义、价值过小，但是实现成本过高，也常常会被团队拍砖的。
　　怎样才能被越拍越少
　　总结了经常被挑战的问题之后，那怎样才能被越拍越少呢？我个人认为：
　　1、多做总结。
　　每一个需求上线后都回过头来，如果让自己再做这个需求，要怎么做，会优化哪些？PRD怎么写？甚至要不要重新写一次？这次的主要问题暴露了我哪方面的欠缺？
　　这样，每次总结，相信在做产品设计时会考虑越来越全面，对产品将面临的风险（或者说坑）会有比较充足的预估。
　　2、设计过程中多问自己为什么
　　某一个功能点，为什么要做？价值点是什么？实现成本如何？ROI高吗？为什么要这么做？还有更好的解决方案吗？
　　让自己设计的每一个功能点都能站住脚，不仅有价值而且实现方案是最优的。
　　3、需求评审之前做充足的沟通
　　在有了初步的产品实现方案之后，就应该跟核心开发同学做一次小范围的深入沟通，主要确定
　　需求的实现逻辑都是可行的
　　评估实现成本
　　是否跟原有产品逻辑有所冲突
　　是否还有没有考虑到、或没有说明清楚的需求点。
　　在评审前跟开发同学做充分的沟通，可以极大减少评审中被拍的次数。
　　4、终极绝招：产品经理必备撕逼技能
　　这个世界上不缺少挑刺、抱怨的人，但是缺少能给出建设性意见的人。
　　所以当面对只会说你的方案这里不对，那里不对的人，
　　那需要提醒他：
　　如果你觉得我是错的，那你最好证明你是对的
　　或者
　　如果大家没有更好的方案，那证明现有的这个就是最好的。
　　还有哪些比较好的方法可以避免评审被拍，欢迎大家在文章下面留言补充