跨單位年度專案的溝通節奏：例會、回報清單與上線檢查

跨單位的年度專案，參與的人越多，越需要三樣固定的東西：每週同一時段的例會、只有一份的資料總表，以及上線前後各一份的檢查清單。磨人配合教育部專案，在戶外教育資源平臺與 2026 全臺戶外教育季中，開工前就與專案團隊約定這三樣，並把每一項的負責人寫明。

參與的人越多，完成的時間越長

協調成本有研究可以對照。Herbsleb 與 Mockus，2003 以變更管理系統的資料加問卷分析跨據點的軟體開發，跨據點的工作項目完成時間約為同地點的兩倍半。資料指向的機制是跨據點的工作項目牽涉更多人，而牽涉的人數與完成所需的日曆時間高度相關。研究對象以跨地點的開發團隊為主，這裡借用的是人數與完成時間的關係。

跨單位的年度專案，參與者包含主管單位、專案團隊與各參與單位，磨人這端另有工程師、設計與測試人員。牽涉的人多，每一次確認所需的日曆時間通常也長，所以磨人在動工前先把節奏固定下來，讓每項事情最晚在哪個時段能當面對焦，雙方事先都知道。

每週固定時段的例會，暫停與改期也留紀錄

磨人與專案團隊約定每週固定一次的例會。條款、表單這類需要雙方持續討論的事項，都排進這個時段處理，會中記錄與後續處理由專案團隊同仁負責。固定時段讓雙方不必每週重新約時間，也知道問題最晚何時能當面對焦。

Schwaber 與 Sutherland，2020 的 Scrum 指南對產品開發採用同樣的想法：Sprint 是一個月以內的固定長度，Sprint Review 是團隊與關鍵利害關係人討論成果與下一步的工作會議。Scrum 是產品開發框架，這裡取用的是固定節奏讓利害關係人定期看到成果這一點。

Herbsleb 與 Grinter，1999 以一個跨地點的軟體專案為個案，指出最困難的部分是整合，非正式溝通管道中斷會放大協調問題；穩定的計畫、流程與規格有幫助，專案中無法預測的部分則需要開發者能隨時主動發起的溝通管道。每週例會對應前者，例會之外的疑問，磨人收在同一串討論，由雙方隨時提出。

例會需要暫停時也有固定做法。專案團隊因內部會議或說明會暫停，當天在討論串預告，並註明相關事項延到下週討論；磨人這端遇到臨時改期，也同樣貼出通知。必要時改約下週另一天，排程有衝突時在同一串提出，確認後改回原時段。多次暫停與改期都循同一方式處理，待辦事項不會因為少開一次會而沒有去處。

活動與課程資料只維護一份總表

年度專案的活動與課程資料來自多個單位，每月滾動更新。磨人與專案團隊的做法是由專案團隊在共用總表維護資料，每月更新後在例會回報，磨人依總表匯入；例會暫停時，改在討論串補報。資料需要調整時，先約定直接改總表或個別回報，磨人在正式站更新時一併處理。

Lee 與 Kim，1999 以 74 組外包關係檢驗，夥伴關係品質可預測外包成功，而參與、溝通、資訊分享與高階主管支持對夥伴關係品質有正向影響。共用總表是資訊分享的具體做法之一，兩邊不必各改各的。該研究年代較早，這裡取用的是溝通與資訊分享影響外包成功的方向。

每月初的分工同樣固定。專案團隊開放下一個月的活動資料，彙整各單位滾動更新的內容後上傳，磨人排定動工與完成時間，再把當月活動切換為上架並開放該月頁面，每月活動在預定時間上架。總表背後的合併、去重與編號設計，另見 跨單位活動的資料整合。

上線前的通知、條款與宣傳時間點

新平台切換前，磨人專案窗口先列出前置作業：公告停止後台編輯、通知維護、寄信給所有場域人員與管理員，並在新站與舊站公告、同步發布到社群，之後才正式上線並發新聞稿。清單附上負責人與完成勾選，由另一位專案協調者逐項確認。信件內容由專案團隊擬稿，磨人調整後由工程師寄出。

