产品需求回顾

晚上再回到公司，想看看接下来准备要做的项目，这两天产品需求讲了8个多小时，之前没有经历过这样的会议，突然有点震惊，表现的也不好。

然后再想想，发觉产品经理提到的需求她们提到的东西，我都记得不多了，虽然自己有看了一部分，但是主要属于自己理解，然后问一下组员学到的。想到这两次会议，自己的状态很不好。

对于我自己：

• 初来咋到，代码内部逻辑读的不多，业务熟悉程度不够，直接去讲对业务关联比较多的东西。如果我听懂了，对我帮助很大，但我没有认真听，或者听一会就累了。

• 不要寄希望于别人为你改变什么。入乡随俗，学会适应

我个人觉得这两次会议有不好的地方：

• 时间太长了，对于我不好的地方是消化不了

• 中间夹杂很多讨论，议论， 在说产品需求文档的时候，我觉得一气呵成的去讲产品的内容，哪怕讲错了，先不要停下来。 而如果错了一点点，就停下来产品经理之间的讨论，开发没有参与产品需求的撰写过程，不会知道产品经理在哪里讨论什么东西，如果产品经理相互讨论，最好私下讨论，如果大部分人都不知道产品经理在讨论的点是什么，那么占用的是大家的时间。

• 有谁试过连续上4个小时的数学课？或者中间休息20分钟，上4个小时的数学课吗？

互相换位思考，职责分明，产品经理上面文档又问题，私下讨论，不要在说需求的时候讨论，我没办法参与产品人之间的讨论过程，只能等待消磨注意力。

个人觉得有效率的会议应该是：

• 产品讲需求，开发认真听。

• 文档有问题，讲完讨论好之后再反馈过来。

• 开发有疑问，再去私下讨论或去找产品。

大段的世间用来开会，就和代码集成到一个大的单体架构一样，启动慢，效率低。采用分而治之的思想…大段会议，分成几次阶段性高效的会议.

以上仅仅是个人愚见。

参考三星高效会议：

凡是会议，必有主题；
凡是主题，必有议程；
凡是议程，必有决议；
凡是决议，必有跟踪；
凡是追踪，必有结果；
凡是结果，必有责任；
凡是责任，必有奖罚；
凡是奖罚，必须透明。

最后

毕竟到公司也没有多久，不要太嚣张了，低调，好好做事，不管开什么会，认真听... 硬着头皮也要听。有方法的听，记录着听。