雖然我不敢斷言,所有的程式設計者都不喜歡開會,但是,可以確定是,起碼大多數的程式設計者都不愛開會。

會議在軟體開發的過程中,有沒有作用?當然有,但是為什麼在程式設計者的心裡,卻感覺相當的惡名昭彰,恐怕還是跟許多人都濫用、誤用了會議,息息相關。

究竟在軟體開發的過程中,應當如何運用會議,使得我們可以得到會議所帶來的好處,而盡量避免它所造成的壞處呢?

開會有其代價,因為,開發者正在進行的工作可能會因此中斷

會議的目的就是要溝通,但會議本身是個強迫性質非常高的溝通方式,因為它會要求所有參與者必須在同時間、同地點一起出現(當然,遠距視訊之類會議方式,對地點的強迫性就沒那麼強了),這使得所有的人,都必須安排或中斷他本來就正在做的事,以便參與會議。

大家都知道,對程式設計者而言,中斷手上正在做的工作之後,必須再花一些時間才能重新再度進入情境,因此。假設有一個三點的會議,程式設計者在午休後從一點開始工作,花了一些時間好不容易進入情況,卻在三點時必須結束正在進行中的事情,而又要等會議結束後,再重新進入情況。因此,時間安排不夠好的會議,會讓程式設計者討厭,自然不足為奇了。

因此,當我們選擇了一個代價這麼高昂的溝通方式時,就隨時都必須要牢記在心:會議的成本是很高的,所以必須換到值得的溝通結果,才有價值。

不用開會,也能掌握開發進度!請善用版本控制系統

當我們透過其他溝通成本更低的方式,就足以達成溝通效果的事情,就沒有必要透過會議來討論。像是什麼呢?例如絕大多數的進度報告。

現在的開發輔助系統其實已經很發達了,透過現成的系統,很容易可以掌握到每一個開發者的進度。就像在版本控制系統上,只要觀察每個開發者的簽入(commit)歷史及內容,就可以知道每個人的開發概況。版本控制系統上的commit內容,就像是工作日誌一樣的作用。身為Team leader或更高階的經理人,只要概略閱讀專案的commit歷史,不僅可以知道每個人的進展,也能大概掌握專案整體的進展。同事之間,還可以交互閱讀其他同事commit歷史及內容,這讓團隊成員間也容易互相了解彼此的狀態。

倘若能有此種系統來輔助,並不需要針對開發者的進度報告會議,那麼安排這樣的會議,基本上就是沒有效率的事情。

我也看過在開發過程中所召開的會議,其目的是想知道產品的整體開發進展,所以,在會議上,安排開發團隊實際展示目前開發出來的產物,以便了解真正的進度。

老實說,在專案的進行中,建立一些里程碑來檢查中間的進行狀態是對的,但是,千萬別把所有的人都拉進這樣的會議當中。我可以明白某些角色在產品未完成前,可能難免會有一些恐懼,擔心產品開發時程會落後,以致於他們想要透過不斷檢查中間產物,以便確保開發的確有在進行當中。

但是,這樣的會議最好的方式並不是把所有的開發者都拉進去會議當中,甚至開發者不應該進到這樣的會議中,因為這最多是由Team leader 或產品經理來和不知道專案進行情況的其他人溝通。

有些會議並沒有謹慎挑選真正需要參與的成員,反而把每個會議都搞得像大拜拜一樣,大多數與會者被迫聆聽著他們一點都不關心的議題,這又怎麼會有效率呢?

所以,千萬不要邀請程式設計者,去參與那些無關的會議,不要忘了,會議的代價是很沉重的。

有許多溝通管道可行,強迫大家在同一時間、地點討論,未必有效率

有很多的議題,在會議開始之前,就可以不斷的溝通、討論。會議並不是唯一溝通的途徑,有任何需討論溝通的項目,可以持續的利用電子郵件、或其他專案討論用的系統來討論。

這類的討論不論是對時間、對地點的強制性都很低,這使得任何一個人都可以挑選一個合適的時間,例如開發者剛完成手邊工作的一個段落,適合把工作情境切換出來時,來進行討論。這能讓溝通的代價變低許多。只有那些無法透過這些系統「非同步」討論、或是反而溝通成本變高(例如,不面對面就會始終雞同鴨講)的議題,才謹慎的召開會議來討論。

但是,無論如何,在會議召開之前,都應該盡可能的利用事先的討論,把會議中需要討論的議題,以及佔用的時間降到最低。

需區分會議的目的是進度或腦力激盪?

就像里程碑的審查會議,應該是在里程碑達成時,就發行一個版本,而這個版本先經過測試人員測試,並且完成具體的測試報告,發送予相關的人員。同時間,關心進度的人員,也多能自行執行操作該發行的版本,並且對於該版本的實際情況建立起一定程度的了解。而在實際會議召開時,就不會發生下列情況:所有的人需要重頭到尾看展示(demo),然後才開始討論問題。

因為,一來是這樣也看不到細節,不見得能找到問題,二來是根本浪費所有人的時間,很多事先可以準備的事情,都應該在會議前完成,而非在會議進行中才來完成。每個人在事前就應該準備好要討論的問題,以及供討論的材料,而不是會議中才來找問題及討論。

更可怕的是,很多會議中的討論時常離題,例如,在產品進度的會議中,部份與會人員又開始天馬行空地發想產品的功能,分明是把產品進度會議,當做產品功能腦力激盪會議來使用。在這種情況下,無疑也是浪費許多人的時間。

但真的最令人害怕的是,有些人習慣用會議感受自己在工作上的存在,因此,他們對於召開會議情有獨鍾。事不分大小、不論需要之有無,一律召開會議。

在一個組織裡,不同的角色被會議傷害的程度是不同的,有些角色本業就是在溝通,因此,會需要參與很多會議,這類的角色被會議傷害的程度就低,甚至不會有太多傷害。但是,正如前文所言,對程式設計者來說,會議會造成工作情境的切換,影響到工作效率。沒事就把他們叫到會議裡,只會讓整體開發一直受到影響。

勿矯枉過正,面對面討論的會議仍要開,有其不可取代的意義

無論如何,會議還是有其正面的功用,有些時候,面對面的討論,還是會比書信往返、文字溝通來得簡單有效。當有此類的需求時,該召開的會議還是免不了,因為在這種情況下,所得的效率,多過於損失的效率。尤其像需要高度互動討論的議題,堅持不開會議,反而是沒效率了。

會議是個工具,運用的好可以增加溝通的效率,反之,則讓效率大打折扣。程式設計的工作有其獨特性,本質上會議的安排會讓此類工作受到影響的程度比較高。

因此,如何運用會議,格外需要留意。當我們時時刻刻都記得,會議一個代價很高的溝通工具時,就會知道應該如何謹慎的來使用它。

作者簡介


Advertisement

更多 iThome相關內容