産品需求回顧

晚上再回到公司，想看看接下來準備要做的項目，這兩天産品需求講了8個多小時，之前沒有經曆過這樣的會議，突然有點震驚，表現的也不好。

然後再想想，發覺産品經理提到的需求她們提到的東西，我都記得不多了，雖然自己有看了一部分，但是主要屬于自己了解，然後問一下組員學到的。想到這兩次會議，自己的狀态很不好。

對于我自己：

• 初來咋到，代碼内部邏輯讀的不多，業務熟悉程度不夠，直接去講對業務關聯比較多的東西。如果我聽懂了，對我幫助很大，但我沒有認真聽，或者聽一會就累了。
• 不要寄希望于别人為你改變什麼。入鄉随俗，學會适應

我個人覺得這兩次會議有不好的地方：

• 時間太長了，對于我不好的地方是消化不了
• 中間夾雜很多讨論，議論， 在說産品需求文檔的時候，我覺得一氣呵成的去講産品的内容，哪怕講錯了，先不要停下來。 而如果錯了一點點，就停下來産品經理之間的讨論，開發沒有參與産品需求的撰寫過程，不會知道産品經理在哪裡讨論什麼東西，如果産品經理互相讨論，最好私下讨論，如果大部分人都不知道産品經理在讨論的點是什麼，那麼占用的是大家的時間。
• 有誰試過連續上4個小時的數學課？或者中間休息20分鐘，上4個小時的數學課嗎？

互相換位思考，職責分明，産品經理上面文檔又問題，私下讨論，不要在說需求的時候讨論，我沒辦法參與産品人之間的讨論過程，隻能等待消磨注意力。

個人覺得有效率的會議應該是：

• 産品講需求，開發認真聽。
• 文檔有問題，講完讨論好之後再回報過來。
• 開發有疑問，再去私下讨論或去找産品。

大段的世間用來開會，就和代碼內建到一個大的單體架構一樣，啟動慢，效率低。采用分而治之的思想…大段會議，分成幾次階段性高效的會議.

以上僅僅是個人愚見。

參考三星高效會議：

凡是會議，必有主題；

凡是主題，必有議程；

凡是議程，必有決議；

凡是決議，必有跟蹤；

凡是追蹤，必有結果；

凡是結果，必有責任；

凡是責任，必有獎罰；

凡是獎罰，必須透明。

最後

畢竟到公司也沒有多久，不要太嚣張了，低調，好好做事，不管開什麼會，認真聽... 硬着頭皮也要聽。有方法的聽，記錄着聽。