想像一場已經用上 AI 的工作會議。散會後，摘要整理好了，待辦進了系統，每件事都有負責人和期限。
隔天，訊息陸續進來：客戶想調整交付順序，可以答應嗎？設計需要加購素材，可以支出嗎？原本排週五的工作，能不能挪到下週？
每個問題都不大，卻都在等同一個人回覆。老闆忙著開會，團隊只好先做別的事。到了下一次進度會議，有些待辦仍停在原地。
前一篇 AI 會議文章談的是如何把資訊交給負責人。接下來還有一個管理問題：這位負責人，究竟有權決定多少事？交辦時，工作內容與決策權限需要一起交代。
有了負責人，還要說清楚誰能拍板
把專案交給一位同事，可能包含很多不同的期待。有人負責蒐集資料，有人協調進度，有人決定怎麼做。若只寫一個名字，大家對這份責任的理解可能差很多。
老闆以為對方會自行推進，同事卻以為自己只能整理選項、等主管決定。尤其當價格、客戶關係或其他部門的安排牽涉其中，先問一句，是很合理的反應。此時可以先檢查，交辦當下有沒有把判斷範圍講清楚。
Atlassian 的 DACI 決策框架，把推進決策、最後拍板、提供意見與接收通知分成不同角色。這個區分很適合拿來檢查日常分工：負責把事情往前推的人，未必擁有最後決定權；需要提供意見的人，也不必每一位都核准。
小團隊可以先不套完整框架。每次交辦，多說清楚三件事就有幫助：誰做最後決定、決定前需要問誰、決定後要通知誰。同一件事若有多個主管參與，也要事先約定意見不同時由誰裁決，避免執行者逐一詢問，最後仍得回到老闆這裡。
從影響範圍與補救難度，決定授權到哪裡
授權可以從一類具體決策開始。例如先讓專案負責人安排內部工作順序，再觀察他如何處理交期衝突。這比一次交出整個專案的所有決定，更容易看清楚需要補哪些資訊與能力。
Amazon 在決策方法中區分容易回復與難以回復的決定，讓兩者採用不同的處理速度與層級。這個觀點提供了一個實用起點：做錯後能不能改回來，會影響適合交出去的決策空間。
拿到自己的團隊裡，還可以一起看三件事：最多會花掉多少資源、會影響哪些人，以及負責人是否具備判斷所需的資訊。更換內部簡報順序通常容易補救，答應客戶提前交付則可能牽動整組人的排程。兩者即使都沒有新增支出，也需要不同的權限。
以下是一張可供調整的授權示意表。實際範圍應依公司的專案規模、人員經驗與既有制度設定。
| 決策事項 | 可以自行決定的範圍 | 需要先請示的情況 | 回報方式 |
|---|---|---|---|
| 內部工作排序 | 在既定人力與交付期限內調整 | 影響其他專案，或必須改變對外交期 | 更新排程並通知受影響同事 |
| 例行採購 | 核定預算、品項與供應商範圍內 | 超出總額、改換關鍵規格，或產生持續付費承諾 | 留下用途、金額與憑證 |
| 客戶需求調整 | 已約定服務範圍內，不增加費用與工期 | 增加交付項目、折扣，或改變驗收條件 | 將確認結果記入專案紀錄 |
預算上限也要有明確口徑。單筆上限之外，還要看同一專案的累計金額；一次小額訂閱，也可能帶來長期支出。條件交代得越具體，雙方越容易判斷何時可以往前走。
授權要連同目標、資訊與回報時間一起交出去
有權限，還需要有能力使用它。讓同事自行決定採購，卻看不到剩餘預算；讓業務協調客戶需求，卻不知道交付團隊已經滿載，都會讓判斷變得困難。授權前，主管需要確認對方拿得到哪些資訊，也找得到必要的協作窗口。
目標的優先順序同樣重要。這次要優先守住交期、控制成本，還是保留客戶測試的彈性？當幾個目標無法同時滿足，團隊需要知道取捨原則。只交代完成日期，遇到衝突時仍得重新請示。
以內部排程為例，一段完整的授權可以這樣寫。以下為示意：
這週由專案負責人安排製作順序，目標是週五交出已約定的版本。可以在現有人力內調整順序，週三更新一次進度；如果預估會延後交付、需要借用其他專案人力，或客戶新增交付項目，請在對外承諾前找主管確認。
這段話同時交代了結果、可動用的資源、回報時間與例外條件。主管不必逐項核准排序，同事也知道什麼時候需要停下來討論。若還不熟悉工作，可以先縮小授權範圍，陪他完成幾次判斷，再逐步放寬。
前一篇 AI 會議文章保留了對外承諾的人工確認。這裡可以再把那個人寫清楚：由具有相應權限的業務、專案負責人或主管確認。AI 協助整理現況與提醒待辦，核准權限則由公司事先決定。
例外需要一條找得到人、等得到答案的路
授權表無法預先列出每一種情況。客戶臨時改需求、供應商延遲、不同部門搶同一段工時，都可能超出原本範圍。因此，授權時也要安排例外由誰接手，以及原主管不在時可以找誰。
團隊提出請示時，可以一起帶上目前發生的事、可行選項、各自影響，以及自己建議採取的做法。主管比較容易掌握取捨，也能從建議裡看見同事如何判斷。若情況緊急、資訊尚未齊全，應先通報已知影響，再補資料，避免為了整理完整而延誤處理。
請示還需要一個最晚決定時間。例如客戶下午需要答覆，就要說清楚何時之前必須拿到內部決定。主管若無法即時處理，應轉給約定的代理人。超出權限的承諾，在尚未核准前先保留；既有授權內的工作則可以繼續。
這些約定能讓回報更有用。一般進度照固定節奏更新，超出範圍的事情即時提出。團隊逐漸學會辨認例外，主管也能把注意力留給需要共同取捨的地方。
主管怎麼回應，會決定團隊下次敢不敢做主
授權之後，主管看到的做法可能和自己不同。只要仍符合約定目標與限制，可以先讓負責人把事情做完，再討論結果。若每次都因為順序、用字或個人習慣而改回來，同事很容易把先請示當成最穩妥的工作方式。
結果不如預期時，可以回頭看當時掌握的資訊、採用的理由，以及有沒有及時回報例外。判斷有依據、過程符合約定，仍可能遇到不好的結果；偶然得到好結果，也不能直接證明做法值得重複。檢討時把這幾件事分開，才知道要補資訊、練判斷，還是修改權限。
主管如果在過程中發現新的風險，當然可以介入，但需要說明是哪個條件改變了，以及這次介入是否影響往後的授權。讓團隊看得懂改變的原因，下一次才能沿用新的判斷方式。
可以先選一種經常發生的決策，試行兩週，記錄等待核准的時間、超出權限的次數，以及返工原因。兩週是方便啟動的建議週期，發生頻率低的工作需要拉長觀察。若等待減少、品質仍符合要求，就有依據討論下一步；若同一個邊界反覆被問到，則把那條規則補清楚。
結語：讓團隊有條件做出負責任的決定
建立授權方式，可以從下次交辦多問一句開始：這件事，對方能自己決定到哪裡？把可做的決定、需要的資訊與請示條件寫下來，再透過實際工作修正。
老闆仍然需要設定方向、分配資源，也要承擔培養團隊的責任。當現場的人能在清楚的範圍內做主，主管便能把時間用在跨部門取捨、長期安排，以及團隊尚未有能力處理的問題。
授權的根本目的，是讓組織具備持續判斷與行動的能力。每一次說清楚界線、檢視決定、修正原則，都是在把個人的經驗變成團隊可以使用的方法。
好的授權，讓負責的人知道何時可以往前走，也知道何時需要找人一起決定。
延伸閱讀
團隊已經有人負責，日常決策卻仍需要你逐一確認嗎？可以帶著最近幾件反覆請示的工作，和納許一起整理分工、決策權限與回報方式，找出適合先交出去的範圍。
參考資料
- Atlassian：DACI 決策分工框架，對應決策角色與拍板責任。
- AWS：Amazon 的決策方式，對應決策的可回復性與處理層級。
