今天，和大家聊聊開會這件事，看似簡單實則很難的一件事。

作為一名產品經理，工作中會涉及各種各樣的會議。和老板的會、和運營的會、和設計的會、和技術的會，還有產品內部的各種會。所以開會對于產品經理來講，是一項很重要的技能。

說實話，我自己剛開始是個特別恐懼開會的人，尤其是自己主持的會議，怕hold不住全場，怕冷場。隨著開會次數越來越多，不斷碰壁踩坑，也算總結了一些經驗。今天分享給大家，希望對大家有所幫助。

產品經理的日常會議包括哪些？

我們先來看看產品經理的日常會議有哪些，比如：需求溝通會、需求評審會、設計評審會、需求排期會、需求宣講會、項目復盤會等等等（每個公司對于會議的稱呼可能不同）。

接下來簡單給大家介紹幾個會議：

• 需求溝通會：主要是產品和老板、運營之間溝通需求的會議。經常溝通的內容包括產品版本需求、運營后臺的需求、還有一些活動需求。這樣的會議，在一個需求確定前，可能需要反反復復開幾次。產品運營多多溝通，可以有效降低需求理解偏差。
• 需求評審會（運營）：當我們產品人員把需求轉化為具體的功能界面后，便需要再和運營/老板/技術去開會，看看是否滿足需求。這個會議，可以讓我們從多方維度來思考這個功能的設計，讓其更加完善。
• 設計評審會：設計師主導的會議，召集大家評審設計圖，確定定稿方案。這個會議可以有效降低設計圖改改改的次數，讓公司各部門對上線后的效果有預期。
• 需求宣講會：產品主導的會議，參會人員是技術人員。這個會議主要是為開發講述接下來版本要做的功能，讓大家對功能有心理預期，以便于接下來的工作量評估。會議內容包括需求背景介紹，功能流程講解，數據的來龍去脈，一些特殊狀態限制條件等。
• 需求排期會：這個會議一般是和需求宣講會在同一天完成，技術針對宣講會上的需求，進行工作量評估，最終確定人員排期以及預計上線時間。版本上線時間確定了，一來可以讓團隊進度更可控，二來可以讓公司各部門更好的安排工作計劃。
• 項目復盤會：這個會，相信不用我多說什么了。大家都知道復盤的重要性，通過復盤，我們可以發現每個版本過程中的問題，找到解決方案，讓團隊協作更高效。

其實，上述大大小小的會議，均涵蓋在2類會議中：一個是自己主持的會議，一個是自己參與的會議。在這2類會議中，自己所處角色不一樣，所需具備的技能也不一樣。

怎么主持會議？

主持會議，這真是我工作后的一大難關。

作為會議主持人，全場的焦點聚集在你的身上，要負責把控整個會議的進度，調節會議氣氛。聽著好像不難，但在實際會議中，因參會人數較多，你一不留神就…跑題了，就要想辦法把討論內容重新拉回正軌，還會有冷場啊，會議時間無限拖延啊等情況。所以想要主持好一次會議，還是需要不斷的練習和總結經驗。

接下來，我們先來看看那些低效會議是怎樣的，存在哪些問題，以及自己的一些建議。

低效會議1：缺乏背景介紹，直接開始講細節

我們先來看看這種開會場景，如下：

事例中講到的是一次技術需求宣講會，產品經理在沒有做任何功能背景介紹的前提下，一上來就說xx功能需求是怎樣的，涉及的改動點有哪些。

從技術需求的角度來看，開發人員確實最想了解的是下個版本增加修改了哪些功能，涉及哪些改動，自己的工作量如何等。但是如果這些細節的改動脫離了需求背景，便很可能導致會議只圍繞細節功能點去討論，而忽略用戶真實使用場景和流程，最終很容易導致有些場景技術上考慮不全。

（或許你會感覺上述場景似曾相識…）這是我剛開始參加工作的時候，時常犯的一個錯誤。結果就是，給大家講的一臉蒙圈…還需要反反復復再溝通幾次，大家才理解需求。

因為參會人員沒有參與之前的需求討論，如在會議開始時，我們不做需求來源和整體性的介紹，便會導致大家對全局沒有概念，缺乏對產品功能宏觀層面的理解，容易鉆進細節之中，導致遺漏。

建議：在會議開始時，需要做一些背景介紹，流程介紹，讓大家有整體感，做到心里有數。因為這樣，大家思考的維度就不會局限于功能本身，會更開闊更全局的去思考問題。

低效會議2：缺乏會議主線和計劃

我們先來看看這種開會場景，如下：

這次會議，是給我印象很深的一次會議。記得當時給我的打擊很大，開會之后整個人就很低落。因為會議時間比預計的長了將近2個小時，最后大家都無心在聽產品方案了。雖然會議結束確定了最終方案，但是回想整個會議過程，會議失控的讓自己想找個旮旯兒鉆進去…

好了，我們來說說這個會議的問題吧。

首先，會議缺乏計劃

在會議開始前，我并沒有想清楚整個會議的每一步該如何進行，沒有在腦海中演練過一遍。作為會議主持人，如果腦子很混亂，那么一場會議又怎么可能會清晰呢？

