在一個有一定規模的機構內，正式途徑的溝通包括有會議、電郵，隨著科技發展，有些機構也漸漸適應及接受使用即時通訊軟件作為有紀錄的溝通渠道，溝通比以前就更加直接和簡單了。
在項目的框架中，為保持項目組成員之間的資訊同步，必然牽涉溝通。一般在項目中，會議是最主要的溝通途徑。會議是項目組成員需要共同參與的工作，對於項目中較重要的決策，例如項目初期決定產品發展方向，確立項目範圍，時間表，實施框架等，都需要透過會議充份討論，以確保項目組成員的深度參與，訂立合適的項目計劃。初期的項目會議，亦是協助建立團隊的起點，有助成員互相認識，配合後續的分工安排。
隨著項目發展，會議仍然是項目組之間重要的溝通渠道。對於不是放軟手腳做的項目來說，一週最少一次的項目會議是必要的。有持續進展的項目，一周內能發生的事很多，可以積聚不少問題，會議有助讓決策成員聚起來討論和處理問題，同時亦讓項目組成員審視進度，讓項目繼續推進。行Agile的項目，甚至要求每天一次會議，但筆者個人認為會議並不是愈多愈密就愈好，下面會進一步再說。接下來先談一下會議參與成員的安排。
之前在「建立團隊」的篇章亦提過，項目成立時一般會按其核心範圍，訂立需要參與項目的相關業務團隊及系統人員，並透過這些成員的domain knowledge 推進項目。但在實際環境下，項目的範圍始終都會發展至影響一些周邊，如果周邊組員也要同等份量參與項目，這種做法會導致機構內大小項目不能並行，造成浪費，所以我們不能要求每個模組都對項目付出同等的參與程度，反而需要分成核心團隊及周邊成員，適當使用機構內的人力資源。
這個做法對於項目會議的安排尤其重要，每周會議主要是要求項目組核心團隊的參與，對於周邊模組，則應採取按需要而定的策略，切勿強制要求各組成員參與周會。項目經理要控制參與項目會議的人數，盡可能保持在 7-9 人，上限不超過11-13人。但筆者經常也遇到有團隊拉大隊參與會議的情況（單一個部門就7-8人也見過，背後原因可能是寧願浪費時間也不想另作溝通，或者本身團隊內分工不清沒人願意牽頭），但這個也不難處理，因為這種情況來參與會議的人中不少是只參與不發言的，所以控制發言人數在7-9 人也是可以接受的。
另外一點是，項目會議並不是愈多愈好，項目經理更要盡最大努力控制會議的時長。一般來說每周進行的會議應控制在一小時左右，二小時為上限。事實上在進行超過一小時會議後，效率已經會開始下降，超過兩小時效率就更加會大跌。以「嚴控範圍」篇章中所提到的項目為例，這個項目每周會議就是一整個下午，這是相當浪費時間及耗費精力的。事實上，會出現這種長時間會議，對項目本身就是一個警號，首先時間長直接表示的是討論的內容太多而且放在同一個會議上討論，本來就應該要分開不同會議進行。另外再引伸的潛在問題就是項目範圍太闊，而且夾纏不清未能有效分割處理。如果項目長時間會議同時牽涉大量成員參與，問題則更加嚴重，因為大部份人在會議上的大部份時間也是浪費的。
要正確處理項目時間過長的問題，除了全體項目組成員參與的會議，項目亦應該設立個別獨立會議的機制，組織個別成員聚焦討論個別不關乎整體的問題，這亦包括專為周邊模組而開的會議，這可以大大有助減輕佔用全體會議的時間，全體會議亦可聚焦討論較大影響的事項。另外，筆者通常在項目中會刻意安排業務成員與IT成員的配對，確保溝通的過程暢順，這個做法用個別獨立會議進行也會比較容易。當然，更根本的處理方法應該是在項目範圍上設限，或者透過分phase / 分項進行，這樣每個子項目的重點會更加清晰，溝通上亦會更容易管理。
之前在「建立團隊」的篇章亦提過，項目成立時一般會按其核心範圍，訂立需要參與項目的相關業務團隊及系統人員，並透過這些成員的domain knowledge 推進項目。但在實際環境下，項目的範圍始終都會發展至影響一些周邊，如果周邊組員也要同等份量參與項目，這種做法會導致機構內大小項目不能並行，造成浪費，所以我們不能要求每個模組都對項目付出同等的參與程度，反而需要分成核心團隊及周邊成員，適當使用機構內的人力資源。
這個做法對於項目會議的安排尤其重要，每周會議主要是要求項目組核心團隊的參與，對於周邊模組，則應採取按需要而定的策略，切勿強制要求各組成員參與周會。項目經理要控制參與項目會議的人數，盡可能保持在 7-9 人，上限不超過11-13人。但筆者經常也遇到有團隊拉大隊參與會議的情況（單一個部門就7-8人也見過，背後原因可能是寧願浪費時間也不想另作溝通，或者本身團隊內分工不清沒人願意牽頭），但這個也不難處理，因為這種情況來參與會議的人中不少是只參與不發言的，所以控制發言人數在7-9 人也是可以接受的。
另外一點是，項目會議並不是愈多愈好，項目經理更要盡最大努力控制會議的時長。一般來說每周進行的會議應控制在一小時左右，二小時為上限。事實上在進行超過一小時會議後，效率已經會開始下降，超過兩小時效率就更加會大跌。以「嚴控範圍」篇章中所提到的項目為例，這個項目每周會議就是一整個下午，這是相當浪費時間及耗費精力的。事實上，會出現這種長時間會議，對項目本身就是一個警號，首先時間長直接表示的是討論的內容太多而且放在同一個會議上討論，本來就應該要分開不同會議進行。另外再引伸的潛在問題就是項目範圍太闊，而且夾纏不清未能有效分割處理。如果項目長時間會議同時牽涉大量成員參與，問題則更加嚴重，因為大部份人在會議上的大部份時間也是浪費的。
要正確處理項目時間過長的問題，除了全體項目組成員參與的會議，項目亦應該設立個別獨立會議的機制，組織個別成員聚焦討論個別不關乎整體的問題，這亦包括專為周邊模組而開的會議，這可以大大有助減輕佔用全體會議的時間，全體會議亦可聚焦討論較大影響的事項。另外，筆者通常在項目中會刻意安排業務成員與IT成員的配對，確保溝通的過程暢順，這個做法用個別獨立會議進行也會比較容易。當然，更根本的處理方法應該是在項目範圍上設限，或者透過分phase / 分項進行，這樣每個子項目的重點會更加清晰，溝通上亦會更容易管理。
沒有留言:
發佈留言