假設一家公司的資訊部門準備導入 AI 內部 Helpdesk。員工可以詢問軟體操作、查找使用規範，或了解權限申請流程。主管希望員工少等一點，也讓資訊人員騰出時間，處理更複雜的問題。

系統上線後，回覆變快了，自動處理的工單也增加了。但有些員工照著答案操作仍然失敗，最後私下找同事幫忙；有些工單雖然結案，同樣的問題卻隔天又出現。

看到這些情況，團隊可能需要修改回答、增加人工轉接，也可能發現，比起繼續擴充問答功能，員工更需要的是找到正確的支援窗口。

這裡有兩層決策：產品路線圖決定接下來要解決什麼問題，上線策略決定每項能力如何交給員工使用。團隊需要根據實際使用情況，調整這兩層的安排。

公司的工具會更新、流程會改變，員工也會用我們沒想到的方式使用產品。主管很難一開始就把所有事情想清楚，但可以讓團隊每做一步，都多一些依據來決定下一步。

控制理論中的「雙重控制」（Dual Control），可以幫助我們思考這件事。

雙重控制關注的是：選擇行動時，同時考慮它對任務的效果，以及它會帶來什麼資訊、這些資訊如何改善後續決策。預期能學到什麼，會影響我們現在選擇怎麼做。相關研究

例如，操作一台還不清楚其反應特性的設備時，控制者可能先做一次試探性的操作。它未必讓設備最快達到目標，卻可能幫助我們摸清設備的反應，讓後續操作更準確。取得資訊有成本，值不值得，得看它能幫助我們作出什麼決定。

借用這個思路，我們可以重新考慮 AI Helpdesk 的產品路線圖與上線策略。

產品路線圖：這次投入，要幫助我們決定下一步做什麼？

團隊一開始可能有幾個方向：讓員工更快找到可用答案、減少求助時來回補充資料的次數，或協助員工完成申請、查詢處理進度。

這些方向都合理，但資源有限，先做哪一個？

假設團隊決定先推出操作問答，讓員工能直接查詢常見問題。除了觀察答案是否正確，也可以留意員工拿到答案後，還需要什麼協助。這些資訊會影響團隊接下來要做的功能。

例如，團隊原本打算持續增加問答範圍，使用後卻發現，員工往往已經找到操作說明，只是不知道自己的狀況該交給誰處理。這時候，就有理由把工單分流排到前面，先解決找錯窗口的問題。

另一種情況是，員工求助時經常缺少設備、版本或錯誤訊息，資訊人員得反覆追問。下一步也許應該先讓 Helpdesk 協助收集背景資料，減少雙方來回確認的時間。

在產品路線圖這一層，借用雙重控制的思路，就是在選擇要做什麼時，也考慮這項投入能幫助團隊釐清什麼，讓下一筆資源花得更有依據。

路線圖上的項目因此可以附上一個待釐清的問題。推出操作問答，是要了解員工能否靠現有文件自行解決問題；改善工單分流，是要了解求助延誤有多少來自找錯窗口。結果不同，後面的優先順序就可能不同。

如果不論學到什麼，最後都得照原定順序把功能做完，這些資訊對產品決策的幫助就很有限。

上線策略：這次開放，要幫助我們判斷可以走多遠？

決定先做操作問答之後，還有另一組問題：先開放哪些內容、讓誰使用、何時轉交人工，以及什麼情況下可以擴大或必須暫停。

假設團隊先選擇文件完整、出錯後容易補救的軟體操作問題。試用期間，觀察 AI 是否會辨識員工的使用環境、引用適用版本的文件，以及員工能不能照著指引完成工作。

找誰試用，也會影響我們能知道多少。如果參與者都很熟悉 IT，他們可能自己補足答案裡缺少的步驟。即使試行順利，也還不知道一般員工能否順利操作。團隊可能需要先調整試用對象，再決定是否擴大開放。

這一層要弄清楚的是：在什麼條件下，這項能力能可靠地提供服務？

回覆速度與自動處理量仍然值得追蹤，但還得看員工是否完成原本的工作、同一問題是否反覆求助，以及轉交人工後需要多少補救。團隊應根據這些結果，調整開放範圍與運作方式。

例如，某類問題經常需要人工重做，就可以先縮小範圍；員工表示操作失敗時，應有清楚的轉接方式。至於權限申請，AI 能協助說明流程，不代表它已經適合直接核准權限。

雙重控制不保證每一步都同時增加成果與知識。保留人工檢查，可能增加處理時間；安排不同對象試用，也可能讓全面開放的日期往後移。主管要判斷，這些代價能不能換來有用的資訊，幫助團隊少做錯誤的決定。

