減少軟體開發中的會議

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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