「主管，這兩件事哪個先做？」

「客戶臨時提出需求，我們要先接嗎？」

「另一個部門還沒有回覆，可以請你幫忙協調嗎？」

很多主管不是不想授權。他已經說過好幾次：「你們可以自己判斷，不用每件事都問我。」但團隊碰到優先順序、臨時需求或跨部門衝突，最後還是會回來等他決定。

主管一忙，工作就停；主管一出差，訊息就堆著。他原本想把時間留給策略、人才和長期問題，最後卻整天在回答零碎問題。

看到這種情況，主管很容易懷疑：是不是團隊不夠主動？是不是大家不願意承擔責任？

但團隊一直來問，也可能是因為他們少了做決定需要的條件。目標、排序理由、權限和協調方式都在主管手上，大家遇到問題時，當然只能找主管。

主管若想擺脫這些日常請示，光說「你們自己決定」還不夠。他得先建立一套工作方式，讓團隊知道四件事：根據什麼判斷、誰能作決定、什麼時候調整，以及遇到例外時該怎麼找人幫忙。

先別急著怪團隊，看看決策卡在哪裡

主管大概都碰過這種情況：兩件工作同時出現，團隊明明比主管更了解現場，卻還是問「哪一件先做？」

主管直接給答案，眼前的問題確實解決了。團隊也同時學到一件事：遇到衝突時，把選擇交給主管最快，也最安全。

幾次下來，就會形成一個循環：

團隊遇到衝突 → 主管直接給答案 → 團隊少了一次練習取捨的機會 → 下次繼續問主管

把決策權往下移，只是第一步。團隊還需要以下四項安排，才能接得住這些決定。

一、把取捨依據從主管腦中拿出來

團隊要自己決定，得先知道公司現在最在意什麼結果。

假設團隊面前有兩件事：修正新客戶無法付款的問題，以及完成業務答應本週展示的新功能。如果主管心中最重要的目標是「提高新客戶完成第一次下單的比例」，答案可能很明顯。但這個目標沒有說清楚時，兩件事各自都有道理，團隊只好請主管裁決。

因此，主管不能只交付一張工作清單，還要和團隊談清楚：

• 這段時間最想改變的結果是什麼？
• 服務哪些客戶或使用情境？
• 看到哪些證據，表示我們正在靠近目標？
• 當時間、品質和範圍互相衝突時，優先保護什麼？

共同目標不能只是牆上的口號。兩個合理選項撞在一起時，團隊要能拿它來作取捨。

工作排序也要讓人看得懂。團隊除了知道第一名、第二名、第三名，還要理解背後的價值、時機、風險和相依性。只公布順序，等於只給答案；情況一變，大家仍然得回來找主管。

二、事先約定誰能決定，以及用什麼方式決定

團隊就算知道目標，也可能還是不敢作決定。「你們自己決定」這句話，留下了太多模糊空間。

他們可以直接決定嗎？要先問過誰？需要全體同意嗎？主管只是想知道，還是得由主管批准？如果結果不好，主管會支持原本的授權，還是事後追問「這件事怎麼沒有先問我」？

這些問題可以提前說好。常見的決策方式大致有四種：

• 負責人自行決定並告知：適合影響範圍小、容易修正，而且負責人掌握足夠資訊的事情。
• 徵詢相關人員後，由負責人決定：適合需要專業意見，但仍要有人承擔最後選擇的事情。
• 團隊共同決定：適合影響所有成員、需要共同承諾，或事後很難逆轉的事情。
• 升級由主管決定：適合超出預算、策略、法規、安全或重大聲譽風險的事情。

每種方式都有適合的情況。討論開始前，大家要知道這次由誰決定、其他人怎麼參與，以及遇到什麼情況要升級。

主管也要分清楚「知情」和「核准」。如果團隊每次告知之後都得停下來等同意，資訊透明很快又會變回逐案請示。

三、讓常見決策跟著固定節奏發生

很多組織有不少會議，卻沒有說清楚每場會議要處理什麼決定。

有人想到問題就臨時找主管，主管再把相關人員一個個叫來。同一組優先順序一週談了好幾次，進度也要等主管追問才更新。所有事情都靠主管往前推，主管自然會變成整套工作方式的瓶頸。

比較穩定的做法，是替不同層次的決策安排固定時間。例如：

• 每隔一段短週期，確認接下來要達成的成果，並選擇最有助於這個成果的工作。
• 每天由實際執行的人看一次現況，調整當天的合作方式和工作順序。
• 定期檢視已完成的成果和外部回饋，決定下一段時間要維持、停止或改變什麼。
• 定期回顧工作和決策方式，修正權限、流程與合作規則。

固定節奏不代表所有問題都得等到開會再處理。它提供的是一個大家都知道的時間點：什麼問題在這裡談、誰要參與，會議結束前又要決定什麼。

常見問題有了固定的處理時間，主管不用一直催，團隊也不必為每次變動臨時召集一群人。

四、讓工作狀態主動觸發下一步

固定節奏適合處理週期性的取捨，現場還是會碰到不能等到下次會議的狀況。這時候，拉式工作就派得上用場。

所謂拉式，是團隊有能力承接時，依共同排序主動拿取下一項工作。工作卡住了，也由當事人按照約定，找進需要的協助。主管不用看到誰有空，就趕快把另一件事塞過去。

要做到這件事，團隊至少要看得見：

