(此圖由AI產生)

今天來聊聊專案制工作中最重要的一環：「溝通」，依據 PMI 所述，PM 有大約 90% 的時間都在進行溝通，這裡的溝通包含但不限於口頭、書面、寄信、會議，甚至如寫文件(因為文件是要給人看得嘛）..etc，也就是說「溝通」是指所謂的「資訊傳達」這件事。

由於在專案生命週期中，所有成員的溝通效率會直接影響到專案的成功率，在 PMP 的十大知識領域中，「溝通管理」即是負責確保專案中的所有資訊能夠準確、即時地傳遞給所有相關方，避免因溝通不良導致錯誤決策或延誤的一連串行動。

專案的溝通管理主要有三個流程，這三個流程有不同的目標和活動，確保所有成員都能做到有效的資訊交換，分別是：

• 規劃溝通管理
• 管理溝通
• 監控溝通

流程一：規劃溝通管理 Plan Communications Management

規劃溝通管理可以拆成數個子分類，我們一個一個來看：

1. 溝通需求分析

根據專案的範圍、規模、複雜度及利害關係人的期望，分析與確定誰需要什麼樣的資訊，什麼時候需要，以及通過哪種方式獲得這些資訊。

這個分類有一個常見考題，就是要計算溝通管道數量。例如，假設專案中有20人，請問有多少不重複的溝通管道。這裡的溝通管道是指每兩人為一個溝通管道，所以20人就是 n(n−1)/2 = (20 * 19)/2 = 190

但說真的算這個管道數量就試圖個理論長知識，我們實務上還是盡量遵守價值導向來進行專案溝通就好..，

2. 溝通技術

關鍵字是：急迫性、可用性、專案環境、機密性與敏感度..etc。

面對不同情境要選擇合適的溝通技術或工具，比如說，如果是遠端工作要討論專案，那即時視訊的溝通方式，相比聲音又多了一個視覺畫面可以利用展示，絕對會比單純電話溝通更有效。

3. 溝通模型

關鍵字是：編碼、訊息、傳遞形式、雜訊、解碼

理解和設計溝通的基本流程，包括編碼（傳達意圖）、訊息（傳達內容）、傳遞形式（工具或媒介）、雜訊（干擾因素）和解碼（接受方的理解）。這些模式確保資訊能被正確接收和理解，減少溝通過程中的錯誤和誤解。

例如我要轉頭和同事溝通一件事情：「我 approve 你的 PR 囉」

這件事情在我腦海中整理並傳達出來的過程就是編碼，整理與組織好的資訊就是訊息，由於我們是用口頭講的，所以夠過我的嘴巴講出來就是指傳遞形式，雜訊可能是如辦公室的吵雜聲導致同事一開始沒聽清楚，或者是他一開始戴耳機沒注意到我在說話，解碼則是對方聽到並且消化完理解含意。

4. 溝通方法

關鍵字是：正式、非正式、書面、口頭。

不同的溝通方法可以區分成正式、非正式、書面、口頭四種，在不同的情境使用不同的溝通方法，例如跨部門專案進度報告中，可能會使用正式的書面報告，而在 WFH 遠端工作團隊內部的日常溝通中，則可能是採用非正式的即時通訊居多。

5. 人際與團隊技巧

關鍵字是：聆聽、協商、EQ、同理心..etc。

以促進有效的溝通和解決衝突為目標，良好的人際技巧能幫助 PM 在複雜的專案環境中建立信任和合作氛圍，從而提升專案的整體效率。

6. 溝通管理計畫

制定一份完整的溝通計劃，記錄各類溝通活動的詳細資料，包括需要的資訊、發送頻率、方式、責任人等。這個計畫是專案溝通管理的基礎文件，確保專案的所有溝通活動有序進行。

能制定溝通管理計畫當然很好，但我們也要注意不要淪為形式，如果人數或專案規模並不大，並且也沒有涉及外部廠商，純粹是內部專案，那還是盡量以價值導向為主。

反過來說，如果是涉及外部廠商業務，通常就會事先擬定溝通管理計畫，把當事人的名稱、公司、聯絡管道或方式(手機或信箱)都整理在一份 EXCEL 上，那這份計畫對團隊其實也就很有幫助了(可能稱之 XXX 名單或 XXX 清單之類的。

流程二：管理溝通 Manage Communications

1. 溝通技巧

PM 需要靈活運用各種溝通技巧，如公開演講、書面報告、視覺輔助工具等，來確保資訊能被有效傳遞給不同的利害關係人。例如，對於需要說服高層的報告，PM 可以結合簡報和圖表，讓資訊更直觀明瞭。

2. 專案報告

建立溝通渠道並進行實施，如召開定期會議、發布進度報告等，確保所有成員對專案進展有充分的了解。比如定期進行的 Sprint 會議，可以讓所有團隊成員同步了解進展和遇到的問題，確保大家在同一節奏上。

3. 專案溝通

記錄所有溝通內容，包括會議記錄、電子郵件、規格文件等，並按照組織的文件管理規範進行存檔。這些文件不僅是專案溝通的依據，也可以為後續的專案績效評估提供參考。

流程三：監督溝通 Monitor Communications

監督溝通是持續性的行為，要根據溝通狀態與專案狀況即時更新調整溝通計畫或者根據觀察到的狀況，盡量弭平資訊的落差。

例如，如果團隊成員對某些技術或功能細節有誤解(最常見就是團隊成員是後來加入的)，不理解專案或特定維護功能的前因後果或歷史背景故事，那 PM 就應該和對方說明。

如果 PM 也是後來加入的，那就應該和該成員一起尋找部門內相對資深的成員或技術主管諮詢，想辦法了解 context 脈絡背景，才好對當前的專案有更高的掌握度。

並且溝通的風險應對同樣重要，包括因文化差異、語言障礙或技術故障，例如大家都 WFH 遠端工作，如果通訊軟體壞了怎麼辦？如果 ZOOM 爆炸了，還有 Google Meet 可用，Google Meet 後面還有 Slack huddle 的備案，真的萬不得已，還有 LINE 電話（先澄清：LINE 不是也不該當成工作軟體，所以這裡說萬不得已）或直接手機打電話的方式可以溝通。

PM 需要提前識別這些風險，並準備相應的應對措施(至少放在心裡某個角落)，以減少對專案的影響。

結語

溝通也要避免形式主義，例如：主管要求員工寫日報呈上，我認為這就是傳統但不一定有效的溝通方式。日報的目的是為了讓主管了解每日進度和遇到的問題，但你我心知肚明，主管可能不會每天都仔細閱讀這些日報。如果日報只是為了形式而做，那它就會浪費團隊成員的時間。

更有效的方案是 Stand Up Meeting 站立會議，這種方法可以讓團隊成員即時分享進度和問題，還能讓大家做到資訊的互通有無。

這也是為什麼現在大部分軟體公司都有實施 Stand Up Meeting 原因 (此次鐵人賽我不會介紹 Stand Up Meeting，因為太常見了)，它的實行成本很低，不管是敏捷、瀑布還是混合都可以加入。以筆者我而言，過往待過的三間公司都有實行 Stand Up Meeting 制度：可能是 PM 每日對負責專案召集成員開會，也可能是技術主管每日召集 Team 內團隊成員開會了解大家進度。

甚至，當筆者以公司研發部門的 Hub 身份與 PM 對外，和母公司、外包公司，三間公司齊頭開發某個大專案時，也是每週固定幾天與兩間公司開 Stand Up Meeting。

回到開頭說的「日報」，Stand Up Meeting 也可以做會議紀錄，例如筆者目前所在公司，每天站立會議 PM 都會快速紀錄每個人狀態在 Jira 留言區上，假如主管今天想看大家狀況，可以通過會議紀錄了解主要狀況，去對應的 Jira 票號一路下翻就可以看到每天站立會議的簡短紀錄，這種做法都比要求員工寫日報上呈好多了，不僅能促進團隊成員之間的互動，還能避免資訊煙囪效應，讓每個人的方向盡量對齊。

所以真正有效的溝通管理應該避免走形式主義，而是應該選擇能夠達到目的、創造價值的方式。重點是選擇適合的溝通方法，確保資訊能準確、即時地傳達。