产品经理需求评审会必问的7个问题！挺过去，你就是最强嘴炮王者
有一句玩笑话：产品经理不是在吵架就是在去吵架的路上，生动的刻画了我们产品经理在沟通上需要花的时间。
做为一个产品经理经常会在需求评审会上遇到技术的吐槽，常见的大概是以下几个问题：
- 感觉这个功能没什么用啊，我们为什么要做？
- 你这个方案设计的不合理，应该这样这样设计。
- 你设计的时候有没有考虑过XXX的情况？
- 你的需求不够完整，缺了很多东西。
- 这个需求改动太大了，真的要改吗？
- 你这个需求又改回去了，那你们当时为什么要改呢？
第一问：感觉这个功能没什么用啊，我们为什么要做？
技术这么问的潜台词是：我们不知道需求的目的和背景，无法判断这么做合不合理，产品经理赶紧讲一下。
大部分时候技术并不是真的觉得这个功能没有用，这是一种吐槽和询问。
你要是听到这句话，你赶紧把这个需求产生的背景、需求的目的说清楚，让技术清晰的知道为什么要做这个需求，这个需求是解决什么问题的。这样就能和技术在信息层面保持一致，能更好的达成共识。
这种情况就是在需求评审会的最开始没有把关键信息交代清楚，这是一个新人在入行的时候常犯的一个问题。
新人很多时候都会以为大家的信息是一致的，所以我不需要解释为什么。但其实不是的，技术部门需要产品部门去传达这些背景信息，产品是一个关键节点。
在整个研发流程里面，大部分信息都是产品负责传递的，一般不会出现其他部门直接和技术部门对接的情况，这样一来虽然产品经理已经和业务部门讨论过好几轮了，但是技术部门是第一次介入，所以必须认真的从头开始讲。
当然极少数情况下是技术真的觉得没什么用，我遇过这种情况，技术觉得根据自己的经验上这个功能没必要，然后就一直不做。
这是比较麻烦的一种情况，而且通常是技术比较强势的情况下会出现的。这个时候就搁置争议，会后拉上他和领导去讨论一下这个问题，双方各自陈述一下理由，然后由领导来给一个建议。这种情况下如果领导决定要做的话技术也不会说什么。
第二问：你这个方案设计的不合理，应该这样这样设计。
这也是很常见的一个情况，技术觉得产品经理的方案不好，他的方案好。
这倒没什么潜台词，纯粹技术觉得产品太菜，所以当场把自己的想法说出来，免得做一个坑的方案，后面还要填坑。
这个情况有两种可能，一个是产品和技术对整体业务的掌握程度不同，所以大家的想法就不同；另一个是方案的偏好性不同，效果差不多，一个选A一个选B。
第一种情况如果是产品经理掌握的不够，那么是比较麻烦的，因为这表示你还不熟悉公司的业务，对你的信任度会产生负面的影响。你要做的是马上在会上把相关的细节问清楚，然后中止评审会去调整方案，准备充分再来。一定要尽量避免产生这样的情况。
新人在这个时候常犯的一个错误是知道有问题还是强行推进这个方案，怕自己受到质疑，其实不可取，只有把事情做对了做好了才会没有人质疑，不然即便不当场质疑你会后也可以找领导反馈，这样更不好。
如果是技术掌握的不够，那么你需要说清楚这么设计的原因，他的方案在哪些方面存在问题，通常是和其他模块的联动上存在问题。就事论事，你把事情讲清楚了一般就不会有啥问题，大家心里都是有数的。技术提其他方案也仅仅是因为信息掌握的不够全面。
第二种就是一个偏好性的问题，你可以说一下你这么设计的原因，也可以说一下技术的方案也是可行的，两个方案其实没有好坏之分，只是你倾向于这个方案，和业务部门达成共识的也是这个方案。
第三问：你设计的时候有没有考虑过XXX的情况？
或许是善意的提醒，或许是恶意的挑刺，不重要，一律当成善意的提醒。你怎么看待这个问题就决定了你怎么处理这个问题，善意的回应比较好。
如果你考虑到了这个情况，那么你可以说考虑到了，等下会具体说一下，现在先按顺序把前面的讲清楚。
把节奏控制在自己手里，不要跳着去讲，一个会议的会议节奏要掌握在会议主持手里，需求评审会的节奏就要把握在产品经理手里，你要是打乱节奏回答问题，那整个会的节奏就会很乱，时间就会长，你虽然成功的回答了大家的问题，但是效率不够，会有点乱糟糟的，这样也不好。
如果没有考虑到，你可以说这个情况之前不清楚，等下集中讨论下。注意，不要打扰既定的会议节奏，在需求评审会上把能确定的都先确定下来，把漏掉的部分在后面花时间讨论一下。
一般来说不超过15分的讨论可以当场讨论，然后定一个方向，如果是时间比较长的，那么会后讨论，然后再定方案，弄完之后再做二次评审。
第四问：你的需求不够完整，缺了很多东西。
这也是会遇到的，一般来说新人的时候遇到的比较多，后面其实应该还好。
出现这种情况的话有两种情况：一种是产品的方案真的不完整，一种是技术觉得你的方案不完整。
不管是哪一种情况，如果听到这个首先需要做的是让提出这个问题的技术，具体说一下缺哪些东西，然后一一的对一下。
有的时候技术说的是对的，有的时候技术也就是说一下，不一定。就事论事的把这个事情弄清楚，技术如果说的是真的那就都记下来，然后去改，回去自己加强技能，如果就这么一说那么这个确认的动作能够有效的减少那些无效的干扰，同时能够让这种情况以后少发生，省很多事。
一般来说其实也不会缺很多东西，一个产品拿出来的方案不会是千疮百孔的，因为在评审之前通常都会有其他人看过、讨论过，不会是产品经理一个人弄完就拿出来评审的，但是可能真的有地方没写到，不多，也就有一两个地方，技术就正好想到了，在会上让技术指出来，然后简单的给一个方案，定下来就行，会后把方案不上去。
第五问：这个需求改动太大了，真的要改吗？
这句话是有潜台词的，技术的意思是开发的工作量有点大，你们这么改有没有想清楚。
技术说这句话的时候多少有点不情愿或者有点担心，因为这种情况下通常意味着大量原来的代码都没有用了，过去的工作可能都白费了，这是技术不愿意看到的，所以技术会确认一下也是人之常情。
还有一种可能是需要改动的这块代码过去比较乱或者用到的地方比较多，所以技术有点担心改了之后出各种问题，他们会说这句话，希望业务部门和产品再考虑一下。
如果是前面那种好处理，产品尽可能的把修改的目的和背景讲清楚就行，一般来说如果确实需要改的话技术也不会多说什么。
但如果是后面那种情况，那么最好和技术沟通一下，然后尽可能的多留一点时间给技术和测试，确保上线之后不出问题。
这种情况在小公司其实比较容易出问题，经常会出现业务的领导说不行，必须在多少天内把这个需求实现了，可能是业务那边已经答应大领导或者答应客户了，也可能是外行指挥内行，不管是哪个都比较坑。
第六问：你这个需求又改回去了，那你们当时为什么要改呢？
这种情况经常出现在产品的初创期，因为方向不确定，需要不停地调整和摸索，所以有可能会出现反复修改的情况。
会问这个问题的技术一般来说是习惯了做成熟产品的研发，但是初创型的产品必然是会经常调整的。
我也遇到过这种情况，技术经常强调的就是你们想清楚再开发，尽量规划的远一点，这样后面就不用经常改来改去。
讲这个话的技术还是一个资深的技术，我觉得讲这个话就有点外行了。改不改的看阶段，并不是产品想改，而是业务需要。
第七问：这个地方能不能改成XXX？
在这个需求评审会上除了研发部门的同事以外，通常还会有对应的业务部门的同事，业务部门有时候也会在会议上提出一些东西，通常是追加需求或者修改方案。
如果是追加需求的话其实还行，你可以评估一下改动的大小，比较小的话当场沟通一下加进去就行，如果比较大的话你就建议下个版本和其他内容一起搞个优化，当前这个版本就先不要加了，因为方案都已经确定了，加需求的话这个会就没法开了。一般业务部门是会同意的。
如果是改方案的话就比较坑了，通常是临时想到一个方案，然后说能不能这么这么改。这种的话其实就说明运营的经验也不是很丰富，所以才会出现当场改方案的拆台情况。
如果出现这种情况那你就可以问一下说，是不是新的方案比原来的方案好很多，如果答案是否定的那么建议用已经整理好的方案，这样可以尽快上线，如果是确实新方案好很多那么就需要重新整理方案并重新开需求评审会，尽量不要让这种情况发生，比较浪费时间，尽可能在开会前和业务部门多讨论。
一个产品经理，如果没有经历过无数需求评审会的洗礼是不能成长为一个真正的产品经理的，真的勇士就需要直面技术的怒怼和业务的拆台，而且大概率是需要反复直面。
不重要，只要成功挺过去，你就是最强嘴炮王者。
如果觉得不错就关注我吧。欢迎大家留言讨论。
