人才發展 · 週會改革手冊與實作紀錄
週會開完只有進度報告？把議程改成「要決定的事」，留下可追蹤行動
將議程依資訊同步 I、協調 A、決策 D 分流，建立決策紀錄與具驗收結果的行動台帳
本文目錄
先把每一項議程分成 3 種，而不是按部門排隊用 6 個議程示範：哪些根本不必進會議？決議與待辦，不能存在同一個模糊欄位下週就能實作的 30 分鐘會議設計下載、核對與成效衡量來源與限制圖片與素材說明一場 60 分鐘的週會，6 位同仁依序報告「上週做了什麼、這週準備做什麼」，最後卻沒有人確認跨部門卡住的資源、方案該選 A 或 B、誰要承擔下一步。問題通常不是會議沒有寫紀錄，而是議程沒有區分「單向告知」與「需要集體做決定」。
GitLab 的公開工作手冊主張會議要有清楚目的與共同可查的議程，決策後應記錄責任人、背景與後續行動；Atlassian 的 DACI 決策法則區分推動決策的人、核准的人、提供意見者及需知會者。S01S02 這些是公開的管理做法，不代表實行後就必然減少 50% 會議時間。
本文提供一組合成的「原始週會議程 → 新議程 → 決策與待辦」範例，另附 4 份可直接使用的 CSV。目的是讓主管下次週會就能辨識哪些事項應改為書面更新、哪些非同步即可處理、哪些必須拿到會議做決策。
先把每一項議程分成 3 種，而不是按部門排隊
| 類別 | 內容特徵 | 預設處理方式 |
|---|---|---|
| I：資訊同步 | 指標、已完成工作、沒有待決爭議 | 會前文件或非同步訊息；只保留異常 |
| A：協調／解除阻塞 | 跨人資源、權限或相互依賴 | 相關人員短時間會議，產生責任與期限 |
| D：需要決策 | 選項存在取捨、有人需核准、延遲有成本 | 進入決策議程，明列方案、理由與決策人 |
這個 I／A／D 分類是 TARAISG 為教學設計，不是 GitLab 或 Atlassian 的既有三分類標準。若涉及事故、敏感人事或法律議題，也不能因為要縮短會議而跳過必要的正式程序。
GitLab 文件指出，會議前需提供背景、目的與討論問題，並儘量以同一份文件作為單一資訊來源；其流程手冊也要求決策留下理由與執行責任。S01S03 這支持「將可事前閱讀的資訊放到會前」的做法，但不等於所有週會都應取消。
用 6 個議程示範：哪些根本不必進會議？
假設團隊在推進企業課程與網站內容，原週會有 6 件事：
- 本週已完成 5 篇文章上架：I，會前書面更新，附實際 URL 與驗收結果。
- 新客戶詢問數與已聯繫狀態：I，會前表格呈現，只有異常需討論。
- 企業內訓案例的去識別化審核缺少負責人：A，約定審核窗口及完成時點。
- 下一梯課程先做線上直播或實體場：D，列出兩種方案的限制、決策人和當天決策期限。
- 站內表單變更需要法務及業務確認：A，協調驗收範圍，不在會上直接跳過風險審核。
- 新視覺該選「單一主視覺模板」或「各篇獨立圖解」：D，先以讀者理解目標、製作成本與編輯一致性作決策條件。
這只是合成編輯案例，其中「文章已上架」等措辭是情境資料的一部分，並非本批 B002 真實完成紀錄。
若 I 類都有可讀資料，就把主要會議時間留給 A、D。原本一人輪流報告，改為每個決策項目先寫出「要決定的一句話」。例如：「是否先讓下週內訓採用合成案例，不等待尚未核准的客戶資料？」這比「內訓進度報告」更能推動行動。
決議與待辦，不能存在同一個模糊欄位
決議是一項經授權、可追溯的選擇；待辦是一項有人負責、能被驗收的工作。兩者互相連結，但不能用「同意方向」取代交付。
本文的合成決議 D-001：「下週企業內訓優先使用已審核合成案例，未授權客戶資料不得進入教材。核准角色為專案主管，理由是降低教材準備期間的資料外流風險，於 2026-10-23 前檢視。」
對應待辦 A-001：「教材負責人於 2026-10-22 交付 3 份合成資料與說明，驗收為欄位無可辨識真實個資、答案可重算、上課可離線使用」。
好的記錄至少要能回答：決定了什麼、為什麼、誰有權決定、什麼證據支撐、誰要交付、何時完成、如何確認完成。如果決策人沒出席，標記「待核准」而不是寫成已決議。
Atlassian 的 action item 指南也特別指出，應具備具名責任、具體動作、範圍、完成結果、期限及來源，才能讓會議內容轉成可追蹤工作。S04 本篇將「決議紀錄」與「行動台帳」拆成兩個可關聯表格，避免往後沒辦法追溯。
下週就能實作的 30 分鐘會議設計
這是一個建議排程，不是唯一正確時長：會前先更新 I 類內容；會議前 5 分鐘確認問題與缺件，中段 15 分鐘處理 D 類方案取捨，再用 8 分鐘排除 A 類跨部門阻塞，最後 2 分鐘由每位責任人複述承諾與驗收方式。若決議資訊不足，記錄誰在何時補證據，別為求當場有結論而猜測。
會後由指定記錄者補齊決議連結與 action item，隔天在共同文件內確認有無異議；下週開會先讀上週未結決議，而非讓每個人從零報告。需要持續探索、建立信任或處理複雜歧見的會議，不宜完全壓縮成純決策清單。
下載、核對與成效衡量
可先觀察 4 週：會議前資料準備率、進會議仍沒有必要決策材料的件數、逾期行動的原因、決議被重開的比例。不以開會分鐘數下降作唯一成功指標，否則可能只是把討論轉移到更分散的訊息往返。
延伸閱讀：企業 AI 內訓需求訪談 專注訓練前的工作需求澄清；本篇處理例行主管週會的決策結構。企業服務提案準備度 則處理業務收到詢問後的分流，可將其中待決事項帶入週會。本文不綁定單一付費課程。
來源與限制
[S01] GitLab Handbook〈All-Remote Meetings〉：https://handbook.gitlab.com/handbook/company/culture/all-remote/meetings/
[S02] Atlassian Team Playbook〈DACI〉：https://www.atlassian.com/team-playbook/plays/daci
[S03] GitLab Handbook〈Team processes〉：https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/tenant-scale/cells-infrastructure/process/
[S04] Atlassian〈How to turn meeting action items into trackable work〉：https://www.atlassian.com/work-management/project-collaboration/team-meetings/action-items
會議與團隊資料皆為虛構案例；建議時長與分類需按實際組織情況調整。
圖片與素材說明
封面：萊姆綠底三個節點代表會前告知、跨部門協調與正式決策。（教學概念或合成資料示例）
本文由 TARAISG（TIANDIREN AI SOLUTION GROUP）使用 AI 模型產生正文、整理來源並設計實務工具。方法依據與限制列於文末；案例為明確標示的教學假設。未有具名紀錄時，不宣稱經人工或專家審核。
查看內容製作與更正說明