所以對于臨場發揮能力不是很強的各位，在開會前，務必要把整體流程過一遍，讓自己的思路清晰。只有這樣，才能更清晰的傳達給其他參會人員。

其次，會議缺乏主線

在會議中，逐一討論了各部門的計劃和方案，但是缺乏一個核心。既然是產品主持的會議，核心肯定是溝通產品方案。所以在會議開始時，需要首先表達自己的觀點和立場，這樣大家可在此基礎上去做延伸和建議，而不像上述會議中那樣，有很多天馬行空的跑題和無效討論。

建議：

（1）會議開始前，制定會議計劃

會議開始前，在腦中過一遍會議流程，預計的發展是怎樣的，每一步每個節點要做什么，如何講述才能讓大家清晰明了。這些，都是需要在會議前想好的，否則會議失控的讓你想找個旮旯兒鉆進去。當然，除了失控的場面，還有可怕的冷場，最怕空氣突然安靜，空氣中充滿著尷尬。如何化解冷場，這就要看會前資料準備情況和臨場發揮了。

（2）會議開始前，確定每個議題的預計時長

如會議中，大家在某個議題上討論時間過久，便要中止討論，以免造成會議時間延長過多。畢竟大家有自己的每日工作計劃，如你的會議比預期時間延長了很多，一是耽誤大家的工作，引來不滿，二是會議效率較低。

（3）會議開始時，明確會議主線

作為會議主持人，在會議開始時，要首先表達自己的觀點。不然就會被動的跟著別人的思路走，便很容易失控（具體看會議目的是什么，需具體問題具體分析）。

低效會議3：會議目標不夠明確／目標過多／目標太大

在會議前，沒有想清楚會議目標是什么，即本次會議要達到什么樣的效果，得出什么結論。如果這些沒有明確，那么很可能導致開了很久的會議，最終卻無結論。整個會議等于白開了，制定不了下一步的工作計劃。

如果會議目標太多，便很可能導致每一個目標都討論不完整，不夠清晰。而會議目標太大，會導致討論很久都遲遲定不了結論，因為目標過大，所以涉及的內容必定會很多，便沒辦法當下拍板確定。

建議：

1. 在制定會議時，便要想清楚，召開這個會議的目的是什么，要達成什么效果，得出什么結論。
2. 每個會議達成一個主要目標即可，切記不要目標過多，因為目標過多，很可能導致最終沒有一個完成。
3. 會議目標不要太大，太大的目標讓人感覺很空，范圍很大，且可討論的內容很多，在一次會議上很可能討論不出結論。每次會議制定可落地的小目標即可，如想達成的目標很多，那就分幾次會議，這樣會更高效一點。

通過如上幾個真實會議場景，給大家講述了主持會議的一些建議。當然，會議基本的提前邀約（會議目的、流程&議題、時間、地點、參與人員等），會后會議紀要就不在這里贅述了。

如何參與會議？

是不是有時候在會議上一臉蒙逼？搭不上話？當被會議主持人Q到的時候，大腦一片空白，不知道該講些什么？聽會議上其他人講述觀點，自己也沒什么好的想法？

這說明一個問題，會前沒做準備，沒思考??！

你以為大家會上滔滔不絕的言論都是臨時想到的嗎？

大部分可以在會上表達自己想法的人，多多少少都是在會前做了準備，仔細研究了會議議題。只有這樣，才能更好的理解議題，因為在會前有充足的時間去思考。

所以，想要在會上沒有那么丟人，老老實實在會前研究和思考下會議議題吧。這也是對于會議的尊重。

總結

一場低效混亂的會議，簡直是噩夢，而且浪費大家的時間。所以我們在主持會議和參與會議時，要扮演好自己的角色，讓會議更高效。

主持會議

（1）會議前

• 提前邀約：發送會議時間、地點、目的、流程、議題、資料文件、與會人員等信息；
• 做好充足準備：包括明確會議目標、制定會議主線和計劃，明確會議流程，確定每個議題時間等。

（2）會議中

• 先做整體性介紹，包括背景介紹、流程介紹等；
• 注意把控每個議題的時間和進度，防止跑題；
• 當某個議題進行不下去或討論時間過久時，需考慮跳過，留作會后討論或思考。

（3）會議后

發送會議紀要，明確下一步工作計劃。

參與會議

• 會議前，詳細查看和思考會議議題；
• 會議中，積極表達自己的觀點，參與討論。

如上內容，是自己工作這幾年對于會議的總結，希望對你有所幫助。開會是產品經理甚至每個職場人的必備軟技能之一，想靈活運用這門技能，就需要不斷的去練習和踩坑積累經驗。

大家加油吧～

相關閱讀

如果你不知道交互說明怎么寫，推薦閱讀：

一份完整的交互說明包含什么（上）

一份完整的交互說明包含什么（下）

如果你對原型排版有疑惑，推薦閱讀：

?什么樣的原型更受開發歡迎？

作者：拾月，4年產品交互設計經驗，微信公眾號：用戶體驗研究所（ID：PM_Cynthia）

本文由 @Cynthia拾月 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Pixabay，基于 CC0 協議