需求评审会出现这几个信号，你的企业可能存在工作累，产出低

出现以下几个信号：你就需要注意了。

• 会议出现激烈争辩，产品经理疲于应付，但又无力招架
• 产品 逻辑思维不清晰，无法理解与会人员的疑问，疲于解释，又答非所问
• 与会人员 一人一套说法，互找漏洞，缺乏观点的收拢
• 会议争论大，讨论激烈，会后不做整理，风平浪静，开发时各执一词
• 会议时间过长，约定的时间经常延迟，动不动就是三四个小时
• 人人都是产品经理，产品需求经常受到质疑，众人均希望改需求
• 集体因为某个设计笑场，突然大家就乐了

1. 会议出现激烈争辩，产品经理疲于应付，但又无力招架

2. 产品 逻辑思维不清晰，无法理解与会人员的疑问，疲于解释，又答非所问

- 产品逻辑弱，或者表达不清晰。解决不了疑问。
- 产品易复杂，功能耦合大。也设计不好简洁的产品
- 开发难度大，抱怨连连，项目动不动就延期，做项目做着做着总能发现有隐藏需求
- 很多时候，研发人员会之一：需求方的描述如何，产品如何进行的需求转变，转变后，是否会发生较大的变化，功能过于“强大”。
- 没做好，轻则 增加了工作量，功能对应的风险增加（甚至就并非需求方的需求）
- 你一般会发现，产品 不会对需求进行二次确认，签字画押。你做的不是人家要的就变得很正常

3. 与会人员 一人一套说法，互找漏洞，缺乏观点的收拢

4. 会议争论大，讨论激烈，会后不做整理，风平浪静，开发时各执一词

- 这个事情，说到底还是制度的问题，因为争论无法避免，团队总算需要磨合。没人会喜欢一天到晚争论不休。我们经常说要提前暴露问题，提前暴露问题，不正是这副模样吗？
- 最要的是 就争论点，必须做详细的会议记录（针对 人、论点、时间都做记录）
- 对最终结果，做最终结果的描述，分发，告知所有相关人员，并确认！！！
- 不管是什么结论，都必须形成 决议，得到一致的确认

5. 会议时间过长，约定的时间经常延迟，动不动就是三四个小时

- 经典的方法：Five Hat理论。五帽子法。
- 提前找相关人员进行确认，会议只做决议公示。
- 当然方法很多。这里不加叙述

6. 人人都是产品经理，产品需求经常受到质疑，众人均希望改需求

- 很显然这里有明显的需求不对称，或者设计不合理之处。一致说错，十有八九真的有问题
- 还有一种可能性：管理弱，则出现长期无法就产品功能做出明确划分、功能收拢、功能的独立性就弱
- 感觉上，你发现事情不是一套一套，仿佛什么事情都是要一起考虑。没有明显的区域感

7. 集体因为某个设计笑场，突然大家就乐了

- 很显然，这个设计不是很无奈，就是很扯淡。要么就是谁在合适的时间说了个笑话。如果是针对设计来的笑场，那就要注意了。
- 大家最终可能会因为外部的因素：吃饭啦、上厕所、暂时定不下来。
- 大家为了结束开会，而拼命加速，但后面还是可能要继续开会