開會雖煩人,但該開的,還是得開好

0 評論 4518 瀏覽 9 收藏 15 分鐘

本文介紹了4類重要的會議類型、闡述了開會的作用以及在小產如何開會的方法。

工作中,估計沒有人喜歡開會,但是無人能從中幸免。

我也很不喜歡開會。開會是非常消耗精力的,全程都要集中精神。就算不是主持會議,只是普通地參與會議,我都覺得非常累人。

每次開完會,回到自己的工位上,總感覺身體被掏空,腦子已經轉不動了,好一陣子什么活都干不了。

但是,我并不排斥開會。

在項目推進過程中,有各種會議需要產品經理參與。有些還需要產品經理來組織、主持。那些必須要參與、必須要開的會議,沒什么好說的。一些可開可不可的會議,我一般是傾向于,如果條件允許,還是得盡量組織各方過來開一開。

有時候因為各種原因,該開的會不開了,我反而會有一絲不安。

這是因為,“開會”雖然煩人,但是真的有用。

一、4類重要的會議類型

“會議”有很多種類型。這里我們只關注與“需求”、“項目”相關的會議。

普通小廠,一般不像大廠那么規范。每個項目,推進流程可能會很不一樣,并沒有一套被嚴格執行的規范。

哪些會要開,哪些不用,會議要怎么開,都是具體情況具體安排,比較靈活,或者也可以說,比較混亂。

概況來說:項目推進過程中,大概有以下4類會議,比較常見,也比較重要。

1. 項目立項的會議

顧名思義,就是評估需求是否有價值,確定是否立項執行。需求的發起人向各干系人闡述自己的想法,然后讓大家評估其價值,商定執行方案。

與會人員根據自身立場,以及自己掌握的其他信息,提出意見建議,補充完善需求內容。這里面,一般沒有我們初級產品經理什么事。我們參加會議,往往只是因為我們需要了解這個項目的各種信息,以便后續設計推進。

我們只是“聽眾”而已。

因此,有時候初級產品經理也可以不參加。等大佬們商定之后,由經辦人把會議結果告知我們就可以了。

2. 明確需求范圍與內容的會議

立項之后,這個項目還是一個粗糙的想法。這時候,產品經理需要制作PRD初稿,將這個粗糙的想法,變成一個范圍明確、效果可預期、內容可執行的方案。

一般來說,這個PRD,10%是立項會議討論確定的,20%是產品經理私下找干系人咨詢討論確定的,還有70%是產品經理自己腦補的。因為大佬們是不管實現細節的。

因此,當產品經理完成PRD初稿后,需要重新召開會議。這一般需要產品經理來組織、主持。會議的主要內容是介紹PRD內容,并討論其中有爭議的部分。

因為開始涉及到執行細節,所以這類會議耗時往往會比較長。一兩個小時以上,都是很常見的。

根據項目情況的不同,這樣的會議可能需要召開好幾輪。討論、修改PRD、重新討論、再修改PRD……

經過多輪會議,最終確定需求范圍以及各內容細節,確定PRD終稿。

3. 面向技術團隊的需求說明會議

雖然在前面的會議中,技術團隊有時候也會參與。但那時主要是負責把控項目的技術可行性。

當需求完成策劃設計,進入開發階段時,有時候產品經理需要組織相關技術同事一起開個會,介紹需求的整體情況。

這時候的重點就不再是討論需求內容,而是明確傳達產品經理的項目要求,并討論各處的技術實現方案。有時候還需要在會議上完成任務分配,確定開發計劃。

4. 圍繞某個具體開發問題的小會議

開發過程中,出現問題,一般我們會在各種工作群中協商討論。如果問題比較復雜,無法在工作群中說明白,這個時候就需要讓各方碰頭開個小會。這類會議,是臨時性的、突發的。

如果是比較復雜的項目,這類小會議會比較頻繁。與會的一般是產品經理和相關的技術同事,有時候也需要業務部門參與。

二、開會的2個重要作用

我們不喜歡開會,一個很重要的原因就是,認為開會沒有用。開會要占用我們的工作時間,影響我們的工作進度。但是同時,卻好像沒起到什么作用,完全是形式主義,為了開會而開會。

比如上面說的,面向技術團隊的需求說明會議。

有時候,產品經理講了一兩個小時,講得口干舌燥,結果下面的技術同事很多都沒有在聽。很多會上強調的細節,之后還是照樣會出錯。

那這樣的會議,又有什么意義呢?

其實,我們認為開會“沒用”,是因為我們對會議“作用”的預期不對。

還是上面這個例子。其實,閱讀和思考,始終都是一個人的事情。產品經理在會上最多也只能說個大概。技術團隊最多也只能聽個大概。會后,還是需要自己一個人,去一字一句閱讀PRD,去思考每個細節的具體實現方案。

那么,開會到底有什么作用呢?

我認為,開會有2個重要的作用:

1. 實現多方同時在線的高效討論

“多方同時在線”,相對應的,就是“單獨私下”的討論。

A向B提出要求。B把要求告知C。C向B詢問某些細節。B發覺自己也不清楚,因為A沒說到這個。所以B又重新去問A。A回復后,B將A的回復告知C。C說B理解錯了,不是這個意思。于是B再重新去問A……