上線若牽涉主機調整，要提早通知主機的維運窗口。窗口在專案團隊那端，磨人建議由專案團隊出面通知。

上線前一日，磨人提醒專案團隊把網站的服務條款與隱私權條款也更新一版，列為上線前檢查項目之一，隨新功能需要同步修改的條款文字，由這項檢查一併處理。

對外宣傳的時間點，磨人建議訂在辦法全部確認、工程端調整完成之後，並搭配動畫影片與懶人包圖文同步釋出，宣傳內容與實際功能才會吻合。專案團隊同意後，由磨人著手設計宣傳素材。專案團隊也會提供年度行銷行事曆，逐日列出功能建置、宣傳信製作、社群發文、資料上傳與正式上線的時程，需要與磨人討論活動辦法與規則文字的項目，直接排進雙方的時間表。

功能上正式站當天，上線、後台名單與對外溝通在同一天銜接：磨人預先提供對應的發文圖片，專案團隊在當晚開獎後到後台查看本週名單，再發布限時動態與公告。活動期間平台本身的做法，見 全國活動的平台做法。

修正完成後先通盤檢查，正式站每週最多更新一次

專案團隊的回報項目集中在共用的回報清單。清單上的項目全部修好後，磨人先自己通盤檢查一遍，確認同一輪的修正之間沒有衝突，再通知專案團隊複驗。這個安排減少專案團隊逐項驗證的負擔。專案團隊複驗後回覆目前沒有問題；後續網站更新，磨人也主動請專案團隊試用新功能，前台與後台皆回報成功。

正式站上線後，磨人專案窗口宣布改為每週最多更新一次，並在追蹤卡片新增「測試完成，準備上正式」狀態。工程師調整後先上測試站，測試人員驗過就標記這個狀態，待工程師部署到正式站，再把卡片移到已完成。測試內容主要由磨人進行，專案團隊表示可以接受，流程自此生效。固定部署頻率，讓雙方知道何時上線，測試與上線也分成兩個動作。

對外素材一次備齊，提早一週確認

每期活動推薦的貼文與影片，磨人先在討論串貼出完整草稿，專案團隊逐項核對機構正式名稱、聯絡窗口、時間與報名方式，並以條列回覆需要調整的字句。磨人當天修正，專案團隊確認後排定發佈時間，貼文常以每週一到兩批的節奏，在草稿當天或隔天排定。

之後磨人盡量提早一週提供確認，一次附上下週三篇貼文與影片，專案團隊當週確認內容，由磨人排程。整批貼文則由磨人一次做完，請專案團隊一次確認全部，專案團隊再轉請顧問一併審閱，逐篇往返的次數因此減少。討論串裡留下的確認紀錄，整理方式見 專案溝通紀錄的做法。

不適合的情況

固定例會、單一總表與上線檢查清單，適合多方參與、需要持續更新的專案。以下情境用較簡單的方式處理即可：

• 單次交付、交付後沒有後續更新的專案：不需要每週例會，在交付時一次驗收。
• 只有一個窗口與一個開發團隊的專案：一份共用清單與一個討論串就能涵蓋溝通。
• 需求與範圍仍在比較方案的階段：先做評估與範圍確認，再訂節奏。

開始前要準備什麼

開工前，磨人與專案團隊先約定下列事項：

1. 例會的固定時段，以及暫停或改期時的預告方式。
2. 資料總表由誰維護、每月何時更新、更新後在哪裡回報。
3. 上線前檢查清單的項目與每一項的負責人，包含要通知的主機維運窗口與服務條款、隱私權條款的更新。
4. 對外宣傳的時間點，訂在辦法確認與工程端調整完成之後。
5. 正式站的更新頻率，以及測試完成的標記方式。

磨人也會在動工前約全員開一場一小時的專案 kickoff 會議，說明彼此分工、前後端資料溝通方式與前端設計稿的部分頁面，後續疑問都回在同一串討論，各位成員在串內確認出席。磨人在 長期維運與平台建置 的專案中，把這些項目當成開工前的固定動作。

參與單位與上線時程確定後，可以帶著時程與參與單位的清單，與磨人討論專案節奏，逐項確認哪些做法適用。