产品经理在需求评审会上必定被问过的7个问题！.docVIP

产品经理在需求评审会上必定被问过的7个问题！ / 有一句玩笑话：产品经理不是在吵架就是在去吵架的路上，生动地刻画了我们产品经理在沟通上需要花的时间。 而需求评审会是所有的沟通场景里面比较重要的一个，所以今天就分享一下在需求评审会上经常会遇到的几个需要特别注重沟通的问题，希望会对大家有所启发。 做为一个产品经理经常会在需求评审会上遇到技术的吐槽，常见的大概是以下几个问题： 感觉这个功能没什么用啊，我们为什么要做？ 你这个方案设计得不合理，应该这样这样设计。 你设计的时候有没有考虑过XXX的情况？ 你的需求不够完整，缺了很多东西。 这个需求改动太大了，真的要改吗？ 你这个需求又改回去了，那你们当时为什么要改呢？ 我们一个个来解析一下。 01 第一问：感觉这个功能没什么用啊，我们为什么要做？ 技术这么问的潜台词是：我们不知道需求的目的和背景，无法判断这么做合不合理，产品经理赶紧讲一下。 大部分时候技术并不是真的觉得这个功能没有用，这是一种吐槽和询问。 你要是听到这句话，你赶紧把这个需求产生的背景、需求的目的说清楚，让技术清晰地知道为什么要做这个需求，这个需求是解决什么问题的。这样就能和技术在信息层面保持一致，能更好地达成共识。 这种情况就是在需求评审会的最开始没有把关键信息交代清楚，这是一个新人在入行的时候常犯的一个问题。 新人很多时候都会以为大家的信息是一致的，所以我不需要解释为什么。但其实不是的，技术部门需要产品部门去传达这些背景信息，产品是一个关键节点。 在整个研发流程里面，大部分信息都是产品负责传递的，一般不会出现其他部门直接和技术部门对接的情况，这样一来虽然产品经理已经和业务部门讨论过好几轮了，但是技术部门是第一次介入，所以必须认真地从头开始讲。 当然极少数情况下是技术真的觉得没什么用，我遇过这种情况，技术觉得根据自己的经验上这个功能没必要，然后就一直不做。 这是比较麻烦的一种情况，而且通常是技术比较强势的情况下会出现的。这个时候就搁置争议，会后拉上他和领导去讨论一下这个问题，双方各自陈述一下理由，然后由领导来给一个建议。这种情况下如果领导决定要做的话技术也不会说什么。 引入第三方能够有效的避免和技术直接发生冲突，但是弊端也很明显，有些技术可能会持续用这个方式，你不可能一直找第三方来解决类似的问题，这个时候就要抓大放小，在小地方就按技术的处理，大的方向还是要说服技术按照你的走，说服不了的话按制度处理。 02 第二问：你这个方案设计得不合理，应该这样这样设计。 这也是很常见的一个情况，技术觉得产品经理的方案不好，他的方案好。 这倒没什么潜台词，纯粹技术觉得产品太菜，所以当场把自己的想法说出来，免得做一个坑的方案，后面还要填坑。 这个情况有两种可能，一个是产品和技术对整体业务的掌握程度不同，所以大家的想法就不同；另一个是方案的偏好性不同，效果差不多，一个选A一个选B。 第一种情况如果是产品经理掌握的不够，那么是比较麻烦的，因为这表示你还不熟悉公司的业务，对你的信任度会产生负面的影响。你要做的是马上在会上把相关的细节问清楚，然后中止评审会去调整方案，准备充分再来。一定要尽量避免产生这样的情况。 新人在这个时候常犯的一个错误是知道有问题还是强行推进这个方案，怕自己受到质疑，其实不可取，只有把事情做对了做好了才会没有人质疑，不然即便不当场质疑你会后也可以找领导反馈，这样更不好。 如果是技术掌握的不够，那么你需要说清楚这么设计的原因，他的方案在哪些方面存在问题，通常是和其他模块的联动上存在问题。就事论事，你把事情讲清楚了一般就不会有啥问题，大家心里都是有数的。技术提其他方案也仅仅是因为信息掌握的不够全面。 第二种就是一个偏好性的问题，你可以说一下你这么设计的原因，也可以说一下技术的方案也是可行的，两个方案其实没有好坏之分，只是你倾向于这个方案，和业务部门达成共识的也是这个方案。 技术在这种情况下一般也不会坚持，因为没必要，他提方案是希望表达出自己的想法，你对他的方案认可了这就可以了。 03 第三问：你设计的时候有没有考虑过XXX的情况？ 或许是善意的提醒，或许是恶意的挑刺，不重要，一律当成善意的提醒。你怎么看待这个问题就决定了你怎么处理这个问题，善意的回应比较好。 如果你考虑到了这个情况，那么你可以说考虑到了，等下会具体说一下，现在先按顺序把前面的讲清楚。 把节奏控制在自己手里，不要跳着去讲，一个会议的会议节奏要掌握在会议主持手里，需求评审会的节奏就要把握在产品经理手里，你要是打乱节奏回答问题，那整个会的节奏就会很乱，时间就会长，你虽然成功地回答了大家的问题，但是效率不够，会有点乱糟糟的，这样也不好。 如果没有考虑到，你可以说这个情况之前不清楚，等下集中讨论下。注意，不要打扰既定的会议节奏，在需求评审会上把能确定的都先确定下来，把漏掉