項目管理 - 溝通的管理（二）

早前開始了「溝通管理」的系列，亦提到會議的重要性。在項目過程中，一般我們認為採用會議的模式，可以確保各個項目組成員同步，即時討論及交流項目上一些重要決策信息。與此同時，項目經理在會議上可直接觀察到成員的反應，能判斷溝通的成效及作出調整，例如安排更進一步的討論或作出說明。

不過，我們也要了解以項目成本來說，會議實際上是相當「昂貴」的溝通途徑。為確保會議進行有效討論，以及訊息即時傳遞，通常會議也需要大部份成員出席，假設一個八人會議開一個半小時，就已經用了12個man-hour，這是可以做很多事情的時間，因此我們經常要提醒自己，要想項目能有實則推進，要嚴控會議的時間，讓團隊有足夠時間處理實務工作。

那麼除了項目會議之外，有哪些途徑可維持溝通而又不太耗費大量時間呢？首先我們從學術角度，先認識一下在實際環境中比較常見的幾種溝通模式。

1) Chain-Model
顧名思義，Chain Model 是鏈狀的溝通，溝通只與旁邊的Node發生，不會進一步超越。常見的實際情況是用戶跟IT 部門各自有PM / Leader，即Business PM / Technical Lead，用戶跟IT的溝通主要都由Leader 負責，其它同事則負責執行，有問題就向各自Leader 匯報，同事之間則不會互相溝通。

2) Wheel-Model
這一種是輪狀的溝通，這種溝通模式在實際環境下是Project Manager 處於正中，項目組其它同事則圍著PM。各個同事都只會跟PM溝通，而PM則負責把信息傳送至需要收取的聽眾。

3) Network-Model
這種模式假設所有組員都會互相溝通，每個信息也會發送給組內的所有人員。這種情況除了是會議，也可以在即時通訊軟件的群組內實現。

從以上各種模式來看，Chain-Model 和Wheel-Model 會有較多的間接對話，Chain-Model 情況尤甚，明顯壞處是有機會導致溝通的過程中出現錯誤，兩層是可以接受，三層或以上則應盡量避免。不過好處是可以保證PM對所有溝通都有掌握，不怕出現災難。

Wheel-Model 假設所有溝通都需要經過中間的PM，這會很大機會讓PM overload，雖然能掌握所以項目細節，但卻反而很大機會變成項目推進的bottleneck。

Network-Model 是可以直接對話的模式，不過在實際情況中反而不常出現，原因是對話內容中會有不少並不是需要所有人接收的內容，這個Model 反而會出現大量雜音，也很難確保所有人接收信息得到同樣的理解。

在實際情況，即使在同一個項目團隊，我們通常都需要多種模式，建議做法是項目整體使用Network-Model 作重要信息溝通，與此同時在項目中分為小組使用Chain-Model。原則上除非必要（如項目組員之間有心病），不建議使用Wheel-Model。

在「建立團隊」的篇章中提過，機構中很多情況下業務部門與業務系統會以一個既定的組合關係出現，而我們亦需要刻意讓這種關係出現在項目中，讓業務需求由正確對應的人員負責落實，這很適合用於項目分組上。

另外，我們也可以應用「踩單車」及「跑馬仔」的理論，分別管理各個分組的運作，建立合適的溝通模式。分組的好處是可以讓各分組選用不同的模式運作，這樣項目運行也會更為靈活。