![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/8ecd892d0ce2b9baa6d565f87ac8cab9.jpeg)
出现以下几个信号:你就需要注意了。
- 会议出现激烈争辩,产品经理疲于应付,但又无力招架
- 产品 逻辑思维不清晰,无法理解与会人员的疑问,疲于解释,又答非所问
- 与会人员 一人一套说法,互找漏洞,缺乏观点的收拢
- 会议争论大,讨论激烈,会后不做整理,风平浪静,开发时各执一词
- 会议时间过长,约定的时间经常延迟,动不动就是三四个小时
- 人人都是产品经理,产品需求经常受到质疑,众人均希望改需求
- 集体因为某个设计笑场,突然大家就乐了
1. 会议出现激烈争辩,产品经理疲于应付,但又无力招架
2. 产品 逻辑思维不清晰,无法理解与会人员的疑问,疲于解释,又答非所问
- 产品逻辑弱,或者表达不清晰。解决不了疑问。
- 产品易复杂,功能耦合大。也设计不好简洁的产品
- 开发难度大,抱怨连连,项目动不动就延期,做项目做着做着总能发现有隐藏需求
- 很多时候,研发人员会之一:需求方的描述如何,产品如何进行的需求转变,转变后,是否会发生较大的变化,功能过于“强大”。
- 没做好,轻则 增加了工作量,功能对应的风险增加(甚至就并非需求方的需求)
- 你一般会发现,产品 不会对需求进行二次确认,签字画押。你做的不是人家要的就变得很正常
3. 与会人员 一人一套说法,互找漏洞,缺乏观点的收拢
4. 会议争论大,讨论激烈,会后不做整理,风平浪静,开发时各执一词
- 这个事情,说到底还是制度的问题,因为争论无法避免,团队总算需要磨合。没人会喜欢一天到晚争论不休。我们经常说要提前暴露问题,提前暴露问题,不正是这副模样吗?
- 最要的是 就争论点,必须做详细的会议记录(针对 人、论点、时间都做记录)
- 对最终结果,做最终结果的描述,分发,告知所有相关人员,并确认!!!
- 不管是什么结论,都必须形成 决议,得到一致的确认
5. 会议时间过长,约定的时间经常延迟,动不动就是三四个小时
- 经典的方法:Five Hat理论。五帽子法。
- 提前找相关人员进行确认,会议只做决议公示。
- 当然方法很多。这里不加叙述
6. 人人都是产品经理,产品需求经常受到质疑,众人均希望改需求
- 很显然这里有明显的需求不对称,或者设计不合理之处。一致说错,十有八九真的有问题
- 还有一种可能性:管理弱,则出现长期无法就产品功能做出明确划分、功能收拢、功能的独立性就弱
- 感觉上,你发现事情不是一套一套,仿佛什么事情都是要一起考虑。没有明显的区域感
7. 集体因为某个设计笑场,突然大家就乐了
- 很显然,这个设计不是很无奈,就是很扯淡。要么就是谁在合适的时间说了个笑话。如果是针对设计来的笑场,那就要注意了。
- 大家最终可能会因为外部的因素:吃饭啦、上厕所、暂时定不下来。
- 大家为了结束开会,而拼命加速,但后面还是可能要继续开会