• 現在有哪些工作正在進行；
• 哪些工作已經準備好，可以被承接；
• 團隊目前還有沒有處理能力；
• 什麼狀態代表工作受阻；
• 卡多久或影響多大時，需要找誰協助；
• 哪些情況已經超出團隊的決策範圍。

例如，新需求出現時，不用立刻插進每個人的手上。先把它放進共同的工作清單，按照原本的方式評估價值和時機；團隊有容量時，再依排序拉進來。如果它涉及重大客訴或法規風險，就依事先約定的例外規則立刻升級。

主管不必再負責推動每一件工作。他要做的是說清楚目標、邊界和例外，並在團隊確實需要時幫忙排除障礙。

這四項安排，可以怎麼放進日常工作？

要降低決策瓶頸，光有一張授權表不夠，多開幾場會也不會自然改善。目標、工作排序、角色責任、固定節奏和日常調整，得放在同一套工作方式裡。

Scrum 正好提供了這樣的基本框架。

在 Scrum 中，Product Goal 說明產品下一個重要方向；每一個短週期再建立 Sprint Goal，讓團隊知道眼前要完成或驗證什麼成果。Product Backlog 則把可能創造價值的工作排成一份透明、持續更新的清單。

有了這些資訊，團隊就有共同的判斷依據。不過，Scrum 並沒有把所有事情都交給所有人決定。Product Owner 對產品價值和 Product Backlog 的排序負責；Developers 決定如何安排 Sprint 內的工作，並隨進展更新 Sprint Backlog。產品價值和執行方法，各自有清楚的負責人。

Scrum 也替重要決策安排了固定節奏：

• Sprint Planning 確認這段時間的目標，並形成初步工作計畫；
• Daily Scrum 讓 Developers 每天依現況調整計畫；
• Sprint Review 用實際成果和利害關係人的回饋，調整下一步方向；
• Sprint Retrospective 檢查合作與工作方式，決定下一段時間怎麼改善。

Product Backlog Refinement 則讓團隊持續釐清產品方向、需求、價值、風險和相依性，減少工作開始後才臨時追問 Product Owner 或主管。

如果團隊還需要更清楚的拉式工作方式，可以在 Scrum 中加入看板做法：把工作流程畫出來、限制同時進行的工作數量，團隊有容量時再拉取下一項工作。

如果只是把專案切成幾週、照表開幾場會議，Scrum 發揮不了作用。它要處理的是：誰來決定、根據什麼資訊、何時調整，以及各自負責哪些事情。這些問題有了固定做法，團隊就不用每次碰到事情再重新討論一次。

導入 Scrum 不代表授權會自動發生。主管如果仍然越過 Product Owner 重排工作、在 Sprint 中直接指定 Developers 的做法，或者把所有透明資訊都拿來逐項核准，決策最後還是會回到主管手上。Scrum 提供了做法，主管也得把相應的決策權交出去。

主管不在時，你的團隊能決定多少？

回看最近兩週，找出幾個曾經回到你手上的決定，再用下面四個問題檢查團隊現況：

1. 有共同判斷依據嗎？團隊知道這段時間最重要的成果，也說得出取捨理由嗎？
2. 決策權和決策方式清楚嗎？大家知道哪些事能自行決定、哪些要徵詢，以及什麼情況才需要升級嗎？
3. 決策有固定節奏嗎？常見的選擇和調整有固定的處理時間，還是每次都等主管發起？
4. 工作能自己往前走嗎？團隊有容量或遇到障礙時，知道如何主動承接、協調和求助嗎？

只要其中一題的答案是否定的，團隊一直來問就不奇怪。那一題，就是目前最需要補上的地方。

主管想放手，不能只少回答幾個問題。他要改變的是「每一個決定都由我發起和批准」的工作方式。團隊有共同目標、清楚權責、固定節奏和拉式機制，主管才能離開日常決策，轉而把時間花在設計和改善這套系統上。

參考資料

• Dhaval Panchal，〈Decide How You Decide〉。本文用來整理自行決定、諮詢、共同決定與升級等決策方式。
• Tim Casasola，〈How Your Organization Can Make Great Decisions By Default〉。本文用來說明如何把透明協作、行動會議與反思變成預設工作方式。
• Roman Pichler，〈Sustainable Pace in Product Management〉。本文用來說明共同管理 Product Backlog、分享決策工作與建立固定策略節奏。
• Scrum Patterns Group，〈Sprint Goal〉、〈Product Backlog〉、〈Developer-Ordered Work Plan〉與〈Autonomous Team〉。本文用來說明目標、產品排序、開發工作安排與團隊自主之間的關係。
• Yuval Yeret，〈Understanding the Kanban Guide for Scrum Teams〉。本文用來說明 Scrum 與看板結合時的視覺化、限制在製品與拉動模式。
• Ken Schwaber、Jeff Sutherland，〈The 2020 Scrum Guide〉。本文對 Scrum 的角色責任、目標、工件與事件的說明以此為正式定義。

作者簡介

范育銘是 Scrum Inc. 認證培訓師及台灣敏捷協會常務理事，曾陪伴不同規模的企業推動數位與組織轉型。我協助主管對齊目標、釐清決策邊界，建立回饋與協作機制，讓主管能放心授權，團隊也能承擔決策與成果責任。

我也持續在 WeAgile 分享組織變革與敏捷實務文章，並提供公開課、企業內訓及教練顧問服務，幫助企業把自組織與自管理，從理念轉化為真正能運作的管理能力。