這種可怕的“傳聲游戲”,想必大家在工作中都碰到過。

相對于這種“單獨私下”的討論,將相關的各方拉在一起討論,效率的提高是巨大的。而且,多方一起碰頭討論,還能極大地避免錯誤。

我曾經碰到過這樣的情況:

A誤以為當前系統沒有某個功能,所以在和B的討論中,確定了無需使用該功能的次優方案。

作為執行方的C,他接到B傳達的需求后,就感到疑惑。因為當前系統已經有該功能了,完全可以采取最優方案。

然后C向B詢問。

B明確說了,A在最優方案和次優方案中,選擇了次優方案(雖然不知道理由),這是已經決定好了的事情。

C想,那可能是有其他的限制吧,沒辦法,那就按次優方案來搞吧。

像這樣的誤解,越到后面就越說不清。而如果,一開始大家一起碰頭開會,那么錯誤從一開始就能避免。

2. 確保向各干系人傳達項目需求

比如上面說的,面向技術團隊的需求說明會議。其核心作用,某種意義上講,其實在于:確保有效地通知到技術部門各團隊的各成員:“我們現在要做這個項目了?!?/p>

你可能會疑惑,我們發個工作郵件不就可以了嗎?

其實不然。

我舉個工作以外的例子。

大學時,體育課要上什么,是自己選的。同一個行政班的同學,可能有的人上籃球課,有的人上足球課。我當時上的是排球課,是這個課的體委。這個課有不同專業不同行政班的同學一起在上。每個行政班內有他們自己的體委,管理他們自己班的同學。

有一次,我需要通知大家,下一節課要在室內上理論課。

所以,我通知了各專業各行政班的體委,讓他們自行通知自己班里的同學。作為一個理科生,我看不出這個“信息傳遞”模型有什么問題。但是,最終來上課的人,不到3成。

理由有很多。有的是忘了通知,有的是通知漏了,有的是以為非強制參加……

信息如何準確及時傳達,其實是一件比預想中要復雜得多、困難得多的事情。我們“浪費”幾個小時,把相關人員都聚集起來,告知他們接下來我們要做的工作。大家來了,意味著“知曉”了;然后走了,意味著“同意”了。

后續我們推進項目時,讓相關業務部門配合,讓技術部門各團隊配合,阻力就會比較小。

我之所以說,有時候該開的會不開了,我反而會不安。這是因為,在普通小廠,團隊組織往往是比較混亂的。

如果沒有“確實”地完成告知工作,那么項目推進過程中,很可能會突然發現,部分團隊因為各種你想不到的原因,居然不知道這個事情,工作現在還完全沒有開展。

這就非??膳铝?。

三、普通小廠會議怎么開

普通小廠的會議,一般比較隨意。

一些關于開會的方法建議,在這里很難發揮作用。

會前分發的資料文件,一般不會有人看。

會議流程基本不存在,有時候開會就像是在開下午茶會。

會議記錄這種東西,基本也是沒有的。

但這些都沒關系。我們不需要開一個“規范”的會議,只要能達到目的就可以了。

產品經理需要經常參與各種會議,有時候還需要負責組織、主持。除了一些常見的注意事項外,這里我根據我的經驗,分享2個比較重要的點。

1. 盡可能讓所有干系人參與會議

如上面說的,有時候,會議內容本身不重要,“參與會議”這個行為本身才是開會的目的。所以,當我們在組織會議時,需要盡可能讓所有干系人都參與。

如果項目涉及多部門,就必須讓所有涉及部門都派人參加。哪怕不參與,也得確保該部門負責人知道這個項目。不然,后續各部門間的配合就會出問題。

如果項目比較復雜,或者技術上有難度,就必須在早期的會議上就讓技術部門參與。讓技術負責人提供可行性建議。

如果有些部門平時不太配合,就需要盡早讓其參與到會議中,讓這個項目變成“我們”的項目。

如果這個項目領導很在意,就需要在組織會議的時候,詢問領導是否參加。我們需要盡量讓領導來參加。不然,有可能我們討論了半天,結果偏離了領導的預期。然后領導一句話,所有工作就都白費了。

2. 必須要得到明確的、可執行的結論

普通小廠的會議,沒有嚴格的“會議流程”。

有時候,上一句還在討論這個問題,下一句突然就開始說那個問題了;有時候,對于一個問題,有人說了這個方案,有人說了那個方案,然后大家沒有進行表態,就開始下一個話題了。

我們初級產品經理,是負責具體執行的人。所以,我們需要對“結論”非常敏感。

具體要怎么執行,如果沒有說清楚,一定要打斷大家,提出疑問,讓與會人員給一個明確的結論。

“所以,具體我們是要……,對吧?”

“現在我們說了3種情況,第1種情況是要……,第2種情況是要……,那第3種要怎么處理,現在還沒確定吧?”

具體怎么執行,結論我們一定要確認清楚。

四、小結

開會,本質上是一種信息傳遞的手段。

在組織比較混亂的普通小廠,我認為,很多時候,開會是一種不可替代的溝通手段。

看似低效,其實有大作用。

雖然開會煩人,但是該開的,還是得開好。

 

作者:簡明產品論,微信公眾號:簡明產品論(ID:JianMingPM)

本文由 @簡明產品論 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!