文章目錄
先說結論：溝通失靈不是量的問題，是設計缺席——一張四欄矩陣（誰、什麼、多常、什麼格式）加一條推拉分流原則，就是溝通計畫的最小可行版。
先看那個矛盾的現場：同一個專案裡，生管課長抱怨「改上線日怎麼都沒人告訴我」，同時業務助理抱怨「專案群組一天九十九則，誰看得完」。資訊爆炸跟資訊斷糧同時發生——因為這個案子的溝通方式是「什麼都丟群組」：簽核、進度、決議、貼圖、抱怨全在同一條河裡流，重要的事跟早安圖用同樣的音量講話，結果就是誰都聽不到重要的事。
台灣專案的經典災難場景：要在 Line 群組五百則訊息裡，考古三週前「到底誰說要改規格」。我看過太多案子的「溝通紀錄」就是這條河——然後大家怪 key user 不認真看訊息。不是他不認真，是你把聯絡簿寫在相簿裡。
溝通矩陣：四欄，開案填一次
小學老師是溝通設計大師：重要的事寫聯絡簿（家長要簽名，賴不掉）、活動照片放班級相簿（想看的自己看）、緊急的事才打電話。三條管道各司其職，沒有家長會漏接大事。你的專案值得同樣的設計，格式就四欄：
| 對象 | 內容 | 頻率 | 格式 |
|---|---|---|---|
| 老闆 | 進度／風險／需要他的 | 週 | 三行週報（向上管理那篇的格式） |
| 指委會 | 裁決題＋儀表板 | 月 | 議題單＋紅黃綠一頁 |
| 部門主管 | 影響他部門的事＋要他配合的事 | 雙週或逆事件 | 短信件，一事一信 |
| key user | 進度＋接下來要他做什麼 | 雙週 | 固定格式的短通知 |
| 專案團隊 | 日常協調 | 日 | 站會或群組 |
| 全員 | 里程碑公告（上線日、凍結期） | 逆階段 | 正式公告（老闆名義發） |
三個設計原則：每個對象一種主打格式（老闆的資訊入口就是週報，別今天信件明天口頭後天群組——入口固定，他才會養成看的習慣）；內容欄寫「他需要什麼」不寫「我想講什麼」（key user 不需要知道全案進度，他需要知道「下週三要你驗收這三張單」）；頻率是承諾（寫了週報就全年不斷線；斷過一次，這條管道的信用就開始漏水）。
推與拉：溝通計畫的核心分流
矩陣填完，還有一個更底層的設計題：每條資訊，用推的還是用拉的？
- 推（push）：主動送到對方面前——週報、確認信、公告、電話。特性是打擾，所以要省著用。
- 拉（pull）：放在固定的地方，等人來查——進度儀表板、共用資料夾、FAQ 文件。特性是安靜，所以要放對地方。
判斷式一句話：需要對方「動作」的，推；供對方「查閱」的，拉。 要他簽核、要他出席、要他提供資料——推，而且推到他面前還要有回音機制（確認信的「未回覆視同同意」就是回音機制的極致版）。進度長怎樣、文件在哪、名詞什麼意思——拉，放在大家知道的固定位置。
兩種失敗都很常見：全推的案子，人人被轟炸，兩個月後所有通知都被已讀不回，你把「狼來了」喊成了日常；全拉的案子，「我都放在共用資料夾了啊」——自助餐開了沒人去拿，然後你怪大家不自助(資訊自助餐的生意，從來都不好)。健康的配比是推的少而重、拉的全而穩：推播只留給需要動作的事，其他一律沉澱到拉取層。
台灣特別條款，單獨立法：Line 群組只做即時協調，決議一律離開群組。 群組的本質是對講機，不是公文系統——「群組裡的決議不算決議」，因為它三週後就被淹了、新加進來的人根本看不到、換手機沒備份就整段蒸發。群組裡吵出結論的當下，動作是把結論搬進會議紀錄或確認信（推），或搬進決議追蹤表（拉）。文件武器庫那篇的單一事實來源，就是決議離開群組之後要住的地方。
維護：矩陣也要保鮮
溝通計畫開案定版，兩個時機要檢視：人事異動（換了主管，他的資訊入口偏好可能完全不同——有人愛信件有人只看紙本，問一次，照調）；漏接事件（有人喊「沒人告訴我」時，先別怪人，回頭查矩陣：他在對象欄嗎？那條資訊走推還是拉？多數漏接追下去都是矩陣有洞，怪人沒有用。把洞補上，同款漏接就絕版了）。
遠端與跨據點的案子，溝通矩陣要再多一層設計（產出物驗收、時差、據點代表），那一篇專門寫過，這裡不重複。
本篇工具帶走：矩陣模板＋推拉判斷式
- 四欄矩陣：對象／內容（他需要什麼）／頻率（是承諾）／格式（一對象一入口）。開案填一次，異動時檢視。
- 推拉判斷式：要動作→推（含回音機制）；供查閱→拉（固定位置）。推的少而重，拉的全而穩。
- Line 條款：群組＝對講機。決議出群組，進紀錄。
最後說一句：溝通計畫做得好的案子有個特徵——很安靜，但沒有人狀況外。每個人都剛好知道他該知道的，不多不少，像一份寫得剛剛好的聯絡簿。就這樣，去把群組靜音吧！