所以，試行之前就應該說清楚：想釐清什麼、最多願意付出多少成本，以及哪些結果會讓我們擴大、修改或停止。「我們還在學習」還不足以解釋為什麼要繼續投入。

上線得到的回饋，也要能改變產品路線圖。

假設試行時發現，AI 經常引用過時的文件。上線策略可以先縮小回答範圍、增加人工檢查；產品路線圖則可能需要提前處理文件更新與版本辨識，延後原本安排的問答擴充。

兩層決策處理的問題不同，卻不能各做各的。現場發現問題後，需要有人判斷：調整目前的服務就夠了，還是連接下來要做什麼，都得重新考慮？

這也牽涉到主管如何安排決策權。

假設 Helpdesk 團隊已經發現某類回答經常誤導員工，想暫停自動回覆，卻必須經過好幾層批准。等待期間，同樣的問題仍然持續發生。又或者，團隊有權修正答案，卻無法調整路線圖上的優先順序，只能一邊補救，一邊繼續做原本排好的功能。

團隊知道出了什麼問題，卻改不了原本的安排。

《賦能：打造應對不確定性的敏捷團隊》強調，面對複雜環境，共享理解與授權執行需要一起建立。接近現場的人必須知道整體目標、事情的背景，以及自己的決定會影響哪些人，才有條件在取得決策權後作出適當判斷。（參考《賦能：打造應對不確定性的敏捷團隊》第十章〈應對不確定性的關鍵：賦能〉。）

回到 Helpdesk，主管要先讓團隊理解，導入這套系統是為了幫助員工順利工作。如果只要求提高自動結案率，團隊很可能忙著把工單結掉，卻沒注意到員工還卡在原來的問題上。

接著，主管要分別說清楚，在這兩層決策上，團隊能決定哪些事。

在上線策略上，團隊能否自行暫停有問題的回答、調整人工轉接條件，或改變試用範圍？哪些情況需要立即通報？

在產品路線圖上，當使用結果顯示原本的優先順序不合適，誰能決定調整？團隊要提供哪些依據？涉及跨部門資源時，又由誰協調？

不一定每件事都交給團隊決定，但團隊要知道哪些可以直接處理，哪些需要找誰決定，以及對方會在什麼時候回應。團隊有權調整 Helpdesk，也不等於 AI 本身取得了核准權限。

書中也談到，共享理解需要持續交換背景資訊。資料放進知識庫、結果出現在儀表板上，仍需要有人一起討論：為什麼出現這些問題？它是否也影響其他部門？原本的假設有沒有改變？（參考《賦能：打造應對不確定性的敏捷團隊》第八章〈培養共享意識〉。）

Helpdesk 的檢討會可以從幾張真實工單開始，讓資訊人員、使用部門與相關權責人一起了解問題。討論後，要決定目前的服務怎麼調整，也要檢查接下來的開發安排是否仍然合理。如果需要重新分配資源，就得有人負責處理。

雙重控制來自控制理論，《賦能》討論的是組織如何應對不確定性。本文借用雙重控制的思路來檢查管理決策，再用《賦能》的觀點思考團隊需要哪些資訊與權限，才能根據結果調整工作；這是本文提出的管理應用，不能直接當作已經證明適用所有企業的公式。

主管不必把每件例行工作都變成實驗。已經熟悉、結果穩定的任務，可以繼續提高效率；如果有些事情還不清楚，而且答案可能改變投入方向，就值得考慮花多少代價把它弄清楚。風險較高的操作，則可能需要先在測試環境或人工審核下驗證。

下一次討論 AI 導入計畫時，可以分開問：

• 看產品路線圖：這次交付能幫助我們判斷，下一個值得解決的問題是什麼？
• 看上線策略：這次使用結果能幫助我們判斷，接下來應該擴大、修改，還是暫停？

然後再問一個兩層都需要回答的問題：如果結果與預期不同，誰有權改變原本的安排？

AI 能幫團隊更快做出東西，主管也要讓團隊有時間檢查成果、有權修正做法，並能根據新資訊重新安排投入。公司的工具、流程與需求變了，產品要做什麼、如何上線，也得有機會跟著改。

作者簡介

范育銘是 Scrum Inc. 認證培訓師及台灣敏捷協會常務理事，曾陪伴不同規模的企業推動數位與組織轉型。我協助主管對齊目標、釐清決策邊界，建立回饋與協作機制，讓主管能放心授權，團隊也能承擔決策與成果責任。 我也持續在 WeAgile 分享組織變革與敏捷實務文章，並提供公開課、企業內訓及教練顧問服務，幫助企業把自組織與自管理，從理念轉化為真正能運作的管理能力。